How to Make a 3000 Act Like It Uses DNS
How to Keep Watch on Backup Completions

Emulating the 3000's Strong Heartbeat

A full hardware emulation makes the Charon HPA virtualization package a viable choice for keeping MPE applications alive. But what about emulating the essential parts of the 3000's software stack elsewhere? The goal of getting MPE and its riches to operate inside another environment has been enticing, and sometimes elusive. The heart of the system lies in IMAGE, wired thoroughly into the 3000's file system.

Hp3000tattoHP wanted to be in this business itself, a few decades ago. Allbase was one of two attempts at doing a relational database on MPE. HP Image was the other. Allbase could not get traction in the 3000 base, and HP Image struggled to get out of HP's labs, although both of these products were compatible with the HP-UX environment. They were not faithful enough to the IMAGE structure and design — that 98 percent compatible curse vexed HP Image in particular.

Coming close to emulation's database potential -- where a relational database can behave like IMAGE -- is also in a couple of spots in the 3000's story. "It's fairly easy to use an RDBMS to emulate most of IMAGE," said Allegro's Stan Sieler, who created advances such as b-tree support inside IMAGE. "It's the last few percent of emulation that gets hard to do efficiently." The efficiency factor is what drove down the hopes of HP Image.

One of the few companies to make a good business out of IMAGE emulation is Marxmeier Software AG, which still sells its Eloquence database in HP-UX, Windows and Linux markets. The product has a TurboIMAGE Compatibility extension to accommodate applications that have been migrated from the 3000 to those commodity platforms. It's still the best database choice for any system that needs to move unaltered from MPE to an environment supported by many hardware vendors.

Long ago, Robelle summed up the compatibility — one way of looking at emulation — between Eloquence and IMAGE. "Eloquence supports the same data types as TurboIMAGE, the same record layouts, and the same indexing (plus new options). The transformation needed to convert IMAGE databases to Eloquence is simple and automatic. Either use Suprtool to copy the data, or use Eloquence's DBExport and DBImport utilities. However, the file formats and internal structures of Eloquence are dramatically different from IMAGE. Only the programming interface is the same."

Unlike the Eloquence offering, pitched to a distinct customer base but with benefits to 3000 migrators, HP had to stop thinking about attracting SQL-hungry customers from other platforms with its Allbase and HP Image designs. As it turns out, satisfying the needs of the IMAGE-using ISVs and users was more important. This might appear to be another case of backward compatibility, and investment protection, holding back the broader reach of the HP 3000. Sieler says the compatibility doesn't hold things back, though.

"I’d argue that “backward compatibility” doesn’t hold back growth," he said. "It enables growth by having a larger pool of software ready to run on your newer models! Remember, the HP 3000 had it easy. The hardware was developed by another HP group, so the hardware development cost was nearly zero.  Few other operating systems, outside of Linux, have that kind of advantage!"

For the most part, the PA-RISC based 3000 hardware was developed by the 9000 people. Indeed, it’s 100 percent the same — except for some models where they decided to not deploy MPE. In some cases that was because a slightly different IO driver set might be needed.

In the 935 era, the only difference (other than the name plate and the price being higher for the 3000) was a single EPROM on a disk controller, with essentially one bit different, so MPE could refuse to boot on a 9000. That bit was eventually moved to Stable Storage, so the hardware was then identical other than the nameplate and model number plate.