« 3000 system census surprises in UK | Main | RAIDing LDEV1, finding code for migration »

April 30, 2012

3000's use in 2028: bug, or feature?

The CALENDAR intrinsic that blocks HP 3000 use in 2028 has been described as a bug. On the first day of that year, dates will not be represented accurately. Some in your community consider that New Year's Day, less than 16 years from now, as the 3000's final barrier. But it depends on how you look at it -- as a veteran, or a voyager.

VladimirNov2010A voyager sees CALENDAR as a deadline for departure. This is a part of MPE that was designed in the 1970s, a period when HP had just scrapped a 32-bit release of the 3000's first OS. And just like the Y2K date design, HP engineers never figured their server's OS had any shot of working by the 21st Century -- let alone 2027. But VEsoft's Vladimir Volokh says, "It's difficult to predict anything, especially the future." An IT pro who's planning to depart the 3000 believes CALENDAR is a bug, but that's not how Vladimir sees it.

"This is not a bug, really," he said. "It's a limitation. The end of 2027 date was as far away as infinity when MPE was created." This is a man who defines the term veteran, the kind of professionals who had to work inside 4K memory spaces to build 3000 programs. Limited and expensive resources like memory and disc were supposed to be extended with newer computers. "Every analyst told us a computer would live five years, at most," Vladimir said.

But as a veteran, you've now come to see the day when MPE's lifespan is reaching eight times that prediction. The veteran who chooses to see CALENDAR as a limitation can refer to HP's own lab response. Engineers during the '90s built HPCALENDAR to start extending the 3000's date limits.

The HP 3000's date intrinsics will outlast those in Unix, so long as a program uses HPCALENDAR. HP advised its 3000 customers in 2008 to begin using it 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.

Lifting the limits in application date handling -- that's one level of engineering skill. Extending the operating system limits beyond the 16-bit CALENDAR is a task with a greater challenge. It doesn't mean that it cannot be done. What matters is how healthy the 3000's best experts will be in 10 years or so. Vladimir says he'll be younger than 90 by then. Almost everyone in today's community will be even younger. And isn't 70 the new 60? It will matter when the 3000 needs the last set of bits to move from 16 to 32.

There's a old joke about software shortcomings being called features, rather than a bugs. Veterans learn to call them limitations and look for ways to overcome these aging designs. Everything is aging, even something as omnipresent at Windows XP. (Microsoft wants to end the life of that OS, used on more than 90 million computers, by 2014. Good luck with that.) XP is dying, the 3000 is dying. Well yes, says Vladimir. He tells his hundreds of customers who he visits, "We are all dying. But slowly."

12:59 PM in Hidden Value, History, Homesteading | Permalink

Bookmark and Share

No more trying to figure out what runs on
MPE/iX or where to find it. No more worrying
about availability! www.MPE-OpenSource.org
is all things MPE/iX: Open Source packages,
freeware, scripting, plus loads of tools
and information to keep your 3000 system
alive and thriving!

Comments

Comments

The comments to this entry are closed.