Re: STIMERM LT value
STP is more accurate than NTP for coordinating the clocks in your data center, but it doesn't eliminate the need to compensate for drift. You still need to periodically use an official time source via NTP. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Saturday, May 15, 2021 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STIMERM LT value On Sat, 15 May 2021 03:51:45 -0700, Ed Jaffe wrote: >On 5/14/2021 9:53 PM, Alan Altmark wrote: >> >> Then if the client wants to reduce the price by redlining items, that's on >> them, but I think IBM or the BP should be bringing a full function proposal. > >Car radios used to be extra. Now they come free and standard. Historical >lineage notwithstanding, 21st-Century mainframes should come with STP >free and standard. Not doing so has already proved itself time and time >again to be a source of embarrassment for our platform... > TANSTAAFL. More so safety equipment, now require by law. But still ... Is it IP restriction or technological complexity that precludes ISVs' offering a competing product at a competitive price? I miss the Consent Decree. Are the clock steering instructions described in some detail in the PoOps part of the option? Even SCK, now? OK. STP is a thousand times more accurate than NTP, but some customers would be satisfied with the latter for a thousandth the price. it's better than adding a minute to CLOCKxx. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On Sat, 15 May 2021 03:51:45 -0700, Ed Jaffe wrote: >On 5/14/2021 9:53 PM, Alan Altmark wrote: >> >> Then if the client wants to reduce the price by redlining items, that's on >> them, but I think IBM or the BP should be bringing a full function proposal. > >Car radios used to be extra. Now they come free and standard. Historical >lineage notwithstanding, 21st-Century mainframes should come with STP >free and standard. Not doing so has already proved itself time and time >again to be a source of embarrassment for our platform... > TANSTAAFL. More so safety equipment, now require by law. But still ... Is it IP restriction or technological complexity that precludes ISVs' offering a competing product at a competitive price? I miss the Consent Decree. Are the clock steering instructions described in some detail in the PoOps part of the option? Even SCK, now? OK. STP is a thousand times more accurate than NTP, but some customers would be satisfied with the latter for a thousandth the price. it's better than adding a minute to CLOCKxx. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On 5/14/2021 9:53 PM, Alan Altmark wrote: Help me with this, Ed. Did you receive a proposal that didn't include STP? Or at least offer it as an option? If it wasn't offered, that bothers me. IMO, all proposals should include cryptos (where not prohibited by law), a pair of copper OSAs, six or more fiber OSAs (speed and type customer choice), a pair of RoCE cards, STP, STP links, and a pair of HMCs (unless you already have them). If it's an IFL box, then add some FCP adapters. Getting this stuff in the initial sale is going to be cheaper than adding it later. Then if the client wants to reduce the price by redlining items, that's on them, but I think IBM or the BP should be bringing a full function proposal. Are you just making this stuff up as you go along? This is absolutely *not* how proposals are built for existing customers -- at least not in my 40+ years of experience. If IBM threw in everything but the kitchen sink, customers would get upset. Whether an MES or a "net new" machine, IBM and/or the business partner takes your existing configuration and upgrades it to the latest kit. It has always been thus. You can add stuff, of course. Car radios used to be extra. Now they come free and standard. Historical lineage notwithstanding, 21st-Century mainframes should come with STP free and standard. Not doing so has already proved itself time and time again to be a source of embarrassment for our platform... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
History, reasoning, and anything else notwithstanding, charging for something that all other hardware does for FREE is hard to justify to a bean counter (or for that matter, most reasonable people) Ed used the correct word. Embarrassing. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Alan Altmark > Sent: Friday, May 14, 2021 9:53 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: STIMERM LT value > > On Fri, 14 May 2021 05:28:52 -0700, Ed Jaffe > wrote: > >Reasonable people can disagree about what the word "pricey" means, but > >no one can defend the indefensible. > > > >Every Intel-based Linux, Windows or Mac, at every hardware price-point, > >can synchronize its clock with an external NTP sever in real-time > >without a reboot. > > The lineage and history of the clocks and time on microprocessors is very > different than that of the mainframe and leads inevitably to the OS needing > to use NTP and have the OS be the Arbiter of Time. (Do apps call > gettimeofday() or do they read the timestamp register? They call > gettimeofday().) > > On the mainframe, we allowed (encouraged?) applications (subsystems, > user apps, middleware) to use the TOD clock. STORE CLOCK is an > unprivileged instruction. And the tradition predates the introduction of leap > seconds, so everyone calculated the same time using the same algorithm > over and over and over and over again. If you have someone doing STCK, > but not using CVTLSO, they're likely to calculate the wrong time. At the end > of the day (no pun intended), the TOD clock needs to be in sync with UTC. > And once that decision is made, it becomes an obvious waste of resources to > implement an ntp client in the OS. > > With ntp, if multiple servers are all synced to the same time source then they > are, by acclamation, synced with each other. But that's not good enough > since there are lots of places with TOD clock or TOD clock-based values. > They need to be on the same time line. > > >For the high six-figure price we paid for our z15, it should have come > >with similar functionality built-in, but didn't. > > > >IBM's current positioning in this regard, as Dave Gibney and others > >discovered, is a source of embarrassment for the platform. > > Help me with this, Ed. Did you receive a proposal that didn't include STP? > Or > at least offer it as an option? If it wasn't offered, that bothers me. IMO, > all > proposals should include cryptos (where not prohibited by law), a pair of > copper OSAs, six or more fiber OSAs (speed and type customer choice), a > pair of RoCE cards, STP, STP links, and a pair of HMCs (unless you already > have them). If it's an IFL box, then add some FCP adapters. Getting this > stuff in the initial sale is going to be cheaper than adding it later. > > Then if the client wants to reduce the price by redlining items, that's on > them, but I think IBM or the BP should be bringing a full function proposal. > > Alan Altmark > IBM > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On 5/14/2021 9:53 PM, Alan Altmark wrote: Help me with this, Ed. Did you receive a proposal that didn't include STP? Or at least offer it as an option? If it wasn't offered, that bothers me. IMO, all proposals should include cryptos (where not prohibited by law), a pair of copper OSAs, six or more fiber OSAs (speed and type customer choice), a pair of RoCE cards, STP, STP links, and a pair of HMCs (unless you already have them). If it's an IFL box, then add some FCP adapters. Getting this stuff in the initial sale is going to be cheaper than adding it later. Then if the client wants to reduce the price by redlining items, that's on them, but I think IBM or the BP should be bringing a full function proposal. If a mainframe proposal (in this case a formal configuration list with pricing) contains features not on the machine being upgraded and/or not talked about with the customer before they see the proposal, I can just see the sparks flying. Not a good idea. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On Fri, 14 May 2021 05:28:52 -0700, Ed Jaffe wrote: >Reasonable people can disagree about what the word "pricey" means, but >no one can defend the indefensible. > >Every Intel-based Linux, Windows or Mac, at every hardware price-point, >can synchronize its clock with an external NTP sever in real-time >without a reboot. The lineage and history of the clocks and time on microprocessors is very different than that of the mainframe and leads inevitably to the OS needing to use NTP and have the OS be the Arbiter of Time. (Do apps call gettimeofday() or do they read the timestamp register? They call gettimeofday().) On the mainframe, we allowed (encouraged?) applications (subsystems, user apps, middleware) to use the TOD clock. STORE CLOCK is an unprivileged instruction. And the tradition predates the introduction of leap seconds, so everyone calculated the same time using the same algorithm over and over and over and over again. If you have someone doing STCK, but not using CVTLSO, they're likely to calculate the wrong time. At the end of the day (no pun intended), the TOD clock needs to be in sync with UTC. And once that decision is made, it becomes an obvious waste of resources to implement an ntp client in the OS. With ntp, if multiple servers are all synced to the same time source then they are, by acclamation, synced with each other. But that's not good enough since there are lots of places with TOD clock or TOD clock-based values. They need to be on the same time line. >For the high six-figure price we paid for our z15, it should have come >with similar functionality built-in, but didn't. > >IBM's current positioning in this regard, as Dave Gibney and others >discovered, is a source of embarrassment for the platform. Help me with this, Ed. Did you receive a proposal that didn't include STP? Or at least offer it as an option? If it wasn't offered, that bothers me. IMO, all proposals should include cryptos (where not prohibited by law), a pair of copper OSAs, six or more fiber OSAs (speed and type customer choice), a pair of RoCE cards, STP, STP links, and a pair of HMCs (unless you already have them). If it's an IFL box, then add some FCP adapters. Getting this stuff in the initial sale is going to be cheaper than adding it later. Then if the client wants to reduce the price by redlining items, that's on them, but I think IBM or the BP should be bringing a full function proposal. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On 5/13/2021 10:19 PM, Alan Altmark wrote: Ed, I won't argue the point of "Why isn't in a standard feature?" (I wish it was, too), but I will take issue with "pricey". I was surprised at how inexpensive it actually is, particularly when I look at what it does. Reasonable people can disagree about what the word "pricey" means, but no one can defend the indefensible. Every Intel-based Linux, Windows or Mac, at every hardware price-point, can synchronize its clock with an external NTP sever in real-time without a reboot. For the high six-figure price we paid for our z15, it should have come with similar functionality built-in, but didn't. IBM's current positioning in this regard, as Dave Gibney and others discovered, is a source of embarrassment for the platform. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On Tue, 11 May 2021 03:25:35 -0700, Ed Jaffe wrote: >We experienced significant clock drift on our z13s. (I can't understand >why IBM makes STP optional and pricey. All Z machines should be able to >synchronize to NIST.) Ed, I won't argue the point of "Why isn't in a standard feature?" (I wish it was, too), but I will take issue with "pricey". I was surprised at how inexpensive it actually is, particularly when I look at what it does. >Our z15 has gone through a full POR several times since being installed >in August 2020 (see the video https://youtu.be/uis-8s_O1K8), the most >recent one being just a few weeks ago. So, it's difficult to know yet if >similar adjustments will be required. If they are, we stand ready to >adjust our CLOCKxx member as needed. I think you'll find the z15 has a more stable clock. But you need to back up and look at your business requirements. FINRA, for example, requires business systems to be within one second of UTC. (Certain kinds of financial transactions have much tighter requirements.) Given the time and effort you spent on fiddling with CLOCKxx, you may find that STP pays for itself very quickly. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On Thu, 13 May 2021 17:51:47 -0400, George Kozakos wrote: >> How does STIMER behave when the interval spans a DST or leap second >> boundary? Is this documented? > >STIMER does not need to know the interval spans a DST or leap second >boundary. When a DST or leap second change occurs an adjustment is >made to existing TQEs. > OK. For STIMER GMT, the adjustment is made at a leap second. For STIMER LT, the adjustment must be made at either a leap second or a DST boundary. For STIMER LT, code must exist to convert LT to TOD/Comparator. Alas, there's no programming interface for this; CONVTOD doesn't do LT. I'm trying to imagine what race conditions exist if STIMER LT is issued very close to a DST/leap boundary and how they might be resolved. It seems to require a quasi-atomic access to TOD, CVTLSO, and CVTLDTO. The same might apply to the TIME macro. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
> How does STIMER behave when the interval spans a DST or leap second > boundary? Is this documented? STIMER does not need to know the interval spans a DST or leap second boundary. When a DST or leap second change occurs an adjustment is made to existing TQEs. George Kozakos, z/OS Software Service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
Returning to Ed's comment about cost for STP The need to pay extra for time syncing on mainframe was and is always hard to justify or even explain. Often even got me laughed at. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of George Kozakos > Sent: Thursday, May 13, 2021 1:28 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: STIMERM LT value > > > > It is also possible to set a user specified LPAR offset via PTFF-STOU > (E) > > > without IPLing but you need to be aware you are jumping the LPAR TOD > on > a > > > running system. > > > > PTFF-STOU(E)? Is this something I'm supposed to recognize? What are you > > trying to tell me? > > See the PERFORM TIMING FACILITY FUNCTION instruction in the Principles of > Operation. > > > Unless you POR every week, your z13s clock is gonna drift and you're > > gonna have to compensate one way or another. > > That's true. You need to configure STP and synchronize to an external time > source (ETS) to have accurate time. > > George Kozakos, z/OS Software Service > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
> > It is also possible to set a user specified LPAR offset via PTFF-STOU (E) > > without IPLing but you need to be aware you are jumping the LPAR TOD on a > > running system. > > PTFF-STOU(E)? Is this something I'm supposed to recognize? What are you > trying to tell me? See the PERFORM TIMING FACILITY FUNCTION instruction in the Principles of Operation. > Unless you POR every week, your z13s clock is gonna drift and you're > gonna have to compensate one way or another. That's true. You need to configure STP and synchronize to an external time source (ETS) to have accurate time. George Kozakos, z/OS Software Service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On Tue, 11 May 2021 03:25:35 -0700, Ed Jaffe wrote: > >We experienced significant clock drift on our z13s. (I can't understand >why IBM makes STP optional and pricey. All Z machines should be able to >synchronize to NIST.) > >This discrepancy wreaked havoc for our folks trying to use the mainframe >as a GIT repository, so we decided to correct the issue in CLOCKxx >exactly as described in this thread. > Might it be better to tweak CVTLSO rather than CLOCKxx? o Wouldn't that keep GMT better aligned with LT? o Decrementing CVTLSO might cause intervals to appear inflated. o Incrementing CVTLSO might cause duplicate/ambiguous timestamps. o How does CLOCKxx affect OMVS timestamps? How do your UNIX timestamps compare to TIME LT/GMT? How does STIMER behave when the interval spans a DST or leap second boundary? Is this documented? How does the TIME macro make the STCK and fetch of CVTLSO/CVTLDTO appear atomic lest one of the latter change between accesses? I know it's a tiny window, but Murphy. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On 5/12/2021 3:59 PM, George Kozakos wrote: Are you IPLing to pick up the new TIMEZONE or are you using SET CLOCK as SET TIMEZONE only accepts hours and minutes? We IPL every Sunday morning to pick up the previous week's IBM service. We also pick up TIMEZONE changes at the same time. You should add OPERATOR PROMPT to CLOCKxx and reply with the UTC|GMT parameter to IEA888A to set the LPAR TOD clock at IPL instead. Haha! With all due respect, there's NWIH we're gonna introduce an operator prompt into our existing "lights out" operation! LOL It is also possible to set a user specified LPAR offset via PTFF-STOU(E) without IPLing but you need to be aware you are jumping the LPAR TOD on a running system. PTFF-STOU(E)? Is this something I'm supposed to recognize? What are you trying to tell me? Without STP, you can access an ETS via an NTP server on the HMC to make sure the HMC clock is accurate, and just before POR set the SE clock to the HMC clock via "Use Console Time" on the SE Date/Time panel (accessed via the HMC: Operational Customization -> Customize Support Element Date/Time) to ensure the CPC TOD is set to the correct time at POR. We do exactly this. It has no effect whatever on the clock drift issue. Unless you POR every week, your z13s clock is gonna drift and you're gonna have to compensate one way or another. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On 5/13/2021 5:48 AM, Paul Gilmartin wrote: On Wed, 12 May 2021 18:59:53 -0400, George Kozakos wrote: ... Without STP, you can access an ETS via an NTP server on the HMC to make sure the HMC clock is accurate, and just before POR set the SE clock to the HMC clock via "Use Console Time" on the SE Date/Time panel (accessed via the HMC: Operational Customization -> Customize Support Element Date/Time) to ensure the CPC TOD is set to the correct time at POR. With that setting will the CPC TOD continue to track the Console Time, or will a periodic POR be necessary as the TOD drifts out of tolerance? It drifts. That is the problem. It's only synchronized at POR. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On Wed, 12 May 2021 18:59:53 -0400, George Kozakos wrote: >... >Without STP, you can access an ETS via an NTP server on the HMC to make >sure the HMC clock is accurate, and just before POR set the SE clock to >the HMC clock via "Use Console Time" on the SE Date/Time panel (accessed >via the HMC: Operational Customization -> Customize Support Element >Date/Time) to ensure the CPC TOD is set to the correct time at POR. > With that setting will the CPC TOD continue to track the Console Time, or will a periodic POR be necessary as the TOD drifts out of tolerance? >> From: Ed Jaffe >> Date: 11/05/2021 06:25 AM >> >> We experienced significant clock drift on our z13s. (I can't understand >> why IBM makes STP optional and pricey. All Z machines should be able to >> synchronize to NIST.) >> I can understand the answer to your second question, and that implies the answer to the first. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
> Where a shop with STP and no clock drift might see this in their CLOCKxx > member: > > TIMEZONE W.08.00.00 > > ours would say (for example): > > TIMEZONE W.07.58.12 > > and this would be adjusted roughly every month to keep us within a > second or two of the real time shown on every Windows workstation in our > Enterprise. Are you IPLing to pick up the new TIMEZONE or are you using SET CLOCK as SET TIMEZONE only accepts hours and minutes? You should add OPERATOR PROMPT to CLOCKxx and reply with the UTC|GMT parameter to IEA888A to set the LPAR TOD clock at IPL instead. This will set an LPAR time offset for the LPAR TOD to correct the time and you can continue use the correct TIMEZONE of W.08.00.00. It is also possible to set a user specified LPAR offset via PTFF-STOU(E) without IPLing but you need to be aware you are jumping the LPAR TOD on a running system. Without STP, you can access an ETS via an NTP server on the HMC to make sure the HMC clock is accurate, and just before POR set the SE clock to the HMC clock via "Use Console Time" on the SE Date/Time panel (accessed via the HMC: Operational Customization -> Customize Support Element Date/Time) to ensure the CPC TOD is set to the correct time at POR. Regards, George Kozakos, z/OS Software Service IBM Mainframe Discussion List wrote on 11/05/2021 06:25:35 AM: > From: Ed Jaffe > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/05/2021 06:25 AM > Subject: [EXTERNAL] Re: STIMERM LT value > Sent by: IBM Mainframe Discussion List > > On 5/11/2021 1:40 AM, Steve Austin wrote: > > And apparently, "someone pointed out that the hardware clock was 1 minute > > out, so a minute was added". I don't know, but my guess is that the person > > setting up the Jenkins builds noticed the clock was wrong. > > We experienced significant clock drift on our z13s. (I can't understand > why IBM makes STP optional and pricey. All Z machines should be able to > synchronize to NIST.) > > This discrepancy wreaked havoc for our folks trying to use the mainframe > as a GIT repository, so we decided to correct the issue in CLOCKxx > exactly as described in this thread. > > Where a shop with STP and no clock drift might see this in their CLOCKxx > member: > > TIMEZONE W.08.00.00 > > ours would say (for example): > > TIMEZONE W.07.58.12 > > and this would be adjusted roughly every month to keep us within a > second or two of the real time shown on every Windows workstation in our > Enterprise. > > Our z15 has gone through a full POR several times since being installed > in August 2020 (see the video https://urldefense.proofpoint.com/v2/ > url?u=https-3A__youtu.be_uis-2D8s-5FO1K8=DwIDaQ=jf_iaSHvJObTbx- > siA1ZOg=mfIgXJBr_9TazLLSYkVdb5y- > zoBwQd2YUp9lnnRvmZM=Nw5YgLcNHOz0KGByGJP6imw1XKh4m2ffFX-9UDeS6AU=aUVAkcbKi373vKoWjZ2A1LlJEfjGOT- > GCV8p1scMQi8= ), the most > recent one being just a few weeks ago. So, it's difficult to know yet if > similar adjustments will be required. If they are, we stand ready to > adjust our CLOCKxx member as needed. > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > INVALID URI REMOVED > u=https-3A__www.phoenixsoftware.com_=DwIDaQ=jf_iaSHvJObTbx- > siA1ZOg=mfIgXJBr_9TazLLSYkVdb5y- > zoBwQd2YUp9lnnRvmZM=Nw5YgLcNHOz0KGByGJP6imw1XKh4m2ffFX-9UDeS6AU=- > zQkZJFZakF7tIiBbESUff7DqBGGUSe1Zd9oir8cyk4= > > > > This e-mail message, including any attachments, appended messages and the > information contained therein, is for the sole use of the intended > recipient(s). If you are not an intended recipient or have otherwise > received this email message in error, any use, dissemination, distribution, > review, storage or copying of this e-mail message and the information > contained therein is strictly prohibited. If you are not an intended > recipient, please contact the sender by reply e-mail and destroy all copies > of this email message and do not otherwise utilize or retain this email > message or any or all of the information contained therein. Although this > email message and any attachments or appended messages are believed to be > free of any virus or other defect that might affect any computer system into > which it is received and opened, it is the responsibility of the recipient > to ensure that it is virus free and no responsibility is accepted by the > sender for any loss or damage arising in any way from its opening or use. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On Tue, 11 May 2021 08:54:05 +1000, Attila Fogarasi wrote: >Z/os has to handle arbitrary TIMEZONE values -- and does it well. Keep in >mind that there are dozens of world locations that have non-hour timezone > It does it poorly. Of the "dozens of world locations" any z/OS system handles only two. And see the problems mentioned by Steve Austin and Ed Jaffe in followup plies. I have a computer in my shirt pocket that does better for a price lower by orders of magnitude. >offsets (typically 30 min and 15 min). There are even locations which have >Daylight Saving Time 30 min ahead of standard time instead of the usual 1 >hour. Could be worse, there used to be countries with 12 min offset for >timezone, but that ended circa 1986. The net is that z/OS doesn't think >that 1 hour 1 minute timezone offset is unusual :) > In the view of many (perhaps most) the intent of Local Time is not to make the computer room floor a sui generis "timezone" but to provide a time that agrees with the clock on the bank wall. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On 5/11/2021 1:40 AM, Steve Austin wrote: And apparently, "someone pointed out that the hardware clock was 1 minute out, so a minute was added". I don't know, but my guess is that the person setting up the Jenkins builds noticed the clock was wrong. We experienced significant clock drift on our z13s. (I can't understand why IBM makes STP optional and pricey. All Z machines should be able to synchronize to NIST.) This discrepancy wreaked havoc for our folks trying to use the mainframe as a GIT repository, so we decided to correct the issue in CLOCKxx exactly as described in this thread. Where a shop with STP and no clock drift might see this in their CLOCKxx member: TIMEZONE W.08.00.00 ours would say (for example): TIMEZONE W.07.58.12 and this would be adjusted roughly every month to keep us within a second or two of the real time shown on every Windows workstation in our Enterprise. Our z15 has gone through a full POR several times since being installed in August 2020 (see the video https://youtu.be/uis-8s_O1K8), the most recent one being just a few weeks ago. So, it's difficult to know yet if similar adjustments will be required. If they are, we stand ready to adjust our CLOCKxx member as needed. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
In answer to some of the questions below. The SYSLOG does appear to be ahead of my watch, but only by about 10 seconds. SVN is subversion and Jenkin should have been Jenkins. Using TIME STCKE,ZONE=LT gave a similar result; 0759 2495 05112021 Entering env date in omvs gave "Tue May 11 08:26:46 UTC 2021" an hour and one minute behind my watch. And apparently, "someone pointed out that the hardware clock was 1 minute out, so a minute was added". I don't know, but my guess is that the person setting up the Jenkins builds noticed the clock was wrong. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, May 10, 2021 12:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STIMERM LT value (I guess Peter R. overlooked that you appear to be operating near the Prime Meridian.) On Mon, 10 May 2021 09:52:16 +0100, Steve Austin wrote: >I've just found out that PARMLIB(CLOCKxx) here specifies; > > TIMEZONE E.01.01.00 > Ouch! Does that mean that SYSLOG, etc. timestamps are a minute ahead of your smartphone? Will that adjust to: TIMEZONE E.00.01.00 next Fall? (Does STP handle that?) How does that affect OMVS? A test might be: //WHEN EXEC PGM=BPXBATCH,PARM='SH date >/dev/console' >Something to do with synchronising with SVN and Jenkin apparently. >Didn't think I'd need to code for ad-hoc tweaks like that. > Does the TIME LT macro avoid tweaks required by STCKE; STCKCONV? May I infer that SVN and Jenkin (subversion?) is broken and admins introduced an offsetting breakage? That's *just*wrong*! >Sorry to waste your time. > Rather, the feckless morons who made that accommodation should apologi[sz]e to Peter and to you. On Mon, 10 May 2021 09:22:16 +0100, Steve Austin wrote: >... > +0038 LDTO. 0DA2 72B0ATCVT 80BFC000 > 1 *-* say x2d( 0DA2 72B0 ) * 2 ** ( 51 - 63 ) * 1e-6 3660.0 Yup. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On Mon, 10 May 2021 20:00:39 -0500, Mike Schwab wrote: >Since IBM and Linux / Unix handle Leap Seconds differently, is this >done so MVS is ahead of Linux, because if you are behind you get >rejected? > z/OS handles this pretty well by pausing during a leap second. Linux/UNIX systems use NTP and may take a few hours to adjust after a leap second. There's no justification for a 60 second offset. One second should be more than enough. Can the OP compare his smartphone to a SYSLOG timestamp? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
Since IBM and Linux / Unix handle Leap Seconds differently, is this done so MVS is ahead of Linux, because if you are behind you get rejected? On Mon, May 10, 2021 at 5:54 PM Attila Fogarasi wrote: > > Z/os has to handle arbitrary TIMEZONE values -- and does it well. Keep in > mind that there are dozens of world locations that have non-hour timezone > offsets (typically 30 min and 15 min). There are even locations which have > Daylight Saving Time 30 min ahead of standard time instead of the usual 1 > hour. Could be worse, there used to be countries with 12 min offset for > timezone, but that ended circa 1986. The net is that z/OS doesn't think > that 1 hour 1 minute timezone offset is unusual :) > > On Mon, May 10, 2021 at 9:43 PM Paul Gilmartin < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > > (I guess Peter R. overlooked that you appear to be operating > > near the Prime Meridian.) > > > > On Mon, 10 May 2021 09:52:16 +0100, Steve Austin wrote: > > > > >I've just found out that PARMLIB(CLOCKxx) here specifies; > > > > > > TIMEZONE E.01.01.00 > > > > > Ouch! Does that mean that SYSLOG, etc. timestamps are a minute > > ahead of your smartphone? Will that adjust to: > > TIMEZONE E.00.01.00 > > next Fall? (Does STP handle that?) > > > > How does that affect OMVS? A test might be: > > //WHEN EXEC PGM=BPXBATCH,PARM='SH date >/dev/console' > > > > >Something to do with synchronising with SVN and Jenkin apparently. Didn't > > >think I'd need to code for ad-hoc tweaks like that. > > > > > Does the TIME LT macro avoid tweaks required by STCKE; STCKCONV? > > > > May I infer that SVN and Jenkin (subversion?) is broken and admins > > introduced an offsetting breakage? That's *just*wrong*! > > > > >Sorry to waste your time. > > > > > Rather, the feckless morons who made that accommodation should > > apologi[sz]e to Peter and to you. > > > > > > On Mon, 10 May 2021 09:22:16 +0100, Steve Austin wrote: > > >... > > > +0038 LDTO. 0DA2 72B0ATCVT 80BFC000 > > > > > 1 *-* say x2d( 0DA2 72B0 ) * 2 ** ( 51 - 63 ) * 1e-6 > > 3660.0 > > > > Yup. > > > > -- gil > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
Z/os has to handle arbitrary TIMEZONE values -- and does it well. Keep in mind that there are dozens of world locations that have non-hour timezone offsets (typically 30 min and 15 min). There are even locations which have Daylight Saving Time 30 min ahead of standard time instead of the usual 1 hour. Could be worse, there used to be countries with 12 min offset for timezone, but that ended circa 1986. The net is that z/OS doesn't think that 1 hour 1 minute timezone offset is unusual :) On Mon, May 10, 2021 at 9:43 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > (I guess Peter R. overlooked that you appear to be operating > near the Prime Meridian.) > > On Mon, 10 May 2021 09:52:16 +0100, Steve Austin wrote: > > >I've just found out that PARMLIB(CLOCKxx) here specifies; > > > > TIMEZONE E.01.01.00 > > > Ouch! Does that mean that SYSLOG, etc. timestamps are a minute > ahead of your smartphone? Will that adjust to: > TIMEZONE E.00.01.00 > next Fall? (Does STP handle that?) > > How does that affect OMVS? A test might be: > //WHEN EXEC PGM=BPXBATCH,PARM='SH date >/dev/console' > > >Something to do with synchronising with SVN and Jenkin apparently. Didn't > >think I'd need to code for ad-hoc tweaks like that. > > > Does the TIME LT macro avoid tweaks required by STCKE; STCKCONV? > > May I infer that SVN and Jenkin (subversion?) is broken and admins > introduced an offsetting breakage? That's *just*wrong*! > > >Sorry to waste your time. > > > Rather, the feckless morons who made that accommodation should > apologi[sz]e to Peter and to you. > > > On Mon, 10 May 2021 09:22:16 +0100, Steve Austin wrote: > >... > > +0038 LDTO. 0DA2 72B0ATCVT 80BFC000 > > > 1 *-* say x2d( 0DA2 72B0 ) * 2 ** ( 51 - 63 ) * 1e-6 > 3660.0 > > Yup. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
(I guess Peter R. overlooked that you appear to be operating near the Prime Meridian.) On Mon, 10 May 2021 09:52:16 +0100, Steve Austin wrote: >I've just found out that PARMLIB(CLOCKxx) here specifies; > > TIMEZONE E.01.01.00 > Ouch! Does that mean that SYSLOG, etc. timestamps are a minute ahead of your smartphone? Will that adjust to: TIMEZONE E.00.01.00 next Fall? (Does STP handle that?) How does that affect OMVS? A test might be: //WHEN EXEC PGM=BPXBATCH,PARM='SH date >/dev/console' >Something to do with synchronising with SVN and Jenkin apparently. Didn't >think I'd need to code for ad-hoc tweaks like that. > Does the TIME LT macro avoid tweaks required by STCKE; STCKCONV? May I infer that SVN and Jenkin (subversion?) is broken and admins introduced an offsetting breakage? That's *just*wrong*! >Sorry to waste your time. > Rather, the feckless morons who made that accommodation should apologi[sz]e to Peter and to you. On Mon, 10 May 2021 09:22:16 +0100, Steve Austin wrote: >... > +0038 LDTO. 0DA2 72B0ATCVT 80BFC000 > 1 *-* say x2d( 0DA2 72B0 ) * 2 ** ( 51 - 63 ) * 1e-6 3660.0 Yup. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
I've just found out that PARMLIB(CLOCKxx) here specifies; TIMEZONE E.01.01.00 Something to do with synchronising with SVN and Jenkin apparently. Didn't think I'd need to code for ad-hoc tweaks like that. Sorry to waste your time. Steve -Original Message- From: Steve Austin [mailto:steve.aus...@macro4.com] Sent: Monday, May 10, 2021 9:22 AM To: 'IBM Mainframe Discussion List' Subject: RE: STIMERM LT value I've run the test twice more specifying a time of 9 o'clock, the 1st with a STIMERM and an LT=value and the 2nd a GMT=value. Below are the results and an extract of the CVT showing CVTLDTO and CVTLSO. Is the value in CVTLDTO correct? Thanks Steve STCKE following STIMERM specifying GMT=: 0813 4587 05102021 STCKE following STIMERM specifying LT=: 07590001 7615 05102021 EXT2: 00FD9168 +0004 NUCLS F1FLGBT 10IOCID F2F5 +0008 DEBVR 00FDF208 CVAF. 00C24000 MMVT. 00FD5880 +0014 NCVP. QIDA. 00OLTEP +0024 AVVT. 8000 CCVT. SKTA. +0030 ICB.. FBYT1 00 +0038 LDTO. 0DA2 72B0ATCVT 80BFC000 +0048 BCLMT 0064 LSO.. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, May 9, 2021 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STIMERM LT value Perhaps the OP should try using GMT= instead of LT=, to see just how things work without the time zone offset coming into play. Is it still off by a minute when using GMT= ? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
I've run the test twice more specifying a time of 9 o'clock, the 1st with a STIMERM and an LT=value and the 2nd a GMT=value. Below are the results and an extract of the CVT showing CVTLDTO and CVTLSO. Is the value in CVTLDTO correct? Thanks Steve STCKE following STIMERM specifying GMT=: 0813 4587 05102021 STCKE following STIMERM specifying LT=: 07590001 7615 05102021 EXT2: 00FD9168 +0004 NUCLS F1FLGBT 10IOCID F2F5 +0008 DEBVR 00FDF208 CVAF. 00C24000 MMVT. 00FD5880 +0014 NCVP. QIDA. 00OLTEP +0024 AVVT. 8000 CCVT. SKTA. +0030 ICB.. FBYT1 00 +0038 LDTO. 0DA2 72B0ATCVT 80BFC000 +0048 BCLMT 0064 LSO.. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, May 9, 2021 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STIMERM LT value Perhaps the OP should try using GMT= instead of LT=, to see just how things work without the time zone offset coming into play. Is it still off by a minute when using GMT= ? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
Perhaps the OP should try using GMT= instead of LT=, to see just how things work without the time zone offset coming into play. Is it still off by a minute when using GMT= ? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
The code shown will result in a timer pop at 11:00:00 local time. As to when the code will get control to issue the STCKE, that is a question of system dispatching and priorities. >From a dump, I think you will be able to see the external interrupt clock comparator timer pop, at whatever STCK(E) time corresponds to 11:00:00 local time. STCKCONV does not do "local time". While it seems unlikely, if you are finding the result off by a minute, since CVTLSO is 0's, perhaps your timezone offset is set to 1 minute off from the number of hours you expect. check CVTLDTO (although the system is using a different block than that when working with timezone offset and leap seconds; the corresponding areas are expected to match). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
>From IPCS cbformat cvt structure(cvt) LSO.. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, May 7, 2021 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: STIMERM LT value On Fri, 7 May 2021 11:37:40 +0100, Steve Austin wrote: >I ran the code below on a Z15 and a z/PDT and got the values shown. >Both are running summertime accounting the 09. But the result is a >minute awry of what I was hoping for. What STIMERM LT value would I >need to specify for >11 o’clock? > >Z15 09590001 3157 05072021 >z/PDT 0959 3251 05072021 > What value do you see in CVTLSO? > STIMERM SET,ID=STIMER_ID,LT=LTVAL,WAIT=YES > STCKE TODSTAMP > STCKCONV STCKEVAL=TODSTAMP,CONVVAL=OUTAREA,TIMETYPE=DEC, + > DATETYPE=MMDD > LAR2,OUTAREA > EXR0,* >EXIT DS0H > LMR14,R12,12(R13) > BR14 > > DS0D >TODSTAMP DSXL16 >OUTAREA DSXL16 CONVERTED VALUE >STIMER_ID DS F >LTVALDCC'1100' POP AT 11 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
On Fri, 7 May 2021 11:37:40 +0100, Steve Austin wrote: >I ran the code below on a Z15 and a z/PDT and got the values shown. Both >are running summertime accounting the 09. But the result is a minute awry >of what I was hoping for. What STIMERM LT value would I need to specify for >11 o’clock? > >Z15 09590001 3157 05072021 >z/PDT 0959 3251 05072021 > What value do you see in CVTLSO? > STIMERM SET,ID=STIMER_ID,LT=LTVAL,WAIT=YES > STCKE TODSTAMP > STCKCONV STCKEVAL=TODSTAMP,CONVVAL=OUTAREA,TIMETYPE=DEC, + > DATETYPE=MMDD > LAR2,OUTAREA > EXR0,* >EXIT DS0H > LMR14,R12,12(R13) > BR14 > > DS0D >TODSTAMP DSXL16 >OUTAREA DSXL16 CONVERTED VALUE >STIMER_ID DS F >LTVALDCC'1100' POP AT 11 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
