Re: Date Time in JCL
In [EMAIL PROTECTED], on 05/17/2007 at 12:30 PM, Mark Steely [EMAIL PROTECTED] said: I believe the answer is no and that's what I told the customer, but I will ask any way. Is there a way to dynamically add the current date and time to a dataset through JCL ? We are z/OS V1R7. There is no direct way; various posters have mentioned indirect ways. My preference would be to use a scheduling package or ISPF File Tailoring. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Date Time in JCL
Mine does, what do you have that does not? On Fri, 18 May 2007 08:06:43 -0600, Howard Brazee [EMAIL PROTECTED] wrote: Our whole computing infrastructure should migrate to GMT, at least internally. -- 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
Re: Date Time in JCL
On Sat, 19 May 2007 08:49:50 -0500, Kenneth E Tomiak wrote: Mine does, what do you have that does not? internally is fine, but what about the programming interfaces? o What is substituted for the dynamic system symbol HHMMSS? Is there a corresponding form for the GMT value? (Wouldn't it be great to be able to: // SET TZ=PST7PDT and then have HHMMSS reflect that time zone convention? Guess where I got that idea?) o Does Rexx even yet have a form of the time() and date() functions that return GMT? (Note that date(), believe it or not, is sensitive to the time zone, even though there's no date zone. I have encountered systems that didn't account for this.) What about COBOL? PL/I? HLASM's SYSTIME (whatever) preset symbol? C is the big winner here (but z/OS's C preprocessor still gets it wrong. IBM rejected my ETR on this.) o Suppose a customer has systems in several time zones. (Can this be done among LPARs on a single system?) Can SYSLOG, for convenience be set to display timestamps in GMT without setting LOCAL=GMT? o And one submitter described a problem here within the last couple years: His site is in the eastern hemisphere, running a legacy TOD=LOCAL. They can tolerate neither the timestamp ambiguity that would result from precipitously seting TOD=GMT, nor the several hours' shutdown which would be required to avoid the ambiguity. o Distantly related: I believe that z/VM and Linux for z/Series are still leap second incompetent (a consequence of being Sysplex Timer incompetent?) When we were running with leap seconds enabled, all our VM LPARs and their z/OS guests were 20+ seconds fast. I believe we abandoned leap seconds for this reason. On Fri, 18 May 2007 08:06:43 -0600, Howard Brazee wrote: Our whole computing infrastructure should migrate to GMT, at least internally. -- gil -- 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
Re: Date Time in JCL
On Sat, 19 May 2007 09:46:23 -0500, Paul Gilmartin wrote: On Sat, 19 May 2007 08:49:50 -0500, Kenneth E Tomiak wrote: o [ concerning time zone choice ] C is the big winner here (but z/OS's C preprocessor still gets it wrong. IBM rejected my ETR on this.) I'll stand somewhat corrected on this. I retested, and c89 -E now works correctly, presumably in consequence of: APAR Identifier .. PK17058 Last Changed 06/02/02 FROM USS THE COMPILER SHOULD RESPECT THE TZ ENVIRONMENT VARIABLE. Symptom .. IN INCORROUT Status ... CLOSED PER Severity ... 3 Date Closed . 05/12/20 Why does the C compiler run as a POSIX(OFF) application? But when I reported the problem 5 years earlier, I encountered considerable resistance from support, likely as a result of the POSIX(OFF) entanglements. It wound up with: = [ IBM ] -565512101 - 01/06/22-13:30- Hi Paul, Just checking if this is something you are still interested in pursuing at this time. I will go ahead and inform the development team of the problem demonstrated in my previous example. It will be something we will look into for a future release unless we've missed the mark on the problem or impact. Will keep the record open for another week pending your feedback. Thanks, ... - [ gil ] -565512101 - 01/06/29-16:06- RESPOND ELECTRONICALLY: c89TZ (User Keyword). Hello, FIN certainly seems appropriate to me. I should know better than to take FIN, but I sensed that was the best I'd get. In fact, no APAR was generated at that time, and the problem persisted for four more years. -- gil -- 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
Re: Date Time in JCL
On Thu, 17 May 2007 12:30:52 -0500, Mark Steely [EMAIL PROTECTED] wrote: I believe the answer is no and that's what I told the customer, but I will ask any way. Is there a way to dynamically add the current date and time to a dataset through JCL ? We are z/OS V1R7. http://bama.ua.edu/cgi-bin/wa?A2=ind0202L=ibm-mainD=0amp;I=1O=DT=0P=100302 Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- 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
Re: Date Time in JCL
However, the issue is that, there is no definitive value of current date. The issue is more than just current date (and current time is worse). It all comes down to submission time, conversion time, execution time, or system for all variable substitution under Batch JCL. Which is valid? And, for date/time what happens if you do a typrun=hold? How do you know if the submission date is what's wanted, or execution date? What happens if you submit just before midnight? Naive idea: why not provide system symbols for all of these (submission time, conversion time, execution time)? SYSSTIME, SYSCTIME, SYSETIME? Robert -- 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
Re: Date Time in JCL
Robert Bardos [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... However, the issue is that, there is no definitive value of current date. The issue is more than just current date (and current time is worse). It all comes down to submission time, conversion time, execution time, or system for all variable substitution under Batch JCL. Which is valid? And, for date/time what happens if you do a typrun=hold? How do you know if the submission date is what's wanted, or execution date? What happens if you submit just before midnight? 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. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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
Re: Date Time in JCL
On Fri, 18 May 2007 09:51:23 +0200, Vernooy, C.P. - SPLXM [EMAIL PROTECTED] wrote: 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. Definitely confusing :-)) On the other hand it is executed only on one or converted only on one . If we have a dateC for conversion time , and we make it GMT , for me it is OK - or a dateE for exec time etc ... We all have different usage .We accept this on a proc for STC ! The result is the same . Which STC of which system in which time zone created the dataset ? But it is supported ! Endless discussion because it does not exist . I am quite sure that if it existed , with the written rules ansd specs , the discussions would be less because we all need it somehow , and we all put different home made solutions for it . Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- 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
Re: Date Time in JCL
On Fri, 18 May 2007 09:51:23 +0200, Vernooy, C.P. - SPLXM [EMAIL PROTECTED] wrote: Robert Bardos [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... 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. Well, let's see If I submit a job on system1 and ask for submission time, I think I would want system1's time. If I submit it to run on system3 and ask for executuion time, I think I want system3's time. Of course, if e.g. system3 is a sysplex with images running in different time zones, I'd probably want GMT time. Dataset1 gets timestamp 10:00, the *next* dataset2 can get timestamp 09:10 if created 10 minutes after dataset1. Quite confusing. I can't see how that would happen unless the two time stamps were based upon a different kind of time. Or perhaps if the job terminated and was restarted on a different member in the 'plex that ran in a different time zone and I was asking for local time. -- Tom Marchant -- 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
Re: Date Time in JCL
Tom Marchant [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Fri, 18 May 2007 09:51:23 +0200, Vernooy, C.P. - SPLXM [EMAIL PROTECTED] wrote: Robert Bardos [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... 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. Well, let's see If I submit a job on system1 and ask for submission time, I think I would want system1's time. If I submit it to run on system3 and ask for executuion time, I think I want system3's time. Of course, if e.g. system3 is a sysplex with images running in different time zones, I'd probably want GMT time. Dataset1 gets timestamp 10:00, the *next* dataset2 can get timestamp 09:10 if created 10 minutes after dataset1. Quite confusing. I can't see how that would happen unless the two time stamps were based upon a different kind of time. Or perhaps if the job terminated and was restarted on a different member in the 'plex that ran in a different time zone and I was asking for local time. It will also work without restart: job1 runs on system1 with time1, job2 runs 10 minutes later on system2 with time=time1-1hr. I must admit, if you know the mechanisme, you know its shortcomings and that could be manageable. I think the problem is at a different level: until now, symbolics are system-wide: with this addition you get symbolics per job. This means that each job must create room to store all these variables. Where do you store them, which variables do you store, how do you keep flexibility in this set of variables, will the user demand a varying set of user variables to be stored (yes, he will), etc. etc.? Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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
Re: Date Time in JCL
On 17 May 2007 14:28:48 -0700, [EMAIL PROTECTED] (Ted MacNEIL) wrote: However, the issue is that, there is no definitive value of current date. The issue is more than just current date (and current time is worse). It all comes down to submission time, conversion time, execution time, or system for all variable substitution under Batch JCL. Which is valid? And, for date/time what happens if you do a typrun=hold? How do you know if the submission date is what's wanted, or execution date? What happens if you submit just before midnight? Define a few values. If they don't fit someone's needs, they are no worse than before. -- 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
Re: Date Time in JCL
On 18 May 2007 00:14:30 -0700, [EMAIL PROTECTED] (Robert Bardos) wrote: Naive idea: why not provide system symbols for all of these (submission time, conversion time, execution time)? SYSSTIME, SYSCTIME, SYSETIME? With Zulu variations. Our whole computing infrastructure should migrate to GMT, at least internally. -- 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
Re: Date Time in JCL
-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.DSYSEDTG..TSYSETMG,... Instead, you would code it like this: // SET MYDATE=SYSEDTG,MYTIME=SYSETMG //DDNAME DD DISP=(,CATLG),DSN=MYUSERID.MYDATA.DMYDATE..TMYTIME,... And then later in the job you could code: //DDNAME DD DISP=SHR,DSN=MYUSERID.MYDATA.DMYDATE..TMYTIME 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 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
Re: Date Time in JCL
On Fri, 18 May 2007 10:42:32 -0400, Farley, Peter x23353 wrote: Let the customer decide what they want: SYSTMEGTime, Execute, GMT SYSTMELTime, Execute, Local But that's a more significant change. I suspect symbolic substitution is performed at only one step in the job flow, prior to the availability of the execution time values. And, at what point in the flow must data set names be fixed for ENQs and JES3 scheduling? I'd be pleased enough to have only the submission or conversion (whichever is more practical) values. GMT, of course. 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. Complicateder and complicateder. So would SETs involving conversion time symbols need to be elaborated at conversion time, SETs involving execution time symbols need to be elaborated at execution time, etc. BTW, the JCL RM appears to prohibit using symbols in SET statements, though the statement is ambiguous and appears to be entirely unenforced. -- gil -- 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
Re: Date Time in JCL
On Fri, 18 May 2007 08:05:31 -0600, Howard Brazee [EMAIL PROTECTED] wrote: It all comes down to submission time, conversion time, execution time, or system for all variable substitution under Batch JCL. How do you know if the submission date is what's wanted, or execution date? What happens if you submit just before midnight? Define a few values. If they don't fit someone's needs, they are no worse than before. Logically almost true. SMOP. But that means a few lines of code that the supplier needs to support and the customer needs to pay for supporting. And there will be service calls, you provided submission date, but I want execution date. But I think the balance is, Just do it!. GMT solves the time zone problem. None of the proposed circumventions (reader exit, JCL tailoring, dynamically updated JCLLIB INCLUDE members) provides more current than conversion time, yet they seem suitable for everyday use. The midnight transition question? If a STC JCL uses DSN=HLQ1.YYMMDD.HHMMSS, is it guaranteed that the date and time are evaluated on the same day? Otherwise there's a pernicious +/- 23:59:59 error. Are authors of the above mentioned circumventions confident that their code is robust with respect to this pitfall? -- gil -- 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
Re: Date Time in JCL
-Original Message- From: Paul Gilmartin [mailto:[EMAIL PROTECTED] Sent: Friday, May 18, 2007 11:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Date Time in JCL On Fri, 18 May 2007 10:42:32 -0400, Farley, Peter x23353 wrote: Let the customer decide what they want: SYSTMEGTime, Execute, GMT SYSTMELTime, Execute, Local But that's a more significant change. I suspect symbolic substitution is performed at only one step in the job flow, prior to the availability of the execution time values. But this is no different than DSN=TEMP (where TEMP is not set to any value at the time the JCL is translated) generating a DSN in the standard temporary format, e.g. SYS07137.T154733.RA000.MYJOBNAM.MYDDNAME.H01 At least ISTM it is not different in principle. And, at what point in the flow must data set names be fixed for ENQs and JES3 scheduling? Now that's a good question, and no doubt a possible argument for not providing execution-time symbols. Worth discussing at length in the functional design meeting. I'd be pleased enough to have only the submission or conversion (whichever is more practical) values. GMT, of course. Agreed, either one would be sufficient to most users' needs. Personally I would be happy to have just submission-time symbols, but my needs are not everyone's needs. 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. Complicateder and complicateder. So would SETs involving conversion time symbols need to be elaborated at conversion time, SETs involving execution time symbols need to be elaborated at execution time, etc. But of course they would. That's the idea of providing different symbols for different stages of a job. Whether or not that idea is practical or not is a different issue. Again, worthy of serious discussion at the functional design meeting. BTW, the JCL RM appears to prohibit using symbols in SET statements, though the statement is ambiguous and appears to be entirely unenforced. By testing, I see that // SET var=value CAN be used inside of a PROC. Inside of a PROC, the PROC symbols can be used pretty much anywhere, so why not as the value in a SET assignment? And if PROC variables can be used, why not system symbols as well? The following JCL translates and executes just fine on z/OS v1.6 after you substitute your own job card: //MYUSERID JOB (...) //PROC1PROC FIRST=ONE //EXEC1EXEC PGM=IEFBR14 //EXEC1DD1 DD DUMMY // SET NEXT=FIRST //EXEC2EXEC PGM=IEFBR14,PARM='NEXT' //EXEC2DD1 DD DUMMY //* // PEND //* //PROC2PROC FIRST=ONE //EXEC1EXEC PGM=IEFBR14 //EXEC1DD1 DD DUMMY // SET NEXT=FIRST //EXEC2EXEC PGM=IEFBR14,PARM='NEXT' //EXEC2DD1 DD DUMMY //* //EXEC3EXEC PROC1,FIRST=TWO //* // PEND //* //EXECJCL EXEC PROC2 //* Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
Re: Date Time in JCL
snip The issue is more than just current date (and current time is worse). It all comes down to submission time, conversion time, execution time, or system for all variable substitution under Batch JCL. unsnip OK, give me all these symbols (CTIME, CDATE, ETIME, EDATE, etc) and I'm likely to find one that works for me 100% of the time given my pretty basic requirement. That may not work for more complex situations but I suspect that's the exception rather than the rule. Paul P -- 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
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 [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.DSYSEDTG..TSYSETMG,... Instead, you would code it like this: // SET MYDATE=SYSEDTG,MYTIME=SYSETMG //DDNAME DD DISP=(,CATLG),DSN=MYUSERID.MYDATA.DMYDATE..TMYTIME,... And then later in the job you could code: //DDNAME DD DISP=SHR,DSN=MYUSERID.MYDATA.DMYDATE..TMYTIME 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-usocid=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
Date Time in JCL
I believe the answer is no and that's what I told the customer, but I will ask any way. Is there a way to dynamically add the current date and time to a dataset through JCL ? We are z/OS V1R7. Thank You -- 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
Re: Date Time in JCL
On Thu, 17 May 2007 12:30:52 -0500, Mark Steely wrote: I believe the answer is no and that's what I told the customer, but I will ask any way. Is there a way to dynamically add the current date and time to a dataset through JCL ? We are z/OS V1R7. Through JCL? YES! Through BATCH JCL? No. (Started Job, sure, and started tasks are easily done, too. Batch is where it gets pesky... like current time by which means of counting (RDR,C/I,INIT).) -- Tom Schmidt Madison, WI -- 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
Re: Date Time in JCL
On Thu, 17 May 2007 12:30:52 -0500, Mark Steely [EMAIL PROTECTED] wrote: I believe the answer is no and that's what I told the customer, but I will ask any way. Is there a way to dynamically add the current date and time to a dataset through JCL ? We are z/OS V1R7. This *topic* was just covered recently (I think in May). Check the archives. .mhyI -- 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
Re: Date Time in JCL
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Steely Sent: Thursday, May 17, 2007 12:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Date Time in JCL I believe the answer is no and that's what I told the customer, but I will ask any way. Is there a way to dynamically add the current date and time to a dataset through JCL ? We are z/OS V1R7. Thank You The answer to this question is still NO. And Charles DeGaulle is still dead as well. And Microsoft Windows still gets BSODs. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Date Time in JCL
In a message dated 5/17/2007 12:48:40 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: This *topic* was just covered recently (I think in May). Check the archives. Comes up repeatedly. First choice is Scheduling PKG, second choice is ISPF SKELs, more choices include Rexx, CLIST, HLASM to generate JCL and sub to internal reader. ** See what's free at http://www.aol.com. -- 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
Re: Date Time in JCL
On Thu, 17 May 2007 12:56:13 -0500, McKown, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Steely Sent: Thursday, May 17, 2007 12:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Date Time in JCL The answer to this question is still NO. And Charles DeGaulle is still dead as well. And Microsoft Windows still gets BSODs. -- John McKown And Charles André Joseph Marie de Gaulle is *STILL* French.dontchya know?! ...mhyI -- 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
Re: Date Time in JCL
deadhorsebeat . . . and none of those choices are really good, at least for a non-sysprog. I know the reasoning behind not having it as a batch JCL, but it seems a case of you might burn yourself, so you can't do it. There's a reason it comes up frequently; many people would find it useful. /deadhorsebeat Jon snip Comes up repeatedly. First choice is Scheduling PKG, second choice is ISPF SKELs, more choices include Rexx, CLIST, HLASM to generate JCL and sub to internal reader. /snip -- 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
Re: Date Time in JCL
You are right...It would be VERY useful. I'm surprised that IBM can't come up with a way to handle system symbols (Perhaps via the SET parameter). Something like: // SET DATE=SYSSYMBOL(LDATE) Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock Sent: Thursday, May 17, 2007 2:25 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Date Time in JCL deadhorsebeat .. . . and none of those choices are really good, at least for a non-sysprog. I know the reasoning behind not having it as a batch JCL, but it seems a case of you might burn yourself, so you can't do it. There's a reason it comes up frequently; many people would find it useful. /deadhorsebeat Jon This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: Date Time in JCL
On 17 May 2007 10:57:42 -0700, [EMAIL PROTECTED] wrote: Comes up repeatedly. First choice is Scheduling PKG, second choice is ISPF SKELs, more choices include Rexx, CLIST, HLASM to generate JCL and sub to internal reader. Is there a place to look at common questions recommendations from this listserv/newsgroup? -- 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
Re: Date Time in JCL
On 17 May 2007 11:01:57 -0700, [EMAIL PROTECTED] (Mark H. Young) wrote: And Charles André Joseph Marie de Gaulle is *STILL* French.dontchya know?! I didn't know he was a Marie. I know of a some (José María)s, and fewer (Joseph Mary)s. -- 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
Re: Date Time in JCL
It can be done, at least I'm doing it on my single LPAR machine. HOW!!!?? 1. Create a script to use unix services date command to build set cards for date and time. Put the set cards into a PDS that will be concatenated in a JES2 PROC DD. Contents of /usr/local/bin/datetime - #!/bin/sh # # script to update the current date and time # echo // SET DATE=`date '+%m%d%y'` /tmp/datetime echo // SET TIME=`date '+%H%M'` /tmp/datetime cp /tmp/datetime //'SYS1.SETVAL.PROCLIB(DATETIME)' rm /tmp/datetime 2. Create a file for loading the crontab to run the datetime script once per minute. Contents of /cronfile - 0-59 * * * * /usr/local/bin/datetime 3. Load /cronfile into crontab - crontab /cronfile This tells cron to run the script will run once per minute, at the top of the minute. 4. Concatenate the PDS containing the DATETIME member in the JES2 PROC DD. //JES2 PROC MEMBER=00 //IEFPROC EXEC PGM=HASJES20, //DPRTY=(15,15),TIME=1440,PERFORM=9 //PROC00 DD DISP=SHR,DSN=SYS1.PROCLIB BATCH PROCS *** // DD DISP=SHR,DSN=SYS1.SETVAL.PROCLIB 5. Start the cron daemon (there are different ways to do this, we use JCL to which gives a consistent jobname in the d a,l displays)' Also remember to configure the cron daemon to start at IPL. The userid that is used to run the cron daemon should have a uid=0. //$PDACRON JOB ($PROD),'$PDACRON',MSGCLASS=X,CLASS=I, // MSGLEVEL=(1,1) //* * * * * * * * * * * * * * * * * * * * * * * * * * //IEFPROC EXEC PGM=IKJEFT01,DYNAMNBR=50 //SYSEXEC DD DSN=SYS1.SBPXEXEC,DISP=SHR //SYSTSPRT DD TERM=TS,SYSOUT=X //SYSTSIN DD * oshell /usr/sbin/cron 6. Add the //INCLUDE MEMBER=DATETIME card after the JOB card. Code the date and time variables in your DSN name. //$USER19A JOB (BATCH),IEFBR14,MSGCLASS=X,CLASS=I, // MSGLEVEL=(1,1),NOTIFY=SYSUID //INCLUDE MEMBER=DATETIME //STEP01 EXEC PGM=IEFBR14 //SYSPRINT DD SYSOUT=* //VDSBYPAS DD DUMMY //DD1DD DSN=$USER19.DDATE..TTIME, // UNIT=SYSALLDA,DISP=(,CATLG), // SPACE=(CYL,(1)), // DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920) Thus, the variables resolve to the current date and time - 01 //$USER19A JOB (BATCH),IEFBR14,MSGCLASS=X,CLASS=I, 02 // MSGLEVEL=(1,1),NOTIFY=SYSUID =NOTE= -- MSGLEVEL=(1,1),NOTIFY=$USER19 03 //INCLUDE MEMBER=DATETIME =NOTE= I1// SET DATE=051707 =NOTE= I1// SET TIME=1348 04 //STEP01 EXEC PGM=IEFBR14 05 //SYSPRINT DD SYSOUT=* 06 //VDSBYPAS DD DUMMY 07 //DD1DD DSN=$USER19.DDATE..TTIME, =NOTE= --DD1DD DSN=$USER19.D051707.T1348, 08 // UNIT=SYSALLDA,DISP=(,CATLG), 09 // SPACE=(CYL,(1)), 10 // DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920) Possible gotcha's 1. Running jobs that create the same date/time stamp in less than one minute can result in 'not cat 2' files. (or within the same day with a date stamp only.) 2. The pds where the DATETIME member is stored must be compressed regularly. In our case, once a day is plenty on a 7 cylinder file. Thanks, Jim Weidt Senior Systems Engineer Jostens Inc. Office: 952-838-7555 Cell: 612-419-3738 [EMAIL PROTECTED] CONFIDENTIALITY NOTICE: The information contained in this e-mail communication and any attached documentation may be privileged, confidential or otherwise protected from disclosure and is intended only for the use of the designated recipient(s). It is not intended for transmission to, or receipt by, any unauthorized person. The use, distribution, transmittal or retransmittal by an unintended recipient of this communication is strictly prohibited. If you are not the intended recipient of this e-mail, please delete it from your system without copying it and notify the above sender. -- 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
Re: Date Time in JCL
On Thu, 17 May 2007 14:06:55 -0500, Weidt, James [EMAIL PROTECTED] wrote: It can be done, at least I'm doing it on my single LPAR machine. HOW!!!?? huge snip Way overly complicated. Not to mention all the things that could go wrong. If you only have a single LPAR, that eliminates most (not all) of the caveats and ambiguities surrounding the reasons that IBM has never allowed system symbols in batch jobs. So instead of jumping though hoops, you can code a fairly simple IEFUJV exit that calls ASASYMBM to resolve the symbols. As already mentioned by several people, this subject comes up often. PLEASE check the archives. You'll find a reference to sample IEFUJV code also. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Date Time in JCL
On Thu, 17 May 2007 14:06:55 -0500, Weidt, James [EMAIL PROTECTED] wrote: 2. The pds where the DATETIME member is stored must be compressed regularly. In our case, once a day is plenty on a 7 cylinder file. Why not make it a PDSE? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Date Time in JCL
The system is OS/390 2.9, we've never used PDSE and we don't change what we don't have to. Thanks, Jim Weidt Senior Systems Engineer Jostens Inc. Office: 952-838-7555 Cell: 612-419-3738 [EMAIL PROTECTED] CONFIDENTIALITY NOTICE: The information contained in this e-mail communication and any attached documentation may be privileged, confidential or otherwise protected from disclosure and is intended only for the use of the designated recipient(s). It is not intended for transmission to, or receipt by, any unauthorized person. The use, distribution, transmittal or retransmittal by an unintended recipient of this communication is strictly prohibited. If you are not the intended recipient of this e-mail, please delete it from your system without copying it and notify the above sender. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Thursday, May 17, 2007 2:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Date Time in JCL On Thu, 17 May 2007 14:06:55 -0500, Weidt, James [EMAIL PROTECTED] wrote: 2. The pds where the DATETIME member is stored must be compressed regularly. In our case, once a day is plenty on a 7 cylinder file. Why not make it a PDSE? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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 -- 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
Re: Date Time in JCL
Jon, I (and I assure you, a lot of people in IBM) understand the need for this. However, the issue is that, there is no definitive value of current date. Instead of it being a case of you might burn yourself, so you can't do it. I see it as a case of being able to get it almost right which, as Roger Miller puts it so well, is just another way of saying wrong Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock Sent: Thursday, May 17, 2007 1:25 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Date Time in JCL deadhorsebeat . . . and none of those choices are really good, at least for a non-sysprog. I know the reasoning behind not having it as a batch JCL, but it seems a case of you might burn yourself, so you can't do it. There's a reason it comes up frequently; many people would find it useful. /deadhorsebeat Jon snip Comes up repeatedly. First choice is Scheduling PKG, second choice is ISPF SKELs, more choices include Rexx, CLIST, HLASM to generate JCL and sub to internal reader. /snip -- 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 -- 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
Re: Date Time in JCL
On Thu, 2007-05-17 at 17:06 -0400, Wayne Driscoll wrote: I (and I assure you, a lot of people in IBM) understand the need for this. However, the issue is that, there is no definitive value of current date. Instead of it being a case of you might burn yourself, so you can't do it. I see it as a case of being able to get it almost right which, as Roger Miller puts it so well, is just another way of saying wrong My take on this is *I* know what date and time I run my jobs to extract dumps, logs, ENQ ... I use my UJV (on the cbt) all the time - and I *never* get the wrong date/time. We all have to be careful all the time - it's part of our job(s). Shane ... -- 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
Re: Date Time in JCL
However, the issue is that, there is no definitive value of current date. The issue is more than just current date (and current time is worse). It all comes down to submission time, conversion time, execution time, or system for all variable substitution under Batch JCL. Which is valid? And, for date/time what happens if you do a typrun=hold? How do you know if the submission date is what's wanted, or execution date? What happens if you submit just before midnight? - Too busy driving to stop for gas! -- 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
Re: Date Time in JCL
On Thu, 17 May 2007 21:29:43 +, Ted MacNEIL wrote: However, the issue is that, there is no definitive value of current date. The issue is more than just current date (and current time is worse). I think the point in posts previous was to come up with a unique file name. One that can be kept and referenced in historical sequence. One whose position within a date/time context is obvious to a casual observer. If you've more complex needs, then a more complex solution is in order. -- 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
Re: Date Time in JCL
My client wrote a small program to add a $ddate symbolic that does it. At 01:56 PM 5/17/2007, you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Steely Sent: Thursday, May 17, 2007 12:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Date Time in JCL I believe the answer is no and that's what I told the customer, but I will ask any way. Is there a way to dynamically add the current date and time to a dataset through JCL ? We are z/OS V1R7. Thank You The answer to this question is still NO. And Charles DeGaulle is still dead as well. And Microsoft Windows still gets BSODs. snip Doug Fuerst Consultant BK Associates Brooklyn, NY (718) 921-2620 (Office) (718) 921-0952 (Fax) (917) 572-7364 (Cell) [EMAIL PROTECTED] -- 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
