Großrechner-SW entsteht immer häufiger am PC, doch:

Der PC kann den Mainframe nicht ersetzen

01.09.1989

Die Klagen der Fachabteilungen über den Anwendungsstau sind Legion. Und auch die Auslagerung der Programmerstellung auf PCs schafft hier nur bedingt Abhilfe. So kann derzeit noch nicht auf Testläufe am Großrechner verzichtet werden. Der PC kann den Mainframe zwar entlasten, jedoch nicht ersetzen.

*Clemens Max ist als Berater für Informationstechnologie bei der KPMG Deutsche Treuhand-Unternehmensberatung GmbH, Frankfurt, tätig.

Nicht nur die Überlastung der DV-Fachleute sondern auch unzureichende Entwicklungswerkzeuge sind schuld, daß am Großrechner nicht effektiver programmiert werden kann. Daher haben immer mehr Softwarehersteller erkannt, daß sich der PC als Front-end für die Softwareentwicklung durchsetzt. Sie bieten verstärkt PC-Versionen ihrer Produkte beziehungsweise PC-Software an, die auf den Großrechner zugeschnitten ist.

Es gibt inzwischen Werkzeuge, die es ermöglichen, am PC Software für den Großrechner, wie ClCS-Dialogprogramme, zu erstellen und zu testen. Die bekanntesten Produkte sind Realia COBOL, das von der GFU mbH vertrieben wird, sowie die COBOL/2 Workbench von Micro Focus.

Mit solchen Produkten läßt sich die Programmentwicklung über weite Strecken vom Großrechner losgelöst durchführen, denn Programmteile werden auf dem PC oder auf dem Fileserver abgelegt. Die Generierung von Masken und Copy-Strecklen sowie die Editierung und Übersetzung der Programme erfolgen dort. Danach laufen die Programme am PC und können mit einem Debugger getestet werden.

Im Anschluß an die Testläufe findet der Filetransfer der Softwarebausteine zum Großrechner statt. Über 3270-Emulation werden dort die Programme nochmals vollständig generiert und anschließend integriert.

Rasche PC-Programmierung entlastet den Großrechner

Die Programmentwicklung auf dem PC weist gegenüber dem Großrechner eine Reihe von Vorteilen auf:

- Durch Verlagerung von Editierung, Übersetzung und eines Teils des Tests auf den PC wird der Großrechner spürbar entlastet, was entweder die nächste fällige Aufrüstung hinausschiebt beziehungsweise die Rückgabe von Rechenzeit an den Anwender ermöglicht.

- Durch Feldverarbeitung, Grafikunterstützung sowie ein gleichmäßiges Antwortzeitverhalten wird am PC eine Benutzoberfläche angeboten, die ein effizienteres Arbeiten ermöglicht.

- Die bei der Programmentwicklung im Mittelpunkt stehenden Aufgaben - Editierung und Generierung - können von den heutigen PCs in kürzerer Zeit bewältigt werden. Vergleichstests haben gezeigt, daß Übersetzungsläufe am PC meistens weniger als ein Drittel der Wartzeit am Großrechner verbrauchen.

- Vor allem kleinere Unternehmen schrecken vor den relativ hohen Kosten von guten Testwerkzeugen am Großrechner zurück und beschränken sich auf Standardlösungen, wie EDF unter CICS. Zu den genannten PC-Programmierwerkzeugen gehören leistungsfähige Debugger, mit denen der überwiegende Teil der Anwendungslogik auf dem PC getestet werden kann. Dadurch fallen die durch Systemabstürze bedingten gegenseitigen Störungen weg.

- lnsgesamt wird durch die verbesserte Werkzeugunterstützung eine Verkürzung der Entwicklungszyklen möglich, die zum Abbau des Anwendungsstaus oder zur Reorganisation von Altsystemen genutzt werden kann.

Mit der Verlagerung der Programmentwicklung auf den PC scheint sich ein großer Teil der heutigen Probleme lösen zu lassen. Stellt sich die Frage, ob die Bereitstellung der beschriebenen Werkzeuge bereits ausreicht, um eine deutliche Reduzierung des Entwicklungsaufwands zu erreichen. Denn bei näherem Hinsehen zeigen sich einige technische wie organisatorische Schwierigkeiten. So machen sich eine Reihe von Unterschieden

unliebsam bemerkbar, die aus verschiedenen Rechnerkonzepten resultieren.

