>> Rexx covers this by guaranteeing that if a single clause contains (any number of) references to TIME() and DATE() the TOD clock will be read only once and that value used for all. The TIME macro should nave no need to read the TOD clock more than once.
Paul, If that is the definition of the midnight pitfall, then DFSORT already covers that. If you used DFSORT date formats (Date1 thru Date5 ), DFSORT reads the TIME macro once and stores the value. It is not changed in between despite how many times you have the references of Date parm in your control cards. Thanks, Kolusu DFSORT Development IBM Corporation From: Paul Gilmartin <[email protected]> To: [email protected] Date: 09/13/2016 09:26 AM Subject: Re: DFSORT - ICETOOL - Search for text and replace with date Sent by: IBM Mainframe Discussion List <[email protected]> On Tue, 13 Sep 2016 09:06:28 -0700, Sri h Kolusu wrote: >>> You could consider: //SYSUT1 DD *,SYMBOLS= instead of ICETOOL and >substitute the dynamic system symbols for &YYMMDD and &HHMMSS, however: > >What exactly is the midnight pitfall? If you used the LOCAL system symbols >then you would get the local time. DFSORT also has several date formats >and it is based on the time the step ran. > It's probably covered, depending on how "the time the step ran" is obtained. >If you meant that a job that started at 11:59:59 PM and the SORT step ran >at 00:00:10 then we would get the next date as SORT would not have any >idea about when the Job started. > The pitfall, however narrow, is that if midnight occurs between the evaluations of &YYMMDD and &HHMMSS the composite value may be in error by (almost) 24 hours. Rexx covers this by guaranteeing that if a single clause contains (any number of) references to TIME() and DATE() the TOD clock will be read only once and that value used for all. The TIME macro should nave no need to read the TOD clock more than once. UNIX time() function returns a single raw RTC value and provides functions to format that. I suppose that if processors are fast enough that the gap, accumulated over the expected life of all installed z/OS systems, meets a six sigma criterion it's not worth concern. Has anyone done the calculation? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
