On 2017-11-19 12:45, Charles Mills wrote:
Subtract?
Sort of. My impression -- and I would be happy if someone could definitively
confirm or correct me -- is that leap seconds are of course subtracted from
the TOD value, but the value in CVTLSO is negative, so adding CVTLSO
subtracts the leap second count. On the test LPAR that I am currently
looking at CVTLSO is zero, so that's not much of a clue.
http://www.longpelaexpertise.com/toolsTOD.php supports my thinking.
how does one ensure that CVTLSO hasn't changed
I don't know. How DOES one change CVTLSO? I just searched MVS System
Commands and Init & Tuning for <leap> and <CVTLSO> and got no hits.
Specifically, is there a supported way of changing it "suddenly"? Google
reveals that you and I had this same discussion a year ago:
https://www.mail-archive.com/[email protected]/msg59183.html
A more significant issue IMHO is that CVTLSO is the *current* leap second
adjustment. If one is converting a timestamp from ten years ago -- say from
an archived SMF dataset -- how does one get the leap second offset at that
time? If it changes between STCK and AG or between the start of some job and
its end, then at worst one is off by one second. Adjusting a TOD from 2007
by today's offset will put you off by four seconds. For a TOD (real STCK or
"computed") from 1971 you will be off by almost half a minute.
Yeah, LE *could* support negative UNIX times. Would not take a great
algorithmic leap. But the fact is that they don't.
Charles
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]]
On Behalf Of Paul Gilmartin
Sent: Friday, November 17, 2017 6:40 PM
To: [email protected]
Subject: Re: A modest proposal: LE enabled HLASM + C runtime
On 2017-11-17, at 18:56:20, Charles Mills wrote:
Okay, in response to absolutely no popular requests, here is how to
convert a TOD to a UNIX time:
Add CVTLSO. There's your all-important leap seconds, affine or otherwise.
Subtract?
...to save a couple of cycles in the case of repetitive conversions
you could adjust that constant for CVTLSO and only do one subtract.
Taking care that CVTLSO hasn't changed midstream, which might devour the
saving.
BTW, how does one ensure that CVTLSO hasn't changed between the STCK and the
access of CVTLSO?
...
If the result is negative you are out of luck. The C library routines
do not support negative times (times before 1/1/1970).
I believe that (used to be) a POSIX requirement, but many non-IBM UNIXen
tolerate the violation. In:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html#tag
_16_299_05
ERRORS
The localtime() [CX] and localtime_r() functions shall fail if:
[EOVERFLOW]
The result cannot be represented.
... no mention of negative argument.
This leaves the bugbear "-1", returned as an error by mktime(). But is that
1969-12-31 23:59:59. I suppose returned value is -1 but errno is
This link posted by Mark Jacobs in IBM-MAIN a few weeks ago might be
helpful:
https://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102081
--
Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/
