In general I've found Giovanni's code to be pretty solid. His style is a lot different from mine, but it's good code. Without having looked at the ENDJOBS code, I'll guess he's used the List Jobs (QUSLJOB) API, and probably also the Retrieve Job Information (QUSRJOBI) API, both of which were no doubt mentioned in your original thread.

If you decide to roll your own:

• First choice should almost always be an API, if one is available and it's not too complicated.
• Next choice should be OUTPUT(*OUTFILE). Either there's no API, or the API is complicated and an equivalent outfile exists (and would be much faster to code).
• Last choice would be OUPTUT(*PRINT) followed by CVTSPLF  and reading the resultant file. Before there were outfiles on many of the display commands (which were before most of the APIs), this was your only choice. Biggest problem with *PRINT is it's not upwards compatible; new release of OS, or even a PTF apply, can break your code.

Last I checked (a few years ago), he doesn't manage service program signatures very well. if you install a new version of one of his tools and don't recompile your programs, they blow up with a signature violation. Would be nice if he used a named signature instead of letting the system create one. Or maybe he is now, not sure.

Chris Ringer

The problem I used to have with the *OUTFILE solution, is that between releases there was frequently addition of new fields to the outfile, which would typically blow out the processing program on a level check. My solution was to create a temporary (use for compile) version of the outfile, and then crtdupobj to QTEMP and use that as a basis for the retrieve command, the command was smart enough to ignore the missing fields, and my program didn't need to be recompiled (and also didn't care about the new fields in the latest release outfile).

But all these hassles encouraged me to move to API's. Especially since my job used to be to fix everyone elses errors at OS upgrade for when they used OUTFILE as a solution.