Die Programmierung des IBM-Transaktionsmonitors CICS erfolgte in den vergangenen Jahren traditionell im sogenannten Macrolevel-Code. Gegenwärtig findet vielerorts ein Wechsel zum moderneren Commandlevel-Code statt. Da IBM das alte Programmiersystem schon bald nicht mehr unterstützen will, sind die Anwender ratlos. Was wird aus den alten Macrolevel-Anwendungen? Kenneth Dakin* schildert in seinem Beitrag mögliche Wege aus der "CICS-Krise".

Der Europäische Binnenmarkt '92 fordert die Unternehmen. Zukunftsstrategien für global orientierte Märkte werden schon heute entworfen. Erfolgreiche Unternehmen müssen aber auch nach innen vorbereitet werden. Einer der gewünschten Nebeneffekte des Europäischen Binnenmarktes wird der verschärfte internationale Wettbewerbsdruck sein.

Nur wer sein Unternehmen intern durchforstet und damit nach außen fit für den härteren Wettbewerb macht, kann in Zukunft erfolgreich sein. Die unternehmerischen DV-Konzepte können dabei nicht unberücksichtigt bleiben, im Gegenteil: Zunehmender Druck von außen veranlaßt die Unternehmen dazu, ihre innere Struktur wirtschaftlicher zu gestalten und sich schon heute - auch bei Kosten-Nutzen-Analysen - entscheidende Startvorteile für die Zukunft zu sichern.

Die internationale Aufbruchsstimmung hat den DV-Sektor schon seit geraumer Zeit erfaßt. Rasante Entwicklungen im Hard- und Softwarebereich zwingen die Anwender dazu, vormals bewährte Verfahren und Techniken in immer kürzeren Abständen als veraltet einstufen zu müssen. Diese Entwicklung ist nicht nur für den User unangenehm, sie ist auch für den betriebseigenen Kostenrechner ein ökonomisches Ärgernis erster Güte.

Verfolgt man die IBM-Entwicklung der letzten zwei Jahrzehnte, so erhält man ein Beispiel dafür. Der IBM-Anwender sieht sich mit folgendem Problem konfrontiert: die Adaption des SAA-Standards, von der PC-Ebene (PS/2) über Abteilungsrechner (AS/400) bis hin zum Mainframe (MVS/ESA, DB2). Ziel ist es, in sämtlichen Bereichen Portabilität und Kompatibilität sicherzustellen.

Hinzu kommt die Berücksichtigung des AD/Cycle-Konzeptes oder wahlweise der Einsatz unabhängiger CASE-Tools für Design, Entwicklung und Pflege von Anwendungen.

IBM-Anwender zu sein heißt aber auch, teilzunehmen an der Installation neuer Subsysteme und Systemkomponenten wie MVS/ESA, Cobol II, PL/1 und den neuen Versionen von CICS.

Die CICS-Programmierung selbst hat eine rasante Entwicklung genommen: Alte und neue CICS-Programme existieren nebeneinander, wobei die neuen in den letzten zehn Jahren die alten zunehmend ergänzt, wenn nicht sogar verdrängt haben. Heute weiß jeder DV-Kenner, daß von etablierten Verfahren und Techniken dann Abschied genommen werden muß, wenn sie zukünftige Entwicklungen blockieren. Gemeint sind damit die ClCS-Macrolevel-Programme.

Diese Anwendungen sind bekannterweise in keinem der zukunftsträchtigen Programme enthalten, repräsentieren aber in vielen Unternehmen den "Showstopper" schlechthin, wenn es darum geht, an zukünftigen Entwicklungen und am Einsatz neuerer CICS-Versionen teilzunehmen. Immer mehr entwickelte sich diese so weit verbreitete Programmiertechnik zum Sorgenkind der Anwender.

Als IBM vor etwa 20 Jahren erstmalig ihr Produkt CICS vorstellte, war die Programmierung dieses Transaktionsmonitors nur Im sogenannten Macrolevel möglich. Zu diesem Zeitpunkt kannte man kein "Commandlevel". In genau dieser Zeit legten allerdings viele Unternehmen ihren DV-Grundstock. Natürlich wurden die wichtigsten Anwendungen im ClCS-Makrolevel-Code geschrieben.

Darüber hinaus zwangen technische Restriktionen wie die Limitierung des Speichers oder Durchsatzprobleme zu einer teilweise recht "trickreichen" Programmierung. Auch in späteren Jahren konnte noch beobachtet werden, daß besonders komplizierte Problemstellungen im bewährten Macrolevel entwickelt wurden.

Die Macrolevel-Programmierung erfordert sehr gute Kenntnisse der Systeminterna und ist zeitaufwendig. IBM entschloß sich deshalb zu Beginn der 80er Jahre zur Ankündigung eines ClCS-Commandlevels. Die Programmierung wurde wesentlich vereinfacht, die Anwendungsentwicklung erreichte dadurch eine deutlich größere Produktivität. Außerdem konnten interne Parametersteuerungen des CICS aus Applikationsprogrammen in das ClCS-lnterface verlagert werden.

Alle Unternehmen, deren Kernanwendungen im Macrolevel geschrieben wurden, stehen heute aber vor einem Kardinalproblem: IBM hat angekündigt, daß der Macrolevel zukünftig von Programmiersprachen und CICS nicht mehr unterstützt wird. Für den Anwender heißt das, entweder er löst, das Problem heute, oder er wird an zukünftigen Entwicklungen nur bedingt teilnehmen.

Die DV-Strategen sitzen in der Klemme: Sie müssen aufgrund der SAA- und AD/Cycle-Konzepte neue Pläne ausarbeiten, um mit der Marktentwicklung standhalten zu können und wettbewerbsfähig zu bleiben. Die neuen MVS-Versionen fordern außerdem den Einsatz der ihnen angepaßten Systeme, wie zum Beispiel CICS 3.1.

