I agree with the comments on what should have been done, and I agree that the documentation needs to be corrected. However, I also agree with IBM that they should not introduce an incompatibility and that any enhancement to TOD conversion requires a business case. A starting point might be to research the acceptability of z/OS Unix System Service (*NOT* USS!) to the *ix community and the effect of that on z sales.
With regard to whether z/OS is UNIX, I must reluctantly agree that it is, albeit without many of the facilities that the community expects. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> 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 really must speak up here in defense of Paul/Gil's long time position on the failings of the STCKCONV/CONVTOD services. Firstly, you are not correct that "no one agrees with" Paul/Gil's position on the values produced by STCKCONV. There are at least some of us out here who agree with his position wholeheartedly. Our failing is not to have spoken up in his defense previously to now. Contrary to your opinion, Paul/Gil's use of "correct" is factually correct. People (including programmers) may reasonably expect that a request to convert a machine-based time value to "the local time" should produce an accurate representation of that local time. Similarly, if a programmer asks for a conversion of a machine-based time value to GMT/UTC/TAI or other time standard then they should get what was requested. Whatever architectural basis is used for the epoch at the machine level, the result of requesting a conversion of that hardware time measurement into human-intelligible format must produce "the correct time" according to the locale-ly correct standard, including "daylight savings" or "summer time" variations and also leap seconds. STCKCONV and CONVTOD perform neither of these functions, and should long since have been clearly documented as not performing them. In this sense, Paul/Gil's assertion that these services only produce accurate values prior to 1972 is factually accurate in one sense, since before 1972 we had no leap seconds. Paul/Gil is of course not totally accurate either, in that since the values produced by these services never did take locale-specific DST variations into consideration, by the rule of "locale-ly correct" even values prior to 1972 are not accurately converted. Paul/Gil's oft-expressed desire for IBM to fully support the Olson time database (I think I have that name correct, but please correct me if I do not), the "tz" timezone database that is regularly updated and supported across (most of) the rest of the computing world is something that I agree should have been done by IBM a very long time ago, especially since "z/OS is Unix" is an oft-repeated claim. If you do not support the Unix time database standard then you are not (entirely) Unix. And I frankly care not a whig whether it is POSIXly correct to say that or not. It does not conform to the commonly understood Unix time standard among programmers around the world. Period. Simply documenting the obvious failure of the STCKCONV/CONVTOD services to support leap seconds and locale-specific DST rules in any form is the very least that IBM should do. I can agree with your (I think unstated, or perhaps only stated infrequently) opinion that the STCKCONV/CONVTOD services themselves should not change to support time conversion features that they do not currently support. Too many compatibility and support issues to count. That there should be a new pair of services with enhanced capabilities available as alternatives to STCKCONV and CONVTOD, which new services actively use the "tz" database and correctly adjust any conversion for leap seconds as well as locale-dependent DST issues would be an obvious (to me) solution, along with carefully documenting STCKCONV's/CONVTOD's limitations in these areas. As for current LE provided time/date services, a brief RTFM reveals that many of them seem to use a different epoch than the (E)TOD clock, specifically 00:00:00 14 October 1582 according to the current LE Programming Reference. And only one of those services (CEEGMTO) purports to know the difference between local time and GMT time. Most confusing. All opinions expressed here are purely my own, and not my employer's. With utmost respect and admiration for your continued activity in this forum 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 BLSUXTOD conversion service <snip> 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. </snip> You have been saying the same thing for years, with no one apparently agreeing with you. The "time output by these services" corresponds exactly to the input values, according to an architectural definition. That is what you have been told you multiple times. , There is an assumption of using the standard epoch (if that assumption is not mentioned, I'd support mentioning it). <snip> Would you be willing to see added to this description a caution such as: Note: if the (E)TOD clock is set according to IBM's recommendation, the times output by STCKCONV and CONVTOD do not match the input values, but may differ according to the content of various common control blocks. ? </snip> No I would not. Because it is not true, unless I am misunderstanding. <snip> What was the objective of providing these two services? </snip> I do not know. They meet the needs of whoever is using them currently. <snip> They give correct results only for dates before 1972, and I see little value in that. </snip> I believe that they give correct results in 100% of cases. I think that it is your use of "correct" that is not correct. I have already mentioned being willing to document that leap seconds are not taken into account. Anyone who needs leap seconds to be taken into account can adjust their STCK value accordingly. If you were to ask for a system service that would do that adjustment, under the assumption of use of the standard epoch, a service that would be adjusted every time a leap second is added, that would be reasonable. I suspect (without knowledge) that there already are ways of getting that done either through LE or USS. Of course "reasonable" does not equate to "likely to happen" -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- 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
