Heck, if it's two ATM transactions, one second matters.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, June 17, 2020 8:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CVTLSO race
On Wed, 17 Jun 2020 07:33:48 -0700, Charles Mills wrote:
>If a mainframe process is synchronizing with an off-box process, or engaging
>in communications that contains a timestamp governed by a standard, isn't
>"true" UTC a requirement?
>
The current CVTLSO is 27 seconds:
2020 9:33:48 AM
Subject: Re: CVTLSO race (was: ... STCKCONV ...
If a mainframe process is synchronizing with an off-box process, or engaging
in communications that contains a timestamp governed by a standard, isn't
"true" UTC a requirement?
Charles
-Original Message-
On
Behalf Of Peter Relson
Sent: Wednesday, June 17, 2020 5:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CVTLSO race (was: ... STCKCONV ...
Is it worth reminding that leap second offset and time zone are basically
for human consumption?
The values used for real processing ought to be the valu
Is it worth reminding that leap second offset and time zone are basically
for human consumption?
The values used for real processing ought to be the value returned by
STCK/STCKE/STCKF unmodified.
Peter Relson
z/OS Core Technology Design
Subject: Re: CVTLSO race (was: ... STCKCONV ...)
Either way there is a potential error as the field does not indicate the
time
range it applies to.
Your solution is incorrect if the STCK time was before the leap second was
to
be added but the refetched LSO applies for after the time.
On Tue, 16 Jun
Either way there is a potential error as the field does not indicate the time
range it applies to.
Your solution is incorrect if the STCK time was before the leap second was to
be added but the refetched LSO applies for after the time.
On Tue, 16 Jun 2020 10:52:52 -0500 Paul Gilmartin
On Tue, 16 Jun 2020 14:16:13 +0300, Steff Gladstone wrote:
>We need to capture the date and time in a GLUE and need more precision than
>the CICS variables give us.
>
There's a possible timing window in naive leap second
correction. Suppose:
STCK
(a leap second occurs, adding 1 to
