Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.11.1993 - 

Das Ende von VS-Cobol kommt Mitte 1994

Tools helfen Mainframern beim Einstieg in eine neue Cobol-Aera

Eine Cobol-Aera geht zu Ende. Waehrend die Branche von objektorientierter Programmierung schwaermt, laeuft ab Mitte naechsten Jahres die Entwicklung von VS Cobol aus. Nun muessen auch die letzten Mainframer auf Cobol II umsteigen. Mit einem Automatisierungs-Tool laesst sich die Konversion, vor allem wenn eine Vielzahl von Programmen betroffen ist, wesentlich vereinfachen und beschleunigen.

Laut Ankuendigung von IBM sollen am 30. Juni 1994 der Support und die Wartung von OS/VS Cobol nach ANSI-Standard 74 eingestellt werden. Weiterhin ist anzunehmen, dass ab diesem Zeitpunkt die Weiterentwicklung von Cobol II nach dem ANSI-85-Standard beendet und die Entwicklungsarbeit voll auf Cobol 370 ausgerichtet wird. Allerdings stellt der Uebergang zu Cobol 370 aus Sicht von Cobol II-Anwendern kein Problem dar, da der volle Sprachumfang in diese neue Version uebernommen wird.

Big Blue verspricht einfache Portierung

IBM hat versprochen, dass sich Cobol-II-Programme ohne jegliche Aenderung unter Cobol 370 kompilieren lassen und lauffaehig sind. Der von IBM angestrebte Compiler LE (Language Environment) 370, der zur Verarbeitung von Cobol, PL/1 und C faehig sein soll, wird also auch Cobol II abdecken, da der komplette Umfang dieser Sprache wie gesagt in Cobol 370 enthalten ist.

Durch den von IBM gesetzten Termin gibt es fuer die Anwender keine Moeglichkeit mehr, eine Migration zu umgehen. Der Umstieg auf Cobol II erscheint aber allein schon aufgrund der dadurch nutzbaren technischen Moeglichkeiten geboten. Vom Standpunkt der Anwendungsprogrammierung bleiben bei Installationen von XA- oder ESA-Systemen von IBM - das gilt auch fuer VSE-RZs seit Version 1.3 von VSE/ESA - viele Faehigkeiten von Betriebssystem und Hardware weitgehend ungenutzt, solange nicht Cobol II implementiert ist.

Entscheidend ist, dass Cobol II die Moeglichkeit zur 32-Bit- Adressierung bietet, durch die Anwendungsprogramme oberhalb der 16-MB-Grenze operieren koennen. Objektmodule sind in einem Speicherraum von bis zu 2 GB ausfuehrbar. Durch diese Faehigkeit von Cobol II konnte IBM viele fuer die OS/VS- und DOS/VS-Cobol-Compiler geltenden Restriktionen beseitigen.

Mit Cobol II lassen sich existierende Programme, die durch ihre Groesse an die Kapazitaetsgrenze des Compilers gestossen sind, weiter ausbauen. Dadurch wird eine regulaere Erweiterung von Tabellen und anderen Konstrukten moeglich, ohne auf Segmentierung der Anwendung oder zweifelhafte Programmiertechniken zur Umgehung der Compiler- Grenze zurueckgreifen zu muessen.

Viele bei VS Cobol bestehenden Einschraenkungen sind in der aktuellen Cobol-Version aufgehoben worden, so dass XA- und ESA- Rechenzentren damit eine nahezu grenzenlose Speicherkapazitaet nutzen koennen. Zum Beispiel wurde die Grenze der Procedure- Division von 1 MB auf 4 MB und die des Arbeitsspeichers von 1 MB auf nicht weniger als 128 MB ausgedehnt. Jetzt ist es moeglich, bis zu einer Million Zeilen Sourcecode in einem einzigen Modul unterzubringen.

Beim Schreiben von CICS/VS-Programmen mit Cobol II besteht die Moeglichkeit, sie oberhalb der Grenze der bereits angesprochenen Speicherbeschraenkung ausfuehren zu lassen. Ausserdem werden CICS/VS- Programme grundsaetzlich mit der Option RENT (re-entrant) kompiliert. Durch Unterbringung der Module in der "link pack area" koennen mehrere Anfragen aus verschiedenen CICS-Regionen die gleiche Programmkopie benutzen. Auf diese Weise spart das System Speicherplatz und Verarbeitungszeit, die sonst fuer das Laden verschiedener Kopien benoetigt werden.

Cobol II fuehrt viele Funktionen aus, die frueher der Entwickler beim Schreiben von CICS/VS-Programmen selbst beitragen musste. So braucht der Programmierer beispielsweise nicht mehr Pointer fuer den Zugriff auf CICS-verwaltete Daten bereitzustellen, so dass sich Service-Reloads eruebrigen. Auch Restriktionen beim Gebrauch von STRING, UN- STRING, INSPECT, STOP RUN und STATIC CALL sind aufgehoben. Ein mit STATIC CALL aufgerufenes Cobol II- Unterprogramm kann auch CICS-Befehle enthalten.

