> -----Original Message----- > From: Vernooy, C.P. - SPLXM [mailto:[EMAIL PROTECTED] > Sent: Friday, May 18, 2007 3:51 AM > To: [email protected] > Subject: Re: Date & Time in JCL > > "Robert Bardos" <[EMAIL PROTECTED]> wrote in message > news:<[EMAIL PROTECTED]>... > <Snipped> > > Naive idea: why not provide system symbols for all of these > > (submission time, conversion time, execution time)? SYSSTIME, > > SYSCTIME, SYSETIME? > > > > Robert > > > > Of which system? Jobs can travel through serveral systems in an NJE > network, submitted on system1, converted on system2 executed on system3, > each with their own timesettings. Dataset1 gets timestamp 10:00, the > *next* dataset2 can get timestamp 09:10 if created 10 minutes after > dataset1. Quite confusing.
OK, I haven't ever contributed to this long-running debate, so here's my USD$0.02 worth: Let the customer decide what they want: SYSTMSG Time, Submit, GMT SYSTMSL Time, Submit, Local SYSTMCG Time, Convert, GMT SYSTMCL Time, Convert, Local SYSTMEG Time, Execute, GMT SYSTMEL Time, Execute, Local And the same kind of set for Date of course (SYSDTSG etc.). GMT's could be suffixed "U" for "Universal" or "Z" for "Zulu" instead of "G", I don't really care as long as the functionality is the same. 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. So, you would NOT use the following example in your JCL to create a dataset to be used later in the same job: //DDNAME DD DISP=(,CATLG),DSN=MYUSERID.MYDATA.D&SYSEDTG..T&SYSETMG,... Instead, you would code it like this: // SET MYDATE=&SYSEDTG,MYTIME=&SYSETMG //DDNAME DD DISP=(,CATLG),DSN=MYUSERID.MYDATA.D&MYDATE..T&MYTIME,... And then later in the job you could code: //DDNAME DD DISP=SHR,DSN=MYUSERID.MYDATA.D&MYDATE..T&MYTIME with no ambiguity at all. As for RESTARTed jobs, well I don't know the rule for whether SET statements are re-executed on a restart or not. If the SET's are bypassed, RESTART is probably not possible. In which case, it's like the old vaudeville routine, "Patient: Doctor, Doctor it hurts when I do that! Doctor: Don't do that!". I also just realized why people think there would be a JOB-related storage need, to carry along Submit and Convert dates/times. But wait -- why wouldn't Convert and Submit simply replace the text of the symbol name with the text value at that point in time? Then subsequent steps (Convert and Execute after Submit, Execute after Convert) would see only constant text, not a variable. Only Execute symbols would be "always live" and always changing. And if you need RESTARTability, don't use Execute-time symbols. Is that enough specification to make it viable? 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