Zunächst ist zu beachten, daß sich durch die unterschiedlichen Zeichendarstellungen - EBCDIC am Großrechner und ASCII am PC - Probleme ergeben. Für die Umsetzung der Quellprogramme reichen die auf den gängigen PC-Host-Kommunikationskarten enthaltenen Konvertierungsprogramme aus.

Komplizierter ist die Transferierung von Testdaten, da hier nicht nur alphanumerische Zeichen, sondern auch binärcodierte Daten vorkommen. Alphanumerische Daten werden anhand einer Konvertierungstabelle umgesetzt, die Binärcodierungen sind in beiden Darstellugsarten gleich. Da man den Daten nicht ansieht, welcher Klasse sie angehören, muß ihre Struktur vor der Konvertierung bekannt sein.

Bei Verwendung von Dateien mit variablen Satzarten ist es daher notwendig, vor der Umsetzung jedes Satzes durch Inspektion seine Art zu ermitteln. Eine Lösung der hier geschilderten Problematik ist in den beschriebenen PC-Entwicklungswerkzeugen nicht integriert.

Die Sprachoberflächen, das heißt die Quellcodes, sind auf PC und Großrechner gleich. Dafür unterscheiden sich die Laufzeitsysteme, sodaß unterschiedliche Maschinencodes verwendet werden. Dies hat zur Folge, daß auf dem PC nur solche Programme zum Ablauf gebracht werden können, die als Cobol-Quellcode vorliegen.

Vorhandene Assembler-Unterprogramme oder Standardsoftware in Maschinencode können nicht einfach auf den PC portiert werden. Sie müssen zur Integration am PC vollständig, oder in einer abgemagerten Version als Dummy reimplementiert werden. Da dies nicht so einfach zu bewerkstelligen ist, können Tests am PC nicht vollständig durchgeführt werden. Auf Tests am Großrechner und damit auf den Einsatz eines zentralen Testwerkzeugs kann daher nicht verzichtet werden.

Auf die Frage nach dem Funktionsumfang auf dem PC, etwa bei CICS, wird man von den Anbietern gerne auf die IBM-Handbücher verwiesen. Bei genauerer Betrachtung erkennt man, daß der Compiler die ClCS-Syntax zwar vollständig erkennt, die Semantik zu manchen Befehlen und zu einigen Optionen wie Coditions - entsprechend den PC-Gegebenheiten - fehlt. Als Beispiel seien die BMS-Funktionen genannt. Hier wird die Bildung von Pages oder Partitions nicht unterstützt.

Download-Probleme bei umfangreichen Programmen

Für viele Entwickler mag es sich bei den Einschränkungen um von ihm wenig genutzte Funktionen handeln. Dennoch sollte er sich bewußt sein, daß der Testumfang am Großrechner davon abhängt.

Da insbesondere die Altsysteme nicht vollständig auf den PC portiert werden können, erspart der Programmierer sich insbesondere bei Wartungsaufgaben auch weiterhin nicht das Arbeiten in der Großrechnerumgebung. PC-Programmierwerkzeuge können die vorhandene Entwicklungsumgebung nicht ersetzen, sie bilden eine zusätzliche. Durch die Erweiterung der Entwicklungslandschaft erhöht sich der technische wie organisatorische Aufwand für deren Pflege. Außerdem steigt der Ausbildungbedarf für die Programmierer.

Bei der Wartung von Software, die am PC entwickelt wurde, ist der Nutzen eher fraglich. Für Änderungen an reinen Großrechnerprogrammen sind nur wenige Umwandlungsläufe - meistens ein einziger - mit anschließendem Test erforderlich. Beim Einsatz eines PC-Werkzeugs wird der Änderungsvorgang schwerfälliger, da die Umwandlungs- und Testläufe zuerst auf dem PC und anschließend auf dem Großrechner durchzuführen sind.

Man sollte die Neigung der Programmierer, Modifizierungen direkt auf dem Großrechner durchzuführen, unterdrücken, will man das Problem der Inkonsistenz zwischen den Softwareversionen am PC und am Großrechner im Griff behalten. Manche Firmen verwenden daher die PC-Werkzeuge nur für die Erstentwicklung, nicht aber für die Wartung ihrer Software. Informationssysteme sind heute so komplex, daß sie nicht mehr von Einzelpersonen, sondern von Teams erstellt werden und daher aus einer Vielzahl von zusammenhängenden Bausteinen bestehen. In der Regel wird dadurch eine Vernetzung der PCs erforderlich. Dann nämlich können die Softwarebausteine im Server abgelegt werden, der zudem als Gateway zum Großrechner dient.

