Re: 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. > Kind of like: https://en.wikipedia.org/wiki/Maya_calendar#Long_Count >I will initiate an RCF to get this updated. > Thanks for turning over that rock. I couldn't have come close to what you did. I started a similar thread on ASSEMBLER-LIST, trying to avoid the innumeracy hangup. I'll try to snip it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLSUXTOD
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 service to handle values from May 11,1971, at 11:56:53.685248 to January 25, 2114, at 11:50:41.055743. 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. Currently, but 0 off in the STCK result means (approximately) "before 1971", and bit 1 on means 1971-2042 (approximately). But come the end of the standard epoch, bit 0 off will be treated when windowed (approximately) as the 71 years following the end of the standard epoch. Thus, the wording is wrong, and Gil's puzzlement is fully understandable. It's actually that an input STCK value with bit 0 off is treated as "after the end of the standard epoch, not the first part of the standard epoch". But it's worse. The lead-in does not match the service names. The lead-in for the section has "provides a caller...with a TOD clock image" which does 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 and BLSUXTID/BLSUETID. The "TOD" services take an input clock value and return a formatted date/time. The "TID" services take an input formatted date/time and return a clock value. The book has two sections -- "TOD Clock Service" and "26-Character Time Stamp Service". The section name should correspond to the output. Thus TOD Clock Service would be BLSUXTID. 26-Character Time Stamp Service would be BLSUXTOD. And that is analogous to the 17-Character Time Stamp Service which is BLSUMTOD and is documented as such. The 26-Character Time Stamp Service has analogous errors (and its register sub-section incorrectly shows the "TID" name) The register section also has this: Note: If using a LINK macro, specify the addresses of the fullwords in the PARAM parameter. which is wrong. If using a LINK macro, you would specify the parameters in the PARAM parameter. I will initiate an RCF to get this updated. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLSUXTOD
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, 1900 because there are 0 years left after you subtract the year 1900. >> On Fri, 28 Dec 2018 18:18:51 -0600, Joe Monk wrote: >> >> >So, January 1, 1900 + 143 years = January 1, 2042, which is when the 104 >> >bit clock will roll over, and bit 0 will return to zero. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLSUXTOD
"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 incremented every 1 microsecond. Carries are propagated out of bit 0. Joe On Fri, Dec 28, 2018 at 8:32 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > 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. Coordinated > Universal > > Time (UTC) is recommended as this origin, and it is said to begin the > > standard epoch for the clock. > > > > - The time-of-day (TOD) clock provides a high- resolution measure of > > real time suitable for the indication of date and time of day. The > cycle of > > the clock is approximately 143 years. > > > > - The TOD clock is a 104-bit register. > > > How are those bits numbered? 0 to 103? What's the value of bit 0? What's > the value of bit 103? > > >So, January 1, 1900 + 143 years = January 1, 2042, which is when the 104 > >bit clock will roll over, and bit 0 will return to zero. > > > By my arithmetic, January 1, 1900 + 143 years = January 1, 2043. > > Doesn't forcing bit 0 to 1 as described below restrict the cycle of the > clock > to 71 years rather than the 143 years from 1971 to 2114 stated below? > > >On Fri, Dec 28, 2018 at 5:06 PM Paul Gilmartin wrote: > > > >> 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 service to > >> handle values from May 11,1971, at 11:56:53.685248 to January 25, > 2114, at > >> 11:50:41.055743. > >> > >> ??? > >> But in PoOps I see > >> ... > >> If the programming support uses the standard epoch, bit 0 of the > clock > >> remains one > >> through the years 1972-2041. (Bit 0 turned on at 11:56:53.685248 > (UTC) > >> May 11, 1971.) > >> > >> I'm inclined to believe the latter, and that Bit 0 returns to 0, not 1, > in > >> September, 2042. > >> Is there an error in the IPCS doc? > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLSUXTOD
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. Coordinated Universal > Time (UTC) is recommended as this origin, and it is said to begin the > standard epoch for the clock. > > - The time-of-day (TOD) clock provides a high- resolution measure of > real time suitable for the indication of date and time of day. The cycle of > the clock is approximately 143 years. > > - The TOD clock is a 104-bit register. > How are those bits numbered? 0 to 103? What's the value of bit 0? What's the value of bit 103? >So, January 1, 1900 + 143 years = January 1, 2042, which is when the 104 >bit clock will roll over, and bit 0 will return to zero. > By my arithmetic, January 1, 1900 + 143 years = January 1, 2043. Doesn't forcing bit 0 to 1 as described below restrict the cycle of the clock to 71 years rather than the 143 years from 1971 to 2114 stated below? >On Fri, Dec 28, 2018 at 5:06 PM Paul Gilmartin wrote: > >> 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 >> service to >> handle values from May 11,1971, at 11:56:53.685248 to January 25, 2114, >> at >> 11:50:41.055743. >> >> ??? >> But in PoOps I see >> ... >> If the programming support uses the standard epoch, bit 0 of the clock >> remains one >> through the years 1972-2041. (Bit 0 turned on at 11:56:53.685248 (UTC) >> May 11, 1971.) >> >> I'm inclined to believe the latter, and that Bit 0 returns to 0, not 1, in >> September, 2042. >> Is there an error in the IPCS doc? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLSUXTOD
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 origin, and it is said to begin the standard epoch for the clock. - The time-of-day (TOD) clock provides a high- resolution measure of real time suitable for the indication of date and time of day. The cycle of the clock is approximately 143 years. - The TOD clock is a 104-bit register. So, January 1, 1900 + 143 years = January 1, 2042, which is when the 104 bit clock will roll over, and bit 0 will return to zero. Joe On Fri, Dec 28, 2018 at 5:06 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > 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 service to > handle values from May 11,1971, at 11:56:53.685248 to January 25, > 2114, at > 11:50:41.055743. > > ??? > But in PoOps I see > ... > If the programming support uses the standard epoch, bit 0 of the clock > remains one > through the years 1972-2041. (Bit 0 turned on at 11:56:53.685248 (UTC) > May 11, 1971.) > > I'm inclined to believe the latter, and that Bit 0 returns to 0, not 1, in > September, 2042. > Is there an error in the IPCS doc? > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
