December 04, 2017
2028 was never MPE's end of life date
Even though it was designed in the late 1960s, MPE never had an end of life date. Hewlett-Packard chose to call its end of business deadline for MPE/iX the 3000's end of life. HP was done in December of 2010, but the end of life claim was never true. Now we've learned that not even the expiration of the CALENDAR intrinsic's accuracy, in 10 years from this month, won't make the 3000 die, either.
During the latest CAMUS conference call, a few developers and support providers made the future clear. The year 2028 would not be the moment when a 3000 would fail to boot up and run software including the MPE/iX OS. This was only the year when CALENDAR wouldn't be useful.
"I'm hearing the system won't roll over and die on January 1, 2028," said one 3000 owner during the call.
"Correct," said Doug Werth at Beechglen. "There are some things that may stick at 2027, depending on how the code was written." Some dating features go back to 1900 for the YYYY elements of the date fields. "There are a lot of places in the operating system that still use the CALENDAR format," Werth added.
Support providers can prepare repairs for the places where MPE uses CALENDAR. The seven companies with source code for the 3000's OS, such as Pivital Solutions, can craft more elegant solutions.
Terry Floyd of the Support Group said MANMAN calls CALENDAR in the subroutine SLJDMPE, "which is used all over the place." Floyd has identified and outlined a repair for MANMAN's source code that permits the MPE/iX application to run until 2049.
Nobody has had much conversation about another alleged end of life date for alternatives to MPE/iX. Unix and its date handling routines stop being accurate in 2038. It's also true for Linux, which drives a lot of the enterprise applications that have tried to replace 3000 apps, as well as much of the cloud-based servers like Amazon's. End of life is not a phrase used in that discussion, one so prevalent that Year 2038 has its own Wikipedia page.The latest time that can be represented in Unix’s signed 32-bit integer time format is 03:14:07 UTC on Jan. 19, 2038. The date is 2,147,483,647 seconds after Jan. 1, 1970. (Both MPE used 1 January 1900 as a start date.) Beyond that time in that January of 2038, due to integer overflow, Unix time values will be stored as a negative number and the Unix and Linux systems will read the date as Dec. 13, 1901 rather than Jan. 19, 2038. There's even a cute animation of what the cutover will look like 20 years from now.
Embedded Linux is getting some attention for its date failure situation. Linux uses a 64-bit time_t for 64-bit architectures only; the pure 32-bit Application Binary Interface would not be changed due to backward compatibility. Embedded Linux systems would then support 64-bit time_t on 32-bit architectures, too.
At least MPE's CALENDAR will continue to provide the correct date of the correct month on the first day of 2028. A pivot point might be one way to resolve that for any customer who cannot modify application source code. The modification would use HPCALENDAR as a replacement for CALENDAR.
As we expected and hoped, MPE experts are already thinking about how to resolve Y2028. That they'd be doing so here in 2017 should be proof enough that the end of life of MPE/iX is far away. That's not so for the HP 3000—although an emulated 3000 has got a hardware end of life. Stromasys Charon relies on Linux, so there's work afoot to resolve that, too.
Use our search engine to find 20 years
of HP 3000 news and articles
The comments to this entry are closed.