Re: clock, daylight savings time
On 15 Mar 2008 12:42:19 -0700, [EMAIL PROTECTED] (Ted MacNEIL) wrote: And modern day politicians found a cheap solution to energy use that didn't work and cost a lot, but made it look as though they were useful (not to mention it allowed them to use power). DST actually costs more than leaving the clocks alone. Even if it was cost-neutral, there is a significant cost in changing it. But the politicians are Doing Something! -- 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: clock, daylight savings time
---snip And modern day politicians found a cheap solution to energy use that didn't work and cost a lot, but made it look as though they were useful (not to mention it allowed them to use power). ---unsnip--- Anyone ready to declare Open Season on politicians? :-) Maybe we should put a BOUNTY on them! :-) -- 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: clock, daylight savings time
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman ---snip And modern day politicians found a cheap solution to energy use that didn't work and cost a lot, but made it look as though they were useful (not to mention it allowed them to use power). ---unsnip--- Anyone ready to declare Open Season on politicians? :-) Maybe we should put a BOUNTY on them! :-) Well, we DO have our (U.S.) biennial revolution day coming Nov. 4 this year. I suspect it'll pass unnoticed again, and most if not all the incumbents will be re-elected.. -jc- -- 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: clock, daylight savings time
On 12 Mar 2008 13:55:20 -0700, [EMAIL PROTECTED] (Robert Justice) wrote: sounds good here too, changing the clock twice a year is absurd Even Ben Franklin can make mistakes - this time he assumed that the world had his sleeping habits. And modern day politicians found a cheap solution to energy use that didn't work and cost a lot, but made it look as though they were useful (not to mention it allowed them to use power). -- 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: clock, daylight savings time
And modern day politicians found a cheap solution to energy use that didn't work and cost a lot, but made it look as though they were useful (not to mention it allowed them to use power). DST actually costs more than leaving the clocks alone. - 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: SPAM: Re: clock, daylight savings time
snip--- But Rick, do your users all reside in different time zones like mine do??? Isn't amazing how much railroad schedules and saving daylight make our lives so difficult at times. Decisions, decisions! --unsnip No, we were split only across 5 different time zones. (GMT, on London and Liverpool, plus the continental US) -- 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: clock, daylight savings time
On Wed, 12 Mar 2008 23:15:25 -0500, Bruce Hewson wrote: do your users all reside in different time zones like mine do??? There's an argument here for a facility whereby users could variously override the PARMLIB setting with a JOBPARM, TSO PROFILE, RACF setting, or the like. -- 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: clock, daylight savings time
On Wed, 12 Mar 2008 10:16:08 -0600, Howard Brazee [EMAIL PROTECTED] wrote: ... I wish my clock radios have a button on it that synchronized the clock to whichever station it was tuned to. ... I've got one. I'm not sure what it synchonizes with but it is perpetually about 4 minutes ahead of local time. I do have to set the time zone and set a DST is observed flag. No SET TIME function in case I want to have it's external time a non-standard offset (say, 4 minutes) from it's internal time. z/OS and the various hardware timers it can use could be a whole lot worse (as my clock radio demonstrates). Pat O'Keefe -- 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: clock, daylight savings time
In [EMAIL PROTECTED], on 03/11/2008 at 01:30 PM, Eric Bielefeld [EMAIL PROTECTED] said: My first thought when I read Seymour's original post was that he was being humourous. I'm sure we'll find out when he logs on again. No, Spring forward, Fall back is a common mnemonic in the USA. -- 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: clock, daylight savings time
In [EMAIL PROTECTED], on 03/11/2008 at 12:18 PM, Schwarz, Barry A [EMAIL PROTECTED] said: While all true, it doesn't address the question. Yes it does, because -(A-B) = (B-A); in particularar, (CDT-CST) = -(CST-CDT). -- 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: clock, daylight savings time
Aw, the HECK with this. I hereby declare that from now on, daylight savings is banned and all clocks shall be set to GMT only, worldwide. Signed, Doc Farmer Benevolent Dictator and Confirmed Horophile (stop snickering, I'm *not* a NY Governor) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, March 11, 2008 19:27 To: IBM-MAIN@bama.ua.edu Subject: Re: clock, daylight savings time In [EMAIL PROTECTED], on 03/11/2008 at 12:18 PM, Schwarz, Barry A [EMAIL PROTECTED] said: While all true, it doesn't address the question. Yes it does, because -(A-B) = (B-A); in particularar, (CDT-CST) = -(CST-CDT). -- 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 -- 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: clock, daylight savings time
On 12 Mar 2008 06:09:21 -0700, [EMAIL PROTECTED] (Doc Farmer) wrote: I hereby declare that from now on, daylight savings is banned and all clocks shall be set to GMT only, worldwide. Signed, Doc Farmer Benevolent Dictator and Confirmed Horophile (stop snickering, I'm *not* a NY Governor) You've got my vote. -- 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: clock, daylight savings time
---snip--- I hereby declare that from now on, daylight savings is banned and all clocks shall be set to GMT only, worldwide. Signed, Doc Farmer Benevolent Dictator and Confirmed Horophile (stop snickering, I'm *not* a NY Governor) -unsnip--- I disagree. Let all HARDWARE clocks be set to GMT and use PARMLIB OFFSET values to adjust to local time. -- 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: clock, daylight savings time
Doc Farmer wrote: Aw, the HECK with this. I hereby declare that from now on, daylight savings is banned and all clocks shall be set to GMT only, worldwide. I have no issue with time zones. But, I really don't like the semi-annual confusion caused by switching between Daylight Saving and Standard Time. Yes, it's been proved to save energy. However, it's also been proved to cost more in the end. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.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: clock, daylight savings time
Ed, Actually, latest studies show it causes an additional one to four per cent increase in energy use: http://www.npr.org/templates/story/story.php?storyId=87991839 Tom Harper IMS Utilities Development Team Neon Enterprise Software, Inc. Sugar Land, TX -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Wednesday, March 12, 2008 10:47 AM To: IBM-MAIN@bama.ua.edu Subject: Re: clock, daylight savings time Doc Farmer wrote: Aw, the HECK with this. I hereby declare that from now on, daylight savings is banned and all clocks shall be set to GMT only, worldwide. I have no issue with time zones. But, I really don't like the semi-annual confusion caused by switching between Daylight Saving and Standard Time. Yes, it's been proved to save energy. However, it's also been proved to cost more in the end. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.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 -- 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: clock, daylight savings time
snip I have no issue with time zones. But, I really don't like the semi-annual confusion caused by switching between Daylight Saving and Standard Time. Yes, it's been proved to save energy. However, it's also been proved to cost more in the end. -- Edward E Jaffe /snip Ed, Here in Indiana we switched to day light saving time a couple years ago and studies have shown our energy usage has increased. Not sure if we just have not got the hang of it yet or it actually does cost more. Thanks, Fletch Sr. Systems Analyst Conseco, LLC The first step towards failure is trying - Homer Simpson -- 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: clock, daylight savings time
On 12 Mar 2008 08:13:22 -0700, [EMAIL PROTECTED] (Rick Fochtman) wrote: I disagree. Let all HARDWARE clocks be set to GMT and use PARMLIB OFFSET values to adjust to local time. Better than nothing. But in the U.S. lots of people are learning ESPN time. Maybe it will result in a country like China with one time zone. Your solution gets rid of most of our (in this forum) problems of Daylight Savings Time (although not the fact that nothing is saved). We still have report times with overlapping times in the fall, even if time-date stamps are accurate. I wish my clock radios have a button on it that synchronized the clock to whichever station it was tuned to. Maybe put a radio in my Microwave oven to set its clock. And when power is restored after a black-out, re-set the clock. -- 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: clock, daylight savings time
Uh, what part of Benevolent Dictator did you not understand? ;D -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Wednesday, March 12, 2008 11:14 To: IBM-MAIN@bama.ua.edu Subject: Re: clock, daylight savings time ---snip--- I hereby declare that from now on, daylight savings is banned and all clocks shall be set to GMT only, worldwide. Signed, Doc Farmer Benevolent Dictator and Confirmed Horophile (stop snickering, I'm *not* a NY Governor) -unsnip--- I disagree. Let all HARDWARE clocks be set to GMT and use PARMLIB OFFSET values to adjust to local time. -- 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: clock, daylight savings time
Rick Fochtman wrote: ---snip--- I hereby declare that from now on, daylight savings is banned and all clocks shall be set to GMT only, worldwide. Signed, Doc Farmer Benevolent Dictator and Confirmed Horophile (stop snickering, I'm *not* a NY Governor) -unsnip--- I disagree. Let all HARDWARE clocks be set to GMT and use PARMLIB OFFSET values to adjust to local time. -- 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 I think a PARMLIB OFFSET can only be a default to use for an application - in case the end user of a server based application has not (or can not !) defined her own default (or session based offset). Birger Heede IBM Denmark -- 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: clock, daylight savings time
For a person who demands absolute precision and accuracy from others (USS is not unix, directory blocks are not 256, etc), your insistence that CST can be 7 hours off of GMT appears very much out of character. Your attempts to justify this with algebraic gibberish are unbelievable. Has someone hacked your account and posted this in your name or is at an early start on April 1 postings? -Original Message- From: Shmuel Metz (Seymour J.) Sent: Tuesday, March 11, 2008 4:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: clock, daylight savings time In [EMAIL PROTECTED], on 03/11/2008 at 12:18 PM, Schwarz, Barry A said: While all true, it doesn't address the question. Yes it does, because -(A-B) = (B-A); in particularar, (CDT-CST) = -(CST-CDT). -- 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: clock, daylight savings time
sounds good here too, changing the clock twice a year is absurd - Original Message - From: Doc Farmer [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Wednesday, March 12, 2008 9:07 AM Subject: Re: clock, daylight savings time Aw, the HECK with this. I hereby declare that from now on, daylight savings is banned and all clocks shall be set to GMT only, worldwide. Signed, Doc Farmer Benevolent Dictator and Confirmed Horophile (stop snickering, I'm *not* a NY Governor) -- 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: clock, daylight savings time
In [EMAIL PROTECTED], on 03/11/2008 at 08:28 PM, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] said: No, Spring forward, Fall back is a common mnemonic in the USA. They say that the memory is the second thing to go; I don't remember the first thing. -- 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: clock, daylight savings time
I always heard it was the knees. On Wed, 12 Mar 2008 17:43:50 -0300, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: They say that the memory is the second thing to go; I don't remember the first thing. -- -- 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: clock, daylight savings time
The buzz on the radios in Idaho explain that while you are saving money in the spring, you get home earlier in the summer and run those air conditioners longer. Thus you spend more overall. And those old urban legends it was for the farmers, well the animals and crops can figure out when the sun comes up without a clock. It was all about trying to save electricity during the war. On Wed, 12 Mar 2008 12:00:45 -0400, Fletcher, Kevin [EMAIL PROTECTED] wrote: snip I have no issue with time zones. But, I really don't like the semi-annual confusion caused by switching between Daylight Saving and Standard Time. Yes, it's been proved to save energy. However, it's also been proved to cost more in the end. -- Edward E Jaffe /snip Ed, Here in Indiana we switched to day light saving time a couple years ago and studies have shown our energy usage has increased. Not sure if we just have not got the hang of it yet or it actually does cost more. Thanks, Fletch Sr. Systems Analyst Conseco, LLC The first step towards failure is trying - Homer Simpson -- 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: clock, daylight savings time
I thought it was your hair. Scott IDF -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth E Tomiak Sent: Wednesday, March 12, 2008 7:10 PM To: IBM-MAIN@bama.ua.edu Subject: Re: clock, daylight savings time I always heard it was the knees. On Wed, 12 Mar 2008 17:43:50 -0300, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: They say that the memory is the second thing to go; I don't remember the first thing. -- -- 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: clock, daylight savings time
But Rick, do your users all reside in different time zones like mine do??? Isn't amazing how much railroad schedules and saving daylight make our lives so difficult at times. Decisions, decisions! On Wed, 12 Mar 2008 10:13:51 -0500, Rick Fochtman [EMAIL PROTECTED] wrote: ---snip--- I hereby declare that from now on, daylight savings is banned and all clocks shall be set to GMT only, worldwide. Signed, Doc Farmer Benevolent Dictator and Confirmed Horophile (stop snickering, I'm *not* a NY Governor) -unsnip--- I disagree. Let all HARDWARE clocks be set to GMT and use PARMLIB OFFSET values to adjust to local time. Regards Bruce Hewson -- 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: clock, daylight savings time
In [EMAIL PROTECTED], on 03/10/2008 at 04:26 PM, Schwarz, Barry A [EMAIL PROTECTED] said: Is CDT really 7 hours off from GMT? CST is -0600. Fall back one hour and you get -0700. -- 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: clock, daylight savings time
In [EMAIL PROTECTED], on 03/10/2008 at 04:08 PM, Paul Gilmartin [EMAIL PROTECTED] said: There's a paradigm shift required here. The core UNIX function, localtime() does not automatically switch to and from DST. Rather, if localtime() is called with the same argument and with the environment variables having the same values, One of those environment variables is TZ and the spring forward/fall back dates are optionally part of the TZ value. -- 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: clock, daylight savings time
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour J.) Schwarz, Barry A said: Is CDT really 7 hours off from GMT? CST is -0600. Fall back one hour and you get -0700. Why would you fall back from CST? Wouldn't that give Daylight Spending Time? -jc- -- 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: clock, daylight savings time
Shmuel Metz (Seymour J.) wrote: Is CDT really 7 hours off from GMT? CST is -0600. Fall back one hour and you get -0700. Huh??? You don't fall back from CST. You spring forward to CDT, which is -0500! http://www.timeanddate.com/library/abbreviations/timezones/na/cst.html http://www.timeanddate.com/library/abbreviations/timezones/na/cdt.html -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.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: clock, daylight savings time
On Tue, 11 Mar 2008 04:35:14 -0300, Shmuel Metz (Seymour J.) wrote: There's a paradigm shift required here. The core UNIX function, localtime() does not automatically switch to and from DST. Rather, if localtime() is called with the same argument and with the environment variables having the same values, One of those environment variables is TZ and the spring forward/fall back dates are optionally part of the TZ value. Yes, but the important distinction is that, in contrast to the CVT fields, neither TZ nor any other environmental setting needs to be changed semiannualy. -- 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: clock, daylight savings time
Edward E Jaffe wrote: You don't fall back from CST. You spring forward to CDT, which is -0500! Correct. And, springing forward from -8 (PST) yields -7 (PDT), which was the actual time zone offset of the system on which I executed the demo program: I was confused about the time zone on the machine on which I tested the code. I have access to systems with various time zone offsets. That was really PDT (Pacific Daylight Time), _NOT_ Central Daylight Time (CDT) as I stated. PST = UTC - 8 PDT = PST + 1 spring forward PDT = UTC - 7 LOCAL TIME = GMT TOD + CVTLDTO - CVTLSO CVTLDTO - CVTLSO = LOCAL TIME - GMT TOD CVTLDTO = LOCAL TIME - GMT TOD + CVTLSO GMT: 22:57:14.900771 2008/03/10 (UTC [most call it GMT]) LOCAL: 15:56:51.900771 2008/03/10 (Pacific Daylight Time) --- = -07:00:23 (LOCAL TIME - GMT TOD) = (CVTLDTO - CVTLSO) + + :23 (LSO [actual, current value]) - -07:00:00 (LDTO) -- WB -- 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: clock, daylight savings time
On Mon, 10 Mar 2008 20:01:59 -0500, William H. Blair wrote: The service corresponding to time() is TIME STCK[E],,ZONE=GMT Except for the difference in epoch and radix, the UNIX time() function is conceptually equivalent to z/OS TIME STCK[E],addr or TIME BIN,addr,ZONE=GMT or TIME DEC,addr,ZONE=GMT. Here we agree. It would have been nice if z/OS had implemented the following function: TIME STCK[E],addr,ZONE=LT I would prefer that ZONE be an argument to STCKCONV so any user anywhere could convert a timestamp, possibly recorded elsewhere, to local time. Even better, ZONE should support values indicating specific, not necessarily local, time zones. The service corresponding to gmtime() is STCKCONV Nope. STCKCONV is just a formatting conversion service. It does not return anything about the current time or date on the system on which it is executed. ... No. RTFM: man gmtime ... struct tm * gmtime(const time_t *clock); ... The function gmtime() similarly converts the time value, but without any time zone adjustment, and returns a pointer to a tm structure ... gmtime() is just a formatting conversion service. It does not return anytthing about the current time or date on the system on which it is executed. In what way does this not correspond to STCKCONV? ... In z/OS what corresponds to the UNIX gmtime() function is (at best) TIME BIN,addr,ZONE=GMT or TIME DEC,addr,ZONE=GMT. I know of no service corresponding to localtime(). In z/OS what corresponds to the UNIX localtime() function is (at best) TIME BIN,addr,ZONE=LT or TIME DEC,addr,ZONE=LT. No. RTFM: struct tm * localtime(const time_t *clock); The function localtime() converts the time value pointed at by clock, and returns a pointer to a ``struct tm'' (described below) which contains the broken-out time information for the value after adjusting for the current time zone (and any other factors such as Daylight Saving Time). Again, localtime() is just a formatting conversion service ... There is no built-in z/OS service I know of that will return a TOD clock-format (STCK or STCKE) value that has been corrected to represent the local time. As above, such corrections would more usefully be performed by STCKCONV, so archival timestamps could uniformly be uncorrected TOD clock values. -- 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: clock, daylight savings time
On Mon, 10 Mar 2008 19:38:59 -0500, William H. Blair wrote: If by the phrase correct result you mean actual LOCAL TIME then it can't and won't. That is not what I was trying to show you. I was demonstrating and illustrating the fact that that, for input to STCKCONV, you HAVE TO ALREADY HAVE a corrected local time stamp value (in STCK or STCKE format) in order to get the correct LOCAL TIME out of the STCKCONV service. The purpose of the program was to demonstrate that you can't get what you call the correct result out of STCKCONV with JUST a TOD clock value. The arguments for storing time stamps in a universal convention, such as UTC are well known; I hope you're aware of them. One of the strong ones is the ambiguity in local time during the autumn Daylight Saving adjustment. If you have TOD clock values recorded in a data set (such as a log file of some sort) then you will simply have to know (if you did not also record the contemporaneous values of the LSO and LDTO fields) and be able to reproduce them. In some cases, of course, this information is known. For example, the value of CVTLSO is pretty constant, and can actually be looked up in a table whose argument is GMT, because when LSO changes and, in the past, has changed, is set by international agreement and is published. So that does not need to be recorded with the STCK[E] values, if you are willing to go to the trouble of looking it up in a table. The value of LDTO is simply time zone-dependent, and if you know the time zone of the machine that produced the data then that can be looked up in another table. There are two boundary conditions that are difficult to deal with, but for the most part, unless you are writing an operating system or a product, you don't really need this data recorded. It's easier of course if you do have it, but it costs you an extra 16 or 32 bytes in your log records or whatever. Wouldn't this complexity, and the associated tables, better be incorporated in a system facility, such as an enhanced STCKCONV, eliminating the need for each application's developer to repeat the coding effort, and reducing the hazard of coding errors? One might invoke Unix System Services to perform much of the computation. Unfortunately, UNIX is ignorant of leap seconds, as required by POSIX specification of the standard functions (but this doesn't preclude extensions as an alternative). -- 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: clock, daylight savings time
Paul Gilmartin wrote: I would prefer that ZONE be an argument to STCKCONV so any user anywhere could convert a timestamp, possibly recorded elsewhere, to local time. Even better, ZONE should support values indicating specific, not necessarily local, time zones. Yes, that was an [obvious] omission. It was a great surprise to me, and a disappointment, when I first learned about STCKCONV. .. such corrections would more usefully be performed by STCKCONV, so archival timestamps could uniformly be uncorrected TOD clock values. STCKCONV could, of course, be enhanced to do this, but it could just as well be a new service (or a new macro). But which macro or which service offered it is not important. But there is no reason why the TIME macro/service should not also be enhanced to return a LDTO- and LSO-corrected STCK[E] GMT/UTC TOD clock value. TIME already returns the local time, just not in an STCK[E] format. So I don't think it would be more useful to have this _just_ in STCKCONV. It would be most useful to have it in both, but if IBM were going to deliver it in just one, I would choose TIME, since I can handle the double or quadruple arithmetic myself just as easily as I can code new parameters on an (enhanced) STCKCONV macro invocation. In other words, most folks would benefit from it being added to the TIME macro and service. Nonetheless, your goal that archival timestamps could uniformly be uncorrected TOD clock values is both noble and desirable, but they could be that way now (and are in many products I know of). All one has to do is a little bit of extra work, or simply store the LDTO and LSO values ALSO. There's nothing that prevents this from being done now. If STCKCONV were enhanced, you'd have to write some new code anyway. If you're willing to write some new code when that day comes, just go ahead and write it now to handle the actual or implied LDTO and LSO values. Then when the new STCKCONV features you want become available, you can just remove some of that new code and let STCKCONV do it for you. -- WB -- 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: clock, daylight savings time
Paul Gilmartin wrote: Yes, but the important distinction is that, in contrast to the CVT fields, neither TZ nor any other environmental setting needs to be changed semiannualy. True. But I bet most z/OS mainframe folks are happy it still works the way it does now. Why? Not everybody wants to or can afford to change their time zone offset at the same time that the civil clocks are changed. And, not every system is in a location that observes Daylight Saving Time. Of course, there could be yet another parameter that indicates whether or not THIS system observes DST, and another parameter that indicates the magnitude of the DST change (not all locations around the world adjust the clock by exactly one hour for Summer Time or whatever they call it). But, even if z/OS had all of this additional automatically-effective parameterization available, I bet that a significant plurality would not take advantage of it, and instead elect to handle it manually, across an IPL, just like they do now. If OS/360 had done it right to begin with, and had the DST parameters, calculations and corrections built in from the very beginning, we would not have the problems we now have because all subsystems and applications would have been able to handle DST-instigated local clock discontinuities from the very beginning; every programmer would have known that time-sensitive programs had to be coded to do so. But, that was not to be the history we now regret. UNIX, coming along later, did it just a little bit better. -- WB -- 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: clock, daylight savings time
While all true, it doesn't address the question. You never fall back from CST to CDT, you spring forward. -Original Message- From: Shmuel Metz (Seymour J.) Sent: Tuesday, March 11, 2008 12:41 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: clock, daylight savings time In [EMAIL PROTECTED], on 03/10/2008 at 04:26 PM, Schwarz, Barry A said: Is CDT really 7 hours off from GMT? CST is -0600. Fall back one hour and you get -0700. -- 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: clock, daylight savings time
My first thought when I read Seymour's original post was that he was being humourous. I'm sure we'll find out when he logs on again. Eric Schwarz wrote: While all true, it doesn't address the question. You never fall back from CST to CDT, you spring forward. -Original Message- From: Shmuel Metz (Seymour J.) CST is -0600. Fall back one hour and you get -0700. -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- 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: clock, daylight savings time
In [EMAIL PROTECTED], on 03/08/2008 at 02:31 PM, Gregory Pinkowski [EMAIL PROTECTED] said: Question is: do I have to reset any secondary time of day clock that the HDC (this is some kind of Z9 with a HDC that I think runs some kind of UNIX as its embedded system??) uses for things like hardware time stamps or knowing when to call home or something? As long as TZ is set properly, an OS/2 or Unix system will automatically switch to and from DST. -- 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: clock, daylight savings time
On Mon, 10 Mar 2008 14:23:40 -0300, Shmuel Metz (Seymour J.) wrote: As long as TZ is set properly, an OS/2 or Unix system will automatically switch to and from DST. There's a paradigm shift required here. The core UNIX function, localtime() does not automatically switch to and from DST. Rather, if localtime() is called with the same argument and with the environment variables having the same values, it will produce identical correct results whether Daylight Saving or Standard time is in effect. I believe this is in contrast to the z/OS STCKCONV service. however, I can not find in the docmentation (z/OS V1R7.0 MVS Assembler Services Reference IAR-XCT) whether STCKCONV returns local time or GMT nor how Daylight Saving and Leap Seconds are handled (possibly in accord with the table in the PoOP?) The programmer ought to be given the choice of either. Perhaps I'll submit an RCF. -- 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: clock, daylight savings time
Paul Gilmartin wrote: I believe this is in contrast to the z/OS STCKCONV service. however, I can not find in the docmentation (z/OS V1R7.0 MVS Assembler Services Reference IAR-XCT) whether STCKCONV returns local time or GMT nor how Daylight Saving and Leap Seconds are handled (possibly in accord with the table in the PoOP?) The programmer ought to be given the choice of either. Perhaps I'll submit an RCF. STCKCONV returns neither. It returns what it has been given. If it is given local time, then the result will be local time. If it is given GMT, then the result will be GMT. It is just a conversion service, whose input is either a 64-bit TOD clock value or a 128-bit ETOD clock value. To get a TOD clock value corrected for the local time zone and leap seconds for input to STCKCONV, you would need to execute code such as this: TIME STCK,STCKGMTCURRENT GMT TOD CLOCK STCKCONV STCKVAL=STCKGMT, CONVERT GMT TIME+ CONVVAL=GMTTIMED,TO + TIMETYPE=DEC, HHMMSSTHMIJU + DATETYPE=MMDD MMDD * L R4,CVTPTR LOAD CVT ADDRESS USING CVT,R4 CVT ADDRESSABILITY L R5,CVTEXT2 OS/VS2 COMMON EXTENSION USING CVTXTNT2,R5 CVTXTNT2 ADDRESSABILITY LMR14,R15,CVTLDTO DATE/TIME ZONE OFFSET LMR2,R3,CVTLSOLEAP SECONDS CORRECTION LMR0,R1,STCKGMT TOD CLOCK STCK VALUE * *CALCULATE LOCAL TIME = GMT TOD + CVTLDTO - CVTLSO * ALR R1,R15 CORRECT GMT BY LDTO BC8+4,TOD1IF CARRY, ALR0,=F'1' ADD 1 TO HOW ALR R0,R14 ADD LDTO HOW * TOD1 SLR R1,R3 SUBTRACT LSO LOW BC2+1,TOD2IF NO CARRY, BCTR R0,0 SUBTRACT 1 FROM HOW SLR R0,R2 SUBTRACT LSO HOW * TOD2 STM R0,R1,STCKLCL TOD CLOCK LOCAL TIME STCKCONV STCKVAL=STCKLCL, CONVERT LOCAL TIME + CONVVAL=LCLTIMED,TO + TIMETYPE=DEC, HHMMSSTHMIJU + DATETYPE=MMDD MMDD LAR1,GMTTIMED BAS R14,HEXPRT MVC GMTWTO+12(24),PHEX LAR1,LCLTIMED BAS R14,HEXPRT MVC LCLWTO+12(24),PHEX WTO MF=(E,GMTWTO) WTO GMT WTO MF=(E,LCLWTO) WTO LCL ... HEXPRT UNPK PHEX+00(8+1),00(4+1,R1) UNPK PHEX+08(8+1),04(4+1,R1) UNPK PHEX+16(8+1),08(4+1,R1) TRPHEX+00(24),HEXTAB-C'0' BRR14 PHEX DSCL25 GMTWTO WTO ' GMT: +1+2',MF=L LCLWTO WTO ' LOCAL: +1+2',MF=L STCKGMT DSD STCKLCL DSD LCLTIMED DSXL16 GMTTIMED DSXL16 HEXTAB DCC'0123456789ABCDEF' CVT DSECT=YES CVT map This produces the following output today (for the Central Daylight Savings Time Zone) [with punctuation characters manually inserted]: GMT: 22:57:14.900771 2008/03/10 LOCAL: 15:56:51.900771 2008/03/10 The above illustrates the fact that both the LDTO (time zone offset) and LSO (leap seconds correction factor) have been PROPERLY taken into account in the calculation of the local time. Some folks get it wrong. The CVTLDTO field must be ADDED to the GMT TOD Clock value, but the CVTLSO field must be SUBTRACTED from the GMT TOD Clock value to get the right local timestamp. The programmer ought to be given the choice of either. Not an issue. It just converts whatever you give it. Perhaps I'll submit an RCF. Not a bad idea. It would be nice if the documentation made clear that it's just a _conversion_ service. -- WB -- 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: clock, daylight savings time
Is CDT really 7 hours off from GMT? -Original Message- From: William H. Blair Sent: Monday, March 10, 2008 4:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: clock, daylight savings time snip This produces the following output today (for the Central Daylight Savings Time Zone) [with punctuation characters manually inserted]: GMT: 22:57:14.900771 2008/03/10 LOCAL: 15:56:51.900771 2008/03/10 -- 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: clock, daylight savings time
The service corresponding to localtime() is TIME, not STCKCONV. Bob Paul Gilmartin wrote: On Mon, 10 Mar 2008 14:23:40 -0300, Shmuel Metz (Seymour J.) wrote: As long as TZ is set properly, an OS/2 or Unix system will automatically switch to and from DST. There's a paradigm shift required here. The core UNIX function, localtime() does not automatically switch to and from DST. Rather, if localtime() is called with the same argument and with the environment variables having the same values, it will produce identical correct results whether Daylight Saving or Standard time is in effect. I believe this is in contrast to the z/OS STCKCONV service. however, I can not find in the docmentation (z/OS V1R7.0 MVS Assembler Services Reference IAR-XCT) whether STCKCONV returns local time or GMT nor how Daylight Saving and Leap Seconds are handled (possibly in accord with the table in the PoOP?) The programmer ought to be given the choice of either. Perhaps I'll submit an RCF. -- 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: clock, daylight savings time
Barry A Schwarz wrote: Is CDT really 7 hours off from GMT? No. I was confused about the time zone on the machine on which I tested the code. I have access to systems with various time zone offsets. That was really PDT (Pacific Daylight Time), not Central Daylight Time (CDT) as I stated. GMT: 22:57:14.900771 2008/03/10 (UTC [most call it GMT]) LOCAL: 15:56:51.900771 2008/03/10 (Pacific Daylight Time) PST = UTC - 8 PDT = PST + 1 spring forward PDT = UTC - 7 -- WB -- 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: clock, daylight savings time
On Mon, 10 Mar 2008 18:11:39 -0500, William H. Blair wrote: I believe this is in contrast to the z/OS STCKCONV service. however, I can not find in the docmentation (z/OS V1R7.0 MVS Assembler Services Reference IAR-XCT) whether STCKCONV returns local time or GMT nor how Daylight Saving and Leap Seconds are handled (possibly in accord with the table in the PoOP?) The programmer ought to be given the choice of either. Perhaps I'll submit an RCF. STCKCONV returns neither. It returns what it has been given. If it is given local time, then the result will be local time. If it is given GMT, then the result will be GMT. It is just a conversion service, whose input is either a 64-bit TOD clock value or a 128-bit ETOD clock value. I'm confused. I thought STCKCONV takes as input a TOD clock value, and if you operate as IBM recommends, TOD clock values are always GMT. To get a TOD clock value corrected for the local time zone and leap seconds for input to STCKCONV, you would need to execute code such as this: TIME STCK,STCKGMTCURRENT GMT TOD CLOCK STCKCONV STCKVAL=STCKGMT, CONVERT GMT TIME+ CONVVAL=GMTTIMED,TO + TIMETYPE=DEC, HHMMSSTHMIJU + DATETYPE=MMDD MMDD * How can the below give the correct result if STCKGMT is read from a log file written on the other side of a Daylight/Standard or Leap Second boundary? L R4,CVTPTR LOAD CVT ADDRESS USING CVT,R4 CVT ADDRESSABILITY L R5,CVTEXT2 OS/VS2 COMMON EXTENSION USING CVTXTNT2,R5 CVTXTNT2 ADDRESSABILITY LMR14,R15,CVTLDTO DATE/TIME ZONE OFFSET LMR2,R3,CVTLSOLEAP SECONDS CORRECTION LMR0,R1,STCKGMT TOD CLOCK STCK VALUE * *CALCULATE LOCAL TIME = GMT TOD + CVTLDTO - CVTLSO * ALR R1,R15 CORRECT GMT BY LDTO BC8+4,TOD1IF CARRY, ALR0,=F'1' ADD 1 TO HOW ALR R0,R14 ADD LDTO HOW * TOD1 SLR R1,R3 SUBTRACT LSO LOW BC2+1,TOD2IF NO CARRY, BCTR R0,0 SUBTRACT 1 FROM HOW SLR R0,R2 SUBTRACT LSO HOW * TOD2 STM R0,R1,STCKLCL TOD CLOCK LOCAL TIME STCKCONV STCKVAL=STCKLCL, CONVERT LOCAL TIME + CONVVAL=LCLTIMED,TO + TIMETYPE=DEC, HHMMSSTHMIJU + DATETYPE=MMDD MMDD LAR1,GMTTIMED BAS R14,HEXPRT MVC GMTWTO+12(24),PHEX LAR1,LCLTIMED BAS R14,HEXPRT MVC LCLWTO+12(24),PHEX WTO MF=(E,GMTWTO) WTO GMT WTO MF=(E,LCLWTO) WTO LCL ... HEXPRT UNPK PHEX+00(8+1),00(4+1,R1) UNPK PHEX+08(8+1),04(4+1,R1) UNPK PHEX+16(8+1),08(4+1,R1) TRPHEX+00(24),HEXTAB-C'0' BRR14 PHEX DSCL25 GMTWTO WTO ' GMT: +1+2',MF=L LCLWTO WTO ' LOCAL: +1+2',MF=L STCKGMT DSD STCKLCL DSD LCLTIMED DSXL16 GMTTIMED DSXL16 HEXTAB DCC'0123456789ABCDEF' CVT DSECT=YES CVT map This produces the following output today (for the Central Daylight Savings Time Zone) [with punctuation characters manually inserted]: GMT: 22:57:14.900771 2008/03/10 LOCAL: 15:56:51.900771 2008/03/10 The above illustrates the fact that both the LDTO (time zone offset) and LSO (leap seconds correction factor) have been PROPERLY taken into account in the calculation of the local time. Some folks get it wrong. The CVTLDTO field must be ADDED to the GMT TOD Clock value, but the CVTLSO field must be SUBTRACTED from the GMT TOD Clock value to get the right local timestamp. The programmer ought to be given the choice of either. Not an issue. It just converts whatever you give it. Perhaps I'll submit an RCF. Not a bad idea. It would be nice if the documentation made clear that it's just a _conversion_ service. -- 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: clock, daylight savings time
On Mon, 10 Mar 2008 19:31:58 -0400, Bob Rutledge wrote: The service corresponding to localtime() is TIME, not STCKCONV. I don't see that. localtime() has as an input a time_t, which is an affine function of physical time; the UNIX analogue of a TOD clock reading. What is the corresponding input to TIME? As I see it: The service corresponding to time() is TIME STCK[E],,ZONE=GMT (but the zone is ignored; presumed always GMT?) The service corresponding to gmtime() is STCKCONV I know of no service corresponding to localtime(). Can you help me with this? -- 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: clock, daylight savings time
Paul Gilmartin wrote: I'm confused. I thought STCKCONV takes as input a TOD clock value, and if you operate as IBM recommends, TOD clock values are always GMT. STCKCONV takes a TOD clock-FORMAT value as input. What that is, or what that input represents, is YOUR business. STCKCONV is just a conversion service, provided as a built-in function by z/OS. STCKCONV will convert _any_ TOD STCK- or STCKE-format TOD clock timestamp value to its corresponding human readable time and date (although its output is in packed decimal, so you first have to convert it to zoned decimal before you can actually print it). How can the [program I illustrated] give the correct result if STCKGMT is read from a log file written on the other side of a Daylight/Standard or Leap Second boundary? If by the phrase correct result you mean actual LOCAL TIME then it can't and won't. That is not what I was trying to show you. I was demonstrating and illustrating the fact that that, for input to STCKCONV, you HAVE TO ALREADY HAVE a corrected local time stamp value (in STCK or STCKE format) in order to get the correct LOCAL TIME out of the STCKCONV service. The purpose of the program was to demonstrate that you can't get what you call the correct result out of STCKCONV with JUST a TOD clock value. If you have TOD clock values recorded in a data set (such as a log file of some sort) then you will simply have to know (if you did not also record the contemporaneous values of the LSO and LDTO fields) and be able to reproduce them. In some cases, of course, this information is known. For example, the value of CVTLSO is pretty constant, and can actually be looked up in a table whose argument is GMT, because when LSO changes and, in the past, has changed, is set by international agreement and is published. So that does not need to be recorded with the STCK[E] values, if you are willing to go to the trouble of looking it up in a table. The value of LDTO is simply time zone-dependent, and if you know the time zone of the machine that produced the data then that can be looked up in another table. There are two boundary conditions that are difficult to deal with, but for the most part, unless you are writing an operating system or a product, you don't really need this data recorded. It's easier of course if you do have it, but it costs you an extra 16 or 32 bytes in your log records or whatever. -- WB -- 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: clock, daylight savings time
Paul Gilmartin wrote: As I see it: The service corresponding to time() is TIME STCK[E],,ZONE=GMT Except for the difference in epoch and radix, the UNIX time() function is conceptually equivalent to z/OS TIME STCK[E],addr or TIME BIN,addr,ZONE=GMT or TIME DEC,addr,ZONE=GMT. (but the zone is ignored; presumed always GMT?) In the case of TIME STCK[E],addr the value of the TOD clock, whatever it is set to (presumably UTC or GMT), is returned, and ZONE=whatever is ignored. It would have been nice if z/OS had implemented the following function: TIME STCK[E],addr,ZONE=LT (that is, when STCK[E] is specified, ZONE is _NOT_ ignored) But since TIME STCK[E] _does_ ignore ZONE=whatever, you have to use the code I illustrated to get a corrected TOD clock LOCAL timestamp value. The service corresponding to gmtime() is STCKCONV Nope. STCKCONV is just a formatting conversion service. It does not return anything about the current time or date on the system on which it is executed. In z/OS what corresponds to the UNIX gmtime() function is (at best) TIME BIN,addr,ZONE=GMT or TIME DEC,addr,ZONE=GMT. I know of no service corresponding to localtime(). In z/OS what corresponds to the UNIX localtime() function is (at best) TIME BIN,addr,ZONE=LT or TIME DEC,addr,ZONE=LT. There is no built-in z/OS service I know of that will return a TOD clock-format (STCK or STCKE) value that has been corrected to represent the local time. -- WB -- 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
clock, daylight savings time
I'm new...to this list and at my new job... Question about setting the clock: Haven't IPL'd in 4 months, so tonight I'm going to IPL the production z/OS 1.7 LPAR and similar test LPAR (each a monoplex) to pick up a new SYS1.PARMLIB(CLOCK00) with a different offset to Greenwich Mean Time (7 instead of 8 for Pacific). Shutdown will quiesce everything nicely. Systems are simple, mostly CICS and MQ. And I come from more of an internals/development background, and haven't been around operations nor hardware lately. Question is: do I have to reset any secondary time of day clock that the HDC (this is some kind of Z9 with a HDC that I think runs some kind of UNIX as its embedded system??) uses for things like hardware time stamps or knowing when to call home or something? My point is, GMT did not change, so I don't need to change any hardware CPU TOD clock for z/OS (not like the old days when we'd set to local). But do I need to make other clock changes for the HCD part of the hardware itself or does it operate on GMT or something? If I need to do more, what's involved? Do I need to do some kind of power-on reset? For the LPAR or for the whole box or whole HCD? Or does IBM take care of that? -- 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: clock, daylight savings time
On Sat, 8 Mar 2008 14:31:26 -0800, Gregory Pinkowski [EMAIL PROTECTED] wrote: I'm new...to this list and at my new job... Question about setting the clock: Haven't IPL'd in 4 months, so tonight I'm going to IPL the production z/OS 1.7 LPAR and similar test LPAR (each a monoplex) to pick up a new SYS1.PARMLIB(CLOCK00) with a different offset to Greenwich Mean Time (7 instead of 8 for Pacific). Shutdown will quiesce everything nicely. This is out of my area of expertise. But from what I recall from previous semiannual postings to this list: o IPL shouldn't be necessary. o Change the local time offset with an operator command. o The updated PARMLIB member will cover the next IPL. o If you have a Sysplex Timer, you can schedule the change in the Sysplex Timer. o Your Unix System Services TZ variables should be set to PST8PDT. There is no time change for UNIX. o Going forward is very safe. Going back is only a problem if you have applications so benighted as to keep critical timestamps in local time, and then to be upset when it regresses. -- 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: clock, daylight savings time
Gil, - Thanks a ton. No coupling facility from what I'm told, GRS via couple dataset (I'm used to MIM via CTC, so this is new to me too). I just want to prove periodically an IPL works, I know it's not necessary. I just haven't seen one at this site since I started here, and I want to compare the start-up to some timing issues I've see starting the disaster recovery machine. USS exists only to support TCPIP, NPF and MQ as necessary. - Greg BTW when I shut down the test LPAR yesterday, z/OS didn't seem to recognize the hardware console as a z/OS console until I cause an interrupt after it's lost the other consoles. Is this normal? -- 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
