It all depends on where you use the windowing. If for terseness on
data entry for internal conversion to 4-digit years and retention as
4-digit years, then a floating window relative in some way to current
year is the obvious and only rational choice.
If you elected to retain the date as a 2-digit year in external files or
data-base records and must be able to continue to read the data, then a
floating window is not an option for externally saved dates: the
windowing base-year choice is implicitly fixed by assumptions at
creation once you store a date in 2-digit year format.
If you made your applications smart enough to associate or "compute"
(based on a 4-digit year stored somewhere) a 4-digit base year to use
for windowing with each data set or data base record containing 2-digit
years, I guess you could make make historical 2-digit year dates work
indefinitely with both new and historical data; but that sounds like
something that would be much more difficult to maintain without error
and more costly in the long run than just changing external data formats
and storing 4-digit years. Otherwise, virtually every time you needed
to process a two-digit year in historic data, you would first need to
pre-process the date field to determine the appropriate window base-year
and to expand to a 4-digit year.
z/OS applications should be basing time-related decisions using
time/date formats with 4-digit years, and not relying on internal binary
clock formats. At least at our installation during Y2K mitigation there
was no application programmer code dependency on the hardware TOD clock
for date determination, and I would think that would be more the rule
than an exception. I wouldn't expect much of a ripple from the z/OS
hardware clock wrap, because for the most part only z/OS itself and some
IBM subsystems need to be able to deal with it -- not an issue unless
you plan to be running on a severely back-level unsupported version of
z/OS at the time of the wrap. I can't speak for Unix/Linux application
conventions.
JC Ewing
On 1/9/20 11:04 AM, Charles Mills wrote:
I am not an applications guy, and I didn't do any applications Y2K remediation,
so I am not an expert, but it would seem to me that if I had used windowing I
would have based the window on the current date -- today minus 80 years or
something like that -- so that it would never fail (in this way -- of course,
software has many ways to fail). It would work as well in 2040 as it did in
2000.
Don't forget we've got another one of these coming up in 2042, and for people
using UNIX times, one in 2038. 2042 does not seem so far away as it once did.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Joel C. Ewing
Sent: Thursday, January 9, 2020 8:37 AM
To: [email protected]
Subject: Re: it was 20 years ago today ....
I always preferred to describe a 100-year windowed two-digit year
representation by its lowest or "base" year, in this case 1920 -- just
easier for me to visualize the 100 continguous years of validity on a
timeline..
One would hope those who chose the fixed-windowing temporary solution to
Y2K described in this article were honest enough to call 2020 the
"Failure Year" and not some nice euphemism like "Pivot Year" that would
sound less threatening to management with marginal tech skills.
JC Ewing
On 1/9/20 9:14 AM, Charles Mills wrote:
https://www.zdnet.com/article/the-y2k-bug-is-back-causing-headaches-for-developers-again/?ftag=TRE-03-10aaa6b&bhid=21203266192019599533914397741980
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
