Vor- und Nachteile einer Umstellung

Zwei Alternativen für die DV-Umstellung auf Cobol II

05.10.1990

Plant ein Unternehmen im großen Rahmen auf Cobol II umzustellen, so bieten sich nach Einschätzung von Karin Kullmann* zwei Verfahren an: eine projektweise Umstellung oder aber eine Umstellung während der Wartung. Welche Vor- und Nachteile diese beiden Vorgehensweisen haben, beschreibt die Beraterin in ihrem Beitrag.

Schlagwörter wie SAA und Portierbarkeit von Anwendungen sind seit einigen Jahren in aller Munde. Wer sich dem SAA-Konzept verschreibt, kommt um die Einführung von Cobol II nicht herum. Dabei entstehen Vorteile wie Codier- Erleichterungen (Evaluate, Continue, Not-Bedingungen, Perform with, Test before/after) oder Strukturierungsverbesserungen durch die Terminierung von bedingten Anweisungen (End-if) sowie die Unterstützung der 31-Bit-Adressierung für große Anwendungen und das Testtool Cobtest.

Allerdings ist zu beachten, daß Cobol II auch systemspezifische Nicht-SAA-Komponenten enthält, die sich negativ auf die Portierbarkeit von Anwendungssystemen auswirken. Um die Portabilität zu gewährleisten, müssen solche Komponenten durch Programmierrichtlinien eingeschränkt werden.

Am Anfang unserer Umstellung auf Cobol II stand die Voruntersuchung. Bereits 1988/89 wurden bei einer Testinstallation zunächst der Sprachumfang von Cobol Il und anschließend das Anwendungsumfeld in unserem Unternehmen untersucht. Ungefähr 5600 Batch- und 1500 Online-VS-Cobol-Programme (CICS) aus den Bereichen Versicherungen, Banken Standardanwendungen (unter anderem SAP, Paisy, Copics) sind im Einsatz.

Zuerst wurden bei den verschiedenen Herstellern Informationen über die Verträglichkeit von Standardsoftware-Produkten und Cobol II eingeholt. Anschließend wählten wir eine Konvertierungshilfe - das sogenannte "SWS Migrationtool" - aus, die eine automatisierte Migration von Quellprogrammen unterstützt. Insbesondere wurden nicht mehr unterstützte VS-Cobol-Anweisungen durch Cobol-lI-Anweisungen ersetzt, Scope Delimiter eingefügt und veränderte Zeilen sowie der Migrationszeitpunkt protokolliert.

Während einer 30tägigen Testinstallation haben wir zahlreiche Batch- und Online-Programme (CICS) auf Cobol II umgestellt und getestet. Dabei traten keine Fehler auf. Die migrierten VS-Cobol-Programme konnten mit dem Cobol-II-Compiler fehlerfrei umgewandelt werden.

Mit all den Informationen wurden zwei Alternativen für die Einführung von Cobol II erarbeitet. Zunächst gibt es die Möglichkeit einer projektweisen Umstellung, wobei jedes Anwendungssystem einzeln umgestellt wird. Die Adressierung des Systems kann im 31-Bit-Mode geschehen. Ob ein in Produktion übergebenes Programm bereits umgestellt ist, kann leicht festgestellt werden.

Als wesentlicher Nachteil läßt sich anführen, daß Unterprogramme, die von mehreren Projekten benötigt werden, in zwei Versionen vorhanden sein müssen. Zudem sind mehrere Software-Entwickler ausschließlich mit der Umstellung beschäftigt.

Eine zweite Möglichkeit ist die Umstellung während der Wartung eines Programms. In diesem Fall geschieht die Umstellung neben der Projektarbeit während der Änderung eines Programms. Dabei sind keine Arbeitskräfte an dieses Verfahren gebunden. Allerdings ist auch diese Lösung mit einigen Nachteilen verbunden. Cobol II kann bis zum Ende der Umstellung des gesamten Anwendungssystems nur im 24-Bit-Modus genutzt werden. Außerdem ist der Umstellungszeitraum nur schwer planbar.

