HP 3000 customers, support experts, and vendors have heard a fresh take on the upcoming demise of CALENDAR functions. Date keeping was going to suffer for anybody who needed that intrinsic to steer 3000 date-keeping. Nobody wanted to debate that fact. As I reported in 2015, with considerable help from Vesoft's Vladimir Volokh, CALENDAR doesn't have enough bits to track dates beyond December 31, 2027. It would be easy to conclude the 3000's date capability will go bust at the end of that December.
That's fake news, said Steve Cooper of Allegro to everyone on last week's CAMUS user group call. "A whole lot of fake news," he said, when one user referenced our 2015 article as proof dates were going to be a problem on 3000s in about 10 years. "You need to get the true scoop instead of spreading rumors."
Cooper was one of several 3000 experts who said that dates could be kept accurately in MPE/iX for much longer than 10 years from the end of next month. HP's replacement for CALENDAR—an intrinsic written in the early 1970s—adds bits to let 3000s track data. HPCALENDAR isn't employed inside lots of MPE/iX software, but that will change for anyone who wants their MPE/iX end of life to be determined by utility and value, rather than capability.
In 2015, our story asked Whether the End of 2027 is MPE's End, Too. It isn't, so long as you use HPCALENDAR to replace CALENDAR. MPE/iX app managers will need source code access to make this kind of substitution, using the new intrinsic method of remediation.
There was also talk of a pivot point strategy to handle things without replacing CALENDAR. Pivot points were in vogue for some Y2K repairs. In such designs, software processes a date by comparing the date to the moment it processes the date. The old ColdFusion software from Microsoft did this to add century information for Y2K, for example. A Stack Overflow discussion illustrates how pivot points work in Python.
HP advised its 3000 customers in 2008 to begin using HPCALENDAR on HP 3000s. HPCALENDAR harks back to version 5.5 of MPE/iX. Its power lies in the 3000 for use by programmers who want accurate dates beyond 2038 (the limit in Unix) for application files.
HP ordered 16 extra bits for date handling through HPCALENDAR in the 1990s, just too late to influence the heart of MPE.
While working in the realm of those original 16-bit MPE intrinsics, "You cannot make less than 9 bits for the date of the year," Vladimir said. "That would be less than 365 days. So that leaves us 7 bits to express the year."
The '90s HPCALENDAR, reaching into the new elbow room of 32 bits, can use as many as 23 bits for the year. That intrinsic will cover 8 million years, even more. HPCALENDAR is available in Native Mode MPE, and it remains the best choice for any new work done on a 3000's applications.
But MPE's existing intrinsics provide the barrier here: the oldest are in Segmented Library (SL)—and the newer HPCALENDAR is in Native Library (NL). And the only companies with any chance of adjusting the 3000's dates into 2028 and beyond are those which have insight into MPE/iX source. Then there's knowing what to do with it. They must get into the MPE source and recompile it to use HPCALENDAR.
That insight into MPE/iX source is needed for a system-wide repair of CALENDAR date intrinsic functionality. It's a broad spectrum fix, though, when a localized alteration will do the job. Even HP's own SHOWCLOCK gets the date correct when you boot a system by setting its date for 2028.
"There are still some pieces of code that are doing date handling by calling CALENDAR," Cooper said. "But the operating system does not fall over dead at that point. The banner will say "1900" and if you do a SHOWTIME it will say 1900. But if you do a SHOWCLOCK it will correctly show '2028'."
Reading a file, modifying a file: these will occur with the correct timestamps. They all use the larger, more modern date format. Programs which use CALENDAR will provide a date in the 1900s when run on 2028. The date-keeping in the MPE/iX banner is going to be incorrect. Any software that reaches out for a date intrinsic will be just fine if it uses HPCALENDAR.
The user group has its board member Ed Stein to thank for the talk about the date changes coming up in a decade or so. Stein says that he'd rather seek out date repairs now for his 3000s, while there are still support and development experts taking on projects. There's a lot less retirement going on for people working in their late 70s. But Stein, like a lot of 3000 pros, understands it's better to take care of things before they become unsolvable problems—when there's nobody working who knows where CALENDAR might be running inside a program on MPE/iX.