Re: Time Change (Sync)
Hi Steve, the very modern island of Singapore. Quite the tropical island paradise, if you enjoy technology while sitting on the beach sipping amber fluid. On Sun, 15 Mar 2009 09:21:06 -0600, Steve Comstock st...@trainersfriend.com wrote: Bruce Hewson wrote: [snip] Bruce Hewson Resident, Tropical Island Paradise. So, I have to ask: where is that? Kind regards, -Steve Comstock The Trainer's Friend, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Bruce Hewson wrote: Hi Steve, the very modern island of Singapore. Quite the tropical island paradise, if you enjoy technology while sitting on the beach sipping amber fluid. Ah, yes. Very nice. I taught a couple of DB2 courses for DBS many years ago. Had a grand time. Got any training needs there these days? On Sun, 15 Mar 2009 09:21:06 -0600, Steve Comstock st...@trainersfriend.com wrote: Bruce Hewson wrote: [snip] Bruce Hewson Resident, Tropical Island Paradise. So, I have to ask: where is that? Kind regards, -Steve Comstock The Trainer's Friend, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Folks Time updates due DST..again we have much discussion. But I would like any comments regarding z/OS time, when the customers accessing the system are not physically located in the same time zone. I believe the ISO standards support local time display with timezone infomation such as EST appended. But with timezone acronym usage overloaded...i.e. EST means Eastern Standard Time, but for which continent. Although we support applications accessed in other time zones, some of which do have Daylight Savings adjustments, we do not change our machine time. The users see local time via adjustments made by the application performing the display. The Unix approach is one way, but it is not a simple as can be made out, as the timezone information is kept in more than one location. And it does only apply to the local machine, and not to remote user access points. With globalization continuing, I see a need for a standard that allows the host system to run in pure UTC, with only access points modifyng the time display as required at that access point. At least, here wher I work, I no longer have to play with time changes bi- annually. Regards, and thanks for reading, Bruce Hewson Resident, Tropical Island Paradise. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
On Sun, 15 Mar 2009 03:35:57 -0500, Bruce Hewson wrote: Although we support applications accessed in other time zones, some of which do have Daylight Savings adjustments, we do not change our machine time. The users see local time via adjustments made by the application performing the display. Good. The Unix approach is one way, but it is not a simple as can be made out, as the timezone information is kept in more than one location. And it does only Don't judge the Unix approach by the idiosyncrasies of IBM, which does worse than most other vendors. For example, in both Solaris and OS X the file or link /etc/localtime provides the last resort system default -- no need to keep the information in more than one location. But it's not a POSIX requirement, and IBM doesn't do it. apply to the local machine, and not to remote user access points. Applications connecting to remote user access points can localize by using the environment variable TZ and the tzset() function. With globalization continuing, I see a need for a standard that allows the host system to run in pure UTC, with only access points modifyng the time display as required at that access point. That pretty much is the Unix approach. One regrettable exception is that the crontab facility does not support offsets for user acces points. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
On Sun, 2009-03-15 at 06:43 -0500, Paul Gilmartin wrote: Don't judge the Unix approach by the idiosyncrasies of IBM, which does worse than most other vendors. For example, in both Solaris and OS X the file or link /etc/localtime provides the last resort system default -- no need to keep the information in more than one location. But it's not a POSIX requirement, and IBM doesn't do it. M - localtime is a handy reference. Still leaves the small matter of tzdata which must be kept up to date depending on the vagaries of various world-wide intellectual light-weights that happen to have fallen into positions of influence in their own little ponds. Despite Pauls protestations, even the (pure ) *nix world is somewhat subject to the limitations of bureaucratic stupidity. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
At 15:57 -0500 on 03/14/2009, Paul Gilmartin wrote about Re: Time Change (Sync): On Sat, 14 Mar 2009 16:07:31 -0400, Robert A. Rosenberg wrote: Since the time change only needs to occur twice a year, it should not be that hard to have a started task running that will update CVTLDTO when 2AM on a switch morning occurs. The task is fired off at midnight on a switch day and then waits for 120 minutes to do its thing and exit. Good. You avoided the loop pitfall that has been known to trap some programmers. But does the SET TIMEZONE operator command have any additional effects that this process would omit? The first think of is making necessary adjustments for clock comparator values for STIMER LT= queue elements. -- gil If updating CVTLDTO is not totally adequate and the use of SET TIMEZONE is needed, then the daemon can use SVC 34 to issue the command in lieu of updating the CVT directly (remember that the utility must be running authorized to have write access to the CVT) so being allowed to use SVC 34 is not an extra problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
On Fri, 13 Mar 2009 18:45:33 +0100, SCHARITZER Gerald wrote: In the z/OS UNIX world the time zone is specified in the TZ environment variable. The information herein contains the UTC offset plus DST rules. TZ remains constant, when switching to and from DST. It only tells functions like localtime(), when to apply DST and when not. This algorithm does not require periodic maintenance of local time. Say that three times; it's true. Too many programmers suffer MVS tunnel vision and believe some maintenance is required at the DST boundary. In other operating systems, better designed IMO, it's unnecessary. In the z/OS MVS world the time zone is stored in CVTLDTO, which only contains the UTC offset. This makes life easy for the TIME macro, which simply adds the offset to UTC to obtain local time. However, CVTLDTO does not remain constant throughout the year. Switching to and from DST literally means to modify CVTLDTO accordingly. In order to keep z/OS UNIX and z/OS MVS local time in sync, CVTLDTO must be adjusted at exactly those points in time, when the DST algorithm of TZ kicks in. Exactly matters. Is this serialized, or might the update of CVTLDTO occur a few microseconds away from that boundary, yielding invalid local times such as 2009-03-08 02:00:00.01 or incorrect local times, such as 2009-11-01 02:00:00.01 (which can only be Standard Time) when the Standard time was actually 01:00:00.01. Such windows can be closed by saving the CVTLDTO value before the STCK and comparing the value after the STCK. And human beings want to see log timestamps in local time, but z/OS outside UNIX provides no facility for converting UTC to local time. NTP considers only UTC and has nothing to do with local time, time zones or daylight saving time. Both ETR and STP allow the specification of an ETS (external time source), to automatically adjust the clock and/or the UTC offset. Again this only modifies CVTLDTO and has no effect on TZ based time. Alas, there are yet leap seconds, which affect NTP. Is NTP now leap second savvy, so it doesn't ring with damped oscillations for minutes after a leap second. I consider it a design blunder that the standards require computer systems to operate on UTC when UT1 is more practical. z/OS does its best to deal with leap seconds, and suffers for being better than most of the rest of the world. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
At 18:45 +0100 on 03/13/2009, SCHARITZER Gerald wrote about Re: Time Change (Sync): In the z/OS MVS world the time zone is stored in CVTLDTO, which only contains the UTC offset. This makes life easy for the TIME macro, which simply adds the offset to UTC to obtain local time. However, CVTLDTO does not remain constant throughout the year. Switching to and from DST literally means to modify CVTLDTO accordingly. In order to keep z/OS UNIX and z/OS MVS local time in sync, CVTLDTO must be adjusted at exactly those points in time, when the DST algorithm of TZ kicks in. Since the time change only needs to occur twice a year, it should not be that hard to have a started task running that will update CVTLDTO when 2AM on a switch morning occurs. The task is fired off at midnight on a switch day and then waits for 120 minutes to do its thing and exit. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
On Sat, 14 Mar 2009 16:07:31 -0400, Robert A. Rosenberg wrote: Since the time change only needs to occur twice a year, it should not be that hard to have a started task running that will update CVTLDTO when 2AM on a switch morning occurs. The task is fired off at midnight on a switch day and then waits for 120 minutes to do its thing and exit. Good. You avoided the loop pitfall that has been known to trap some programmers. But does the SET TIMEZONE operator command have any additional effects that this process would omit? The first think of is making necessary adjustments for clock comparator values for STIMER LT= queue elements. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
At 14:29 -0700 on 03/12/2009, Gibney, Dave wrote about Re: Time Change (Sync): Clocks are a different story. Twice a year I have to take the sh*t about how hard or expensive it is to have our z9 in sync with the rest of the world. Why is your CPU clock not set to GMT/UT? That would insure that there is no need to reset the clock - Just update the local time offset twice a year. So long as time stamps are in GMT, the DST/ST switches should not affect anything important. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Before I got here the TODs on the CPCs had always been set to local time, so it might be just a historical quirk at some installations based on the original installation choice many years ago. I remember when we changed from TOD=LOCAL to TOD=GMT+offset about 10+ years ago. Painful, but the results are worth it. In our case because we're ahead of GMT (Aussies) it was a bit of a trick to get the couple datasets right but no drama after testing (there was a recent discussion on couple datasets and time changes). Now it's just adding or taking away the DST offset on whatever is the sysplex's time source, STP or Timers depending on the plex. Note that we still have to bounce some CICS regions as their apps can't tolerate the backwards move, but going forwards is no outage and backwards is really no drama except for wayward apps like ours who use local time instead of GMT. cheers Peter On Fri, 13 Mar 2009 01:49:00 -0400, Robert A. Rosenberg hal9...@panix.com wrote: At 14:29 -0700 on 03/12/2009, Gibney, Dave wrote about Re: Time Change (Sync): Clocks are a different story. Twice a year I have to take the sh*t about how hard or expensive it is to have our z9 in sync with the rest of the world. Why is your CPU clock not set to GMT/UT? That would insure that there is no need to reset the clock - Just update the local time offset twice a year. So long as time stamps are in GMT, the DST/ST switches should not affect anything important. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Gibney, Dave gib...@wsu.edu wrote in message news:edfbe8a9b39ed541ba3c8177c32ff0c898c...@exchangevs-02.ad.wsu.edu.. . -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant Sent: Thursday, March 12, 2009 1:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) On Thu, 12 Mar 2009 13:01:00 -0700, Dave Gibney wrote: ... What would it really get us? One production LPAR, one Development LPAR and a couple sandboxes. In that case, clock synchronization is probably much less critical. Clocks are a different story. Twice a year I have to take the sh*t about how hard or expensive it is to have our z9 in sync with the rest of the world. The idea of paying for setting the time is ludicrous to any herder of small boxen. Even though I understand the need for the z/clock to be highly secure, I think IBM does a disservice to all of us who work the platform in small shops. And, I avoid POR like the plague. Another idea: now that everybody is converting to STP, Sysplex Timers will become cheap. Why not buy one (or two), connect them to your individual CPU's and connect them with a modem to a timeserver? That is all the hardware you need. It is possibly for the shorter term future, but as long as you z/boxes support a Sysplex Timer, it will work. 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
It has been on GMT for a couple decades. Still, it took an IPL before 1.7 when SET TIMEZONE became available. The further question isn't so much semi-annual changes as it is clock drift. Takes a POR to fix that. And yah, maybe used sysplex timers are getting cheap. Cheap is not free, which is what NTP is for any other box. Some may have noticed a recession going on. Currently, we need approval from the Governor! To spend $5K or more. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert A. Rosenberg Sent: Thursday, March 12, 2009 10:49 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) At 14:29 -0700 on 03/12/2009, Gibney, Dave wrote about Re: Time Change (Sync): Clocks are a different story. Twice a year I have to take the sh*t about how hard or expensive it is to have our z9 in sync with the rest of the world. Why is your CPU clock not set to GMT/UT? That would insure that there is no need to reset the clock - Just update the local time offset twice a year. So long as time stamps are in GMT, the DST/ST switches should not affect anything important. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Dear Colleagues, I would like to split the term in sync with the rest of the world in two separate topics. Hardware Clock Synchronization == The objective of this is to keep the mutual differences of the hardware clocks of a set of machines below some limit. This can be done with ETR, STP, NTP and probably several other protocols. Local Time Synchronization == Assuming that the clocks of a given set of machines are in sync, the objective is to produce the same mapping of hardware clock time - which is usually an unsigned binary integer obtained from a binary counter - to local time (year, month, day, hour, ...) for identical time zones. This already poses a challenge to z/OS, because there are two different sources of time zone information. In the z/OS UNIX world the time zone is specified in the TZ environment variable. The information herein contains the UTC offset plus DST rules. TZ remains constant, when switching to and from DST. It only tells functions like localtime(), when to apply DST and when not. This algorithm does not require periodic maintenance of local time. In the z/OS MVS world the time zone is stored in CVTLDTO, which only contains the UTC offset. This makes life easy for the TIME macro, which simply adds the offset to UTC to obtain local time. However, CVTLDTO does not remain constant throughout the year. Switching to and from DST literally means to modify CVTLDTO accordingly. In order to keep z/OS UNIX and z/OS MVS local time in sync, CVTLDTO must be adjusted at exactly those points in time, when the DST algorithm of TZ kicks in. NTP considers only UTC and has nothing to do with local time, time zones or daylight saving time. Both ETR and STP allow the specification of an ETS (external time source), to automatically adjust the clock and/or the UTC offset. Again this only modifies CVTLDTO and has no effect on TZ based time. kind regards and have a nice weekend Ing. Gerald Scharitzer, BSc Advanced System Specialist Technology Tools WAVE Solutions Information Technology GmbH International Services London Member of UniCredit Group 18 Mansell Street, London E1 8AA, UK phone: +44 (0) 20 7170 1977 mobile: +44 (0) 7866 493242 fax: +44 (0) 20 7481 0306 mailto:gerald.scharit...@wave-solutions.com http://www.wave-solutions.com Company name: WAVE Solutions Information Technology GmbH, Company location: Vienna Register of company: Handelsgericht Wien, FN: 122529s Branch: WAVE Solutions Information Technology GmbH International Services London, Reference number: CN FC016222 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Thursday, March 12, 2009 9:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) Clocks are a different story. Twice a year I have to take the sh*t about how hard or expensive it is to have our z9 in sync with the rest of the world. The idea of paying for setting the time is ludicrous to any herder of small boxen. Even though I understand the need for the z/clock to be highly secure, I think IBM does a disservice to all of us who work the platform in small shops. And, I avoid POR like the plague. Got bit this year by an application. Used SET TIMEZONE to spring forward. EntireX servers were an hour off until we noticed when a time critical window opened late. Of course, I don't think even Parallel Sysplex would have helped with this one. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
On 12 Mar 2009 23:25:29 -0700, hal9...@panix.com (Robert A. Rosenberg) wrote: Why is your CPU clock not set to GMT/UT? That would insure that there is no need to reset the clock - Just update the local time offset twice a year. So long as time stamps are in GMT, the DST/ST switches should not affect anything important. Every computer in the world that uses a clock should be on GMT/UT, and when local time is important, use the offset. That includes the computer in my iPod. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Cost. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Timothy Sipples Sent: Thursday, March 12, 2009 12:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) Mark Steely writes: We are z/OS V1R9 on a z/10 2098-N01 processor. We have 2 CPU's both z/10 2098 - not sysplex. Naive question (and hopefully still related to your core question): why no Parallel Sysplex? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
To clarify as another site not sysplexing. Coupling Facilities cost money. Then, setting up the plex takes people time. Finally, What would it really get us? One production LPAR, one Development LPAR and a couple sandboxes. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Steely Sent: Thursday, March 12, 2009 8:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) Cost. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Timothy Sipples Sent: Thursday, March 12, 2009 12:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) Mark Steely writes: We are z/OS V1R9 on a z/10 2098-N01 processor. We have 2 CPU's both z/10 2098 - not sysplex. Naive question (and hopefully still related to your core question): why no Parallel Sysplex? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Economic stimulus for IBM :-D Sorry. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Thursday, March 12, 2009 3:01 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) To clarify as another site not sysplexing. Coupling Facilities cost money. Then, setting up the plex takes people time. Finally, What would it really get us? One production LPAR, one Development LPAR and a couple sandboxes. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Steely Sent: Thursday, March 12, 2009 8:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) Cost. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Timothy Sipples Sent: Thursday, March 12, 2009 12:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) Mark Steely writes: We are z/OS V1R9 on a z/10 2098-N01 processor. We have 2 CPU's both z/10 2098 - not sysplex. Naive question (and hopefully still related to your core question): why no Parallel Sysplex? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
On Thu, 12 Mar 2009 13:01:00 -0700, Dave Gibney wrote: ... What would it really get us? One production LPAR, one Development LPAR and a couple sandboxes. In that case, clock synchronization is probably much less critical. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant Sent: Thursday, March 12, 2009 1:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) On Thu, 12 Mar 2009 13:01:00 -0700, Dave Gibney wrote: ... What would it really get us? One production LPAR, one Development LPAR and a couple sandboxes. In that case, clock synchronization is probably much less critical. Clocks are a different story. Twice a year I have to take the sh*t about how hard or expensive it is to have our z9 in sync with the rest of the world. The idea of paying for setting the time is ludicrous to any herder of small boxen. Even though I understand the need for the z/clock to be highly secure, I think IBM does a disservice to all of us who work the platform in small shops. And, I avoid POR like the plague. Got bit this year by an application. Used SET TIMEZONE to spring forward. EntireX servers were an hour off until we noticed when a time critical window opened late. Of course, I don't think even Parallel Sysplex would have helped with this one. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
On Thu, 12 Mar 2009 14:29:05 -0700, Gibney, Dave wrote: Got bit this year by an application. Used SET TIMEZONE to spring forward. EntireX servers were an hour off until we noticed when a time critical window opened late. Of course, I don't think even Parallel Sysplex would have helped with this one. I don't understand this one. What's an EntireX server. o How did it get it wrong? o Didn't it use the TIME macro? o Did it read the offset parameters from CVT at startup and forget to refresh them? o Did it STIMER to the start of the window and overlook the SET TIMEZONE? o Did it use STIMER DINTVL= when STIMER LT= would have been proper? o What happens with an outstanding STIMER LT= when the clock is advanced/retarded for Daylight Saving Time - From the console? - By ETR or STP? In which of these cases does z/OS DTRT? Is there so little information in the RM that a RCF is appropriate? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
See below Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Thursday, March 12, 2009 3:03 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Time Change (Sync) On Thu, 12 Mar 2009 14:29:05 -0700, Gibney, Dave wrote: Got bit this year by an application. Used SET TIMEZONE to spring forward. EntireX servers were an hour off until we noticed when a time critical window opened late. Of course, I don't think even Parallel Sysplex would have helped with this one. I don't understand this one. What's an EntireX server. EntireX is a Software AG middleware product. The servers are long running STC. We use Natural programs inside them. o How did it get it wrong? The time was off one hour until we discovered and rolled them o Didn't it use the TIME macro? o Did it read the offset parameters from CVT at startup and forget to refresh them? o Did it STIMER to the start of the window and overlook the SET TIMEZONE? o Did it use STIMER DINTVL= when STIMER LT= would have been proper? Don't know these answers, I'm just a SAG customer. o What happens with an outstanding STIMER LT= when the clock is advanced/retarded for Daylight Saving Time - From the console? - By ETR or STP? In which of these cases does z/OS DTRT? Is there so little information in the RM that a RCF is appropriate? Don't know these answers, I'm just an IBM customer :) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Perhaps you already know about this, but there is something called a qualifying Parallel Sysplex required to obtain aggregated software licensing. Here's some more information: http://www.ibm.com/servers/eserver/zseries/swprice/sysplex/ There are also scenarios where Parallel Sysplex may provide more efficient utilization of resources, allowing otherwise smaller capacity settings on members of the Sysplex (and/or deferring capacity increases). This depends on your workloads, of course. And, then of course, there are the positive attributes of Parallel Sysplex itself, attributes which may have cost benefits elsewhere in the organization. Your situation may vary, but it's important to run a full and realistic analysis. You may have done that already, but perhaps these comments are at least useful to others. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Time Change (Sync)
We are z/OS V1R9 on a z/10 2098-N01 processor. We have 2 CPU's both z/10 2098 - not sysplex. We do have a CTC connection between the two machines. What would be the best way to have the time automatically be sync with each other and with GMT. I have heard of sysplex timers , but I don't think that how it is handled now. Any insight would be helpful. Thank You -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Mark, The follow on from Sysplex timers is Server Time Protocol. It is microcode on the processors and uses the HMC. It isn't free however. Search the Redbook Library (there are 2 volumes, perhaps three) on the topic. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Steely Sent: Wednesday, March 11, 2009 17:10 To: IBM-MAIN@bama.ua.edu Subject: Time Change (Sync) We are z/OS V1R9 on a z/10 2098-N01 processor. We have 2 CPU's both z/10 2098 - not sysplex. We do have a CTC connection between the two machines. What would be the best way to have the time automatically be sync with each other and with GMT. I have heard of sysplex timers , but I don't think that how it is handled now. Any insight would be helpful. Thank You -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
And I have a feeling that CTCs aren't sufficient - I think you need coupling links. But I've never implemented it, so check the doco as Alan mentioned. Shane ... On Wed, 2009-03-11 at 19:19 -0500, Field, Alan C. wrote: The follow on from Sysplex timers is Server Time Protocol. It is microcode on the processors and uses the HMC. It isn't free however. Search the Redbook Library (there are 2 volumes, perhaps three) on the topic. -Original Message- Mark Steely We are z/OS V1R9 on a z/10 2098-N01 processor. We have 2 CPU's both z/10 2098 - not sysplex. We do have a CTC connection between the two machines. What would be the best way to have the time automatically be sync with each other and with GMT. I have heard of sysplex timers , but I don't think that how it is handled now. Any insight would be helpful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Mark Steely writes: We are z/OS V1R9 on a z/10 2098-N01 processor. We have 2 CPU's both z/10 2098 - not sysplex. Naive question (and hopefully still related to your core question): why no Parallel Sysplex? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Time Change (Sync)
Yep, you definitely need Coupling Links. And the STP feature is a priced one, about the same (perhaps slightly less) than the Timer. The redbooks Shane mentioned are the go. There's quite a bit to it. cheers Peter On Thu, 12 Mar 2009 11:41:43 +1000, Shane ibm-m...@tpg.com.au wrote: And I have a feeling that CTCs aren't sufficient - I think you need coupling links. But I've never implemented it, so check the doco as Alan mentioned. Shane ... On Wed, 2009-03-11 at 19:19 -0500, Field, Alan C. wrote: The follow on from Sysplex timers is Server Time Protocol. It is microcode on the processors and uses the HMC. It isn't free however. Search the Redbook Library (there are 2 volumes, perhaps three) on the topic. -Original Message- Mark Steely We are z/OS V1R9 on a z/10 2098-N01 processor. We have 2 CPU's both z/10 2098 - not sysplex. We do have a CTC connection between the two machines. What would be the best way to have the time automatically be sync with each other and with GMT. I have heard of sysplex timers , but I don't think that how it is handled now. Any insight would be helpful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
