Re: JOBD analysis

On 08 May 2013 13:22, Stone, Joel wrote:

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?

A distinct object type for the Job Description and a Library list is an interesting idea, but I do not agree that a /better approach/ is necessarily a given. The library list has different portions for which addition consideration is likely necessary, and a *JOBD is used for many more things than just SBMJOB. The *JOBD currently only supports setting the USR portion, leaving each of the SYS, CUR, and PRD undefined. Might a second list of elements on the redirection from the INLLIBL parameter indicate which portions of the [henceforth referred to as the non-existent] *LIBLST object should be inherited for the job? So for example:
CHGJOBD aJobD INLLIBL(*LIBLST) LIBLST(aLib/aLibLstObj (*USR *SYS))

And what of priority\override for resolving conflicts with other means of establishing those other portions of the *LIBL. If the *SBSD has a SYSLIBL entry, is the subsystem the arbiter because its entry must be honored... or must the OS guess which one should be first and which should be second? AFaIK that particular issue has already been resolved for SBMJOB SYSLIBL(); I do not know the effect, but presume the value from the Subsystem Description just goes above whatever is requested on the submit.

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?

For ever that I can recall, the SBMJOB command default for each of the /library list/ related parameters [each of SYSLIBL, INLLIBL, and CURLIB] has been *CURRENT to reflect the setting from the job issuing the request. That is very convenient for use from interactive jobs. Like the CL stream statement [pseudo-command] //BCHJOB, the System/38 was more JobD-centric for establishing the attributes for the submitted job; IIRC the /library list/ did come from the *JOBD. This document [if authorized. I am not; I am often amazed at what IBM sometimes protects, offering only to BPs <ugh>] implies as such:
http://www.ibm.com/support/docview.wss?crawler=1&uid=nas1ba244e768edbe2d1862565c2007d2b41

The following scanned\image document may have the details for what the S/38 did; a doc capable of being searched ¿per OCR?, but that hangs my client system:
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/system38/SC21-7730-0_System_38_Control_Program_Facility_Programmers_Guide_Jan79.pdf

Here is a message warning about incorrect /assumptions/ about what the defaults are; e.g. what is default INLLIBL on /my/ system vs the defaults on another system where the code with the /assumption/ might be run:
http://archive.midrange.com/midrange-l/201206/msg00465.html