Peter Farley said:
SYSTMEG Time, Execute, GMT SYSTMEL Time, Execute, Local ======== 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.
Despite being an aviator, I like "G" more than "Z" in this context
because it connotes G-global versus L-local.
From: "Farley, Peter x23353" <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU>
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Date & Time in JCL
Date: Fri, 18 May 2007 10:42:32 -0400
> -----Original Message-----
> From: Vernooy, C.P. - SPLXM [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 18, 2007 3:51 AM
> To: IBM-MAIN@BAMA.UA.EDU
> 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
_________________________________________________________________
Catch suspicious messages before you open themwith Windows Live Hotmail.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_protection_0507
----------------------------------------------------------------------
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
