Immer mehr Großrechner-Anwendungen entstehen am PC. Kein Wunder denn für Cobol-Programmierung in VSAM oder ClCS-Umgebung werden PC-Entwicklungswerkzeuge angeboten, wie sie am Großrechner nur mit großem - auch finanziellem - Aufwand zu realisieren sind. Für andere Programmiersprachen wie Fortran sieht die Lage weniger rosig aus. Cobol-Spezialisten jedoch können nicht genug Lob für die Entwicklung von Großrechner-Software am PC finden - aus den verschiedensten Gründen. So hofft der PC-Koordinator der Elekluft auf eine Beschleunigung der Software-Entwicklung durch Unabhängigkeit von den Warte- und Rechnerzeiten am Mainframe. Und während die riesigen Datenmengen der Kassenärztlichen Bundesvereinigung den PC auf die Funktion eines reinen Entwicklungstools eingrenzen, will die Hamburger Baugenossenschaft ihren Großrechner langfristig durch einen Abteilungsrechner ersetzen. Walter Sedat, DV-Leiter der Transnautik GmbH, schließlich überlegt, wo PCs und wo Großrechner optimal eingesetzt werden können. Ausschlaggebend ist seiner Ansicht nach die Art der Anwendung.
Walter Sedat, DV-Leiter bei der Übersee-Schiffsagentur Transnautic GmbH & Co KG., Hamburg
Als Schiffsmakler besorgen wir für unsere Reeder die Tonnage und betreuen deren Schiffe im Hafen. Die EDV-Abteilung erledigt dafür die Verwaltungstätigkeiten wie Lohn und Gehalt. Ein großes Gebiet ist auch die Logistik unserer Übersee-Agentur für die weltweite Containerkontrolle.
Vor drei Jahren zeichnete sich die Überlastung unseres IBM-4381-Rechners ab. Da traf es sich gut, daß ich eine Anonce über Entwicklung am PC sah.
Neben dem konkreten Anlaß wollte ich die Programmierung unabhängig vom Großrechner machen. Ich hatte schon darüber nachgedacht, ob man Programmierung nicht dezentralisieren kann. Das hätte zur Folge, daß die Entwickler unabhängig vom Arbeitsplatz Mainframe - zu Hause etwa - arbeiten könnten. Nichtiger jedoch waren uns die Einschränkungen durch die Einbindung in das DV-System .
Wenn viel getestet wird, stürzt ein CICS-Job schon mal ab. Dann ist es von Vorteil, wenn der Programmierer in einer Umgebung, die ihm alleine gehört, wie am PC, entwickeln und ohne auf Rechnerzeiten zu warten neu testen kann. Außerdem geht des Umwandeln der Programme bedeutend schneller.
Für 10 000 Mark ist auf dem PC-Markt schon ein ausgesprochen leistungsfähiger Rechner zu bekommen. Auch die PC-Netze sind günstiger als entsprechende Produkte für Großrechner. Die CPU-Leistung auf PC ist ebenfalls bedeutend billiger als auf dem Großrechner.
Wir entwickeln alle unsere Cobol-Anwendungsprogramme in ClCS-Umgebung am PC. Besonders die Programmierer sind von der Arbeit am PC begeistert. Immer wieder betonen sie die Leistung des PC-Debuggers. Damit können sie bei jedem Command anhalten und sich alle Feldinhalte anschauen.
Die angenehmen Testmöglichkeiten bringen möglicherweise die Gefahr mit sich, daß Programmierer ihre Vorüberlegungen abkürzen und ihre Codes einfach einhacken. Aber die Frage heißt doch: Steigt die Produktivität? - Und bei uns tut sie das.
Insgesamt führt die Entwicklung von Großrechner-Software am PC zu einer Produktivitätssteigerung. Das Maskenerstellen am PC geht wesentlich schneller als auf dem Host, der Zentralrechner wird entlastet, und die Entwicklungszeiten verkürzen sich.
Bei uns wird zwar nur Software am PC erstellt, die dann auf einem Großrechner abläuft. Ich glaube aber, daß man langfristig dezentralisieren sollte. Sicher müßte es das Ziel sein, die Sachbearbeiter unabhängiger zu machen - Intelligenz vor Ort zu bringen.
Aus meiner Sicht gibt es viele Aufgaben, die am PC bedeutend leichter zu erledigen sind als am Großrechner. Ich glaube jedoch nicht, daß es viele Sachbearbeiter gibt, die unabhängig von Unterstützung durch die zentrale DV arbeiten können.
Anwendungen, auf die eine große Anzahl von Anwendern zugreifen müssen, werden wohl auch in Zukunft durch Großrechner abgedeckt werden. Immer dort jedoch, wo es um einen engen Benutzerkreis geht, empfiehlt sich der PC. Die Frage PC oder Großrechner stellt sich also nicht. Wichtig ist einzig die Anwendung.
Die PCs sind derzeit im Vormarsch, weil der starke Konkurrenzdruck der vielen Firmen die Innovation vorantreibt. Bei den Großrechnern jedoch - wer konkurriert da schon?
Wir hatten ganz spezifische Probleme: Eines war, daß wir die gleichen Programme inklusive Oberfläche in drei völlig verschiedenen Umgebungen einsetzen wollten. Als gesetzlicher Unfallversicherung der Bau- und Berufsgenossenschaft obliegt uns die arbeitsmedizinische Betreuung der Versicherten.
In der Hamburger Hauptverwaltung sind alle nötigen Daten in einer IBM-4661 gespeichert. Unser Medizinisches Zentrum in Neumünster arbeitet jedoch auschließlich mit PCs, ebenso wie unser Untersuchungsmobil.
Das zweite Problem war unser begrenztes Budget. Deshalb haben wir uns Anfang 1987 auf die Suche nach günstigen Tools gemacht, die sowohl auf dem PC als auch auf dem Großrechner laufen. Damals bin ich von Kollegen als Fantast bezeichnet worden. Doch noch im selben Jahr sind wir auf der Hannover-Messe fündig geworden.
Beeinflußt wurde unsere Entscheidung, am PC zu entwikkeln, auch durch die Auslastung des zentralen Rechners. In den vorangegangenen vier Jahren hatten wir zwei Rechnergenerationen ausgewechselt. Die IBM 370/115 wurde durch die 4331 ersetzt und diese wiederum durch die 4361. Wir konnten uns ausrechnen, daß bald die Entscheidung für das nächsthöhere Modell angestanden wäre. Weil das zu teuer war, haben wir uns entschlossen, den Host zu entlasten und die Entwicklungstests auszulagern.
Seit 1987 entwickeln, ändern und warten wir alle Programme auf dem PC und ausschließlich in Cobol. Dabei werden die Programme der zentralen DV immer weniger. Dort laufen vor allem noch die "alten Schinken", die nicht in Cobol geschrieben sind.
Inzwischen erproben wir die Vernetzung von PCs und entwickeln dafür netzwerkfähige Programme. Langfristig wollen wir den Host soweit entlasten, daß wir ihn bei Überlastung oder zu hohen Wartungskosten durch einen Abteilungsrechner ablösen können.
Die Entwicklung am PC bringt uns noch einen weiteren großen Vorteil. Wir haben zwar umfangreiche VSAM-Dateien, aber keine Datenbank. Doch unser Entwicklungssystem ist mit einer Schnittstelle ausgerüstet, über die wir auf die PC-Version des relationalen Datenbanksystems Oracle zugreifen können.
Auf diese Weise kommen wir für sehr wenig Geld zu einer Datenbank, die wir uns für den Großrechner früher nicht leisten konnten und uns heute nicht mehr leisten wollen.
Hinzu kommen die typischen PC-Vorteile. Die Programmierer freuen sich über wesentlich kürzere Antwortzeiten. Auch die Dokumentation läßt sich mit entsprechenden PC-Tools schneller erstellen. Auf dem Host, so sagen meine Programmierer, haben sie einen ähnlich komfortablen Debugger nicht gefunden.
Einschränkend muß ich noch auf ein Cobol-Problem hinweisen. Wir arbeiten auf dem Host noch mit dem Cobol-74-Compiler, weil der neuere Compiler nach dem ANSI-85-Standard nicht unter VSE/SP läuft. Das ist zwar eigentlich ein Problem von IBM, führt aber bei uns gelegentlich zu Fehlern, denn auf dem PC fahren wir eine GLol85-Version.
Dank unserer Entscheidung von 1987 brauchten wir seit mehr als fünf Jahren unseren DV-Haushalt nicht mehr zu erhöhen. Damals arbeiteten wir noch voll in der Großrechnerwelt, doch heute wissen wir, daß es nicht viel kostet, auf PCs umzusteigen. Wir werden wohl in Zukunft den Etat sogar runterfahren.
Bei der Einführung der PCs gab es die üblichen Widerstände bei Leuten die mit der Großrechner-Entwicklung gewachsen sind. Heute ist es jedoch so, daß sich unsere Programmierer, wenn man sie vor die Wahl stellt, wo sie entwickeln wollen, eindeutig für den PC entscheiden.
Früher war ich mit meiner positiven Einstellung zu PCs ziemlich allein. Doch unser Weg hat sich als richtig herausgestellt. Wenn ich damals bei der Einführung noch unsicher war, so weiß ich heute, daß wir auf diesem erfolgrei-chem Weg weitergehen können.
Peter Becker, Mitarbeiter des Rechenzentrums und Projektleiter bei der
Kassenärztlichen Bundesvereinigung In Köln
Die Entwicklungsumgebung, mit der wir schon seit Jahren am Großrechner arbeiten, hat unsere sowieso schon stark geforderte Unisys 2200 zusätzlich belastet. Wenn fünf oder sechs Mitarbeiter gleichzeitig Programme entwickelten, liefen die Editoren langsam und der Durchsatz war gering.
Als dann die selbe Software für den PC angeboten wurde haben wir rasch die Gelegenheit zur Verlegung unserer Entwicklungstätigkeit genutzt. Der Hauptgrund dafür war also bei uns die Systemüberlastung. Doch das neue Entwicklungsverfahren verlangte auch eine neue Infrastruktur. Nicht nur mußte das Programm zum Laufen gebracht sondern auch die Verbindung zum Host und eine funktionierende Datenübertragung mußten realisiert werden. Außerdem brauchten die Mitarbeiter Schulung für den Umgang mit dem PC.
Da jedoch das Produkt, mit dem wir heute am PC arbeiten, in der Handhabung der Großrechner-Software gleicht, hat sich für uns - abgesehen von den Vorteilen - wenig geändert.
Die Fileschnittstellen sind unabhängig von der Datenhaltung. Der programmierer sieht also nicht, ob es sich um eine Datenbank oder um VSAM-Dateien handelt. Die VSAM-Anwendungen testen wir am PC in dem Code, den unser Programm erzeugt, übertragen den Code auf die Mainframe, generieren den Code für die Zielmaschine und kompilieren ihn dann.
Ich kann mir nicht vorstellen, daß wir Anwendungen vom Großrechner auf den PC herunterholen und dort laufen lassen, denn wir haben riesige Datenmengen von den Kassenärztlichen Vereinigungen statistisch aufzubereiten. Solche Datenmengen schafft bisher kein PC.
Der PC bleibt für uns daher ein Tool, auf dem wir für den Großrechner entwickeln und wo wir die Entwicklungen mit kleineren Datenmengen auch austesten. Dabei sind die Vorteile nicht zu übersehen.
Erstens sind wir unabhängig vom Zentralrechner, zweitens bietet unsere PC-Oberfläche wesentlich mehr Bedienungskomfort und drittens haben sich die Entwicklungszeiten entscheidend verkürzt. Ein Zeitvergleich, bei dem die gleiche Anwendung am unbelasteten Host und am PC generiert wurde, hat ergeben, daß beide Systeme etwa gleich gut abgeschneiden. Normalerweise ist der Host jedoch voll ausgelastet und braucht dann etwa die doppelte Zeit.
Leider sind jedoch bei unserem Entwicklungsprogramm die Testhilfen am PC noch nicht so, wie wir uns das wünschen. Meine von Haus aus positive Einstellung zum PC hat sich durch den Einsatz als Entwicklungstool für den Host nur bestätigt. Das gilt auch für meine Mitarbeiter. Zu sehen, wie schnell die Arbeit am PC vorangeht, hat sie gleich bei der ersten Vorführung überzeugt. Sie waren regelrecht wild darauf vom Host runterzukommen, um am PC zu programmieren.
Hans-Joachim Schmitt, PC-Koordinator bei der Elekluft GmbH in Bonn
Unser Unternehmen befaßt sich mit Wartung und Service-Leistungen vor allem für Behörden. Bisher arbeitet die zentrale DV-Abteilung mit 25 Mitarbeitern an einem IBM-4381-Rechner. Im Moment sind wir jedoch dabei, die Programmentwicklung auf PCs zu verlagern.
Bei der Umstellung auf PCs geht es uns ausschließlich um die Anwendungsprogrammierung im kaufmännischen Bereich. Reine Rechenzentrumssoftware wird wohl auch künftig von unserer Systemgruppe am Großrechner entwickelt.
Wir wollen so weit kommen, unsere gesamten Cobol-Projekte für den Großrechner am PC zu entwickeln. Dafür hat Elekluft eine Entwicklungssoftware gekauft, mit der sich die Pre-Monitor-Umgebung CICS am PC abbilden läßt. Unsere Tests haben gezeigt, daß Großrechner-Software auf dem PC läuft. Und wir sind - auch wegen der Erfahrung anderer Unternehmen - überzeugt, daß umgekehrt auch am PC entwickelte CICS-Anwendungen auf dem Mainframe funktionieren. Im Normalfall braucht man sie dafür nur zu kompilieren.
Bei neuen Systemen müssen natürlich die entsprechenden Job-Control-Funktionen zur Verfügung gestellt und auch noch einige Tabelleneinträge eingefügt werden, die CICS braucht.
Wir sind darauf gekommen, Mainframe-Software am PC zu Entwickeln, weil unsere Anlage rund um die Uhr stark ausgelastet ist. Entsprechend selten können unsere Entwickler darauf zugreifen.
Abgesehen von der Entlastung des Hosts soll uns der PC vom Warten auf Rechnerzeiten unabhängig machen kürzere Antwortfristen als die bisher vom Mainframe gewohnten 15 bis 20 Minuten ermöglichen.
In Zukunft sollen Projekte am PC durchgezogen werden. Dabei sind wir uns jedoch noch nicht ganz einig, ob das Management auf einem PC-Server stattfinden soll, oder ob die Source-Codes auf dem Großrechner bleiben und Informationen im Bedarfsfall auf den PC geholt werden. Auch ist noch nicht ganz klar, auf welche Weise Datensicherheit und Source-Code-Verwaltung zu gewährleisten sind.
Neben dem Projekt-Management spielen auch die Testmöglichkeiten eine Rolle. Ich frage mich, ob man bei großen Datenmengen - die der PC nicht mehr verarbeiten kann - Untermengen von Testdaten bilden kann, die einen Probelauf am PC zulassen. Nur wenn das funktioniert, läßt sich die Host-Unabhängigkeit der PCs für Testläufe nützen.
Am Großrechner ist die Eingrenzung von Fehlern bei Batch-Läufen manchmal sehr umständlich und schwierig. Mit einem PC-Debugger stelle ich mir das viel einfacher vor. Der Aufwand, um gleichwertige Tools am Großrechner zu erstellen und zu benutzen wäre meiner Meinung nach ungleich größer. Außerdem sind entsprechende Tools dort wesentlich teurer.
Kostenersparnisse entstehen zudem bei den Entwicklungszeiten. Sprich, die Personalkosten sinken im Verhältnis zum Ergebnis. Allein von der Vereinfachung der Testmöglichkeiten verspreche ich mir eine Zeitersparnis von 20 bis 30 Prozent. Außerdem lohnt sich die Verwendung der PCs schon wegen ihrer Flexibilität. Wir nutzen sie zum Beispiel auch für Dokumentation und Textverarbeitung.
Trotzdem erfordert die Umstellung auf Entwicklung am PC am Anfang einen größeren Aufwand - etwa für die Erstellung der Anwendungsumgebungen.
Den Vorwurf von mangelnder Teamunterstützung durch den PC halte ich jedoch für unzutreffend. Teamwork ist mehr ein organisatorisches als ein PC-Problem. Ich gebe natürlich zu, daß das Projektmanagement einfacher wird, wenn die Rechner vernetzt sind.
Ich sehe in der Verwendung von PCs für Großrechner-Entwicklung keine Grundsatzfragen. Für mich ist der PC ledigleich ein Tool, das einfacher zu handhaben ist als jeder Großrechner.