On Sat, 29 Dec 2018 14:00:03 -0500, Jim Mulder wrote:
> SA22-7832-11 (z14 level of Principles of Operation) explains how the TOD
> clock
>and clock comparator deal with the next epoch.
>
Wow!
... the multiple- epoch facility ... the clock-comparator sign control ...
Thanks.
> I can't
.
Poughkeepsie NY
"IBM Mainframe Discussion List" wrote on
12/29/2018 12:36:14 PM:
> From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 12/29/2018 01:53 PM
> Subject: Clock Windowing (was: BLSUXTOD)
>
On Sat, 29 Dec 2018 11:54:48 -0500, Peter Relson wrote:
> ...
>What this is likely trying (but failing) to say is that this service
>applies a windowing technique, which much of z/OS will do in the coming
>years, as we approach the end of the standard epoch.
>
I forgot to ask:
How will this
On Sat, 29 Dec 2018 11:54:48 -0500, Peter Relson wrote:
>
>What this is likely trying (but failing) to say is that this service
>applies a windowing technique, which much of z/OS will do in the coming
>years, as we approach the end of the standard epoch.
>
Kind of like:
not match the table that shows that the output is a 26-character
buffer. So either the lead-in is wrong or the reference to BLSUXTOD here
is wrong. I think the latter. The description in the register sub-section
shows the "TID" name.
There are actually two pairs of services: BLSUXTOD/BLSUETOD an
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
to:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Peter Relson
Sent: Friday, December 28, 2018 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TOD clock values, leap seconds and BLSUXTOD conversion service
There is an architectural definition of what a tick in bit 51 of the 64-bit TOD
clock.
Thus a given c
On Fri, 28 Dec 2018 21:57:43 -0600, Joe Monk wrote:
>>"By my arithmetic, January 1, 1900 + 143 years = January 1, 2043".
>
>Ummm ... Did you forget the year 1900? Theres only 142 years left after you
>subtract the Year 1900.
>
WTF!?
So, by that reasoning, January 1, 1900 + 1 year = January 1,
"By my arithmetic, January 1, 1900 + 143 years = January 1, 2043".
Ummm ... Did you forget the year 1900? Theres only 142 years left after you
subtract the Year 1900.
"How are those bits numbered? 0 to 103? What's the value of bit 0? What's
the value of bit 103?"
Yes, 0 to 103. Bit 51 is
On Fri, 28 Dec 2018 18:18:51 -0600, Joe Monk wrote:
>So if you read the POO, you see:
>
> - Communication between systems is facilitated by establishing a
> standard time origin that is the calendar date and time to which a clock
> value of zero corresponds. January 1, 1900, 0 a.m.
So if you read the POO, you see:
- Communication between systems is facilitated by establishing a
standard time origin that is the calendar date and time to which a clock
value of zero corresponds. January 1, 1900, 0 a.m. Coordinated Universal
Time (UTC) is recommended as this
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
In: MVS Interactive Problem Control System (IPCS) Customization
Version 2 Release 3 SA23-1383-30
I read:
TOD Clock Service
The time-of-day (TOD) clock service provides a caller, including your exit
routine,
with a TOD clock image. In the clock image, bit 0 is set on to allow 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
services (TIME, STCKCONV,
CONVTOD, BLSUXTOD, etc) pay attention to leap seconds. Nor are they likely
ever to do so, if only because no one wants to have to update them
whenever a leap second "shows up".
If you want a service that does something with a historical time stamp and
leap sec
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
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 functio
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.
and BLSUXTOD conversion service
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-determin
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
or leap seconds. When you
JM>use BLSUXTOD, you are expected to any adjustments of interest to you
JM>before calling BLSUXTOD.
>>
>:>IOW, BLSUXTOD does the easy part and leaves the hard part for the user.
>...
>Adjusting the clock (if you know the difference) is quite
s 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 know the context of the TOD clock value you are passing,
>
:>Context? Shouldn't values of properly set TOD clocks read at the same time
:>
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:
> B
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
ble 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 inserted on June 30, 2015 after 23:59:59. So
there is a valid time stamp 23:59:60 on June 30st, just
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 cloc
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
46 matches
Mail list logo
