> 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 > perform the leap second adjustment ahead of the leap second occurrence? > > Glenn Miller > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > This e-mail transmission contains information that is confidential > and may be privileged. It is intended only for the addressee(s) > named above. If you receive this e-mail in error, please do not > read, copy or disseminate it in any manner. If you are not the > intended recipient, any disclosure, copying, distribution or use of > the contents of this information is prohibited. Please reply to the > message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer > system. Your assistance in correcting this error is appreciated. > > > ---------------------------------------------------------------------- > 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
