Re: JOBD analysis

On 08 May 2013 08:18, Gary Thompson wrote:

Agreed, the API is the better solution, especially for long term
and flexible use. However, dspjobd jobd(x) outfile(*print) does,
here in mudville, include the lib list.

When a /programmed/ solution is desirable, versus just an impromptu review of one or a few of something that can be viewed as a spool file, *always* choose an API over the spooled output. Especially if the display request can not effect the "generic*" name specifications to obtain and view many on one request; such as with the DSPJOBD, which lacks a *ALL and a generic for both the library name and the object name of the QUALified JOBD() parameter.

The spooling interface should be avoided...

Foremost because the spooled output is subject to change, likely every release for any headings [with V#R#M#] along with the layout due to enhancements, but they also change between languages thus diminishing potential usefulness to anyone not sharing the same installed release and language option; i.e. daft to have to write a separate solution for each additional release and\or language being used.

Additionally because of the generally probable much larger /cost/ for using spool files. If the OP really wants "all job descriptions", then that is potentially a huge amount of work in terms of open PRTF, open DB spool member, clear, write, plus a large amount of temporary addresses. The QPRTJOBD does not allow overrides, the DSPJOBD data can not be redirected to a database file [although perhaps via CHGSYSLIBL that effect is possible], but that can potentially reduce the overall costs as compared with spooling [although possibly still plagued by either or both layout and release\language difference issues].