> Nice summary, Peter.
Thanks > Do you happen to know who puts in //STARTING JOB ... when MEMBER is only > contained in the JES2 proclib concatenation and not in MSTJCL? You probably mean //STARTING EXEC ... not //STARTING JOB, do you? 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? > I have a MEMBER that starts with a JOB statement in a proclib. As long as > that proclib is in both MSTJCL and JES2 proclib concat, all is well. As soon > as I remove the proclib containing MEMBER from MSTJCL, I get a //STARTING JOB > ... in my JCL and of course a JCL error because my JCL already contains a JOB > statement. MEMBER is started task JCL and gets started either using ASCRE or > a regular START command. 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. 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. On the other hand, *if* a lookup is required to resolve either a PROC or an INCLUDE, then either IEFPDSI *or* PROCxx will be searched, depending on whether the job runs under MSTR or JESx, resp. > I am assuming that it is JES2 that puts these extraneous two lines in. 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. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
