« MPE source code ID'ed as key to encryption | Main | Stromasys reports aim at speed, and help »

April 04, 2016

Working to Set MPE's Future to Forever

AbacusWhen a 3000 manager asked about running Speedware on the Stromasys Charon HPA emulator, the question evolved quickly. In just a few hours, MPE experts were talking about how long the OS could keep running. The detour of the 2027 CALENDAR intrinsic came up. It turns out the community experts are already working on that.

Jeff Elmer of Dairylea Cooperative, whose success story with Charon was part of our 2014 reporting, told the readers of the 3000-L that he's pleased with the way the Stromasys product cut out HP's MPE/iX hardware. The words "run MPE forever" were part of his message.

We used HP's 3000 hardware for 30 years. We've been using the HPA3000 emulator in production since December 2013. Our users would have never known the difference if we had not told them.

We had a 969KS 100 and went to a 2-CPU A-Class on the emulator. Performance is essentially identical but all concerns about "ancient" hardware went away. (Our RAID array hard drives were older than our web developers). Charon is running on a 1U "off the shelf" Proliant server under the Red Hat Linux environment (if we didn't have a DLT8000 and a DDS tape drive attached to it, all that it would take up in the rack would be the 1U). We run our disaster recovery version of the emulator in another location under VMware on OmniCube hardware, although we have never used it for anything other than testing.

Forever"Based on our experiences we would recommend it to anybody," Elmer said. "You could run MPE forever with this setup and over time your performance would only improve as you put newer, faster hardware under it." Whoa, forever? It's the promise of virtualized servers that emulate antique hardware. But MPE/iX has that calendar problem that'll rear up at the end of 2027, right? Not so fast there, said one MPE expert.

When Denys Beauchemein said that forever really meant December 31, 2027, Robelle's Neil Armstrong begged to differ. "That doesn’t stop the system from running, and a lot of issues can be handled at the application level quite easily," he said.

There are people working on such things at the OS level. I’ve been reducing the dependency on CALENDAR in all our software as well. By reducing the number of calls to CALENDAR, this helps mitigate the impact, of course, and adding options to change the result of a call to CALENDAR directly after a call are being considered.

It is an interesting problem.

Beauchemein retorted with the viewpoint of the IT manager who needs to be away from MPE/iX, since it's old.

That is fantastic news. Now I need to find my abacus and see if I can get them to refurbish it along with my slide rules.

Has anyone here even booted a 3000 for December 31, 2027 and see what goes on at the virtual stroke of midnight? Unfortunately, I do not have one handy.

All that Armstrong could offer in reply about a Jan. 1, 2028 bootup was "Yes, it’s been done. Nothing catastrophic happens."

He is right, nothing catastrophic happens. But what does happen?

SETCLOCK allows a manager to revise such a future date and time, but only up to December 31, 2027. It won't accept a higher date; it reports "out of range" if you try. MPE/iX continues to run. After midnight SHOWTIME will give the wrong result, year 1900. But if your application doesn't care about a time stamp (which is unlikely in a business computer) this doesn't matter. SHOWTIME will show Jan. 1, 1900. If days of the week matter, by setting the system date to Y2K, the day of the week will align with the correct day for 2028.

One of the sharpest of the MPE minds, Vladimir Volokh -- who co-created MPEX -- has given us a deep dive on that set of CALENDAR problems. He reports he's done that 2027 boot 10 years ago. In our conversations, his opinion has been that someone in the community will find a way to reroute MPE/iX to a future in 2028 and beyond, relying on current dates.

Dates don't vex MPEX, Vladimir added when we talked about this a few years ago. MPEX can do operations with dates—because unlike COBOL, or even the first language of MPE, SPL, MPEX has a DATE datatype. "If you have MPEX," he said, and here we could hear a wink, "and who doesn’t—DATETOCALENDAR is a function in MPEX."

Last week's exchange on 3000-L shows there's already work underway on getting beyond 2028. The thing about an abacus is that it does still work. Ours hasn't needed to be refurbished since we bought it in 1989. Unlike an abacus, MPE/iX has a purpose for being an everyday tool when the software has close ties to specialized business logic. It has a better reason to keep working forever—however you define that timeframe.

08:08 PM in Homesteading, User Reports | Permalink

Bookmark and Share

Use our search engine to find 20 years
of HP 3000 news and articles



The comments to this entry are closed.