On Tue, 15 Dec 2015 11:57:25 -0800, Skip Robinson wrote: >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. > And many editors, ISPF and XEDIT being conspicuous exceptions, allow a user to begin an edit session without specifying a file name and defer that choice until SAVE. vi under z/OS UNIX is one example. In such cases, the JCL exists only in main storage, never as a persistent file.
I also submit many jobs via FTP; there's a file, but it's pretty far away. >It's possible to substitute your own code for the ISPF submit command. Your >code could be a Rexx ... > I have such; I use it primarily to escape the dreadful Fixed-80 burden. TSO SUBMIT ought to do likewise -- allocate INTRDR with attributes of the data set submitted. >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. > But it doesn't do that. However I keep a significant amount of JCL as here-documents in shell scripts. Self-tailoring -- allows incorporating current date and time in data set names. Lizette had a good idea; I'll go further. Couple a code control system with a scheduler. Most shops discourage submitting production jobs from uncontrolled data sets. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
