Barbara, did you (or someone else) modify/activate the TSO/E submit exit (IKJEFF10), or the JES2 exits (HASPX02, HASPX20) ? TSO will try to generate a JCL card, when no valid JOB card is found. Described in TSO/E customization guide. Christian
-----Ursprüngliche Nachricht----- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von ibmmain Gesendet: Freitag, 26. Dezember 2014 15:19 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: AW: //STARTING JOB ... > 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. Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
