>> 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.
Nothing gets "inserted". Try to think about it from another point of view: You want to submit a job. One way to do it is by starting an ISPF EDIT session, then write the JCL for your job, and finally issue "submit". If you let aside that "submit" can generate a job statement for you, the minimum JCL you need to write is a JOB and an EXEC statement. This is what the START command used to do before Started Job support was introduced with MVE/ESA 5.2 (I believe). START built a JOB and an EXEC statement to invoke the JCL procedure specified on the start command. This job was then processed by either the master or primary (or any other) subsystem. As of MVS/ESA 5.2 START will do some processing *before* the step described above: It looks if the member specified is found in one of its "JCL" library concatenations (IEFJOBS, IEFPDSI), and if found, if this is a JCL starting with a JOB statement. If the first statement is *not* a JOB statement, START reverts back to the processing describe above. However, if it *is* a JOB statement, the content of this very member is then read and handed over to the master or primary (or any other) subsystem. In either case, the subsystem is not adding to nor modifying the JCL received. There is nothing you can do to change this behaviour, I knew of. These are just the rules. Place your "Started Jobs" JCL in one of the libraries in the IEFJOBS or IEFPDSI concatenations. This is the only place "JOBs" are accepted, even it they are to run under the primary JES. There is nothing that forbids a JCL (procedure) library to be in the IEFJOBS, the IEFPDSI as well as in one or more JES PROC concatenations. >> 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. Yes, it is true. The case you describe is *not* supported. Full stop. >> 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. Well, yes I can agree that the behaviour is different in the case you describe: It the behaviour of a supported versus an unsupported case. Why don't you simply add the membet ot a library already in IEFJOBS or IEFPDSI concatenation? Alternatively, add that library to one of these concatenations. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
