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