Die genannten Produkte sind netzfähig. Zur Verwaltung der Softwareversionen innerhalb des Netzes sowie zum Abgleich zwischen PC und Großrechner wird jedoch keine Unterstützung angeboten. Hier bleibt dem Anwender nur die Suche nach einer geeigneten verteilten Datenbank, die sich in die Entwicklungsumgebung integrieren läßt. Daran wird deutlich, daß sich die Hersteller eher als Compiler- denn als CASE-Produzenten sehen. Sie bieten isolierte Werkzeuge an, und kümmern sich noch zu wenig um die technischen und organisatorischen Aspekte der Werzeugintegration. Zu Problemen wie Teamarbeit, Projekt- und Configuration-Management werden keine Lösungen angeboten.

Um nachhaltig Nutzen aus der Entwicklung am PC ziehen zu können, sollte man erkennen, daß die Softwareentwicklung nur zu einem Teil von der individuellen Geschwindigkeit des Programmierers abhängt. Anwender, die mehr als nur kleine, abgeschlossene Projekte in dieser Umgebung durchführen, sollten vor dem Einsatz von PC-Programmierwerkzeugen ein umfassendes und integriertes Konzept erstellen.

Diese Integration erstreckt sich über mehrere Dimensionen:

- Einsatz in allen Projektphasen von der Analyse und dem Entwurf über die Realisierung bis zur Wartung

- Integration der Ergebnisse aller Phasen in einer Entwicklungsdatenbank mit Versionsführung

- Unterstützung von Teamarbeit und Projektmanagement

- Kombination mit leistungsfähigen Generatoren

Der Einsatz eines PC-Programmierwerkzeugs stellt somit keine kostengünstige Alternative zu CASE, sondern lediglich einen Baustein daraus dar.

Als Ursache für den hohen Aufwand für Wartungsaufgaben am Großrechner werden meist die unzureichende Werkzeugunterstützung und die zu langen Antwortzeiten genannt. Dabei wird häufig vergessen, daß die eigentlichen Gründe für den Wartungsaufwand im schlechten Softwaredesign, der fehlenden Dokumentation sowie in der Nichteinhaltung von strukturierter und innerhalb des Unternehmens standardisierter Programmierung zu suchen sind.

Es werden zu viele undurchdachte Schnellschüsse produziert. Die Programmierer tun sich häufig schwer, den Überblick über die Altprogramme, die meistens gar nicht von ihnen

geschrieben wurden, zu behalten. Außerdem mangelt es an der Abstimmung in den Entwicklungsteams und bei der Qualitätssicherung. Die Folge ist, daß Änderungsanforderungen zu einem Herumprobieren an vielen Stellen im Programm führen. Die daraus resultierende hohe Zahl der Umwandlungsläufe ist dann mit den langen Antwortzeiten zu multiplizieren.

Viele Altsysteme werden nicht wegen veränderten Anforderungen reorganisiert, sondern weil sie nicht mehr zu warten sind. Wenn nun dieses Problem nur mit komfortableren Editoren und schnelleren Compilern in Angriff genommen wird ist zu befürchten, daß die Anwendungssysteme nicht besser werden.

Auch zur Verbesserung der Softwarequalität reicht es also nicht, sich ein PC-Programmiertool zuzulegen. Man erhält höchstens schneller schlechte Programme.

Zusammenfassend bleibt festzustellen, daß es wichtig ist, die Frage nach der Programmentwicklung am PC oder am Großrechner nicht lokal zu lösen. Eine Effizienzsteigerung der Systementwicklung bedarf eines integrierten technischen und organisatorischen Konzepts. Darin bildet die Entwicklung der Programme am PC einen wichtigen Baustein, der die Werkzeuglandschaft am Großrechner nicht ersetzt, sondern ergänzt.

Man sollte sich jedoch im klaren sein, daß die Qualität der erstellten Software weiterhin in erster Linie vom guten Design und einer klaren Dokumentation, und damit von der Kreativität der Entwickler abhängt. Hierzu kann das Werkzeug Hilfestellung, aber niemals Ersatz bieten.