Nur zu gerne würde die IBM ihre Anwender aus der technologisch veralteten Midrange-Welt in die geschlossene AS/400-Umgebung umbetten. Mit den /38-Kunden scheint dies Big Blue auch gelungen zu sein. Demgegenüber wehren sich /36-User recht heftig gegen den nicht als Lösung empfundenen Migrationsweg hin zur Application-System-Datenbankmaschine. Der folgende Beitrag zeigt, daß Anwender statt dessen mit Erfolg auf Big Blues RS/6000-Systeme unter AIX wechseln können. Eine Option übrigens, die es in offiziellen IBM-Verlautbarungen erst seit kürzerem gibt. Erster Schritt war ein Sichten und darauffolgendes Aussortieren von Programmen. Dies beinhaltete die Zusammenfassung ähnlicher Programme und das Auslagern nicht mehr verwendeter Programme (nach vorheriger Umfrage bei den Benutzern). Insgesamt führte dies zu einer Reduzierung auf zirka 220 zu portierende Sourcen.
In einem nächsten Schritt erfolgten Tests der Einzelkomponenten, die bei der Portierung zum Einsatz kommen sollten, also insbesondere des Cobol/85-Compilers auf Verträglichkeit mit den existierenden Quellen und Tests des Gfuscgen-Maskengenerators. Weiterhin wurde unter AIX die Struktur der Entwicklungsumgebungen festgelegt; hier waren Entscheidungen zu SCCS- und Filearea-Strukturen nötig. Natürlich sollte konsequent das von AIX zur Verfügung gestellte Sourcecode-Control-System verwendet werden, das eine sehr leichte Verwaltung der verschiedenen Revisionsstände der zu portierenden Quellen und Hilfsprogramme erlaubt.
Um dem Anwender die gleiche Funktionalität wie bisher anbieten zu können, mußten folgende bei der IBM /36 standardmäßig vorhandene Tools beziehungsweise Funktionen unter AIX zur Verfügung gestellt werden:
- Menüsteuerung
Benötigt wurde ein Tool, mit dem Menüs möglichst einfach zu erstellen sind und das die Eingabe sowohl von Menüpositionen als auch sonstigen Befehlen zuläßt. Die Konfigurierbarkeit von hierarchischen Strukturen ist in diesem Zusammenhang eine grundlegende Voraussetzung. Dies wurde mit einem Cobol-Programm realisiert, das den Maskentext und die entsprechenden Funktionen aus einer variablen Menüdatei mit verschiedenen Satzarten einliest (Kopftext, Menütext und Befehle). Der Aufbau von hierarchischen Strukturen wird dabei durch die Verschachtelung von Scripts erreicht.
- Parameterübergabe
Die IBM/36 stellt die Möglichkeit der Datenübergabe zwischen Programm und Script über einen sogenannten Datenstations-Arbeitsbereich (256 Zeichen) bereit. Eine vergleich-
bare Funktion gibt es unter Unix/RM-Cobol nicht. Daher wurde eine Übergabedatei (sequentielle Datei) eingeführt, die eine "Zwischenpufferung" der zu übergebenden Daten erlaubt.
- Auswahlmasken
Die Auswahlmasken werden mit Hilfe eines Cobol-Programmes, das Auswahldaten über Masken einliest, gegebenenfalls prüft und in eine Übergabedatei ausgibt, überarbeitet.
- Ersatz für #GSORT
Eine ähnlich komfortable Möglichkeit der Datenauswahl (aufgrund der in der oben genannten Auswahlmaske eingetragenen Informationen) wie der auf der /36 angebotene Befehl #GSORT bietet das Unix Werkzeug Awk: mit dem Awk-Befehl SUBSTR ist zum Beispiel spaltenorientiertes Abfragen und Mischen von Daten möglich.
Erste Portierungen zeigten, daß vergleichbare Scripts unter AIX wesentlich kürzer und auch lesbarer werden als auf der IBM /36.
- Meldungen
Auf der IBM /36 ist die Ausgabe variabler Meldungen in Bildschirmmasken oder Prozeduren eine Funktion, die systemseitig angeboten wird. Es wird hierbei pro Programm oder Modul eine "zuständige" Meldungsdatei benannt, in der Meldungen mit einer Nummer hinterlegt sind; Meldungsaufrufe erfolgen nur noch über diese Nummer.
Die Umsetzung erfolgt durch ein Unterprogramm, das aus einer indizierten Datei mittels Meldungsnummer den zugehörigen Meldungstext zurückreicht. Die Meldung läßt sich dann in der Maske ausgeben.
- Hardcopy vom Bildschirm
Hardcopies vom Bildschirm werden bei der IBM /36 durch Drücken einer speziellen Funktionstaste erzeugt, unabhängig von der aktuell laufenden Anwendung, dies ist auf der RS/6000 nicht vorgesehen.
Eine Hardcopy-Möglichkeit bietet sich aber im Rahmen der Gfuscreengen-Maskenbearbeitung an, da der aktuelle Bildschirm immer auf einem bestimmten Datenfeld zur Verfügung steht.
Für alle Änderungen, die routinemäßig durchzuführen sind, wurde eine Checkliste zusammengestellt.
Im wesentlichen sah die Portierung wie folgt aus:
1. Programme ohne Bildschirmmasken
Bei Programmen, die keine Bildschirmmasken verwenden, mußten lediglich einige syntaktische Änderungen vorgenommen werden (SELECT-Anweisung, SPECIAL-NAMES-Paragraph, eventuell Dateinamen bei COPY-Anweisungen, Parameterübergabe mit PROCEDURE DIVISION USING etc.). Die Programmlogik kann in der Regel bestehen bleiben, das heißt, die Portierung solcher Cobol-Sourcen ist mit nur geringem Aufwand verbunden.
Mehr Aufwand entsteht bei der Umsetzung der IBM /36-Prozeduren (OCL-Anweisungen und # GSORT-Aufrufe) in vergleichbare Scripts, insbesondere dann, wenn es um komplexere Auswahl- und Sortiermöglichkeiten geht. Es gab Prozeduren mit bis zu 700 Zeilen, die meisten umfassen jedoch zwischen 50 und 200 Zeilen.
Die Scripts wurden zum Teil neu entwickelt, zum Teil kamen bereits vorhandene Scripts als Grundlage zum Einsatz.
2. Programme mit Bildschirmmasken
Hier sind neben den oben genannten syntaktischen Änderungen weitergehende Programmänderungen notwendig:
- Löschen der vorhandenen SELECT- und FD-Anweisungen bezüglich Bildschirmbearbei-tung, Datenstrukturen der Ein- und Ausgabebildschirme der SDA-Masken,
- Einfügen der von Gfuscgen generierten COPY-Dateien und anderer festgelegter Standarddateien für die Maskenbearbeitung.
- Änderung der gesamten Masken-E/A-Routinen bezüglich Cfuscgen-Subroutine-Calls, der Standardaufbau des Maskenaufrufes wurde festgelegt,
- Überarbeitung aller Routinen, in denen mit Bildschirmfeldern hantiert wird: In der Regel können die üblichen MOVES der Daten von Eingabeauf Ausgabebildschirm entfallen, da es bei Gfuscgen eine solche Trennung nicht gibt. Bei anderen Routinen kann es eventuell wegen unterschiedlicher Datenformate zu Problemen kommen.
Mit geringem Aufwand wurden die hierfür erforderlichen Scripts erstellt.
Ein wesentlicher Teil der Portierung ist inzwischen geschehen. Zusammenfassend kann gesagt werden, daß die Portierung selbst wesentlich weniger Probleme bereitete, als ursprünglich angenommen. Betrachtet man den aufzubringenden Einsatz (und damit natürlich die entstehenden Kosten) unter dem Blickwinkel der erreichten Loslösung aus proprietären Architekturen, kann dies als zukunftsträchtige Investition für den Fachbereich Produktionsautomatisierung angesehen werden.
Bei weitergehenden, zukünftigen Entwicklungen ist es notwendig, daß die bereits erzielte Integrationsfähigkeit des Systems in die vorhandenen und neuen DV-Strukturen (verteilte Systeme) erhalten bleibt. Durch die weite Verbreitung von OSF/ Motif bei technischen Anwendungen bietet es sich an, diese Oberfläche auch in der kommerziellen Datenverarbeitung als allgemeine Benutzeroberfläche für offene Systeme einzuführen. Die Möglichkeit mehrere Fenster parallel öffnen zu können, erlaubt dem Anwender weiterhin ein einfaches Wechseln zwischen unterschiedlichen Applikationen, ohne über das Hauptmenü zu gehen.
Zugriff auf weitere Ressourcen
Durch den Einsatz von PCs statt "dummer" Terminals als Datensichtgeräte lassen sich die Endgeräte zum Beispiel über NFS verbinden, so daß der Anwender Zugriff auf weitere Ressourcen hat.
Um eine höhere Performance bei Applikationen, die stark datenbankorientiert sind, zu erreichen, ist ein besonderes Augenmerk auf den Einsatz von verteilten Datenbanken zu richten. Die angewandten Applikationen wie Projektkostenberechnung, Lagerbestandsführung etc. werden in der Regel von verschiedenen Sachbearbeitern im Fachbereich benutzt, die die für ihre Applikation notwendige Datenbasis vorhalten. Der Einsatz von verteilten Datenbanksystemen ermöglicht, daß nur die zusätzlich benötigten Datensätze von einem zentralen Server beziehungsweise von anderen Rechnern geholt werden müssen, während die Standarddatensätze lokal verwaltet werden. Hierdurch ist ein weiteres "Downsizing" und ein optimales Verteilen von Aufgaben auf verschiedene Rechner gegeben. Benötigte Rechnerleistung läßt sich somit viel besser skalieren.
Voraussetzung hierfür ist natürlich die Existenz einer entsprechenden Infrastruktur, die bereits vorhanden war, das heißt einer LAN- und/oder WAN-Anbindung der Rechner.
Der Einsatz von Unix-basierten Systemen erlaubt oft eine Vereinheitlichung der Administration der Rechnerwelten. Man kann davon ausgehen, daß sich alle aufgeführten Punkte im wesentlichen in der Senkung der Unterhaltskosten für Unixbasierte Anwendungen niederschlagen werden.
Nicht vergessen sollte man auch die Tatsache, daß wesentliche Verbesserungen des Preis-Leistungs-Verhältnisses der Rechner auch zukünftig hauptsächlich im RISC- und damit im Unix-Bereich zu erwarten sind. Der Kunde kann somit direkt vom Konkurrenzkampf der Hardware-Anbieter profitieren da Portierungen der Software auf unterschiedliche Hardware zukünftig nur noch einen minimalen Aufwand erfordern.
Doris Grimm ist beim Fachbereich Produktionsautomatisierung der AEG,Frankfurt, Leiterin des Umstellungsprojektes.Dr. Lothar Hirschbiegel war in dieser Abteilung Leiter EDV und Organisation und ist j(...)