Make sure that you are not compiling the module (in the CL) into the QTEMP library. This was a problem I was having, I could not get back a compile list if the IBM compiler was outputting the module into QTEMP (even if a resulting *PGM or *SRVPGM went into a real library.)

I worked around the problem by changing my custom compile command to build modules in a regular library instead of QTEMP, and all worked nicely.

On 6/5/2014 3:08 PM, x y wrote:
My use of a custom compile command (apparently) breaks the error message
retrieval/insertion process.

When I compile using an IBM command (CRTBNDRPG, CRTSQLRPGI, etc.), the
error list gets pulled from EVFEVENT and the errors are inserted, all
expected behaviors.

I used a generic object create command (with *EVENTF specified) in RDi 8.5
and I'd get the errors back. But on RDi 9.0 and 9.1, and with the same
command, I'm not getting my errors back, The job log shows the results but
the error list isn't refreshed--in fact, the previous list isn't even
cleared. EVFEVENT shows the same number of records for a given compile
regardless of the compile command (my object build or the naked IBM
command).

Using Work with Compile Commands, I set up a tailored version of CRTSQLRPGI
and got errors back. The same command string in a stand-alone CL program
executed from the the list of compile commands failed to retrieve the
errors. So, it appears the compile part is okay: the object is created
when the compile is successful and the EVFEVENT member has the
warnings/errors. That leads me to think that the message retrieval
behavior is triggered by receiving a message or checking the status of an
object (message queue or data area?).

I'm stumped and would appreciate any suggestions.

Thank you!


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].