HP did keep MPE's CALENDAR up to date
April 14, 2014
Last week I lumped a error of omission by users into the basket of Hewlett-Packard's 3000 miscalculations. I made my own mistake by doing that. In part of an article about the 3000 user's longer view, I figured the miscue that sparked programming for the Y2K crisis fell into HP's lap. After all, the date handling in MPE was built to break down in 2028. Surely the valiant reworking of two-digit year representation came from a shortcoming out of HP's labs as well, I reckoned.
Vladimir Volokh called me to correct that concept. There was much work to do in our community to salvage good computing in the years leading up to 2000. But that work was the result of developers repairing their own mis-estimations of the durability of 3000 applications. Four-digit representations of years were possible from the very first month the 3000 went into serious duty. (That month happens to be just about 40 years ago, as of this month.) The users of the system, and commercial developers, just didn't see the need for using precious storage to represent four complete digits during 1974.
Four decades have brought the 3000's dating capability within sight of the end-date of accuracy. In the same way as 2000 was a community-wide roadblock, Volokh said that, just like age 70 is the new 60, "2028 has become the new Y2K."
The year 2028 is notable for customers who don't plan to leave the HP 3000. It's the year when timestamps stop being accurate, because the CALENDAR intrinsic in MPE/iX only uses 7 bits to store year information.
For those HP 3000 applications using CALENDAR, HP has advised you use the newer HPCALENDAR in your apps. The newer intrinsic, polished up in 1998 with version 6.0, extends the 3000 application's date accuracy to more than five decades beyond the 3000's inception. 2027 will be the last year to accurately generate timestamps in the 3000's filesystem. HPCALENDAR goes further, for whatever that's worth.
An HP advisory explained the differences, at least in part:
The original MPE timestamp format was that used by the CALENDAR intrinsic, a 16 bit quantity allowing 9 bits for the day of the year and 7 bits for the year, added to 1900. Since the largest number represented by 7 bits is 127, this format is limited to accurately storing years up to 2027.
The newer HPCALENDAR intrinsic uses a 32 bit quantity, allowing 23 bits for the year, since 1900 and the same 9 bits for the day of the year. This format provides a significantly longer period of timestamp accuracy.
If, for example someone needs to store the maturity date for a 30 year mortgage started this month, neither the traditional CALENDAR format nor the time() format will work as they are only accurate to 31 December 2027 and 19 January 2038 respectively. The HPCALENDAR date format provides 23 bits to store the year added to 1900 — and since one can store 8,388,607 in those 23 bits, this format provides the best accuracy for storing future dates on the e3000.
The advisory says in part
Certain Posix applications may use the time() function as the basis for timestamps; and may therefore, store timestamps in the format used by time(), which is a 32 bit quantity representing the number of seconds from the epoch 1 January 1970. This format is limited to accurately storing timestamps up to 19 January 2038.
If your applications have a need to create and store future transaction timestamps, HP recommends using HPCALENDAR, HPDATECONVERT, HPDATEDIFF, HPDATEFORMAT or HPDATEOFFSET to ensure they are created correctly.
HP built MPE to an extraordinary level of durability. Employing MPE/iX on the application level, you can use the invented-in-HP HPCALENDAR intrinsic for apps. Alas, as of this month, the intrinsic for the filesystem, CALENDAR, does have a shorter working lifespan. But I overstepped in thinking that HP wasn't thinking far enough into the future about the 3000. It's just that a reasonable choice about the time-span for filesystem date intrinsics seemed ample, at space enough for 54 years. However, the 3000 is clocking in to begin year Number 41 this month. It may take a village of MPE's experts to reach into 2028 and beyond.
HP first released 5.5 PowerPatch 4 as a Year 2000-ready release during December of 1997. But a more comprehensive, company-wide definition of Year 2000 compliance resulted in new versions of the date intrinsics, which HP first made available in that 1998 PowerPatch.
At the time, users felt like they were overwhelmed enough with their own repairs, and didn't want to think they'd be waiting on HP to repair application date handling. One healthcare IT manager said, "It seems that what I suspected is correct — Y2K fixes will be forthcoming up to and even after Year 2000 arrives. At some point we must evaluate how bad the problems are, and settle on a base release.”
HP's MPE product manager at the time acknowledged that some customers would need to install a PowerPatch "if they use HP’s date intrinsics in their applications." The statement makes me wonder what else a modern-day programmer would be using in an app. There are other ways that an MPE app could cast the date of a transaction or a file. Perhaps anybody who'd develop this sort of intrinsic magic on their own could help in the village-wide challenge to accurately date in 2028.