Downsizing bietet interessante und wirtschaftlich attraktive Perspektiven. Wer moechte nicht die gleiche Leistung fuer weniger Kosten haben? Wie aber kommen die Programme und Daten auf die neuen Rechner? In der ersten Folge seines dreiteiligen Beitrags diskutiert Harry Sneed* die Alternativen Standardsoftware, Neuentwicklung und Portierung.

*Harry Sneed ist Technischer Direktor bei der SES Software- Engineering Service GmbH in Ottobrunn bei Muenchen.

Falls der Anwender die Moeglichkeit hat, im Rahmen des Downsizing- Projekts ein Standardpaket fuer die neue Rechnerklasse mit etwa dem gleichen Funktionsumfang zu finden, stellt dies sicherlich die billigere Loesung mit dem geringsten Risiko dar. Leider gestaltet sich das Angebot an Standardsoftware fuer die Unix-Rechner noch recht mager. Die meisten erprobten Pakete laufen auf dem Mainframe. Auch wenn der Anwender eine Standardapplikation findet, ist der Anpassungs- und Einfuehrungsaufwand recht hoch.

Eine Neuentwicklung beinhaltet immer grosse Risiken, die sich auch mit CASE oder 4GL-Sprachen nicht ganz aus dem Weg raeumen lassen. Die Hauptschwierigkeiten ergeben sich aus der Notwendigkeit, einen neuen Konsens mit den Endbenutzern zu erreichen.

Bei einer Neuentwicklung dauert es mitunter Jahre, bis die alte Funktionalitaet wieder erreicht ist. Diese Luecke koennen sich die meisten DV-Abteilungen nicht leisten, obwohl das neue System viele Verbesserungen verspricht. Demnach kommt diese Vorgehensweise nur dann in Frage, wenn der Betrieb genug Zeit und Kapital hat, um beide Rechnersysteme ueber mehrere Jahre nebeneinander laufen zu lassen. Das heisst aber nicht nur doppelte Rechnerkosten, sondern auch zwei Operationsgruppen und zwei Programmierabteilungen. Die Kosten des Downsizings machen auf diese Weise den erwarteten Gewinn mittelfristig zunichte.

Deshalb bleibt in der Regel lediglich die dritte Loesung, die Portierung. Sie bedeutet eine Uebertragung der Softwarefunktionalitaet in die neue Rechnerarchitektur. Die Datenstrukturen bleiben aus der logischen Sicht der Programme unveraendert, auch wenn die physische Struktur sich veraendert. Schliesslich sollte die Software die gleichen Transaktionen ueber dieselben Ablaufpfade verarbeiten, auch wenn sie voellig anders strukturiert sind. Es handelt sich hier also um eine recht komplizierte und komplexe Aufgabe. Dennoch ist dies oft die einzige wirtschaftlich vertretbare Loesung, um in einer kurzen Zeit mit wenig Kosten vom Mainframe wegzukommen.

Sind die Programme in Assembler oder PL/1 geschrieben, muessen sie erst auf dem Mainframe in C oder Cobol konvertiert, getestet und anschliessend portiert werden. Aber auch Cobol-Software laesst sich nicht ohne weiteres umschreiben, vor allem, wenn einzelne Anwendungen zu gross geraten sind. Diese muessen erst in mehrere getrennt kompilierbare und testbare Module zerlegt werden. Es ist ausserdem notwendig, ein spezielles Zugriffsmodul zwischen den alten Programmen und dem neuen verteilten Datenbanksystem zwischenzuschalten, um die Daten in ihre alte Form wieder zurueckzuversetzen.

Die groessten Hindernisse beim Downsizing-Prozess stellen das Datenbanksystem, der Transaktionsmonitor, die Rahmensoftware und die Programmiersprache dar. Bei vielen Systemen ist es fraglich, ob sie sich fuer eine vernetzte Client-Server-Architektur ueberhaupt eignen.

In der IBM-Welt bedeutet dies

zunaechst eine Migration zu DB/2,

