Re: Date & Time in JCL

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" <Peter.Farley@xxxxxxxxxxxx>
Reply-To: IBM Mainframe Discussion List <IBM-MAIN@xxxxxxxxxxx>
To: IBM-MAIN@xxxxxxxxxxx
Subject: Re: Date & Time in JCL
Date: Fri, 18 May 2007 10:42:32 -0400

> -----Original Message-----
> From: Vernooy, C.P. - SPLXM [mailto:Kees.Vernooy@xxxxxxxxxxxx
> Sent: Friday, May 18, 2007 3:51 AM
> To: IBM-MAIN@xxxxxxxxxxx
> Subject: Re: Date & Time in JCL
>
> "Robert Bardos" <bardos2@xxxxxxxxxxxx> wrote in message
> news:<JHEEIGIGFPGACEGDPJMGGEFNJIAA.bardos2@xxxxxxxx>...
> <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 them?with 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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.