My original point was that new programs should obtain and work only with sixteen-byte STCKE values.
The imposed SMFSTAMP-value format must in the short term be respected, but this requirement does not entail use of eight-byte STCK values in programming. It is better to discard some TOD data in some fields than not to have them available. About Y2k windowing and the usability of similar techniques for STCK-value windowing opinions may differ greatly. The Y2k windowing schemes I am familiar with have mostly worked badly and required much tinkering/adjustment, as indeed have other ad hoc Y2k remediation schemes. (it is not much talked about, but Y2K-related maintenance expenses are ongoing in many large IT organizations.) What can be said with some confidence is that in the light of our Y2K experience there will and should be little sympathy for those who do not address the 2042 problem in a timely way. --jg On 1/31/12, Barry Merrill <ba...@mxg.com> wrote: > 1. Dates beyond 2042 are nearly possible, since tape retention can be 30 > years. > > 2. I have seen IMS APARs that indicate STCKE values are now stored in some > control blocks. > > 3. The TODSTAMP wrap only impacts SMF record fields that are in TOD format; > the SMFSTAMP > format has no wrap because it's date is a separate 4-byte part of the > 8-byte field, > and the date contains the century bit, which won't wrap for 254 > centuries. > > 4. TODSTAMP has microsecond resolution, while SMFSTAMP is limited to 10 > milliseconds, > so TODSTAMP is (IMO) preferred in new SMF records, except for the SMFTIME > field in > the header that still needs to be SMFSTAMP format. > > 5. In MXG processing members, I observed these counts: > > IBM SMF records Vendor SMF records Total Instances > > TODSTAMPs 651 667 1318 > > SMFSTAMPs 147 345 592 > > 6. I plan to be here to observe the wrap; I'll be 101+six months in Sept > 2042. > > Barry Merrill > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf > Of Charles Mills > Sent: Tuesday, January 31, 2012 11:58 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: TOD clock format > >> the programs that digest the records can actually deal with that > > If I had to venture a guess I would guess that 64-bit TOD clock fields will > still be around post-2042 and programs will be using windowing techniques to > decide if a particular 64-bit TOD value is a date and time in 1901 or a date > and time in 2043 (with 2043 being a lot more likely, of course). The problem > is of course somewhat more complicated than Y2K because the time and entire > date will have to be adjusted as well as the year. > > 2042 sounds like it is a long way away, but 2000 seemed like it was a long > way away in 1970. "Are you kidding? We won't still be using my COBOL program > in 2000 -- computers will just be reading our minds by then." > > Actually, I guess, the biggest problem is not that programs endure -- it is > that record layouts (like SMF) and control block formats (like the 24-bit > DCB) endure seemingly forever. > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf > Of Phil Smith > Sent: Tuesday, January 31, 2012 7:08 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: TOD clock format > > John Gilmore wrote: >>There is thus no excuse for any use of an STCK instruction in NEW code. >>Old code is a different matter, If it is judged that there is NO >>possibility that it will still be in use in 2042, STCKs in it need not >>be replaced. Otherwise they should be. > > How about code that's generating SMF records? That's what we're dealing with > here. Yeah, 2042 might be an issue, but the programs that digest the records > can actually deal with that (and will have to, or SMF in general will by > then). > > ...phsiii > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > -- John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
