During a May of 33 years ago, the award-winning database at the 3000's heart got a hearty defense. HP had customers in 1985 who wanted relational indexes for their 3000 data — and a speedy Omnidex utility for IMAGE was not going to sell those customers. It didn't have the HP brand on it.
Those middle 1980s were days of debate about database structures. Adager's Alfredo Rego spoke at a 1985 Southern California Regional User Group conference about the advantages in performance that IMAGE enjoyed over SQL architectures. Rego took what were known as the Codd Rules (from computer scientist Ted Codd) and said that IMAGE could outwork them all. The SCRUG meetings were close to the apex of technical wisdom and debate for MPE in that era. The 3000 was still run by MPE V in that year, when the PA-RISC systems were still more than two years away.
In 1985, though, Oracle and its relational design was riding a wave of success in companies that had retooled from vendor-designed databases like IMAGE. At the time of the defense of IMAGE, the database was beginning to feel some age. The performance limits were more likely induced by the age of HP's CISC computer architecture. The Series 70 systems were still underpowered for large customers, the same companies who had become Oracle's relational database targets.
HP overhauled IMAGE enough to rename the product TurboIMAGE later in the year, a shift in design that put some utilities under the gun to use the full feature set of the database. Even into 1986, the debate continued over the merits of IMAGE versus relational databases as defined by Codd. "What are "relational databases" anyway?" asked VEsoft's Eugene Volokh. "Are they more powerful than IMAGE? Less powerful? Faster? Slower? Slogans abound, but facts are hard to come by."
What Rego promoted in the face of Oracle's 1985 claims remained true for many years to come. Relational databases had more advanced search programming possibilities. But nothing was beating IMAGE for transaction performance during that year. Years later at the History Museum, the message remained clear.
IMAGE has two types of tables -- datasets if you will. One is called a detail table and the other one is called a master table ... Basically you have two ways to access those tables. One is through a doubly linked list, using detail datasets; and one is through hashing, using master datasets. It’s basically value addressing. It calculates, hashes and it says what should be here in position number whatever. And it allows for synonym collisions and distributes them very nicely. That’s called the master dataset structure, and from that master you can link to a chain of detail entries that can be anywhere and can be accessed very quickly. So IMAGE is very, very good for transaction processing.
Burt Grad, who interviewed Rego, understood what an opportunity HP was missing with IMAGE for decades. "If someone had implemented IMAGE on other platforms," he said, "it could have been a competitive product in the computing world."
As it was, the database ruled the 3000 world and its advantages turned away all competitors. Oracle took years to be convinced an MPE port of its database had any prospects, given the dominance of IMAGE on the OS. Later HP took up the mantle of SQL, the language that flowed from the query abilities in relational databases.
HP released a relational database system of its own during the era, a product called Allbase/SQL. Within a few years HP turned IMAGE into IMAGE/SQL because they put an SQL shell in front of it. Allbase had no better luck than Oracle at catching on among MPE users.