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.

This mailing list archive is Copyright 1997-2015 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 here. If you have questions about this, please contact