Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Saturday, December 29, 2018 1:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service
On Fri, 28 Dec 2018 23:52:07 -0600
On Fri, 28 Dec 2018 23:52:07 -0600, Paul Gilmartin wrote:
>> ...
>I believe otherwise. In order to avoid discontinuities at leap seconds of the
>sort
>that cause network failures:
>
> https://en.wikipedia.org/wiki/Leap_second#Examples_of_problems_associated_with_the_leap_second
>the TOD
On Sat, 29 Dec 2018 05:21:30 +, Farley, Peter x23353 wrote:
>"A STCK value came from the clock and is not to be considered UTC time."
>
>Then what is STP/NTP (or whatever the current mechanism is named) supposed to
>do? Isn't the entire point of a hardware clock-setting mechanism to set the
heir own yearly bonus. It's your job to
make your management think that it does affect their bonus, not your users' job.
Don't ask for a reason; create one that makes your management happy and then
"just do it".
Peter
-Original Message-
From: IBM Mainframe Discussion List [mail
On Fri, 28 Dec 2018 14:46:41 -0500, Peter Relson wrote:
>I shouldn't have included "TIME" among the services I mentioned because
>that's "current", not "historic" (so only has to deal with "current" leap
>seconds) and because it does not let you choose STCK as the "zone" -- you
>
Not as the
One major consideration should be who sets the time zone. Many
mainframes support users in multiple time zones. So ideally the
mainframe should be set to UTC then the macro should convert to the
local time of the individual application / user.
On Fri, Dec 28, 2018 at 1:47 PM Peter Relson
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Farley, Peter x23353
Sent: Friday, December 28, 2018 12:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service
Peter,
I
I shouldn't have included "TIME" among the services I mentioned because
that's "current", not "historic" (so only has to deal with "current" leap
seconds) and because it does not let you choose STCK as the "zone" -- you
must choose between local and UTC, both of which are defined with respect
There is an architectural definition of what a tick in bit 51 of the
64-bit TOD clock.
Thus a given clock value (bits 0-51) represents the number of microseconds
since the start of the epoch being used.
It seems true that STCKCONV assumes the standard epoch. As I said, if that
is not mentioned
For a contrary opinion, I believe IBM's documentation and function of the
TOD clock to be quite adequate. The provided macros do the fairly involved
arithmetic to convert a TOD number as-is, which is the most useful option.
Adjusting for leap seconds, DST, and time zone can easily be done before
rum
and for your gentlemanly responses here,
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Peter Relson
Sent: Thursday, December 27, 2018 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TOD clock values, leap seconds and BLSUXTO
On 28/12/2018 1:30 am, Peter Relson wrote:
You have been saying the same thing for years, with no one apparently
agreeing with you.
I admit I am also confused by these discussions.
What value does STCK followed by STCKCONV give at exactly midnight 28
December 2018 UTC?
What value does
OK. You're correct in your pedantry; it does not assert that the time
output by
these services corresponds to the input values -- it guarantees only the
format.
I still feel that statements such as this entice a programmer to that
misbelief.
You have been saying the same thing for years,
On Wed, 26 Dec 2018 09:00:47 -0500, Peter Relson wrote:
>
>>I believe a programmer might reasonably expect that STCKCONV usefully return
>>whatever TIME would have returned at the instant of the STCK.
>
>A programmer would expect next to nothing due to the name of a service
>since it is not
>What date and time in 1900, and what time scale? GMT? UTC? UT1?
Ephemeris tme?
>Terrestrial dynamic time? ...?
Surely you know that the principles of operation documents that a clock
value of 0 is January 1, 1900 12:00 AM UTC (although I believe UTC did not
exist as a term when this was
On Sat, 15 Sep 2018 08:52:55 -0400, Peter Relson wrote:
>
>On Sat, 20 Apr 2013 14:39:08 -0400, Peter Relson wrote:
>>... The documentation says "The STCKCONV macro converts an input
>>time-of-day (TOD) clock value to time of day and date, and returns the
>>converted values to the
"Usually" is slippery. When you need it, it's important.
And if someone truly needs it, then they should make a business case and
submit an RFE for it.
> and even a bad idea to save UTC time, as opposed to saving the
>STCK(E) value.
>
Why?
Perhaps because of the lack of processing of
On Fri, 14 Sep 2018 22:34:09 +0200, Peter Hunkeler wrote:
>
>>There is nothing in error with any of the conversion services. They do
>what they intend to do. And yes they do the easy part.
>
>Is that clear from the description of the service? At least for BLSUXTOD I
>can't remember to have read
The Earth is expected to have a 25 hour day in 200 Million years.
https://www.express.co.uk/news/science/741074/25-hour-day-earth-orbit-slowing
Dividing by the number of seconds in an hour (3600) gives us
55,555.556 years until every day is 24 hours and 1 second long.
Dividing by the number of
>There is nothing in error with any of the conversion services. They do
what they intend to do. And yes they do the easy part.
Is that clear from the description of the service? At least for BLSUXTOD I
can't remember to have read about that fact.
>What there is is a lack of functionality
On Fri, 14 Sep 2018 19:26:55 +, Farley, Peter x23353 wrote:
>
>As Gil has mentioned more than once, the z/OS failure to support and use the
>IANA Timezone package and database is the issue here.
>
>Using the IANA Timezone database would solve all of his issues and many others
>and be a plus
On Fri, 14 Sep 2018 09:14:25 -0700, Charles Mills wrote:
>I believe that is in fact in the standard.
>
The best I easily find is:
https://www.iers.org/IERS/EN/Science/EarthRotation/UTC.html
...
UTC is defined by the CCIR Recommendation 460-4 (1986). It differs from
TAI by an
-MAIN@LISTSERV.UA.EDU
Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service
As to this statement
>z/OS shirks by shutting down user tasks during that second.
"Shutting down user tasks" is not true in general that, but can be true
depending on your time protocol.
I believe that is in fact in the standard.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Mike Schwab
Sent: Friday, September 14, 2018 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TOD clock values, leap seconds
On Fri, Sep 14, 2018 at 9:11 AM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> False. The UTC specification deals with that by requiring the value
> 23:59:60.xxx during a leap second. The sequence of events is
> well-determined.
>
> -- gil
So, after a few thousand
On Fri, 14 Sep 2018 08:08:14 -0400, Peter Relson wrote:
>There is nothing in error with any of the conversion services. They do
>what they intend to do. And yes they do the easy part. What there is is a
>lack of functionality that would usually be unimportant to have.
>
"Usually" is slippery.
There is nothing in error with any of the conversion services. They do
what they intend to do. And yes they do the easy part. What there is is a
lack of functionality that would usually be unimportant to have.
There is expected to be some human understanding of the foibles of a
human-readable
On Thu, 13 Sep 2018 20:00:25 -0400, George Kozakos wrote:
>
>The TOD clock value CF2D 54B4 FBA8 for July 1st, 2015 assuming
>26 leap seconds are specified is correct:
>
>IP LTOD CF2D54B4FBA8 returns
>07/01/2015 00:00:26.00 STCK X'CF2D54B4 FBA8'
>
>The PoP has been now updated
> If I take the value for July 1st, 2015 from the PoP table and
> subtract the equivalent of one second I understand this is the TOD
> value for June 30 23:59:60. Am I mixing up things?
The TOD clock values given in the PoPs correspond to a UTC time of
00:00:00 on the specified date assuming leap
On Thu, 13 Sep 2018 23:18:11 +0300, Binyamin Dissen wrote:
> ...
>It is not reading the clock, it is reading a value in the clock format. In my
>code where the clock value will be logged, it is adjusted before being stored.
>
JM>and does not attempt to account for time zones or leap seconds.
On Thu, 13 Sep 2018 13:31:16 -0500 Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
:>On Thu, 13 Sep 2018 17:39:53 +0300, Binyamin Dissen wrote:
:>>As this is part of the IPCS service, one wonders how it could determine the
:>>TOD adjustment values for specified value.
On Thu, 13 Sep 2018 17:39:53 +0300, Binyamin Dissen wrote:
>As this is part of the IPCS service, one wonders how it could determine the
>TOD adjustment values for specified value.
>
See: https://www.iana.org/time-zones
On Thu, 13 Sep 2018 10:41:30 -0400, Jim Mulder wrote:
> BLSUXTOD does not
BLSUXTOD does not know the context of the TOD clock value you are
passing,
and does not attempt to account for time zones or leap seconds. When you
use BLSUXTOD, you are expected to any adjustments of interest to you
before calling BLSUXTOD.
Jim Mulder z/OS Diagnosis, Design, Development,
As this is part of the IPCS service, one wonders how it could determine the
TOD adjustment values for specified value.
On Thu, 13 Sep 2018 15:59:40 +0200 Peter Hunkeler wrote:
:>So this is the first time I really care for leap seconds. I need a conversion
from TOD clock value to readable
On Thu, 13 Sep 2018 15:59:40 +0200, Peter Hunkeler wrote:
>So this is the first time I really care for leap seconds. I need a conversion
>from TOD clock value to readable format in REXX. Found the BLSUXTOD service.
>Works nice. so far so good.
>
>The PoP has a table of TOD clock values taking
So this is the first time I really care for leap seconds. I need a conversion
from TOD clock value to readable format in REXX. Found the BLSUXTOD service.
Works nice. so far so good.
The PoP has a table of TOD clock values taking care of the 26 leap seconds
inserted so far. The last one was
36 matches
Mail list logo
