Version 7.1 still has *CURRENT as the default - I think that the help text always reflects what is factory. Joel, maybe you could prompt SBMJOB, put cursor on the INLLIBL parameter, and see which value is underlined - that is the default value. If YOUR default is different, someone ran CHGCMDDFT, as Dan suggests.
----- Original Message -----
I'm confused. The default behavior of SBMJOB is to copy the library list from the job that executes the SBMJOB. At least it was so at V5R4 which is the most convenient OS I have to check at the moment. The options for INLLIBL are *CURRENT, *JOBD, *SYSVAL or *NONE. I suppose you could construe *NONE as meaning to ignore the library list. That is the default behavior only if you CHGCMDDFT on SBMJOB. Has this changed in later releases?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Wednesday, May 08, 2013 3:22 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: JOBD analysis
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.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
________________________________________________________________________
This inbound email has been scanned for all viruses by the MessageLabs SkyScan service.
________________________________________________________________________
______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit
http://www.symanteccloud.com ______________________________________________________________________
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
