> I really am at a loss on this entire thread as to why the originator simply > didn't use a started JOB instead of a started task
That originator would be me. The reason would be that I have no access to one of the magic libraries that permits the use of a JOB statement for a started task/job. Could I get access? Quite possibly, but I have learned that one possesses a finite number of brownie points and should expend them judiciously. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Friday, December 26, 2014 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AW: //STARTING JOB ... On Fri, Dec 26, 2014 at 8:19 AM, ibmmain <nitz-...@gmx.net> wrote: > > You probably mean //STARTING EXEC ... not //STARTING JOB, do you? > I am on vacation right now and cannot test. I know that two lines are > inserted, one of them is a JOB card, the other an EXEC statement. Both > are input by forces outside of my control (since I haven't found what > to tweak to make it stop). > > > Well, again, I can only tell from what is my understanding and > experience. I don't have insight into the code. That said, I think > this is just the way the start command processor builds the EXEC > statement. Why does it matter? > Because the exact same, untouched JCL (already containing a JOB > statement) gets an additional JOB card resulting in a JCL error if the > library it comes from is only in a JES2 proclib concatenation, NOT in > MSTJCLxx. > > > I tried to describe that "jobs" are supported only if they are > > present > in either IEFJOBS or IEFPDSI of MSTJCLxx. This is true even if the job > is to be started under a JES. The START command processor reads the > JCL from IEFJOBS or IEFPDSI and "submits" it. > That is not quite true. Once the JCL already containing a JOB > statement is not contained in MSTJCLxx (only in the JES2 proclib > concatenation), the automatic insertion of these two lines (by whatever) > causes a JCL error. > > > Suppose such a job is "complete", i.e. it does *not* reference any > > PROCs > nor does it have any INCLUDE to resolve. In this case no further > lookup neither in IEFPDSI nor in PROCxx is due. > I am NOT concerned with any JCLLIB, since my JCL does not have any > includes at all. I am irked by the JCL error due to an extraneaous > JOB statemment 'helpfully' inserted by whomever which causes the STC > to not start with a JCL error. > > > No, as I wrote, it is the START command processor that builds these > > two > statements. It is my understanding that the way those statements are > build is not different whether they're gonna be sent to the MSTR or to > a JESx subsystem. > Implicit in any START command is 'SUB=JESx' (that's the default). > Exception is if the MEMBER name is equal to an existing subsystem. In > that case, the default in the start command is SUB=MSTR. My start > command is ALWAYS issued with implicit SUB=JES2. Behaviour is > different if the JCL is NOT contained in MSTJCL, only in JES2 proclib. > > Does anyone else know where this insertion of the two lines is explained? > And/or if this insertion can be turned off via parameter? This is even > hard to test, because removing the proclib containing the JCL from > MSTJCL costs an IPL. And my ADCD system is not even set up to use > dynamic JES2 proclib (something else to put on the to-do list). Of > course, in my case, I could just delete the already available JOB > statement, but I want to know *why* it is inserted and if that insertion can > be turned off. > I am not aware of any documentation of this "feature" because it is like not meant to be "messed with" by anyone other than IBM. IBM does not supply PLMs any more and so "how it works" is not really documented to us. However, I will blather on anyway on the subject. In regards to the START command with SUB=JESx, in the "master JCL" (member MSTJCL00 in SYS1.LINKLIB unless overridden), you will see both an //STCINRDR DD SYSOUT=(A,INTRDR) and a similar one for //TSOINRDR. These are the "commutications pipelines" used by the z/OS console START command processor and the LOGON command processor to submit JCL to the JES system for conversion and intepretation before being used by a type of "initiator" which does a "select by jobid" JES function to actually start the address spaces which run the started task (START command) or the TSO user session (LOGON command). Now, JES expects a job to consist of a single JOB card followed by one or more EXEC cards. So, for START, the module IEEVSTAR in SYS1.LINKLIB, builds a JOB card, an EXEC card, and a //IEFPROC.IEFRDER (optional?) and "submits" this to JES via the //STCINRDR. The JOB card template exists in the IEEVSTAR module. That is where this "phantom" JOB card comes from. If you want to make your own JOB card for some reason, then you simply _MUST_ use a STARTED JOB instead of a STARTED TASK. In this case, you have the full facilities of a "batch" job available to the started job. You can have a custom JOB card, use the JCLLIB to point to a private PROCLIB, use // SET, basically it is a batch job submitted to a dedicated initiator via a START command. Well, that's how I conceptualize it. I really am at a loss on this entire thread as to why the originator simply didn't use a started JOB instead of a started task. Unless, of course, he is simply not permitted to. And, that again, is a _management_ decision. There are a _lot_ of those that I don't agree with. But, in the last analysis, on the company machine, I do what the company representative (my management) tells me too. I had a big argument, many years ago, when I was not permitted to make _any_ changes to SYS1.PARMLIB without managerial approval. And they enforced it by using a TSS (Top Secret) rule which stopped me dead if I tried (which I didn't). So, if a problem occurred at night or on the week end which required a PARMLIB update, I had to call management to call the TSS person to give me update authority or the system was just not available. Once I learned that was acceptable and I didn't get chewed out for the delay, I no longer really cared. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
