Athough database has been in the news in the IBM world in the past two or three weeks, all attention has been foc ussed on the Repository Manager, and the fact that IBM seems to have mobilised every small Computer-Aided Software Engineering tools developer to do the work it can’t or doesn’t want to do itself. But a new release of the strategic DB2, release 2.2, is about to hit the streets, and IBM doesn’t want the good things in it to pass unnoticed, so last week, it called the world together to spread the word and Peter White sat in.
Contrary to popular opinion, IBM does know something about relational databases despite losing the likes of Codd and Date, and more recently a number of senior staff at its Santa Theresa development centre. But even the new breed of database expert at IBM admits that the environment is so complicated that in some places IBM is catching up while in other areas it claims to lead.That’s about the most mature view of all the relational database vendors, and certainly the most realistic, and IBM was being very pragmatic at a briefing designed to ensure that the recent Repository Manager announcements didn’t completely overshadow the parallel improvements to DB2 and associated products that came out the same day. We’ve already pointed out that the recent version of the DXT data extract facility, (CI No 1,267) when teamed up with its VMS equivalent, can now extract data from pretty much any data management software running under VMS, including its native RMS, Record Management System, DEC’s own Rdb relational database manager and the two independents, Oracle and Ingres. The first thought that comes into any analyst’s head is that this will be followed by a queue of IBM salesmen, knocking on doors where DEC has a major piece of the database hardware business, saying, It’s OK, you made a mistake not going with DB2 from the start, but it’s not too late to hop aboard, we’ll even help you convert your data.
Modest
Well, IBM salesmen may well say that, but the IBM that was presenting the product was showing a more modest side. Derek Starkey, DB2 UK technical Support said: DXT will support frequent refreshes from a live VMS database, and it takes a lot of time and expense to set up. You wouldn’t go to that much effort just to convert an application across to an IBM environment. No, you want this program to enable you to get the best of both worlds. It might conceivably be used where you were planning to run the data over two environments in parallel over a prolonged migration, but it really isn’t what it’s designed for.So IBM sales people take note.However if any of us were cast in that unfortunate role of IBM salesman, it would be more than a little tempting to remind a customer that his application, complete with live data, could be running on a 3090; 4381 or better still, a large AS/400, in no time at all. Or why not freeze development on the DEC machine, and we use the same data for your new suite of applications that you build on the IBM machine of your choice.
It wasn’t clear from the announcement, but that machine could certainly be an AS/400 or even an OS/2 machine, running Extended Edition complete with its own relational SQL engine, and ideal for rogue users that are fed up with their data processing departments’ DEC environment and want an 80386 or 80486 go-it-alone option.An interesting note raised by one observer was whether or not DEC could change the microcode in its machines to make the DXT product under VMS, DXT/D1, unable to operate, and have IBM constantly re-writing its interface, a tactic that observers once used to attribute solely to IBM. It was a note that fell on deaf ears.Apart from the new targets and hosts for data extraction, IBM was also touting October delivery for DB2 Version 2 release 2, slightly early and delivering up to a maximum of 11% more throughput in the transaction processing stakes than the previous release, taking it perilously close to the 300 transactions a second mark, for simple transactions when running on a 3090-600S under MVS/ESA. This still doe
sn’t take it up anywhere near the Teradata DBC1012 database, nor does it leapfrog Tandem, but most of this performance improvement comes not from deliberately tuning DB2 for transactions, but as a byproduct of re-writing to tune it for improved query speed. IBM seems happy that DB2 performs about 10% slower than a conventional IMS database, and that its transaction rates have grown vastly from the old unusable, Version 1, up to 123 tps on V1.3; 176 on V2.1 under MVS/XA; 186 using V2.1 under MVS/ESA, to its previous maximum of 270 running V2.1 under ESA running on a 3090S as opposed to an E.
Parallelism
This time around though IBM has begun to explore parallelism among its CPUs, moving some jobs out to separate processors, although the bulk of any single DB2 enquiry or transaction is still carried out on a single CPU. The user organisations Guide and Share have been pushing IBM to explore this territory for some time, and it is easy to get the impression that IBM is being as conservative with its introduction of parellelism in DB2 as it is with some of its VLSI components. In other words there is a lot more to come, although IBM only admits to it being a stated Direction.IBM hasn’t even re-written DB2 to take into account the Hyperspace concept of ESA. I don’t know of any customers that could use up a 2 Gigabyte buffer, was one reaction, although customers might find a way to use it if it was there.Yes, said Starkey, you could speed it up once customers had started to become constrained by the 2 Gigabyte limit, and you could certainly take a long hard look at the differences between ESA and XA and their respective microcode assists and spend a lot of tidying time making DB2 more of an ESA product than an XA one. This would speed it up for transactions, and IBM will do it in time. So if this release isn’t about transaction throughput, what is it about? We’ll look at that next time.
