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

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

At 12:03 PM 8/29/2003 -0500, you wrote:

I am having this SQL RPGLE problem too, I was just never bothered by it
enough to mention it until now.  I cannot link to fields from the compile
listing for the SQL RPGLE.  I tried CRTSQLRPGI with DBGVIEW(*SOURCE) and
OPTION(*EVENTF) and then with DBGVIEW(*NONE) and OPTION(*EVENTF).  I think
that answers one of the previous questions.  The last discussion on this
topic on this thread ended with PTF SI06000 and SI06922 already installed
on our system.  These were supposed to do with debug/eventf.  These are
still installed on our system and we are still having the problem.  We are
still running V5R2 and WDSC 5.0.1.
When I execute the CRTSQLRPGI with OPTION(*EVENTF) and there is an error in
the source, in all cases, the following happens after the compile listing
shows up and I click the field in error:
1. A box pops up that says, "Object not found QSQLTEMP1".  EVF2062 RC=291
on top.  I click OK.  Then
2. "Unexpected error opening file '<OS400>QTEMP/QSQLTEMP1(<mbr>)'" appears
at the bottom of the compile listing.

The field appears under '<OS400>QTEMP/QSQLTEMP1(<mbr>)' even though that
member exists in a different library and source file.
My guess is that CODE/400 is reading a different QTEMP than used to create
the object in batch.  Why should it be using QTEMP in the first place?
I then developed a theory that if I compiled interactively I would be able
to get to the member in QTEMP.
Sure enough, I compiled interactively and when I clicked on the field in
error on the compile listing, the QTEMP member opened in CODE and I was
taken to the error.  I think doing this interactively is as worthless as
batch anyway.  Why would you want to edit a member in QTEMP?  At least you
can see the error.
I think the problem is the fact that the member is copied to QTEMP behing
the scenes and compiled from there.  Why does it do that and can we get
around this problem?  I am getting into writing more and more SQL RPGLE
programs but not being able to get to errors quickly is a big hinderance to
using CODE with SQL.  Especially when it is one of my top reasons for using
CODE.  Also, especially when IBM is pushing SQL.  Does SQL RPG have the
same problems?  I usually don't write in RPG III but I will probably run
into quite a bit of legacy SQL RPG code soon.

Thanks,
Craig Strong