On Sun, 8 Feb 2009 23:07:53 -0500, David Andrews wrote:
>
>We periodically SET CLOCK to locally correct for this. (I understand
>that this sets CVTLDTO.)
>
>> Mightn't this cause the Unix time to go backwards for some
>> values of the adjustment.
>
>Yeppers, it sure could, which is why we do this in quiet periods -- one
>of the advantages that we little fish have over the megacorporate 24/7
>behemoths.
>
>While I'm wishing, I wish the sysplex timers weren't so expensive.
>
... Or that there was a three-position switch adjusting the TOD
clock rate: -1%:NORMAL:+1%. (The poor man's STP).
>> What if instead of the complexity you propose one simply fudged the
>> content of CVTLSO, not CVTLDTO,
>
>'splainey? I'm not familiar with CVTLSO, and the CVT DSECT only says:
>"LEAP SECOND OFFSET IN TOD FORMAT"
>
From:
Linkname: Re: Converting TOD to Local Time
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0512&L=ibm-main&P=69168
Subject: Re: Converting TOD to Local Time
From: Peter Relson
Reply-To: IBM Mainframe Discussion List <[email protected]>
Date: Wed, 14 Dec 2005 07:54:23 -0500
A STCK value, as Bob Wright mentioned, is considered "absolute time".
Absolute to UTC: apply leap seconds
Absolute to Local: apply leap seconds and time zone offset
UtcTime = StckTimeStamp - CVTLSO
LocalTime = StckTimeStamp + CVTLDTO - CVTLSO
Assuming addressability to the CVT, and assuming z/Architecture,
LG R1,StckTimeStamp
ALG R1,CVTLDTO
SLG R1,CVTLSO
STG R1,LocalTime
... so fudging CVTLDTO adjusts only local time; fudging CVTLSO
adjusts both local time and UTC time. I'd recommend making such
an adjustment only during your "quiet periods".
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
