"Herstellerunabhängigkeit" ist ein Ausdruck, der Freiheit signalisiert. Gibt es diese Freiheit? Und wie sieht es mit dieser Freiheit aus, wenn Datenbank- und Online-Systeme (sogenannte DB/DC-Systeme) vorhanden sind?
Bei der Betrachtung von reinen Stapelanwendungen mit konventionellen Dateien zeigt sich bereits, daß sich ein Anwender nur noch schwer von einem Hersteller trennen kann. Zwar wurde mit der Einführung höherer Programmiersprachen ein hohes Maß an Portabilität der Programme erzielt, aber ein Herstellerwechsel kostet trotzdem Geld. Bei kleineren Anwendungen bewegt sich das in noch vertretbaren Grenzen, wie einige Anwender mit Umstellungen auf Univac, 90/30 bewiesen haben. Von vielen Herstellern wird die Konvertierung von Programmen und Dateien mit Hilfsprogrammen unterstützt.
Aber bei Installationen mit mehreren hundert oder über tausend Programmen summieren sich selbst bei einer weitgehend automatisierten Umstellung die Beträge zu Millionen. Das haben große Siemens-Anwender ausgerechnet, als ihnen empfohlen wurde, von dem Betriebssystem BS 1000 auf das zukünftig einzige Siemens-Betriebssystem BS 2000 umzusteigen.
Diese Kosten entstehen nicht nur durch die Konvertierung von Programmen und Dateien, sondern auch durch Umschulung, Erstellung neuer Steueranweisungen und Prozeduren, Umstellung selbstentwickelter Systemprogramme (Accounting, Magnetbandarchiv, Jobsteuerungsprogrammen, Spoolroutinen, Bibliotheksprogrammen etc.) und den notwendigen Parallelbetrieb. Nicht berechenbar sind die Kosten des Entwicklungsstopps durch die Umstellung.
Wenn ein Betriebssystem- oder Herstellerwechsel mit Batch-Anwendungen bereits einen Kraftakt darstellt, wie sieht es dann mit Datenbank -und Online-Anwendungen aus? Eins läßt sich klar sagen: Wenn DB- und DC-Programme nicht ähnlich portabel sind wie beispielsweise normale Cobol-Programme, ist eine Umstellung nicht mehr vertretbar. Die Kosten und der Zeitverzug um mehrere hundert Programme umzuschreiben oder gar neu zu entwickeln sind höher als die möglichen Einsparungen an der Hardware.
Es gibt drei mögliche Formen des Wechsels:
1. Wechsel des Betriebssystems (beim gleichen Hersteller)
2. Wechsel des Herstellers
3. Wechsel des DBMS oder des TP-Monitors.
Der Grad der Unabhängigkeit schwankt, ob es sich um Datenbank- oder Online-Anwendungen handelt.
Betrachten wir zuerst die Datenbanken. Ein Betriebssystemwechsel ist in den meisten Fällen problemlos möglich. Die Portabilität der Programme wird durch ein DBMS sogar erhöht. Der Wechsel zu einem anderen Hersteller ist nur noch bei einigen DBMS - und dann nur zwischen einigen Herstellern - möglich. So gibt es etwa für Adabas, IDMS und Total Versionen für unterschiedliche Hardware.
Für einen Anwender mit DL/1- beziehungsweise IMS
Datenbanken dagegen würde ein Herstellerwechsel gleichzusetzen sein mit der Umstellung auf ein anderes DBMS.
Der Wechsel zu einem anderen DBMS ist ein hoher Aufwand: Neuentwicklung der Datenbankstruktur, Umstellen oder gar Neuschreiben der Programme, Konvertieren der Daten und neue Organisation des Ablaufes und der Dienstprogramme. Der Aufwand steigt mit den Unterschieden zwischen den Datenbankmodellen und der Ausnutzung spezifischer Möglichkeiten.
Lediglich bei Codasyl-DBMS besteht eine Verträglichkeit der DB-Strukturen und Programme. So ist beispielsweise eine Aufwärtskompatibilität von IDMS zu UDS gegeben. Da aber im Normalfall nicht mehrere Codasyl-Systeme für einen Hersteller angeboten werden, ist ein reiner Softwareaustausch nicht möglich.
Anders sieht es bei TP-Monitoren aus. Da nicht jeder TP-Monitor für alle Betriebssysteme eines Herstellers verfügbar ist, scheiden sich bereits hier die Geister: betriebssystemabhängige TP-Monitore wie Westi, Betacomm und IMS erfordern eine Umstellung. TP-Monitore mit mehreren Versionen (CICS, Shadow II, Task/Master etc.) erleichtern dagegen einen Wechsel.
Der Wechsel eines TP-Monitors kann sehr sinnvoll sein, weil es erhebliche Unterschiede in der Performance und im Hardware-Bedarf gibt. Für IBM-Anwender gibt es zwar eine Vielzahl von Produkten, doch sie sind untereinander überhaupt nicht kompatibel. Das bedeutet: Programme müssen umgestellt oder neu geschrieben werden.
Alles in allem gesehen wird ein Anwender um so stärker an seinen Hersteller und Software-Lieferanten gebunden, je mehr er DB- und DC-Anwendungen entwickelt und je intensiver er die spezifischen Möglichkeiten der Software nutzt. Wer sich dem nicht gänzlich ausliefern will, kann aber einige Vorkehrungen treffen, deren Erläuterung hier zu weit führen würde. In diese Zielrichtung laufen auch die Bemühungen der deutschen Behörden, die dafür kompatible Schnittstellen für Datenbanken (KDBS) und Online-Systeme (KDCS) entwickeln.