Dennis Stefan ist freier DV-Fachjournalist in München.
Die Portierung von Mainframe-Anwendungssoftware auf Unix-Anlagen scheint modern, und der Ruf nach "durchgängiger Verfügbarkeit auf mehreren Ebenen" geistert allerorten durch die Branche. Gespenstisch sind denn auch die Erwartungen, die in den Nutzen aus der Anpassung der Applikationen gesetzt werden.
Portierungen haben sich zu einem beträchtlichen Teil der täglichen Arbeit im DV-Bereich entwickelt - mit doppeltem Boden, möchte man meinen. Von reinsten Gruselgeschichten zu erzählen wissen nämlich die "guten Geister", sprich: Softwarespezialisten, über die zu überwindenden Hindernisse, wenn die Applikation nach der Anpassung dann auch wieder wie gewohnt funktionieren soll.
Grundsätzlich könne man bei der Anpassung verschiedener Mainframe-Applikationen von vier verschiedenen Problemstellungen ausgehen, erläutert Helmut Meyer, Geschäftsführer der SIM-Basis Software GmbH in Frankfurt. Sie stellen sich je nach Mainframe, Software und Unix-Anlage als unterschiedlich schwer lösbar dar.
Zuerst muß die anzupassende Anwendung in einer übertragbaren, also portablen, Programmiersprache Beschrieben sein. Bei den sehr spezifischen Assembler-Dialekten der jeweiligen Mainframe-Anlagen sind immer Unterschiede zu finden, die natürlich in den Compilern fortgeführt werden. Diese summieren sich in Anwendungen oft zu einer unüberwindlichen Hürde von Anpassungsproblemen, da der Portierungsaufwand bei eigentlich marginalen Dialekt-Differenzen gerade bei komplexen Programmen exponentiell ansteigt.
Assembler ist also demnach out, weil, so Meyer, "ein in Assembler auf dem Mainframe geschriebenes Anwendungssystem für den Einsatz auf Unix-Rechnern (aus Kosten-Nutzen-Erwägungen heraus; Anm. d.A.) eigentlich nur nochmals neu entwickelt werden kann."
Das hochgelobte, da laut Hersteller-Aussagen leicht portable "C" gibt es kaum auf Mainframes - zumindest damit sind noch keine wirklich großen Applikationspakete entstanden.
So bleiben - wieder einmal - die bestehenden Cobol-Programme als zur Portierung allein geeignet und nutzbringend übrig. Im Hinblick auf die Tatsache, daß mehr als 85 Prozent aller kommerziellen Anwendungen auf Großrechnern ohnehin in Cobol codiert sind, läßt dies den Aufwand der Anpassung durchaus sinnvoll erscheinen. Doch auch hier bleibt die Grundproblematik bestehen.
Voraussetzung ist generell eine saubere Codierung. Bei den früheren Cobol-Standards war es jedoch möglich, mit den berühmt-berüchtigten "GO-TO"-Anweisungen jeden Ansatz zur strukturierten - und damit übersichtlichen - Programmierung zu umgehen.
In den ANSI-Standardregeln ist diese GO-TO-Anweisung nicht mehr erlaubt, Cobol-Compiler unter BS2000 beispielsweise lassen dies jedoch noch immer zu. Dies hat bei einer Portierung auf den Unix-Rechner notwendige Logik-Änderungen im Programm zur Folge, was den Aufwand der Anpassung erheblich erhöht.
Auch die Umgebung, sowohl von der Mainframe- als auch von der Unix-Seite her, schafft weitere Probleme. Kommerzielle Anwendungen auf Großrechnern wurden über sogenannte Transaktion-Processing-Monitore direkt aus dem Dialog heraus programmiert. Unter Unix sind solche TP-Monitore wie etwa CICS jedoch nicht verfügbar; Ansätze zur Emulation sind meist wenig zufriedenstellend in Hinsicht auf deren Vollständigkeit.
Um diese Problematik zu umgehen, gibt es die Möglichkeit, eine anwenderspezifische Schnittstelle zu definieren und aus dieser heraus den TP-Monitor aufzurufen. Die Schnittstelle selbst benötigt einen wesentlich geringeren Funktionsumfang und läßt sich daher auch leichter auf ein Unix-System übertragen.
Entsprechende teilweise bereits vorhandene Normen wie etwa die KDCS (kompatible Daten-Kommunikations-Schnittstelle) vom Deutschen Institut für Normung (DIN) und die Einhaltung dieser Normen von seiten der Hersteller sollen in Zukunft für Erleichterung dieser systemspezifischen Problemstellungen sorgen.
Bereits vorhandene Standards jedoch müssen nicht immer ein Freibrief für Portierungserleichterung sein: So etwa gibt es unterschiedliche Standards für die Datenhaltung auf Mainframes Lind auf Unix. Anlagen.
Beim Einsatz auf den Großrechnern finden sich Datenhaltungssysteme wie etwa DB2, Adabas oder Leasy. Für die Index-sequentielle Datenhaltung gilt V-SAM als anerkannter Standard; das Standardisierungsgremium Codasyl legt weitere Möglichkeiten der Datenhaltung fest.
Andere Computer - andere Sitten: Unter Unix werden im Normalfall relationale Datenbanksysteme verwendet, wobei meist der Standard C-ISAM zugrundeliegt. Die Datenstruktur auf den Datenbanksystemen der Mainframe-Rechner ist komplex
vernetzt. Eine Übernahme solch komplexen Strukturen zu relationalen Datenbanksystemen
oder ISAM-Dateien unter Unix sei rein technisch nicht machbar, behauptet Migrationsspezialist Helmut Meyer.
Zur effizientesten Übertragung müßten die auf Mainframes vorhandenen Codasyl-Datenbanken unter Unix vorhanden sein, da beide Datenhaltungsmethoden derart unterschiedlich sind, daß eine erforderliche Entkoppelung der gesamten zu übertragenden Datenhaltungssysteme in keinem sinnvollen Kosten-Nutzen-Verhältnis stünde.
Implementation dauert einen Monat
Laut Meyer beträgt die Zeit der lmplementation der Mainframe-Anwendungen sowie des entsprechenden Systems inklusive einer dem Codasyl-Standard entsprechenden Datenbank auf einen bestimmten Unix-Rechner - mit den entsprechenden technischen Voraussetzungen - etwa einen Monat.
Doch damit nicht genug neben unterschiedlichen Programmiersprachen und -dialekten, Datenhaltungssystemen sowie TP-Monitoren treten auch die Eigenheiten der Betriebssysteme selbst in unangenehme Erscheinung: das unterschiedliche Handling des Job-Control.
MVS, VSE, BS2000. .. alle haben sie Verschiedene sogenannte Job-Control-Languages, die von einer Anwendung aus angesprochen werden, beispielsweise für Druckausgaben. Jedes einzelne Sprachelement dieser Sprachen erfordert bei der Übertragung auf Unix entsprechende nachbildende Shell-Scripts.
Der Anwender hat die Qual der Wahl
Viel Aufwand einsparen könne man bereits bei der Entstehung einer Anwendung durch Beachtung dieser Schwierigkeiten und entsprechender Codierung. Doch welcher Mainframe-Programmierer hat vor zehn Jahren schon an Unix und dessen jetzt sichtbaren Siegeszug gedacht?
Um so mehr scheint es notwendig, neue Entwicklungen respektive bereits vorhandene Technologien in die Programmierplanung für morgen einzubeziehen, denn der Portabilitätsgrad speziell von Mainframe-Software auf Unix-Rechner ist stark davon abhängig, inwieweit bereits auf dem Großrechner-System unter Portabilitäts-Gesichtspunkten entwickelt wurde (Siehe auch CW Nr.41 vom 12. Oktober 1990, Seite 71).
Kam eine portable Wirtschaftssprache zum Einsatz, die die Software von umgebungsspezifischen Bereichen entkoppelte, dann beträgt laut Meyer der Unix-Implementationsaufwand dieses auf dem Mainframe geschriebenen Anwendungssystems deutlich weniger als zehn Prozent vom ursprünglichen Entwicklungsaufwand. Hier wird eine exakte Planung und ordentliche Programmierung belohnt - Schludern allerdings streng bestraft.
Der gesamte Aufwand zur Erstellung von Lösungen wie Codasyl-Datenbank, TP-Monitor-Anpassung und Job-Control-Nachbildung darf jedoch nicht unterschätzt werden. Bei einem System des Hauses SIM-Basis betrug er zusammengerechnet etwa 20 Mannjahre.
Zum Einsatz kommen sollte ein solches System aber nicht nur bei der Umstellung bereits vorhandener Anwendungspakete, sondern auch als Basis bei der Entwicklung neuer Applikationen zum späteren Einsatz auf mehreren Ebenen. Beachtet werden sollte dabei, daß es unwirtschaftlich ist, umfassende kommerzielle Anwendungssoftware in verschiedenen parallelen Source-Entwicklungslinien für Mainframe- und Unix-Systeme zu erstellen.
Die derzeitige Situation stellt sich folgendermaßen dar, daß die Alternativen bei Methoden- und Produktauswahl in den Kombinationsmöglichkeiten insgesamt nahezu unendlich zahlreich sind, sie sich bei Einbeziehung der Forderung nach Portabilität und Kompatibilität zwischen Unix-Anlagen und herstellerspezifischen Betriebssystemen allerdings erheblich reduzieren.
Die Qual der Wahl hat also wieder einmal - der Anwender. Dadurch bietet sich ihm aber auch die Möglichkeit, die besseren - in diesem Fall wohl nicht proprietären, sondern offenen - Systeme zu erwerben und so den Markt zu steuern. *