Re: Why does my RPG program compile twice?

[email protected]
Newsgroups gmane.comp.systems.as400.code
Message-ID <OFACCA5843.AC41B96D-ON05256D91.00662D41@dekko-1>



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

** Vern wrote:
Embedded SQL involves a pre-compiler that converts the "exec sql" specs
into calls to the QSQROUTE program, I think. Some program, anyway. The
resulting source is put into QTEMP of the job that does the pre-compile.
That source is then used to actually create the program. And that is why
you see all these references to QTEMP.

it is possible to tell the system to save that intermediate source, then
compile from it later. This'd give you better handling of the errors, I
believe.

Check the "Using host languages with SQL" manual for details on what the
pre-compiler does. I don't think I have the title exactly right.

HTH

Vern

_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.