Re: Open List of Job Log Messages (QGYOLJBL) API

On 05-May-2014 09:57 -0500, Zachary Johnson wrote:

The problem I am facing here is that I would have to know the library
list at the time the message was issued to be able to figure out
where to look for the program library information. The library list
could have changed during the execution of the job or the program
could even have been run from QRPLOBJ for example. I am implementing
the QGYOLJBL API as an SQL UDTF to be able to quickly research a job
log for an active job. The results of QGYOLJBL still provides lots
of good information but having the library would kind of save a step.
Now I can find the message I am looking for but I then have to go to
the actual job log to figure out the library information.

Of course not all invocations are made via the library list, so even knowing the library list or a means to match the library list of the job from which messages are being listed, is of little help.

Short of asking for an enhancement to that API, to request the program library name be presented as optional additional information [optional being key, not just due to additional work impacts, but because the information is potentially transient especially with regard to the library list], probably using that API is not the best choice to achieve the described requirements. What is the library name for the programs is mostly just a guess outside of stasis, no matter whether requested from outside the job or even from a synchronous list request run inside the job itself. Even what the OS joblog presents can be ridiculously /wrong/ with regard to the library name [even the program name] due to renames and moves. That is because the OS just shows the name materialized from the pointer obtained upon the run-time listing request; i.e. the materialized names from the pointer are not stored statically from the moment the message was issued, they are obtained only when the message is retrieved in the joblog message listing request. The OS really should have always [and would be improved by eventually having] implemented a static copy of the information for used in production of joblog message lists.

There is the Call Job Interrupt Program (QWCJBITP) API that can effect running code within another job, which would allow the information from the synchronously built list to be used as input to a request to find the name of the library for a particular program name within that job. But just as with the OS, the results are not necessarily going to be accurate for the same reasons [moves and renames]; consider: the reference to QRPLOBJ is a classic example whereby the alluded requirements would never be met, because even asking what is MYPROGRAM in *LIBL is not going to reveal that the program is\was in the QRPLOBJ library, just as asking the same question of a prior invocation that had logged a message via a copy of MYPROGRAM that was in a library not included in the current\past *LIBL.