Barbara, Peter says "the JOB and EXEC statements are built by the START command processor."
If we could solve your problem we could also solve mine presumably. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ibmmain Sent: Sunday, December 21, 2014 8:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: //STARTING JOB ... was: Re: JCLLIB in started proc? > The START command processor needs to build and "initiate" some JCL to start what was requested. The JCL will be sent to a subsystem that is able to process that JCL. The Master Subsystem (MSTR) and the Job Entry Subsystems 2 (JES2) and 3 (JES3) are the ones I know. > The first operand of the START command is shown as "membername" in the System Command reference. For brevity, I name it "MEMBER" hereafter. > In order to build the JCL, the START command processor performs the following steps: > 1) Search for MEMBER in the data sets allocated under IEFJOBS in the master scheduler JCL. If found, this member *must* contain a job, i.e. it must start with a JOB statement. > 1a) If it does, this JCL is used in step 4) below. Continue with step 4). > 1b) If it does not, an error is returned and processing ends. > 2) Search for MEMBER in the data sets allocated under IEFPDSI in the master scheduler JCL. > 2a) If found and if the member contains a job, i.e. it starts with a JOB statement, this JCL is used in step 4) below. Continue with step 4). > 2b) If found but the member does *not* start with a JOB statement, it is ignored. Continue with step 3). > 3) Build a job to invoke MEMBER as JCL procedure, i.e. build a JOB statement and an EXEC PROC=MEMBER statement. Continue with step 4). > 4) Send the JCL found or built in steps 1) - 3) to the subsystem for processing. The subsystem is the primary JES by default, or the one named on SUB=, if specified. Exception: If MEMBER is the name of a subsystem (IEFSSNxx), then the default subsystem is MSTR. > 5) START command processing ends. > > After this point, the *subsystem* has to process the JCL. If that requires the resolution of JCL procedures or JCL INCLUDEs, the only source for this is the "procedure library" of the subsystem. > - If the subsystem is the Master Subsystem, then the only "procedure library" is the set of data sets allocated under IEFPDSI in the master scheduler JCL. > - If the subsystem is one of the JESs, then the only "procedure library" is the set of data sets allocated under the PROCnn (nn is the set assigned to STC jobclass in JES). Nice summary, Peter. Do you happen to know who puts in //STARTING JOB ... when MEMBER is only contained in the JES2 proclib concatenation and not in MSTJCL? 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 am assuming that it is JES2 that puts these extraneous two lines in. I was unable to find any parameter that I could tweak to NOT put them in. I didn't even find the place where this behaviour is described. Happens on both z/OS 1.13 and 2.1. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
