On Fri, 18 May 2007 12:31:48 -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 > The difference is that the initiator performs no job-scope ENQ on those generated DSNs, while it does perform a job-scope ENQ on DSNs explicitly supplied by the programmer. One consequence is that it's possible for a job to fail (it doesn't wait at that point) because another holds an ENQ on a generated DSN.
>> 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? > I suspect the designers noticed the behavior as implemented is somehow irregular and difficult to specify. Rather than attempting a specification, they simply prohibited the usage. But that doesn't excuse failure to report as error a programmer's using the prohibited construct -- that's just negligence worse than that they wish to avoid by prohibiting system symbols in batch JCL. -- gil ---------------------------------------------------------------------- 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