IMS/VS erlaubt das Preloading von Cobol-Programmen in den Speicher vor der Ausfuehrung, um so die Performance zu erhoehen. Diese Moeglichkeit auszuschoepfen ist mit VS Cobol oft schwierig, da fuer das Preloading eine spezifische Kompilieroption erforderlich ist. Um das Preloading zu beenden, muss eine Rekompilierung durchgefuehrt werden.

Mit Cobol II benutzt man den gleichen Set von Optionen, egal ob mit dem Programm von IMS ein Preloading gemacht werden soll oder nicht.

Nicht weniger als 60 Prozent der Programmierbudgets von Rechenzentren werden gewoehnlich fuer Aufgaben wie Wartung und Pflege der Programme verwendet. Daher ist der Wunsch, Entwicklungsstandards einzufuehren und die Produktivitaet zu erhoehen, nur allzu verstaendlich.

Techniken des strukturierten Programmierens koennen beim Erreichen dieser Ziele sehr hilfreich sein. Cobol II liefert dazu ein breites Spektrum an Funktionen. Viele dieser neuen Moeglichkeiten, die dem Cobol-85-Standard entsprechen, erlauben Programmierkonstrukte, die mit VS Cobol entweder gar nicht oder nur sehr schwer zu codieren sind.

In vielen Unternehmen werden neue Anwendungen bereits mit Cobol II geschrieben. Gleichzeitig existiert aber eine riesige Menge von zum Teil Mission-critical-Anwendungen, die noch in ANSI-74-Code laufen. In Unternehmen, die ihre Grossrechner-DV zum Teil noch auf VS-Cobol-Basis betreiben, arbeiten im Durchschnitt etwa noch 750 solcher Programme. Bei realistischer Betrachtung ist davon auszugehen, dass eine Migration nach Cobol II haeufig kaum bis zum 30. Juni 1994 zu bewerkstelligen sein wird, da die Entwicklungskapazitaeten in der Regel bereits durch den staendig anfallenden Aenderungsbedarf ausgelastet sind.

Um eine Migration zu erleichtern und zu beschleunigen, kann man ein Tool einsetzen, das Teile des Migrationsprozesses automatisiert. Dazu bieten sich Analyse-, Transformations- und Migrationssysteme an. Solche Tools lassen sich in einigen Faellen auch verwenden, um eine ANSI-68-Syntax nach ANSI 74 zu uebertragen. Sinnvoll sind auch Funktionen, die die Uebersetzung von Macro- level-CICS zu Command-level-CICS oder von Call-level-DL/I zu Exec- level-DL/I zulassen.

Ein Migrationssystem sollte mehrere - auf Programme beziehungsweise Libraries bezogene - Analysefunktionen gleichzeitig ausfuehren. Diese liefern Zusammenfassungen von Programmen und zeigen Zusammenhaenge zwischen Programmen sowie zwischen Programmen und Copybooks auf. Damit koennen Analysen und Reportaufgaben durchgefuehrt werden, die von einfachen Cross- Reference-Reports wie dem "Program CALL Cross-Reference Report" bis zu sehr differenzierten Berichtsverfahren wie dem "Data Element Cross-Reference Report" reichen.

Aufgelistet werden in solchen Berichten saemtliche in den Copybooks definierten Datenelemente, auf die in den analysierten Programmen Bezug genommen wird. Wichtig ist auch, dass der Anwender eine Referenzenliste erhaelt, aus der hervor geht, welche Variablen in welchem Programm angesprochen werden und welche Datei in welchem Programm bearbeitet wird. Auf diese Weise entsteht bei der Migration eine Bestandsaufnahme der Altanwendungen.

Regeln stammen vom Anwender

Sinnvoll sind Werkzeuge, mit denen die Benutzer Optionen, Regeln und Schablonen fuer die Uebertragung der Daten vorgeben koennen. Bei solchen Transformationen kann es sich um eine simple Uebertragung aller Referenzen von einem Set von Datenbezeichnungen auf ein anderes, Restrukturierungsmassnahmen wie die Ausrichtung von Befehlen auf bestimmte Spalten, die Umsetzung von 77-Stufen-Level auf 01-Level, oder auch um einen komplexen Transformationsprozess wie bei der Datenuebernahme von einem DBMS in ein anderes handeln.

Zusaetzlich zur Codekonversion muss ein Migrierbericht erstellt werden. Aus diesem geht hervor, was nach der automatischen Migration noch zu tun bleibt. Die dafuer notwendigen Umsetzroutinen koennen in einer Makrofunktion abgelegt werden, die bei der endgueltigen Migration die noch erforderlichen Veraenderungen vornimmt. Falls die Migration unter MVS erfolgt, laesst sich auf Basis einer PDS-Datei eine Mengenkonvertierung vornehmen. Partitioned Data Sets (PDS) koennen unter VSE allerdings nicht gebildet werden. Daher sind unter diesem Betriebssystem die Jobs manuell an das Migrations-Tool zu uebergeben.