Re: Why does my RPG program compile twice?

Craig, we do a CRTSQLxxxI OPTION(*NOGEN) TOSRCFILE(QSQL) to put the source 
into QTEMP in a file we know about. Then we have a CRTxxx (module, in this 
case) that uses the generated source member. These are encapsulated in a 
single program. That way, you don't lose the link to a job's QTEMP.

As you suggest, you could have the generated source go to a regular library 
of your choice, then have your compile use that. But then that intermediate 
source has to be leaned up - of course, it'd be replaced all the time, maybe.

With the first approach, so long as you leave the spooled output where it 
is, the STRCODE job or whatever can probably find it. Just a guess on my 
part, however, haven't tried it. We do all our SQL stuff in builds and with 
little programs on the system, not through CODE.

At 02:08 PM 8/29/2003 -0500, you wrote:

>Okay.  I think I know more about what happens during SQL compiles.  Thanks
>Vern, that helps.  I looked over the manual "SQL Programming with Host
>Languages" at the section "Preparing and Running a Program wiht SQL".
>Can't start change until the problem is understood :)
>I looked at the QTEMP member and it had QSQROUTE, QSQLCLSE, QSQLOPEN like
>you mentioned.  Also inserted were the full copybooks.  The compile listing
>in my spool referenced this QTEMP member.  I also found the TOSRCFILE
>parameter containing QTEMP and QSQLTEMP1 on the CRTSQLRPGI as you mentioned
>as well.  I agree that saving this intermediate source to a permanent
>library would give better handling of the errors.  Two main reasons:
>1. Batch compiles can only view members outside of QTEMP after the job
>ends.
>2. There are times when CODE sees members in QTEMP after a batch compile
>but these can be old.  For example, member is compiled interactive creates
>member in QTEMP.  Fixes an error.  You decide to compile in batch this
>time.  Error will be back because you would see the member in QTEMP from
>the interactive compile.  Very bad.  This can trick you into thinking you
>are seeing the current member.
>
>I am thinking the best way to fix an error is to look at the generated
>member and make the change in the original member.
>Maybe the best two options are:
>1. Have a permanent library just for SQL precompiles and specify that on
>all compiles.  Then match up changes to original using the intermediate
>member.
>or 2. Just skip *EVENTF and do the traditional match up from the compile
>listing on the iSeries.
>Any suggestions?
>
>I don't think there is anything CODE can do to change unless SQL changes.
>That stinks.  Someone mentioned not making errors.  Yeah, we wouldn't have
>to worry about anything if we didn't make errors.  :)
>
>Thanks,
>Craig Strong


_______________________________________________
This is the CODE/400 Discussion & Support (CODE400-L) mailing list
To post a message email: CODE400-L-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/code400-l
or email: CODE400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/code400-l.

NOTE: WDSc for iSeries disucssion has it's own mailing list.
Information can be found at http://lists.midrange.com/cgi-bin/listinfo/wdsc-l