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
> > 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
> 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: STCK and epoch time
You can use IPCS LTOD stck-value to check that your calculation is correct George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Was Adding 90 seconds to 8 byte TOD FIELD
> Is there any additional documentation on this function ? The function was documented in the z/OS Version 1 Release 11 Implementation redbook - 13.5 Cross-memory TCB and SRB WAIT Regards, George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock values, leap seconds and BLSUXTOD conversion service
> If I take the value for July 1st, 2015 from the PoP table and > subtract the equivalent of one second I understand this is the TOD > value for June 30 23:59:60. Am I mixing up things? The TOD clock values given in the PoPs correspond to a UTC time of 00:00:00 on the specified date assuming leap seconds are used. The TOD clock value CF2D 54B4 FBA8 for July 1st, 2015 assuming 26 leap seconds are specified is correct: IP LTOD CF2D54B4FBA8 returns 07/01/2015 00:00:26.00 STCK X'CF2D54B4 FBA8' The PoP has been now updated with the leaps second value of 27 which occurred January 1st, 2017 Regards, George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Time on one LPAR on CEC
The Logical partition time offset is used when there is a requirement to run with LOCAL = UTC. In that case the LPAR time offset is set to the local time zone offset (e.g. +9 hours for Japan) and STPZONE NO, TIMEZONE=W.00.00.00 in CLOCKxx. If you are running the z/OS systems with a local time zone offset and you do not wish to use the time zone specified via STP (e.g. as it is set to the US time zone) then you can specify STPZONE NO, TIMEZONE=E.09.00.00 (for Japan) in CLOCKxx. Regards,George Kozakos z/OS Software Service, Level 2 Supervisor IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 09/10/2017 12:31:58 PM: > From: Jesse 1 Robinson <jesse1.robin...@sce.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/10/2017 12:34 PM > Subject: Re: Time on one LPAR on CEC > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > We run all LPARs on UTC with local time managed by STP. However, the > LPAR profile definition screen on HMC includes this: > > Clock Type Assignment > _ Standard time of day > _ Logical partition time offset > > I believe that this option allows an LPAR to run with a (presumably > geographic) offset different from other LPARs on the same CEC. I > thought that the option was intended specifically to allow shops to > run LPARs in support of various business applications around the > world. I have no actual experience here. ;-( > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Gibney, Dave > Sent: Monday, October 09, 2017 8:58 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Time on one LPAR on CEC > > Check out the SET TIMEZONE command > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of White, Andy > > Sent: Monday, October 09, 2017 4:25 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Time on one LPAR on CEC > > > > If we run the whole CEC as UTC won't I have to update the clock member > > on all the ones where there is DST? Now I'm ipling 3 systems (us > > based) and not having to IPL the Japan supported LPARS? > > > > > > > > > > > > Run all of the LPARs on UTC Universal Time something formerly GMT and > > set the time zone offset by LPAR. While there will be problems with > > the cutover due to overlapping dates and times, after that most SMF > > records will be consistent since most will use the hardware time and > > be immune to DST changes. People facing times can be used by the > applications. > > > > Clark Morris > > > > > >I'm being told by operations staff who handles the hardware we have > > >to > > deactivate and reactivate the LPARS running on JAPAN time. These are 3 > > LPARS we want to be on Japan time since they don't change to daylight > > savings like the US. > > > -- > 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: CLOCKxx - ACCURACY Parameter - IEA032E message
> It would seem to me, that for the accuracy keyword to work, that STP > must be using external time sources directly? Or is ACCURACY only > really reporting on clock steering events > 50 milliseconds(in your case)? ACCURACY is looking at the steering information and issuing IEA032E if the steering adjustment is greater than the ACCURACY threshold. The steering information used is identical to the information seen via the STP "Adjustment Steering Information" panel accessed via the "Timing Network" panel > > I ask, because we had an event several months back, where our > Firewall team botched up the rules, and all of our HMC's lost > internet access to NIST, and even though the boxes phoned home to > IBM, our own internal problem notifications procedures broke down, > and time was allowed to drift for over a week. In our case, STP was > fat, dumb, and happy because he was communicating nicely with his > NTP servers(multiple HMCs), and it was the HMC's that were falling > out of accuracy. So, I don’t know if this would help me or not. Right, the ACCURACY keyword would not have helped in that scenario. Regards, George Kozakos z/OS Software Service, Level 2 Supervisor IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 04/01/2017 07:54:19 AM: > From: "Jousma, David" <david.jou...@53.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 04/01/2017 07:54 AM > Subject: Re: CLOCKxx - ACCURACY Parameter - IEA032E message > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > Glenn, > > I wasn’t even familiar with this keyword until you brought it up. > However, a couple of comments. In our shop, we have the HMC's > acting as NTP clients to external NIST servers for time updates, and > as NTP servers for STP, and the mainframe as NTP server for the rest > of the datacenter. Our HMC's have firewall rules configured to > allow outbound connections to be able to reach NIST. I realize we > could have configured STP to go to NIST directly for time updates, > but we didn’t want to expose the SE's (even via firewall) to the > internet for time updates directly. > > It would seem to me, that for the accuracy keyword to work, that STP > must be using external time sources directly? Or is ACCURACY only > really reporting on clock steering events > 50 milliseconds(in your case)? > > I ask, because we had an event several months back, where our > Firewall team botched up the rules, and all of our HMC's lost > internet access to NIST, and even though the boxes phoned home to > IBM, our own internal problem notifications procedures broke down, > and time was allowed to drift for over a week. In our case, STP was > fat, dumb, and happy because he was communicating nicely with his > NTP servers(multiple HMCs), and it was the HMC's that were falling > out of accuracy. So, I don’t know if this would help me or not. > > _ > Dave Jousma > Manager Mainframe Engineering, Assistant Vice President > david.jou...@53.com > 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H > p 616.653.8429 > f 616.653.2717 > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Glenn Miller > Sent: Tuesday, January 03, 2017 5:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: CLOCKxx - ACCURACY Parameter - IEA032E message > > A few months ago we activated the "ACCURACY" parameter with a value > of 50 ( the default is zero ) on a few of our z/OS systems ( all > systems are z/OS V2R1 ). We verified that the "IEA034I THE TOD > CLOCK ACCURACY MONITOR IS ACTIVE." is issued whenever these z/OS > systems are IPL'ed. > Until Saturday night, we have never received any "alert" from this > TOD CLOCK ACCURACY MONITOR. However, we did receive the following > message on each z/OS system that has that monitor active: > IEA032E TOD CLOCK ACCURACY LIMITS MAY HAVE BEEN EXCEEDED. > > The IEA032E messages occurred around 8PM Eastern Time on December > 31, 2016. The IEA032E messages were repeated every hour on each z/OS > system until about 2AM on January 1, 2017, or about 6 hours after > they started. Also, the IEA032E messages have not re-occurred since > that 2AM timeframe. > > We have confirmation from IBM that the IEA032E messages were > triggered by the leap second that was inserted into UTC. They also > indicated how to perform a leap second adjustment via the STP panels > if we needed the 50ms accuracy when the leap second occurred. > > > Has anyone else implemented the TOD accuracy monitor on their z/OS > systems? Did anyone else receive the IEA032E messages or did you
Re: Time Change Problem #1398
You should open a PMR. UTC/GMT can only be changed via an IPL with OPERATOR PROMPT specified in CLOCKxx. At POR the processor TOD is set to the SE clock. George Kozakos z/OS Software Service, Level 2 Supervisor IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 08/11/2016 02:38:16 PM: > From: Christopher Brown <cbr...@cswg.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/11/2016 02:38 PM > Subject: Re: Time Change Problem #1398 > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > To all who replied, > > Site does not have STP or wouldn't be in this spot. Their timezone > is W.06 and UTC time is local plus 1 hour. I will try and get a > copy of the CLOCKxx member. > > -- > 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: How set CVTLSO?
>Not any computer systems I work with. They use either 1900 or 1970 >as their epoch. What uses 1972? The "epoch" on z/OS systems is 1900. George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How set CVTLSO?
On 12/10/2016 07:53 PM, Paul Gilmartin wrote: > I understand that the TOD clock continues to be updated during that spin. > Are processes otherwise quiesced or may they continue to execute until > they do (e.g.) STCK? > > What happens to the clock comparator and to other STIMER-queued events? > Someone may want to wait for two seconds physical time; someone else may > want to wait until two seconds after midnight. All CPUs are interrupted to process the external interrupt for the leap second change. The leap second change is applied to TOD (LT) and GMT real/wait TQEs. George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How set CVTLSO?
On 12/10/2016 05:45:48 PM, , Charles Mills wrote: > @George, thanks. I'm looking at the from a software development point of > view, not a sysprog point of view. > > So if a shop is using an ETS and does not schedule the change then the TOD > clock will be steered into reflecting the leap seconds, right? The TOD > clock will slow down until it falls back to the correct time, right? Yes, the TOD is steered to reflect the change in the ETS. This takes about 7 hours, the steering rate is 7 hours per second of adjustment. > For a "Time Control Parameter Change event" where does the leap second get > reflected? Still in the hardware TOD clock? It effectively stops for one > second? Or in CVTLSO? z/OS does not affect the hardware TOD clock. If the leap second change is positive, Timer processing spins on all CPUs for the amount of the leap second change and CVTLSO is updated. STCK time does not change but UTC/GMT jumps backward due to the change in CVTLSO. Regards, George Kozakos -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How set CVTLSO?
> Ah! I am starting to understand. Leap Second steering is accomplished with > the PTFF instruction and is independent of CVTLSO. PTFF appears to slow down > the physical clock. > > So ... steering and CVTLSO are essentially alternatives, right? CVTLSO > should not include any leap seconds that were previously (or were about to > be) "steered" -- is that right? And if a shop is using STP it is probably > not modifying CVTLSO: CVTLSO is probably either zero, or at least stable. Am > I getting this right? > > Charles No, you have it wrong. Steering has nothing to do with leap seconds. STP checks the external time source (ETS) at regular intervals and makes adjustments via steering to keep accurate with the ETS. It just so happens that if you don't schedule the leap second at the appropriate time via the STP panel, when the leap second occurs, the STP UTC time will be 1 second ahead of the ETS and so steering will occur to correct it. If you do schedule the leap second, then STP generates a "Time Control Parameter Change event" external interrupt that gets processed by z/OS to make the leap second adjustment. If it is a positive change, z/OS spins on all CPUs for the amount of the positive leap second change to ensure there are no duplicate UTC time stamps and updates CVTLSO. No steering is required as STP UTC time remained accurate with the ETS. George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How set CVTLSO?
> Mostly a curiosity and "long-term" question: where do you set the leap > second offset? Can it be set without an IPL? > > I searched System Commands for "leap" and did not find anything. > > Charles Via STP or Sysplex Timer Regards, George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Leap Second today!
In my time zone, the leap second occurred at 17:59:60. So, I wonder about the z/OS STIMER macro: If, at 17:59:59 I had issued STIMER WAIT,LT=[18:000:01] would the wait have expired in 3 seconds? Yes, if you scheduled the leap second via STP or ETR. It would expire in 2 seconds if you aren't using leap seconds If, at 17:59:59 I had issued STIMER WAIT,BINTVL=[3 seconds] would the wait have expired at 18:00:01? No, it would expire at 18:00:02 regardless of whether you are using leap seconds Unless the answer to both questions is Yes, there's a bug. I need to correct my answer to the second question: If, at 17:59:59 I had issued STIMER WAIT,BINTVL=[3 seconds] would the wait have expired at 18:00:01? It would expire at 18:00:01 if you are using leap seconds and at 18:00:02 if you are not. In both cases the wait will expire in 3 seconds time. George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Leap Second today!
If, at 17:59:59 I had issued STIMER WAIT,BINTVL=[3 seconds] would the wait have expired at 18:00:01? No, it would expire at 18:00:02 regardless of whether you are using leap seconds And since the Leap Second code is ignorant of whether an entry corresponds to a clock time or a duration, it assumes the former and adds the second regardless. Particularly silly if the wait spans midnight since the syntax of STIMER macro provides no way to specify a time past midnight, so it must have been a duration. So it actually waits for 4 seconds rather than the 3 requested. The problem is that at 17:59:59 when the STIMER is processed we don't know that a leap second will occur at 18:00. George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Leap Second today!
So it actually waits for 4 seconds rather than the 3 requested. The problem is that at 17:59:59 when the STIMER is processed we don't know that a leap second will occur at 18:00. Actually, you could have known that for 4 months, ever since the IERS announced the leap second. (Less the time it takes for a PTF to be created, distributed, and installed.) I don't believe (but I've already been wrong once) that a programmer can request a GMT or LT more than 4 months in the future. Leap seconds are scheduled via STP or the sysplex timer. z/OS can only know about a leap second when it gets the Time Control Parameter Change event external interrupt for STP or the ETR Alert event external interrupt for ETR. George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Leap Second today!
In my time zone, the leap second occurred at 17:59:60. So, I wonder about the z/OS STIMER macro: If, at 17:59:59 I had issued STIMER WAIT,LT=[18:000:01] would the wait have expired in 3 seconds? Yes, if you scheduled the leap second via STP or ETR. It would expire in 2 seconds if you aren't using leap seconds If, at 17:59:59 I had issued STIMER WAIT,BINTVL=[3 seconds] would the wait have expired at 18:00:01? No, it would expire at 18:00:02 regardless of whether you are using leap seconds Unless the answer to both questions is Yes, there's a bug. -- gil George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SLIP trap confusion
You are missing MODE=HOME Regards, George Kozakos z/OS Software Service, Level 2 Supervisor IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 24/10/2014 02:20:12 PM: From: Phil Smith p...@voltage.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 24/10/2014 02:21 PM Subject: SLIP trap confusion Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU ... ... So I started off with: SLIP SET,IF,DISABLE,ACTION=SYNCSVCD,PVTMOD=(VSHDITSK, 2874),ID=PHS1,JOBNAME=ZPHIL510,END ... I'm obviously missing something basic here! I've stopped the started task, defined and enabled the trap, and restarted the task (thinking that maybe it couldn't already be running when the trap is defined). Thanks in advance for any assistance! -- ...phsiii Phil Smith III -- 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: IXC434I
We are installing a Zec12 and trying to IPL our test systems. We do not have the STP configured yet, but we are just trying to ipl the sysplex. We are getting the message IXC434I: IXC434I SYSTEM SYSC HAS TIMING DEFINITIONS THAT ARE NOT CONSISTENT WITH THE OTHER ACTIVE SYSTEMS IN SYSPLEX SCCTEST - EFFECTIVE CLOCK VALUES ARE NOT CONSISTENT. SYSTEM: SYSC IS USING LOCAL SYSTEM: SYSC IS USING EDCITS How does it even know about EDCITS? Why can't we ipl using the local time? XCF has detected that the sysplex couple dataset has an old entry in the SMST for SYSC running in STP-only CTN EDCITS. Are you saying CLOCKxx specified ETRMODE NO, STPMODE NO? Do you specify SIMETRID? What do you specify for PLEXCFG in IEASYSxx? I am guessing that you specified SIMETRID as you talk about ipling the sysplex. In that case you should reply I to IXC420D to intialize the sysplex. If you did not specify SIMETRID then it seems you have specified PLEXCFG=MULTISYSTEM or ANY. You need to specify PLEXCFG=XCFLOCAL. George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting STCK(tod) to readable format
Peter Relson wrote: For what it's worth, and I might be wrong about this, I thought that the clock was typically recommended to be set to UTC. And by subtracting CVTLSO from the STCK value you get to GMT, not to UTC (UTC differing from GMT by leap seconds). And you get to LOCAL by taking GMT and subtracting CVTLDTO. Yes, you are wrong about this. GMT and UTC are essentially the same. GMT changed to UTC (Coordinated Universal Time) on the last second of 12/31/1971. Main difference is UTC uses leap seconds to synchronize with International atomic time (TAI). There have been 25 leap seconds since 1972. UTC was 10 seconds behind in 1972 when UTC started so UTC is 35 seconds behind TAI time. Customers that require precise time and are using STP to synchronize to an NTP server need to use leap seconds. This means the CEC's TOD (STCK time) is NTP server time (UTC time) plus leap seconds. The reason for this is so that the CEC's TOD (STCK time) is correct when a leap second is introduced. If leap seconds are not used so that the CEC's TOD (STCK time) equals UTC then when a leap second is introduced the CEC's TOD will be out by 1 second and STP will take 7 hours to steer the 1 second adjustment. George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Converting STCK(tod) to readable format
Paul Gilmartin wrote: One of these days, I must submit an RCF asking for a clarification of whether the returned value is GMT or LOCAL time (there is no option), and how it deals with leap seconds and Daylight Saving boundaries that may exist between the time of the STCK and the STCKCONV. I expect to be disappointed. It's neither. It's the STCK time where UTC = STCK - CVTLSO LOCAL = STCK - CVTLSO + CVTLDTO MIC Returns the converted time of day in microseconds as 8 bytes of information, where bit 51 is equivalent to one microsecond. This looks a lot like the in put TOD format. That is TOD format for the time of day which is only up to 24 hours. For example: IP LTOD CB3BB8574D418DDC 04/18/2013 23:48:19.810328 STCK X'CB3BB857 4D418DDC' 04/18/2013 23:47:54.810328 UTCX'CB3BB83F 75BD8DDC' 04/19/2013 09:47:54.810328 LOCAL X'CB3C3E5B BC3D8DDC' STCKCONV TIMETYPE=MIC returns 00013F41B5418DDC 04182013 Regards, George Kozakos z/OS Software Service, Level 2 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
