http://www1.cuny.edu/events/fyei/spring_1998/humor.html
On Sat, Mar 25, 2023 at 8:16 AM Peter Relson <rel...@us.ibm.com> wrote: > > z/OS does not support setting the clock past the end of the first epoch. Some > forthcoming z/OS release will. > Until then it would probably not be a good idea to try to fake out the > system. Things will break. > z/OS does support expiration dates (such as mortgage end, etc) beyond the > first epoch. > > Interfaces are in place to allow you to provide a STCKE-format timestamp, but > that doesn't mean that applications have changed to do so. > > Joel E wrote > <snip> > I agree it would be a real rarity for any application code to have any > STCK vs STCKE issues. It would even be rare for ANY installation-written > code to work with TOD values, so much so that any cases would likely be > well known to the Technical Support staff. All application code I ever > saw using a timestamp value used something like the DB2 timestamp > format, not hardware-specific timestamps. > </snip> > > I don't think it is rare at all. > > Joel E wrote > <snip> > I don't see 2042 being much of a z/OS issue for anyone outside of > IBM, and maybe a few 3rd-party vendors. > </snip> > > You might need to reconsider. > > Joel E wrote > <snip> > I think the odds are extremely high that if IBM verifies there are no 2042 > issues in z/OS or in their other products that run on z/OS, that > individual installations will not have any issues with their z/OS > applications. > </snip> > > I on the other hand think the odds are extremely low. But it does primarily > come down to whether they use STCK/STCKF vs STCKE or interfaces that under > the covers use them. > > Gil wrote > <snip> > But most systems I use admirably do not allow non-privileged users to access > the hardware clock. > </snip> > > If by access you mean "write", sure. But I think this discussion is about > "read". > You cannot prevent non-privileged users from reading the clock whether by > STCK, STCKF, or STCKE. > > > > Many use cases within z/OS will continue to use STCK/STCKF for compatibility > reasons, providing a windowing approach that works for 71-ish years at a clip > (or maybe it's 142-ish years at a clip). For example, the windowing will > treat a STCK value with 0 in the high bit not as being between 1900 and 1971 > (the first half of the first epoch) but rather as being between 2042 and 2113 > (approximately) (the first half of the second epoch). And yes that means that > you might well not be able to reliably use data with timestamps that is older > than that (think SMF records). And come back in another 71 years and a STCK > value with 1 in the high bit will not be treated as between 1971 and 2042 but > rather 2113 and 2184 (approximately). > > Other use cases will change (or have changed) to use STCKE (which will can > cover dates well past the Y9999K problem that no one here is going to spend > resources worrying about). > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