Zusätzlichen Druck üben die Entwickler aus, die die gesamte Palette neuer ClCS-Funktionen benutzen möchten: MRO, Source Level Security, remote files CEDF. Prinzipiell hat der verantwortliche DV-Leiter vier Möglichkeiten, um aus dieser Falle herauszukommen:

1. Source-Code-Umstellung

2. Neuentwicklung

3. Emulation

4. Run-Time-Conversion.

Drei der vier Methoden werden unter den Betroffenen allerdings kaum großen Enthusiasmus aufkommen lassen. Diese Lösungen sind mit großem Aufwand, Kosten und Personal verbunden. Letztendlich werden sie nur gleiche Ergebnisse in verschiedenen Varianten liefern.

Bei der Source-Code-Umstellung handelt es sich um ein Gesamtprojekt, bei dem jedes einzelne Anwenderprogramm auf Source-Ebene vom Macrolevel auf den Commandlevel umgestellt wird - manuell oder mit Unterstützung entsprechender Tools. Anschließend müssen diese Programme neu kompiliert, gelinkt und vor allem intensiv getestet werden.

Nach Durchführung dieser Tätigkeiten erfolgt die Einführung dieser Programme ins Gesamtsystem. Bei derartigen Projekten sind pro Cobol- und 8 PL/1-Programm etwa 1,1 bis 1,4 Manntage anzusetzen, für Assembler-Programme ungefähr 1,8 bis 2,0. Hinzu kommt jeweils der Testaufwand. Bereits bei einer Menge von 100 Programmen ist der Umstellungsaufwand in Mannjahren zu kalkulieren.

Der Vorteil dieser Methode liegt allein darin, daß Commandlevel-Programme im System zur Verfügung stehen. Nachteile entstehen dadurch, daß sich neue Fehler in ein umgestelltes Programm einschleichen können. Außerdem ist das Testen von Transaktionsprogrammen sehr zeitaufwendig. Lesbarkeit und Wartung der umgestellten Programme sind meistens kompliziert. Das größte Problem besteht jedoch darin, daß zusätzliche Personal- und Systemressourcen gestellt werden müssen.

Als ein weiteres Handikap wird sehr oft die Verzögerung anstehender wichtiger Projekte genannt. Frustrierend ist dabei, daß man mit diesem kostspieligen Verfahren keine neue Funktionalität gewinnt, sondern letztendlich Gleiches in anderer Form vorliegen hat.

Wesentlich attraktiver scheint dagegen die Neuentwicklung sämtlicher in Macrolevel geschriebener Programme zu sein. Man geht hier den Weg des Reverse Engineering, also zurück zum funktionellen Design, um auf diesem aufbauend neue Programme zu entwickeln. Hierzu ist natürlich ein Projekt größeren Stils erforderlich.

Pseudo-CICS übernimmt die Kontrolle

Der Vorteil dieser Methode liegt darin, daß neuere, besser entwickelte Anwendungen zum Einsatz kommen dürften. Allerdings gibt es auch hier einen Wermutstropfen: Anwendungen mit zumeist kaum veränderter Funktionalität kommen bei relativ hohen zusätzlichen Personalressourcen zum Einsatz.

Bei 100 Programmen kann von folgenden Werten ausgegangen werden: 100 Programme mit jeweils 600 Lines of Code ergeben insgesamt 60 000 Codezeilen. Bei einer Produktivität von 50 Lines of Code pro Programmiertag müßte mit einem Entwicklungszeitraum von insgesamt 1200 Manntagen (inklusive Test- und Produktionseinführung) gerechnet werden.

Eine elegante Methode, dieses Problem zu lösen, ist die Emulation von Macrolevel-Programmen unter MVS. Hier wird ähnlich wie bei Betriebssystem-Emulatoren eine zusätzliche Ebene eingeführt (Pseudo-CICS), welche die Kontrolle des gesamten Programmes übernimmt. Eine Umstellung kann somit relativ schnell vollzogen werden, erfordert allerdings erhebliche zusätzliche Systemressourcen. Da Emulatoren sämtliche Befehle "emulieren" entsteht ein Performance-Verlust, dem durch zusätzliche Hardwareinvestitionen begegnet werden kann.

Die sogenannte Run-Time-Conversion kann als Ideallösung bezeichnet werden, um eine Konvertierung vom CICS-Macrolevel zum Commandlevel durchzuführen. Bei diesem Verfahren wird das eigentliche Programm (Load-Module) ganz normal im Betriebssystem ausgeführt - es entsteht also kein Overhead. Sobald ein CICS-Macrolevel-Statement ausgeführt werden soll, wird dieses an einen Run-Time-Konverter übergeben, der den Befehl in das Commandlevel-Format überträgt und an den Transaktionsmonitor zur Ausführung weiterleitet.

Dieser Vorgang beansprucht etwa zehn bis 15 zusätzliche Maschinenbefehle pro CICS-Call und wirkt sich nicht auf die Performance aus. Vorteile liegen unter anderem darin, daß keine Umstellungszeit anfällt und daß Personal für andere Projekte eingesetzt werden kann. Des weiteren wird das vielfach gefürchtete Auftreten neuer Programmfehler vermieden.

Um an den zukünftigen Entwicklungen teilnehmen zu können, muß das Macrolevel-Problem auf jeden Fall gelöst werden. Heute sind nur etwa die Hälfte der IBM-Großrechnerkunden betroffen. Aber die Grundeigenschaft zukünftiger Programmierprodukte kann nicht wegdiskutiert werden: Die Lebenszyklen werden immer kürzer. Macrolevel konnte sich gute 15 Jahre halten. Und der Commandlevel?