Re: Why does my RPG program compile twice? -- CODE400-L

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