Re: AW: Re: TOD clock values, leap seconds and BLSUXTOD conversion service

2018-09-14 Thread Paul Gilmartin
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 about that fact.
>
(Concerning the similar STCKCONV):
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 caller in the format requested. " This is correct
>and is complete and is all that the service can say.
>
I (and apparently you) disagree about "complete".  The doc could at least 
specify timezone.  It seems to be, "none, rather TAI-27 seconds.)

>>What there is is a lack of functionality that would usually be unimportant to 
>>have.
>
>Usually unimportant Hmmm. Suppose, I have a case to chase where z/OS as 
>well as some non-mainframe parts are involved. Looking at a SYSTRACE of a 
>related dump. Timestamps show by IPCS and those from somewhere else are, as of 
>the last leap-second, 27 seconds apart.
>
>I don't say I had bee burnt by such a case, yet. But I would not state this 
>fact as unimportant.
>I can live with this. I'm just surprised.

See Peter Farley's rhetorical plaint here a couple hours ago.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


AW: Re: TOD clock values, leap seconds and BLSUXTOD conversion service

2018-09-14 Thread Peter Hunkeler

>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 that would usually be unimportant to 
>have.


Usually unimportant Hmmm. Suppose, I have a case to chase where z/OS as 
well as some non-mainframe parts are involved. Looking at a SYSTRACE of a 
related dump. Timestamps show by IPCS and those from somewhere else are, as of 
the last leap-second, 27 seconds apart.


I don't say I had bee burnt by such a case, yet. But I would not state this 
fact as unimportant.
I can live with this. I'm just surprised.


--
Peter Hunkeler







--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN