>In 1972 leap seconds broke this ability. STCKCONV was not updated to >account for this innovation.
STCKCONV was not created until 1990. Not processing of leap seconds was probably more due to the fact that a human typically does not need the answer to take that into account. No one that I know of has made a business case that they do. If you want to format "now", then you can use TIME. And you can ask that the output be provided in one of many formats, including LOCAL and GMT/UTC (each of which has a definition of how it is calculated from the current clock value, where GMT's and UTC's definitions are the same). If you want to format the time represented by a "random" 8-byte (or 16-byte) value in STCK(E) format, according to its architectural definition where bit 51 of the 64-bit value is incremented by 1 every microsecond, and the year 1900 is value 0, then you can use STCKCONV. The time need not be a "past" time; it could be a "future" time (up to a limit which I think in the most current z/OS release is the end of the 2nd epoch). It is true that leap seconds are not taken into account in the (close-enough-for-human-consumption) STCKCONV or CONVTOD processing. If you would like a statement in the book that that is the case, we would likely agree to do so. There are also IPCS-provided modules (that need not be used within IPCS) that do the same sorts of conversions that STCKCONV / CONVTOD do, with differently formatted output. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
