Re: Why does my RPG program compile twice?

Thanks for more insight Vern.  I think I understand now.
Now that I have been using SQL more often, I have come up with a better
(and hopefully complete) list of how to check for errors more easily when
using SQL.  Maybe doing a "Verify" would work best (still not ideal).
Options for error-checking SQLRPGLE source members (e.g. CRTSQLRPGI) in
CODE in order of simpleness as I see it:
1. Use CODE Verifier.  This will verify and xref against the original
source member but errors about undefined SQL variables need to be skpped.
In some instances, can take longer than straight compiling when uncached
and still need to actually compile if no errors.
2. Compile interactively and use the QTEMP member to compare with the
original source member for fixing errors.  Can get confusing if you forget
which member you should be changing.  For this reason alone, this
suggestion is bumped to #2.  Still close to #1 though.
3. If you must compile in batch, use *CURLIB for the TGTSRCFILE library
parm on the CRTSQLRPGI and make sure QSQLTEMP1 source file exists in the
current library.  The current library should be set as the development
library as defined for STRCODE.  Use the generated member for
error-checking and matching against the original source member.
4. Use the spool generated on the iSeries to match the errors in the
original source member in CODE.
5. Do a CRTBNDRPG on the original source member.  This will error-check the
SQL statements though and those will show as errors.  This makes
error-checking very difficult and is therefore at the very bottom.

What does IBM recommend for error-checking SQLRPGLE in CODE?  Would it be
possible that compiling SQLRPGLE might change in the future and therefore
the relationship to CODE?

Thanks again,
Craig Strong

** Craig wrote earlier <snip>:
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.

_______________________________________________
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