Re: JOBD analysis

On 08 May 2013 08:50, Vern Hamberg wrote:

There's a reason that we don't get an Output File (OUTFILE) option
for some DSP* commands, I think - the very issue Joel wants to
address - it's difficult to get some things into a single output
file.

Of course there is _no reason_ a DSPJOBD OUTPUT(*OUTFILE) feature could not have effected a sufficiently long CHAR field for its INLLIBL data much like the RTVJOBA does for its USRLIBL() return value parameter. Other model database files offer data in that fashion, or instead as multiple fields of smaller CHAR lengths, versus making their output data more relational in nature via multiple files.

There is also no reason the OS could not have offered an effective "Output Files" (OUTFILES) implementation to define multiple output files to resolve such situations; similar to OUTFILE in consistency across multiple commands. There is at least one command RTVDIRINF which does, offering an effect of two output files to provide the output data in a more appropriately /relational/ manner, using its own private means of defining a "prefix" versus allowing the user to name the output files explicitly, and using messages to identify the files that were created by the feature.

Thus there is also no reason the OS should not have had something like the following; albeit the OS eventually offered the Retrieve Job Description Information (QWDRJOBD) API in v2r2, so anyone could write their own:

DSPJOBD *ALL/*ALL OUTPUT(*RELDBF)
RELDBF((QTEMP/JOBDLIST THEMBR) (QTEMP/JOBDLIBL THEMBR))
MBROPT(*REPLACE)

The first element of RELDBF would identify the file for the output of Job Description details specific to the *JOBD object; i.e. the values for the parameters from the CRTJOBD, other than the INLLIBL. The second element would identify the file for the output of the list of library names from the INLLIBL specification. The first file could even have its own INLLIBL column to define the "single value" of *NONE or *SYSVAL from the Change or Create Job Description, and record something like *INLLIBL to indicate that redirection to the other file is required to obtain the actual list of library names [if deemed more appropriate to have no rows for the second output file when either of those special\single values had been specified on the INLLIBL]. Whether the request should use the qualified name or instead another unique value [i.e. an effective or actual identity column] would be up for a design discussion... but any possible issues for a MBROPT(*ADD) capability would have to be well defined.