in der Unisys-Welt zu RDMS, in der DEC-Welt zu RDBS. In einer Siemens-Umgebung waere Adabas oder Sesam der beste Ausgangspunkt. Auf jeden Fall ist die erste Stufe der Migration ein relationales Datenbanksystem auf dem Mainframe. Von

hier aus lassen sich die Daten anschliessend auf ein relationales Datenbanksystem in der Client-Server-Welt uebertragen.

Der Transaktionsmonitor koennte ein groesseres Hindernis werden, vor allem, wenn die Verarbeitungslogik darauf abgestimmt ist. Host- Loesungen im Konversationsmodus muessen zuerst in den Transaktionsmodus umgesetzt werden. Es ist ausserdem ratsam, die Bildschirmpraesentation von der Transaktionsverarbeitung zu trennen. Die Maskenbeschreibung, Formatierung und Pruefung sollten moeglichst in eigenen Modulen stattfinden. IBM hat angekuendigt, dass CICS auch fuer verteilte Systeme als Transaktionsmonitor erweitert wird. Von IMS/DC ist keine Rede mehr. Das heisst, wer von der IBM- Mainframe-Welt wegkommen moechte, sollte zunaechst von IMS in CICS migrieren. In der Unix-Welt werden bereits einige dieser Monitore angeboten.

Die Rahmensoftware ist die Summe der Hilfsroutinen, die ueber Jahre erstellt wurden, um die Programmierung zu erleichtern. Sie besteht oft aus Standard-Subroutinen fuer Fehlerbehandlung, Recovery und Restart, Datensicherung, Speicherverwaltung und Plausibilitaetspruefungen sowie Standard-Dateizugriffsroutinen. Einige Betriebe haben Praeprozessoren zu diesem Zweck eingesetzt.

Nicht selten ist diese Hilfssoftware in Assembler geschrieben. Um portierbar zu sein, muesste sie in C neu erstellt werden. Die DV- Verantwortlichen sollten aber pruefen, ob die Rahmensoftware ueberhaupt in der neuen Umgebung noch benoetigt wird.

Einige Routinen werden sicher entfallen. In Anbetracht der unterschiedlichen Funktionalitaet empfiehlt es sich, die Rahmensoftware fuer die neue Zielumgebung zu respezifizieren und in C oder Cii neu zu programmieren.

Das angestrebte Ziel einer Sprachmigration muesste letzten Endes eine objektorientierte Sprache sein, denn diese eignet sich am besten fuer die Funktionalitaet einer Client-Server-Umgebung. Der Migrationsweg fuehrt ueber eine klassische Programmiersprache der dritten Generation.

Es empfiehlt sich, Mainframe-Programme in Assembler, PL/1 oder in einer 4GL entweder in C oder in Cobol85 bereits auf dem Mainframe durch Re-Engineering zu remodularisieren und restrukturieren. Es gilt zu vermeiden, dass die Suenden der Vergangenheit an das neue System weitervererbt werden. Im Anschluss an diese Sanierung werden die Programme in die gewuenschte Zielsprache umgesetzt.

In diesem Zusammenhang spielen auch Datenbank und Telekommunikationssprache eine grosse Rolle, denn es genuegt nicht, unstrukturierte Cobol74- in strukturierte Cobol85-Programme zu verwandeln.

DL/1- oder DML-Anwendungen sind durch Call-Aufrufe zu einem Zugriffsmodul zu ersetzen. Moeglicherweise aendert sich auch die Zugriffslogik, so dass bestimmte Teile des Programms neu geschrieben werden muessen. Deshalb empfiehlt es sich, die Datei- beziehungsweise Datenbankoperationen aus dem Mainline-Code auszulagern. Schliesslich muessen die Operationen der Transaktionsprozessoren (TP) in den Programmen entweder durch Call-Aufrufe oder durch Makros ersetzt werden, je nachdem, ob in der neuen Umgebung statisch oder dynamisch gelinkt werden sollte.

Fuer das Downsizing von kaufmaennischen Anwendungen ist Cobol85 mit SQL und einer TP-Makro-Sprache zu empfehlen. Fuer technische Anwendungen eignet sich C als Portierungssprache.

