> Assuming you are referring to the statement that the ETOD as currently > defined will still overflow at the same time as the old TOD clock, this > statement is technically correct although it is also clearly stated by > IBM that the obvious extension into the high-order zero byte is planned > for the future. Here is what the PofOp says: > > "At some time in the future, STORE CLOCK EXTENDED on new models will > store a leftmost extension of the TOD clock in byte position 0 of its > storage operand" > > So, if at the time of the TOD rollover you are still running "old" > hardware (where what constitutes "new" is still undefined), STCKE WILL > overflow at the same time as STCK and the old TOD. > > What also seems to be unfortunately left ambiguous at this point is > whether the z/OS date conversion facilities that allow you to convert to > and from the ETOD format include support for ETOD values with a non-zero > high-order byte. Those conversion facilities have some very nice > features and could be the basis for some generalized date calculation > routines, where the ETOD format is only used as an intermediate form in > date calculation for historic and future dates. But the way ETOD is > currently formally defined, one would have to assume that these > conversion routines might not tolerate a non zero high order byte and > would fail with conversion of dates beyond the TOD overflow point. > > The fact the current hardware may only support setting and storing ETOD > values with a high order zero byte should not preclude software support > for larger values when these values are used in other contexts than > setting and storing the hardware clock. > > It would be more useful for coding and generalized use of the conversion > facilities if the formal definition of the ETOD format explicitly showed > the high-order byte as an active part of the time value, with a footnote > stating that current hardware models are only capable of being set to > times and storing times where the high-order byte is zero. Perhaps this > is what was intended by IBM, but it is not what is stated. Since this > is the only place the ETOD format is formally defined, until the > definition is changed one is forced to assume ETOD software date > conversion facilities don't support ETOD dates beyond the TOD overflow. > > -- > Joel C. Ewing, Fort Smith, AR jcew...@acm.org
IEATTIME (service routine for TIME and STCKCONV) and IEATCNVT(service routine for CONVTOD) currently do not process the high order byte of an ETOD value. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
