> -----Original Message----- > From: Paul Gilmartin [mailto:[EMAIL PROTECTED] > Sent: Friday, May 18, 2007 11:24 AM > To: [email protected] > Subject: Re: Date & Time in JCL > > On Fri, 18 May 2007 10:42:32 -0400, Farley, Peter x23353 wrote: > > > >Let the customer decide what they want: > > > >SYSTMEG Time, Execute, GMT > >SYSTMEL Time, Execute, Local > > > But that's a more significant change. I suspect symbolic substitution > is performed at only one step in the job flow, prior to the availability > of the execution time values.
But this is no different than DSN=&TEMP (where &TEMP is not set to any value at the time the JCL is translated) generating a DSN in the "standard" temporary format, e.g. SYS07137.T154733.RA000.MYJOBNAM.MYDDNAME.H01 At least ISTM it is not different in principle. > And, at what point in the flow must data set names be fixed for ENQs and > JES3 scheduling? Now that's a good question, and no doubt a possible argument for not providing execution-time symbols. Worth discussing at length in the functional design meeting. > I'd be pleased enough to have only the submission or conversion (whichever > is more practical) values. GMT, of course. Agreed, either one would be sufficient to most users' needs. Personally I would be happy to have just submission-time symbols, but my needs are not everyone's needs. > >And to reply to another poster's objection, these are NOT JOB-saved > >values. They are "live" when-used values maintained at the system level > >only. If you the user want the same value later in the JCL, then save it > >in a SET variable of your own. > > > Complicateder and complicateder. So would SETs involving conversion time > symbols need to be elaborated at conversion time, SETs involving execution > time symbols need to be elaborated at execution time, etc. But of course they would. That's the idea of providing different symbols for different stages of a job. Whether or not that idea is practical or not is a different issue. Again, worthy of serious discussion at the functional design meeting. > BTW, the JCL RM appears to prohibit using symbols in SET statements, > though the statement is ambiguous and appears to be entirely unenforced. By testing, I see that "// SET var=value" CAN be used inside of a PROC. Inside of a PROC, the PROC symbols can be used pretty much anywhere, so why not as the value in a SET assignment? And if PROC variables can be used, why not system symbols as well? The following JCL translates and executes just fine on z/OS v1.6 after you substitute your own job card: //MYUSERID JOB (...) //PROC1 PROC FIRST=ONE //EXEC1 EXEC PGM=IEFBR14 //EXEC1DD1 DD DUMMY // SET NEXT=&FIRST //EXEC2 EXEC PGM=IEFBR14,PARM='&NEXT' //EXEC2DD1 DD DUMMY //* // PEND //* //PROC2 PROC FIRST=ONE //EXEC1 EXEC PGM=IEFBR14 //EXEC1DD1 DD DUMMY // SET NEXT=&FIRST //EXEC2 EXEC PGM=IEFBR14,PARM='&NEXT' //EXEC2DD1 DD DUMMY //* //EXEC3 EXEC PROC1,FIRST=TWO //* // PEND //* //EXECJCL EXEC PROC2 //* Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
