> 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 <IBM-MAIN@LISTSERV.UA.EDU> wrote on 11/05/2021 06:25:35 AM: > From: Ed Jaffe <edja...@phoenixsoftware.com> > 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 <IBM-MAIN@LISTSERV.UA.EDU> > > 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&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=mfIgXJBr_9TazLLSYkVdb5y- > zoBwQd2YUp9lnnRvmZM&m=Nw5YgLcNHOz0KGByGJP6imw1XKh4m2ffFX-9UDeS6AU&s=aUVAkcbKi373vKoWjZ2A1LlJEfjGOT- > GCV8p1scMQi8&e= ), 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_&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=mfIgXJBr_9TazLLSYkVdb5y- > zoBwQd2YUp9lnnRvmZM&m=Nw5YgLcNHOz0KGByGJP6imw1XKh4m2ffFX-9UDeS6AU&s=- > zQkZJFZakF7tIiBbESUff7DqBGGUSe1Zd9oir8cyk4&e= > > > -------------------------------------------------------------------------------- > 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
