Re: JOBD analysis

On 09 May 2013 08:28, Stone, Joel wrote:

First: I am not suggesting breaking JOBD and LIBL, I simply don't
understand why they were bundled together way back when. They don't
seem to have much to do with each other except for the fact that they
are sometimes used simultaneously.

In its inception, the Job Description defined most everything about the initiation of a job. Thus the term Initial Library List (kwd INLLIBL) instead of what might more appropriately be called the User [portion of the] Library List (kwd LIBL on CHGLIBL; SpcVal *USRLIBL for resolving). Realize that the JOBD() specification is what defines /work/ on the system under subsystems, irrespective the existence of any SBMJOB command\feature. Since every unit of work requires a library list, that *JOBD object was a logical choice for storing the LIBL. Every other feature providing the definition of work need not specify both a JOBD and a LIBL. And while admittedly the same ability to name just the JOBD could be had by assigning some redirection to a *LIBLST object for its INLLIBL, the tight coupling established, may have been intended to ensure the more static effect; i.e. as compared to the dynamic effect which would occur from changes to a *LIBLST object shared across multiple *JOBD objects.

IBM bundled them together, but then sets the default on SBMJOB to
ignore the LIBL associated with the JOBD (and use the current LIBL
instead). It seems backwards. Like a double negative.

The Job Description and SBMJOB came from the System/38, where, in a prior message, I described that [AFaIK] the effect was INLLIBL(*JOBD) for the Submit Job request. That same capability is available, just not by default; by either CHGCMDDFT or explicitly specifying INLLIBL(*JOBD). Note that other features such as BCHJOB, ADDPJE, and ADDAJE all use the INLLIBL from the *JOBD.

<<SNIP>>
It seems that the protocol here is to NOT thank people in general,
although I do oftentimes thank people via the list or privately.

Replies with mere trivialities like "Thank you" are useless clutter in the archives. Especially worthless, if such a followup message is not also giving a summary or closure to the thread by saying something like "Doing x, y, and z is the method I chose to effect resolution to my original issue involving a, b, and c". And totally worthless if the reply is a top-post for which the replied-to message is preceded with the "-- <crlf>", the End of Message (EOM) marker; i.e. loss of attribution and text, so neither who nor what is being acknowledged are capable of being inferred without some very visual and accurate threading... which the archives do not necessarily provide [well].

Yes I agree that asking "why doesn't IBM have their own RTVJOBD
command" is a good question. But also wasted energy. I am guessing
that this has been a lacking feature since s/38 days 30+ years ago
and is not on anyone's radar at IBM to address.

Correct. To submit a DCR on the matter will surely be fruitless.

There is an API, so anyone could create their own RTVJOBD to effect the same; or just use the API directly. The answer from IBM to a DCR will be that the /function is already available/ with features already provided with the OS. And they should respond that way. Plus, the community has already provided the capability with effective open-source.

It seems that maybe the cardinal rule of "don't use repeating fields"
was broken with the JOBD/LIBL definition and has made it a bit
difficult for IBM to provide the tools to report JOBDs.

If designed as stored data in database files instead of separate object types, then likely more emphasis would have been on ensuring the separation. As /objects/ there is not so much concern; i.e. no rule so paramount. As retrieved information, the retrieved data can be stored in as normalized form as anyone wishes; without a DSPJOBD supporting an output file, the OS has no cares for how one wishes to use the data to which the access is provided via the API.

Although the archaic single-level library structure in OS400 makes
it a tough sell too (compared to every other OS today which has
unlimited level "libraries").

There is a directory structure and PATH capabilities if you want to work in a similar realm to what /every other OS/ offers as their only and limited world-view. By doing that, the limitations for /QSYS.LIB are access to executable /program/ objects and data, and other objects are restricted to the /applications/ to which they are owned... similar to /every other OS today/ [except they do not protect their /files/ from access by unsupported methods]. But with IBM i OS there is also this entirely different realm available with its own path capability, the /Library List/ for the job and the integrity of the object and data ensured per the /object type/ being supported only for the specific set of methods as defined and enabled by the OS.