(Thanks for the inline comments. It makes it easier to reply.)
On Thu, 3 Mar 2022 03:35:14 +0000, Sri h Kolusu wrote:
>
>>/* ... SYSINI DD * generated here??
>
>No. /( (Slash followed asterisk does not generate SYSIN
>
My experience has been that when I code "/*" (usually inadvertently,
intending "//*") I get a message like:
//SYSIN DD * Generated statement.
>>>Also, is there a hazard that if the job runs at midnight (or any lesser
>boundary) the date may be obtained before midnight; the time the
>next day, resulting in a DATE.TIME almost 24 hours too small?
>
>If we schedule the job to run 1 min past (01,16,31,46) then we wouldn't have a
>problem.
>
That relies on an assumption that the converter will not lose
dispatchability for 15 seconds to a higher priority task. Such
assumptions should be researched and documented. Largely,
I dislike relying on timing to resolve races.
>So within 1 minute you would have 4 runs and within an hour you would have 240
>runs and within a day(24 hours) you would have 5,760 runs.
>
>IMHO 15 second interval is too small and I am not sure what the final goal is
>as he would be creating thousands of dataset within a day. Someone has to look
>up and do some analysis.
>
Good point. How about a single data set:
//SORTOUT DD DISP=(MOD,CATLG),...
>>>Rexx handles this right. I suspect that JCL does not.
>
>I don't think we need REXX in here
>
I didn't intend to advocate Rexx, but to urge remedy of the
system DATE-TIME inconsistency hazard with Rex as an
exemplar. But I have built JCL with Rexx or shell scripts
such as:
TZ=GMT0 date '+//SORTOUT DD DSN=&SYSUID..CPU.Y%y.M%m.D%d.H%H.M%M.S%S,'
--
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