Wichtig ist, dass die Sprachkonversion bereits auf dem Host stattfindet und die konvertierten Programme dort im Produktionsbetrieb wieder getestet werden, ehe mit der eigentlichen Portierung begonnen wird. Damit werden die Weichen fuer die endgueltige Konversion gestellt.

Ein weiteres Hindernis beim Downsizing stellt die Groesse der Programme dar. Zwar besteht die Moeglichkeit, ein Hauptprogramm mit etlichen Unterprogrammen einzusetzen, aber ein einzelnes Programm darf nur eine bestimmte Groesse haben. Bei MS-DOS liegt die Grenze bereits bei zirka 7000 Zeilen, bei OS/400 bei etwa 10 000 Zeilen und bei AIX bei ungefaehr 12 000 Zeilen. Das heisst, groessere Programme koennen nicht kompiliert werden. Diese Begrenzung trifft fuer die Groesse der Objektmodule zu. Es gibt auch eine Obergrenze zu dem Lademodul, die je nach Anlage zwischen 1 und 4 MB liegt.

Andererseits findet man auf dem Mainframe nicht selten

PL/1- und Cobol74-Programme mit ueber 20 000 Zeilen. Es ist den Entwicklern nicht gelungen, diese Programme zu teilen. Vielleicht waren sie einmal in einer vertretbaren Groesse, aber ueber die Jahre sind sie immer umfangreicher geworden. Der Arbeitsspeicher wurde nach Bedarf erweitert, und als neue Funktionen aufkamen, wurden sie im prozeduralen Teil irgendwo angehaengt. So wuchs und wuchs das Programm, bis es eines Tages ueberhaupt nicht mehr handhabbar war. Solche Fehlentwicklungen sind sowohl bei Batch- als auch bei Dialoganwendungen zu finden. Das schlimmste ist, dass diese Programme oft die wichtigsten Funktionen des Unternehmens beinhalten.

Programme in dieser Groessenordnung mit mehr als 12 000 Zeilen eignen sich kaum fuer ein automatisches Re-Engineering, da sie durch diesen Vorgang noch um rund ein Drittel umfangreicher werden. Dies ist eine logische Folge der Restrukturierung von einem Netz in einen Baum, der Auslagerung der I/O-Operationen sowie der Entfernung der Literale und Konstanten aus dem prozeduralen Code. Somit wird aus einem Programm mit 12 000 leicht eines mit 16 000 Zeilen. Abgesehen von den absoluten Compiler- und Link-Edit-Grenzen auf Arbeitsplatz-Rechnern spricht auch sonst vieles gegen derartig grosse Programme.

Erstens sind sie nicht testbar. Die Anzahl Versuchslaeufe, die man fuer das Testen eines Programms benoetigt, waechst exponentiell im Verhaeltnis zur Programmgroesse. Eine Anwendung mit 1000 prozeduralen Anweisungen braucht zirka 100 Testfaelle. Bei 2000 prozeduralen Anweisungen benoetigt man schon 500 Versuche. Fuer 8000 prozedurale Anweisungen sind mindestens 5000 Testfaelle erforderlich. Systematisches Vorgehen ist nur moeglich, wenn kleinere Programmeinheiten jede fuer sich getestet werden.

Zudem lassen sich Programme in dieser Groessenordnung kaum warten. Sie haben in der Regel viele Schnittstellen, Datenreferenzen und Ablaufzweige. Ein Programm mit 10 000 prozeduralen Anweisungen, wovon ein Viertel Verzweigungen sind, wird nach McCabe eine Ablaufkomplexitaet von mehr als 200 haben.

Wer den Wartungsaufwand reduzieren moechte, muss unter anderem die Komplexitaet der Software abbauen. Bei grossen Anwendungen bedeutet dies eine Zerlegung in kleinere

Teile.

Die portierbaren Sprachen C und Cobol85 sehen modulare Programme vor, die mit Call-Schnittstellen verbunden sind. Grosse monolithische Programme sprengen den Rahmen dieser Sprachen. Ueber Cii und OO-Cobol fuehrt der Weg in die objektorientierte Programmierung, aber nur, wenn die Programme bereits stark modularisiert sind. Fuer grosse Programme bleibt dieser Migrationsweg versperrt.