Last week, IBM Corp took a party of UK journalists to Dallas and Austin in an effort to get across the message that the company really does believe in open systems and to demonstrate what it is doing to back up its proclaimed aim to propel the RS/6000 and the company into the number one or number two spot in the Unix market within the next two or three years. On these occasions, there always seems to be a dog that doesn’t bark, a dog indeed whose silence is so manifest that it doesn’t take a Sherlock Holmes to spot that there is something afoot, Watson. As we hinted in CI No 1,810, on this occasion the mute mutt was the one that should occupy the kennel labelled database.
Reinvent the wheel
Whatever the speaker and whatever the ostensible topic, the question of what database was to be used cried out for an answer, but each time it was raised, it was met with dissembling and disclaiming of responsibility. The answer for the present is simple enough – if you want a relational database, be it on the mainframe or the workstation, the recommendation is that you take your pick from Oracle, Ingres, Sybase or Informix. Which is fair enough: all are solid, heavily tested products, each has its attractions for different applications and it makes absolutely no sense to reinvent the wheel, especially at the dawn of the object-oriented programming age where it is certain that all the rules the computer industry has learned to live by will be overturned. Because reinventing the wheel is what the industry has assiduously been doing for the past 30 years: the prospect held out by object oriented programming is that whatever routine your application requires, you will be able to go out and buy it off the shelf as a fully-tested, ready to go object which, if it is written to the standards that the Object Management Group intends to lay down, will mesh seamlessly with all the other objects that you buy from sundry other sources, so that the process of programming will be reduced largely to linking objects – and the biggest software fortunes will accrue to the companies that succeed in developing the most widely-used objects. At the dawn of the object age, it seems highly likely that IBM’s own AD/Cycle applications development schema and tools will scarcely be in place and solid before they become obsolete. It is noteworthy that when a question about AD/Cycle followed immediately upon a discussion of the impact of object-oriented programming on software, the IBMer conducting the session, who clearly has his own ideas about where the industry has to go, joined in the laughter that greeted mention of AD/Cycle. If software engineering remains a major activity at the user site, the object revolution will have failed, and all the benefits that it promises will be lost.
Visionaries
The caveat has to be entered that object-oriented programming doesn’t come free: there is an overhead, significant or substantial according to your point of view, but the potential benefits are so great and the cost of hardware is falling so fast that it is hard to imagine that it will prove an in superable obstacle… and there’s another dog that has not barked in a very long time. A decade ago, talk among the visionaries was all about object-oriented hardware architectures, with the failed Intel Corp iAPX-432 chip set held up as the paradigm, a role that would have been held by IBM’s own System/38 had the company not steadfastly refused to discuss the 38 in the context of object orientation. In the context of the developments outlined above, it is hard not to come to the conclusion that the world needs another undifferentiated relational database management system like a fish needs AD/Cycle. IBM has made it clear that database is so important that it needs to have its own database for Unix. It was made clear that there will be a single IBM database for all IBM’s Unix offerings – AIX/ESA on the mainframe, AIX 3 on the RS/6000, AIX PS/2. So what is it doing? The answer is that it appears to be deriving a Unix relational database from the Database Manager from OS/
2. One speaker hedged on that by saying that it had been one of the options considered, another said categorically that the OS/2 database would run under AIX – and would be offered as a product to run on alien machines as well. But he said that it would not run under AIX/ESA. The IBM database for Unix would conform to ANSI SQL and Federal Information Processing Standards. As to putting a date on it, well it won’t appear next year. All of which makes it sound like a leftover from the old IBM: by the time it arrives, if IBM has been at all successful with the RS/6000, there will be so much investment tied up in existing relational database management systems that the company will have a very hard time getting a new one accepted, even if it does bundle it with the operating system. And if it is greeted with a yawn by the market, the investment won’t be forthcoming to keep it up to speed. The OS/2 Database Manager already looks like a product that few users really need, making it an extremely inauspicious jumping-off point for a Unix database. But in that case, what is IBM to do? Well it seems that it would hate to be reminded of the fact, but it does already have an object-oriented database management system, one that has been tried and tested over 10 years now: it’s the nameless one that comes bundled with the AS/400.
Lip service
Content from our partners
And given all IBM’s lip service to hooks, links and commonality between its proprietary and its open systems, it would seem that the AS/400 database would be the ideal starting point for development of a database for AIX. Those IBMers that dislike the IBM world being polluted by open systems will raise the problem of ASCII and EBCDIC – cited as a reason why IBM would go to third parties for an office system for Unix rather than extend its own OfficeVision into the Unix world (other IBMers say OfficeVision for AIX is, notwithstanding, highly likely). IBM mainframes and AS/400s use the Extended Binary Coded Decimal Interchange Code where almost the entire rest of the world including the Unix fraternity – uses the American Standard Code for Information Interchange. It is pretty clear that one of the first objects all applications in the IBM world are going to need to call is the ASCII-to-EBCDIC converter, which clearly should be a chip installed in every IBM proprietary machine and it is equally clear that IBM needs to conduct a fundamental rethink of its AIX database plans and take another close look at the database in the AS/400.
