Verunsichert fühlen sich viele Anwender durch die DBMS-Politik der IBM. Die Kernfrage für sie lautet: IMS oder DB2. Peter Ullrich* hat sich in Kundenkreisen umgehört und kommentiert die Produktstrategie des Marktführers. Ziel seines Beitrages ist es, einen Trend für die beiden Systeme abzuleiten.
Ganz so beunruhigt, wie es verschiedentlich zu hören ist, brauchen die Anwender von IBMs Datenbankmanagementsystem IMS eigentlich nicht zu sein - im Gegenteil: Sowohl mit Blick auf dieses DBMS-Produkt als auch für DB2-User besteht einigen Grund zur Gelassenheit.
Als eher vordergründiger Beleg für diese Aussage sei der Hinweis auf die offizielle IBM-Philosophie gestattet, wie sie im vergangenen Jahr öffentlich (sofern ein Symposium öffentlich ist) kundgetan wurde: Danach empfiehlt Big Blue für Hochleistungssysteme unverändert IMS mit "Fastpath". Wem das nicht realisierbar erscheint, soll sich dieser Strategie zufolge an DB2 halten; und wenn auch dieses System nicht zum Zuge kommen kann, wird der Anwender auf die herkömmliche Programmierung verwiesen.
Dieser Tatbestand macht bereits deutlich, daß die IBM weiterhin voll auf IMS setzt. Außerdem wird klar, daß IMS und DB2 nur unter einigen Vorbehalten miteinander vergleichbar sind. Doch bevor einige vergleichende Betrachtungen angestellt werden, sei zunächst kurz erläutert, wieso die Fastpath-Empfehlung nicht als Verlegenheitslösung einzustufen ist.
Pufferspeicher wird in das Extended-CSA verbannt
Ähnlich wie CICS geht Fastpath keine Queuing-Umwege, bevor die Nachrichten an ihr Ziel gelangen. Dadurch konnte viel Programmcode gespart und die Performance erhöht werden. Da jedoch keine Warteschlangen existieren, wurden in der "Common Systems Area" (CSA) viele "buffers" notwendig; und dies verbrauchte meist mehr CSA, als in normalen Installationen zur Verfügung stand.
So war es bis Ende 1986. Mit dem IMS-Release 2.1 aber wurden die Pufferspeicher in das Extended-CSA verbannt. Seitdem ist CSA kein Schwachpunkt mehr. Doch nun zur Hauptfrage: Wo und in welchem Maße übertrifft der Newcomer DB2 das altgediente IMS?
Es stellt sich die Frage, welches der Systeme die IBM wie lange zu unterstützen gedenkt. Gespräche mit gewöhnlich gut informierten Anwendern haben gezeigt, daß IBM mit hoher Wahrscheinlichkeit - fast mit Sicherheit - die Unterstützung von DL/1-Datenbanken auch zu Beginn des neuen Jahrtausends noch nicht eingestellt haben wird.
Bestätigt werden diese "Trendmeldungen" auch durch Insider-Informationen, nach denen die von der IBM auf IMS sowie auf DB2 angesetzten Entwicklungsteams in etwa dieselbe personelle Stärke haben. Dadurch darf es wiederum als mehr oder minder erwiesen gelten, daß, wenn die IBM eines fernen Tages wirklich eine Abkehr von IMS vollzieht, eine Bridge-Software verfügbar sein wird, die die IMS-Klientel ins relationale Datenbankland gelangen läßt.
Eine anders angelegte Produktstrategie der IBM wäre kaum plausibel. Denn auch ein so großer Hersteller wie Big Blue kommt nicht an der Tatsache vorbei, daß IMS mehrere tausend Kunden - zumeist die größten und wichtigsten - zu enormen Investitionen in Software veranlaßt hat und weiterhin veranlaßt. Allein diejenigen Großprojekte auf IMS-Basis, die soeben angelaufen sind beziehungsweise den "point of no return" hinter sich gebracht haben, erstrecken sich, wenn man den üblichen Software-Life-Cycle unterstellt, bis tief in die neunziger Jahre.
Darum: Jeder andere Denkansatz als der, daß IMS noch geraume Zeit erhalten bleiben wird, entbehrt der Realitätsnähe. Ist etwa dieser Aspekt der ausschlaggebende für die relative Zurückhaltung, mit der DB2 von den Anwendern aufgenommen wird? Eine kurze Ist-Analyse: In der Bundesrepublik liegt die Zahl der IMS-Anwender, die zugleich auch DB2-Anwender sind, nach Schätzungen von Marktkennern derzeit bei 100.
Ihr Zutrauen zu DB2 ist noch nicht so weit gediehen, daß sie im routinemäßigen Produktionsbetrieb Zugriffe mit IMS/DC auf DB unternehmen würden. Bisher hat noch keiner dieser User das Teststadium verlassen mögen.
Was schon viele DB2-Anwender geärgert hat, sie zum Intervenieren bei der IBM veranläßte und dort heftige Aktivitäten ausgelöst haben soll, ist zudem der schmerzhaft empfundene Mangel an Relationalität in DB2. Unlängst hat sogar der Ex-IBMer Edgar. F. Codd verlauten lassen, die von ihm aufgestellten Grundsätze der Relationalität würden von DB2 nicht erreicht. Hier soll, Codd ergänzend, ein ganz konkretes Beispiel angeführt werden: Existieren zwischen Daten in unterschiedlichen Tabellen logische Beziehungen, so gibt es derzeit keine Möglichkeit, dem DB2 eben dies mitzuteilen. Die Konsequenz: Man muß ein Programm schreiben, das diese logischen Beziehungen kennt; und wenn in der einen Tabelle eine Änderung eintritt, muß das Programm aufgrund der Programmlogik die andere Tabelle entsprechend pflegen. IMS-Anwendern dagegen stehen Definitionsmöglichkeiten über Indizes beziehungsweise Sekundärindizes, ja sogar über logische Verbindungen zur Verfügung; und die Pflege übernimmt das System.
Das ursprünglich als Endbenutzerwerkzeug angekündigte DB2 bietet über eine - extra zu bezahlende - Query-Management-Facility (QMF) dem Informationssuchenden zwei Möglichkeiten, seine Ad-hoc-Abfrage abzusetzen, nämlich im Klartext oder mit Query-by-example. Liegen die gewünschten Daten vor, so kann der Benutzer sie mit Hilfe eines speziellen Features leicht aufarbeiten (Absätze machen, Zwischensummen bilden).
Auch im IMS gibt es seit rund einem Jahr eine relationale Oberfläche. Query-DL/1 hat eine ähnliche Syntax wie QMF. Wenn der Benutzer von Query-DL/1 aus eine Abfrage startet, kann es ihm passieren, daß das System sequentiell die ganze IMS-DL/1-Datenbank durchgeht und er die erhoffte Antwort erst nach mehreren Stunden auf dem Bildschirm hat.
IMS ist darauf ausgelegt, daß der Benutzer sich mit einem Schlüssel an das System wendet und daraufhin entweder genau das Segment zurückerhält, das er haben will, oder die Antwort "Nicht vorhanden". So etwas funktioniert nur bei kleinen Datenmengen und ist nicht für sequentielle Zugriffe gedacht, wie QMF sie vornimmt.
Nun zum Systemhandling durch den DB-Spezialisten: Wenn der IMS-Anwender eine Datenbank reorganisiert, schickt er einen entsprechenden Batch-Job los, und damit steht diese Datenbank fürs erste nicht weiter zur Verfügung. In dem auf 24-Stunden-Betrieb ausgelegten DB2 dagegen lassen sich alle betreffenden Utilities im laufenden System ansprechen - man hat nicht einmal eine andere Wahl.
Auch der Änderungsaufwand sieht DB2 im Vorteil. Verlängert sich beispielsweise innerhalb der Datenbank ein Segment, so muß im MS die Datenbank zunächst entladen werden, dann erfolgt die neue Datenbankdefinition und danach das erneute Laden - all das im Batch und je nach Größe über viele Stunden hinweg. Im DB2 braucht der Benutzer lediglich eine neue Spalte an die Tabelle dynamisch "heranzudefinieren". In der Zwischenzeit steht diese Tabelle weiterhin zur Verfügung; und auch das Füllen der neuen Spalte mit Daten erfolgt im laufenden Betrieb.
Transaktionsprofil im IMS neu definiert
Ein weiteres Kernproblem der DBMS-Produkte ist die Performance. Aus Guide-Kreisen wird über einen Benchmark berichtet, bei dem in Zusammenarbeit mit der IBM im IMS ein Transaktionsprofil definiert wurde. Dieses zieht die IBM seither zu Performance-Messungen für jede neue Maschinengeneration und für jedes neue IMS-Release heran. Das Profil hat man 1 zu 1 in DB2-Abfragen umgesetzt und so einer DB2-Benchmark geschaffen, der die Grundlage von Laufzeitversuchen auf 3090-Modellen bildete. Ergebnis war, daß DB2 auf ganz ähnliche Transaktionen pro Zeiteinheit kommt wie IMS und zunündest in dieser Hinsicht nicht so schlecht ist, wie man es ihm gelegentlich nachsagt.
DB2 verbraucht viel Maschinenkapazität
Fairerweise muß darauf hingewiesen werden, daß DB2 sogar Transaktionsraten erreichen kann, die die von IMS signifikant übersteigen - so wurde es festgestellt in einem Industriebetrieb. Aber erstens sind die Daten- und Programmstrukturen in einem Industriebetrieb gemeinhin um einiges einfacher als etwa in einem Unternehmen der Kreditwirtschaft, und zweitens kommt DB2 nur dann auf solche Raten, wenn die Hardwareausstattung mit CPU und Cache-Speicher sehr üppig ausfällt.
Bekanntlich operiert der Systemspezialist mit DB2, indem er TSO nutzt. TSO stellt die Verbindung her, setzt die Kommandos ab und steuert die Utilities. Nun verbraucht TSO ebenso wie DB2 ziemlich viel Maschinenkapazität; und genau dies hat schon mehr als einen Anwender zu der grimmigen Feststellung veranläßt, hier habe die IBM eine geschickte Methode entwickelt, Hardware zu verkaufen. In der Tat gibt es in Deutschland eine stattliche Zahl von Anwendern, die sehr bald nach ihrem DB2-Erwerb von ihren 43XX-Systemen auf 30XX-Systeme umgestiegen sind.
*Peter Ullrich ist Leiter des Technischen Supports bei der Candle GmbH, München.