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
