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. > > Barbara > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. 111,111,111 x 111,111,111 = 12,345,678,987,654,321 Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
