Just want to emphasize a point already made. Unless the user actually issues the command "SUB a.b.c(jcl-mem)" the submit exit will not know the original data set. In fact, you can be ISPF-editing a job member, type SUB on the command line, and exit without saving. In other words, there may never be a physical file that contains the JCL as submitted.
It's possible to substitute your own code for the ISPF submit command. Your code could be a Rexx that captures the currently edited data set name and inserts it as a comment. Quite a bit of trouble to handle a subset of all job submittals. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lizette Koehler Sent: Tuesday, December 15, 2015 09:54 AM To: [email protected] Subject: [Bulk] Re: JES2 - originating jcl For the TSO exit IKJEFF10 or IKJEFF53 there might be something in SYS1.SAMPLIB. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Sumi, Joseph J. (CMS/CTR) (CTR) > Sent: Tuesday, December 15, 2015 9:02 AM > To: [email protected] > Subject: Re: JES2 - originating jcl > > Thanks, we will investigate TSO submitted jobs and also check with the > Thruput Manager folks. > > > Rgrds, Joseph Sumi > > > > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Vernooij, CP (ITOPT1) - KLM > Sent: Tuesday, December 15, 2015 10:03 AM > To: [email protected] > Subject: Re: JES2 - originating jcl > > We do so in TSO submitted jobs and so do some schedulers and > applications submitting jobs. > But the original question was: does JES2 know and then the answer is simply: > NO. > > Kees. > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of John McKown > Sent: 15 December, 2015 15:58 > To: [email protected] > Subject: Re: JES2 - originating jcl > > Oh, in the below, I forgot to mention that I once had an IKJEFF10 (TSO > SUBMIT) exit which modified the submitted JCL. But the modifications > were generated from a data area created by the ISPF SUBMIT command (another > exit). > So, if you wanted to put in a JCL statement such as: > > //*SUBMITTED FROM .... BY .... ON yyyy-mm-ddThh:mm:ssZ > > (replace trailing Z with appropriate local time indicator, such as: -06:00 > for U.S. > Central Standard. > > This is not for the faint of heart. And I don't have the source any more. > That was 20+ years ago at a shop which no longer exists. > > On Tue, Dec 15, 2015 at 8:52 AM, John McKown > <[email protected]> > wrote: > > > On Tue, Dec 15, 2015 at 8:41 AM, Sumi, Joseph J. (CMS/CTR) (CTR) < > > [email protected]> wrote: > > > >> Hello, is there a JES2 exit that will allow us to place the dataset > >> and member name of the job that was submitted ? The originating > >> dataset/member would be added as a comment to the JESLOG, MESSAGES, > >> or JCL. I would assume > >> JES2 would know where the JCL came from but not sure. > >> > > > > No, it doesn't really. In most cases, the JCL is coming in from a > > "reader" of some sort (local, NJE, RJE, or _most likely today_ the > > internal reader: INTRDR). > > > > In all cases other than the INTRDR case, there is no DSN involved at all. > > And JES2 does know the origin and writes it in SMF. E.g. R1.RD1 for > > a card reader attached to "remote 1". If anybody use RJE any more. > > > > In the INTRDR case, the JCL is simply written out like it would be > > to a normal data set, most likely using QSAM or maybe BSAM. JES2 has > > no idea where the program doing the writing is getting it from. > > There might not even be a "data set", such as in the case of a CLIST > > doing a SUBMIT * command (JCL is in-line). Also, keep in mind that > > if someone is in ISPF EDIT and does a SUBMIT command, that command > > actually writes the contents of the edit buffer to an ISPF > > "temporary" (.CNTL) data sets, so even if > > JES2 somehow knew that DSN, it wouldn't help you with the DSN/MEMBER > > which was actually submitted by the ISPF SUBMIT edit command. > > > > > > > >> > >> Rgrds, Joseph Sumi > > John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
