On Tue, 17 Sep 2013 16:08:26 -0400, Charles Mills wrote:
>
>Time Settings
>
>The zArchitecture hardware clock is (if your shop follows best practices)
>set to Universal Coordinated Time (UTC, similar to Greenwich Mean Time or
>GMT).
>
I believe not. By best practice it is set (and steered by STP) to TAI - 10
seconds
(strangely enough.) All described (often correctly) in at least 3 tables in
the P[ro]Op.
>... z/OS uses several independent methods for determining the local time
>offset when providing local time services to programs:
>
To get UTC, one must subtract CVTLSO from the content of the (E)TOD clock.
A recent thread here provoked one of our programmers to ask why we have
CVTLSO set to 0 rather than the (current) IBM recommendation of 25 seconds.
Our administrator answered:
This problem goes way back to 2004 (z/OS 1.4).
Back then -- and I don't know if it has changed -- SMF cut records and
adjusted for the leap second setting. However, RMF cut records and
*did not* adjust for the leap second setting. This inconsistency was
causing problems when doing some reporting.
The conclusion at the time is that no one absolutely required the leap
second value be accurate so we just set it back to zero which worked
around our problem.
Will this be fixed? (Has it been already?)
Naively, one might assume that STCKCONV might be used to convert
the RMF timestamps to UTC. I suspect it doesn't. IBM refuses to
document clearly what STCKCONV does, claiming it's "common
knowledge". I disagree. Prior to 1972, STCKCONV might have
converted TOD values to GMT (now replaced by UTC). Any "common
knowledge" gained then of TOD-to-GMT (UTC) conversion is obsolete;
overcome by events. Things aren't as simple as they used to be.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