Die Entscheidung über den Einsatz von Cobol II fiel bei uns zugunsten der zweiten Alternative. Alle Software-Entwickler sind dabei in neue Projekte eingebunden. Darüber hinaus steht ihnen nur ein geringer Zeitraum für die Wartung zur Verfügung. Zudem werden Anwendungen, die durch Neuentwicklungen in absehbarer Zeit abgelöst werden, nicht mehr umgestellt.

Im Juli/August 1989 wurde Cobol II, Release 3, installiert und ein Teil der Anwender in einem hausinternen Cobol-II-Workshop geschult. Von diesem Zeitpunkt an kam Cobol II bei Neuentwicklungen zum Einsatz. Parallel dazu haben wir unsere Entwicklungsumgebung Idas (Interaktives Dokumentation und Arbeitsystem) um die Cobol-II-Umgebung erweitert. Dazu zählen Umwandlungsjobs mit und ohne Cobtest, das Migrationtool sowie und die Übergabe von Cobol-II-Programmen in Produktion.

Zusätzliche Tests über die Verträglichkeit von VS Cobol, PL1 und Assembler mit Cobol-II in Batch- und Online-Anwendungen verliefen positiv. Die "Umstellung bei Wartung" wurde ab Januar 1990 geplant - beginnend mit Cobol II-Workshops für alle Anwendungsentwickler.

Mehrere Anwendungssysteme (Neuentwicklungen Batch und Online) sind bereits in Cobol II realisiert. Neuentwicklungen werden jetzt generell in Cobol II geschrieben und falls es keine Schnittstellen zu bestehenden Systemen gibt, auch im 31-Bit-Mode adressiert.

Anfängliche Schwierigkeiten der Anwender mit der "neuen" Sprache, dem Handling der Testhilfe Cobtest und der Adressierung waren schnell vergessen. Allerdings warf der gleichzeitige Einsatz von VS Cobol und Cobol II in Teilbereichen größere Probleme auf, vor allem bei VS-Cobol-Batch-Programmen, die mit der Compile-Option Noresident umgewandelt wurden.

Laut IBM-Literatur ist die Kommunikation zwischen VS Cobol und Cobol II auch in diesem Fall möglich, wenn man mit der Run-Time-Option Mixres arbeitet. Mit dieser Option können residente (Cobol-II-) und nicht residente (VS-Cobol-)Programme in einer Rununit ausgeführt werden - das heißt, die mit Noresident kompilierten Programme werden wie residente Programme behandelt.

Allerdings zeigte sich, daß ein erneuter Link zwischen allen VS-Cobol-Programmen und der Cobol-II-Runtime-Library nötig ist, um die Mixres-Option einsetzen zu können. Deshalb wurden in unserem Unternehmen einzelne Anwendungen mit dem VS-Cobol-Compiler und der Compiler-Option Resident neu umgewandelt.

Der Vorteil liegt darin, daß bestehende Anwendungen keine Probleme aufwerfen, da sie inhaltlich nicht verändert werden, und die Kommunikation mit Cobol II gewährleistet ist. Ein wiederholtes Umwandeln der Programme kann ohne Einbeziehung der Software-Entwickler zum Beispiel an einem Wochenende geschehen. Da nach kann die Umstellung während der Wartung wie geplant beginnen .

Im Laufe eines Monats lassen sich während der Wartung ungefähr 20 bis 30 Programme umstellen. Dabei werden die oft problematischen Altsysteme nicht konvertiert, da diese in den nächsten Jahren größtenteils durch Neuentwicklungen, ersetzt werden. Unsere Programmierrichtlinien wurden unter Berücksichtigung der Erweiterungen und Verbesserungen durch Cobol II neu überarbeitet. Nicht-SAA-Komponenten werden nicht verwendet, um die Portierbarkeit der Programme zu gewährleisten. Als Fazit läßt sich feststellen: Die Resonanz der Software-Entwickler ist durchweg positiv. Außerdem hat der Cobol-II-Sprachumfang viele Verbesserungen gebracht.