« Migrations Altered to Appear as Emulation | Main | Using a PURGEGROUP to clean volumes up »

February 07, 2018

Living with what's still working in MPE

Classic-carsSome functionality of MPE/iX will be outliving its accuracy. That's the situation with the CALENDAR intrinsic, which now has less than 10 years of correct capability remaining. Few 3000 support and development companies can reach inside MPE/iX source, and of those, nobody's going to fix the original intrinsic.

"There is no fix inside the CALENDAR routine," says Steve Cooper of Allegro. "There is no pivot point in the CALENDAR routine. It's returning a number from 0 to 127. It's up to the program to decide what to do with that. Or you live with it."

On the latest technical conference call, some companies with access to HP's MPE/iX source were on the line. "If you want to fix the banner when you log in, then you need the source code for MPE," said Doug Werth. "If you want to fix the program that's printing the wrong date on a report, then you need the source code to your program."

To be clear, even having MPE/iX source code won't give CALENDAR more years of accuracy. Werth said that fixing MPE/iX—something the source code companies like Pivital at least have enough license to attempt—isn't an open subject, either. "There's a lot in that HP licensing we're probably not allowed to talk about," he said, speaking of Beechglen.

Chevrolet ApacheLooking the other way and living with what's still working—that's genuinely possible for a 3000 that's not calculating time between transactions. "For this group of people," said CAMUS board member and 3000 manager Terry Simpkins, "if they're still using MANMAN transactionally, they're going to care. If you're in an archive mode where all you're doing is looking up things that happened in the past, not so much."

Many adjustments for declining functionality will come by revising application code. "You can intercept the call to CALENDAR, but the program will be expecting a 16-bit return value in the CALENDAR format," Cooper said. "There's nothing you can do with CALENDAR's value at that point."

The 3000 has been here before. The last time there was a lot of company, as 1999 turned into 2000 for computers from every vendor. CALENDAR won't kill MPE/iX—in that way, it's unlike what the community did for Y2K remediation. 

Allegro was one of the companies that gave 3000 managers date management tools to help get applications beyond Y2K. "I lost a lot of sleep between 1992 and January, 2000," he said. "I'm not losing sleep over this one."

"If you don't have source, and it bothers you, then there are solutions," he added. "The rest of it is cosmetic and you ought to be able to look past that. If you have your application source code, by all means it's simple."

Werth said, "I still have a customer with an application that is not even Y2K compliant. Every year they set their calendar back to the year where the day of the year lines up with the current day of the week. So Wednesday November 16 is still Wednesday, November 16. The year is just wrong."

"There may be some things you just have to live with. You run a report and it says it's 1909 instead of 2037. You live with that. Where it's critical, you figure out a fix for it. Where the applications are having problems, there's plenty of people who will be available to help fix it." 

08:12 PM in Homesteading | 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.