Wouldn't a better approach when designing the OS - to address the "root cause" of the problem - be as follows:
Have a JOBD entity, and have a LIBL entity, and NOT try to combine them into one entity?
Then JOBD could point to a LIBL, which would contain individual libraries.
It seems so obvious doesn't it - in hindsight? Especially since the default when SBMJOB is run is to IGNORE the LIBL portion of the JOBD anyways!!!
BTW why is the default of SBMJOB to ignore the LIBL? That seems a bit counter-intuitive doesn't it?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, May 08, 2013 12:47 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.
midrange.com
