Die Betriebssystem-Umstellung von BS1000 auf BS2000 stellt wechselwillige Siemens-Anwender nicht selten vor erhebliche Manpower-Probleme. Dem DV-Personal bleibt da oft nichts anderes übrig, als viele Abende und einige Wochenenden im Rechenzentrum zu verbringen RZ-Leiter Gerhard Gontermann moniert, daß der Hersteller einfach zuviel Wissen voraussetze. Außerdem sei es Glückssache, in den Broschüren das Richtige zu finden. Auch Uwe Neveling hält mit seiner Kritik nicht hinterm Berg: "Die Herstellerneutralität ist durch die Einhaltung der KDCS-Schnittstelle allein nicht gewährleistet. Diese Forderung ist sicherlich ein Ziel, das mit der heutigen Herstellerphilosophie nicht in Einklang steht." Einig sind sich die Befragten darin, daß, "wenn alles vorüber ist", das Arbeiten mehr Spaß macht als vorher.

Uwe Neveling

Leiter der Abteilung Systementwicklung, Nova-Versicherungen, Hamburg

(Siemens 7.755 und 7.760, BS2000)

Auch die Nova-Versicherungen folgen gezwungenermaßen (wie wahrscheinlich viele andere Anwender auch) der geschäftspolitischen Entscheidung des Herstellers, volle BS1000-Anwendungen auf das Betriebssystem BS2000 umzustellen. Und das, obwohl wir mit dem Betriebssystem BS1000 und den bei uns eingesetzten Realtime-Software-Komponenten Asmus (Monitor) und Prisma (DB-System) zufrieden sind. Der Umstellungsaufwand ist beträchtlich und bindet einen großen Teil unserer Projektkapazität. Um den Aufwand einigermaßen erträglich zu gestalten, haben wir der eigentlichen Umstellung eine Konzeptionsphase vorangestellt. Unsere Vorgaben für das Konzeptionsteam Dialoganwendungen lauten:

1. Erreichen eines mindestens BS1000 analogen Zeitverhaltens

2. Gewährleistung eines hohen Maßes an Herstellerneutralität

3. Minimierung des Umstellungsaufwandes.

Dieses Konzept wurde mit qualifizierter Siemens-Unterstützung entwickelt und zunächst gemeinsam bezogen auf eine Realtime-Komponente erprobt.

Jede Dialoganwendung wurde und wird danach in drei BS2000-Prozesse aufgeteilt:

1. Die UTM-Anwendung (Für Asmus gibt es keine BS2000-Version, der Umstieg auf einen anderen Monitor war daher unumgänglich. Wir haben uns für UTM entschieden).

2. Die eigentlichen Nova-Anwendungsroutinen (Umstellung 1: 1).

3. Der Prisma-Verbindungsprozeß.

Die Verständigung der drei Prozesse findet über ereignissteuernde BS2000 Makros statt. Ferner greifen die Prozesse auf gemeinsame Bereiche zu. Die Aufwendungen für den UTM und den Prisma-Prozeß entstehen nur einmal, das heißt, die noch umzustellenden Dialoganwendungen nutzen in vollem Umfang das bereits Realisierte. Die künftigen Umstellungsaktivitäten beschränken sich auf die Anpassung der Anwendungsprozesse an das Betriebssystem BS2000.

Erste Erfahrungen mit einem umgestellten Aufgabenkomplex zeigen, daß nicht alle Anforderungen erfüllt wurden. Das Zeitverhalten ist als äußerst kritisch anzusehen. Zur Zeit stellen wir noch eine Verdoppelung im Vergleich zum BS1000 fest.

Das zur Verbesserung des Zeitverhaltens vorgeschlagene Verfahren des Mehrfachladens des UTM-Prozesses ist nur bedingt wirksam. Wir sind nicht sicher, ob es sich wie gewünscht realisieren läßt. Wir warten auf Vorschläge des Herstellers zur Beseitigung bestimmter Nachteile, die durch den Einsatz von BS2000 verursacht werden.

Auch die Herstellerneutralität ist durch die Einhaltung der KDCS-Schnittstelle allein nicht gewährleistet. Diese Forderung ist sicherlich ein Ziel, das mit der heutigen Herstellerphilosophie nicht im Einklang steht. Lediglich die Minimierung des Umstellungsaufwandes ist erfüllt worden. Wir sind gespannt, wie es weiter geht.

Remy Bogner

DV-Leiter, Allgemeine Elsässische Bankgesellschaft, Frankfurt

(Siemens 7.738, BS1000)

Ein Hardware-Wechsel hat für den Anwender in der Regel einen guten Grund. Meistens wird eine derartige Maßnahme durchgeführt, wenn eine gewisse Leistungsgrenze erreicht ist - sei es im Hauptspeicherbereich, bei der CPU-Geschwindigkeit, bei der Peripherie oder im Betriebssystem. In unserem Institut war vor ein paar Jahren die Maschine nicht mehr auf dem neuesten Stand. Der Hauptspeicher war zu klein und die CPU war für größeres Multiprogramming nicht ausreichend. Da wir die Absicht hatten, Online-Anwendungen zu realisieren und dies auf der alten Maschine nicht möglich war, wurde eine Umstellung erforderlich.

Der Hardware-Wechsel war gleichzeitig mit einem Rechenzentrum-Umzug von Köln nach Frankfurt verbunden. Auch der örtliche Wechsel brachte letztendlich Probleme. Wir hatten jetzt zwar einen größeren Maschinensaal sowie neue DFÜ-Standleitungen zu den Filialen, womit bessere Möglichkeiten zu Paralleltests gegeben waren. Nachteilig wirkte sich jedoch aus, daß die Programmierer und das Operator-Team während des Parallel-Laufes getrennt arbeiten mußten.

Probleme mit dem Hersteller gab es in dieser Phase nicht. Sämtliche Maschinen wurden rechtzeitig geliefert, die Siemens-Techniker hatten die Arbeiten schneller als geplant durchgeführt und die Kinderkrankheiten der neuen Anlage wurden schnell beseitigt. Auftretende Komplikationen wurden dabei mit zusätzlicher Hardware gelöst.

Das Betriebssystem stellten wir damals nicht um, wohl aber die Anwender-Software. Hier kann sich der Anwender leicht verrechnen, denn eine 1 :1-Umstellung ist nicht immer der richtige Weg. Auch kann es sich als unsinnig erweisen, dieselben Programme in gleicher Art auf der großen Anlage laufen zu lassen. Damals gingen wir von der 4004-127 mit 192 K auf eine 7.738 mit einem halben Megabyte. Als wir feststellten, daß es Kapazitätsprobleme gab, mußten wir kurzfristig auf ein Megabyte erweitern. Eine Umstellung zieht auf jeden Fall mehr Aufwand nach sich, als vorher geplant. Erst nach einigen Jahren treten jedoch in einem System Schwächen auf, deren Behebung im Normalfall während der täglichen Arbeitszeit nicht durchgeführt werden kann Wichtig und gleichzeitig Voraussetzung für einen guten Hardware-Wechsel ist die klare Analyse und Planung, wobei die Software-Änderung mit der Hardwarelieferung synchronisiert und ein Verrechnungsfaktor von 1,5 bis 2 berücksichtigt werden sollte. Für das geplante System ist eine Änderung immer eine erforderliche Gesundheitskur. Neues Blut und mehr Luft im Speicher wirkt sich später immer positiv aus.

Dietrich Bergmann

Leiter Org./DV, Heinze GmbH, Celle (Siemens 7.541, BS2000)

In unserem Unternehmen gibt es seit 15 Jahren Datenverarbeitung. 1978 wurde der Siemens-Rechner 7.738 installiert. Im Oktober 1979 beschlossen wir, das System 7.541 mit 2 Megabyte und Festplattenspeichern zu bestellen. Das bedeutete gleichzeitig den Übergang auf das Dialogbetriebssystem BS2000. Wir entschieden uns, das Datenbanksystem Sesam beizubehalten, das Transdata-Spektrum auszubauen und den neuen Anforderungen durch die Datensichtstationen 9750 anzupassen. Um den Plantermin April 1981 einzuhalten, begannen wir im Oktober 1980 mit der Umstellung. Vorher waren unsere Mitarbeiter entsprechend geschult worden. Zerlegt man die Umstellung in Phasen, so ergibt sieh folgende Gliederung:

1. Erfahrungen mit dem BS2000 und Dienstprogrammen sammeln.

2. Umstellung der Unterprogramme sowie eines ersten Programmkomplexes in BS2000.

3. Anpassung der Batchprogramme und Umstellung, Beginn der Produktion auf der 7.738 im BS2000.

In der ersten Phase wurden nun Programme zur Übung erstellt, um das Arbeiten mit dem neuen PL/1-Compiler sowie mit Assembler, Sort, Edor (interaktives Datenbearbeitungsprogramm), UTM (Universeller Transaktionsmonitor) und PDN (Betriebssystem für Transdata-Vorrechner) kennenzulernen.

Für einen Dialogkomplex wurde auf der 7.738 unter dem BS1000 eine Verfügbarkeit benötigt, die es dem Umstellungsteam erlaubte, lediglich in einer Blockzeit von vier Stunden täglich im BS2000 zu arbeiten. Um eine längere Blockzeit zu ermöglichen, wurde dieser Programmkomplex als erstes ins BS2000 umgestellt.

Durch Erstellung eines UTM-Teilprogrammes konnte die Blockzeit im BS2000 mit Beginn der dritten Phase auf sieben Stunden täglich erhöht werden.

In der dritten Phase konnten die Batch-Programme (rund 600), die zu 95 Prozent in PL/1 codiert sind, mit dem zugehörigen Job-Control nach Abschluß der Umstellarbeiten und Funktionstest für die echte Produktion freigegeben werden.

Für Programme, deren Ergebnisse nur mit großem Aufwand überprüfbar waren, zum Beispiel bei Änderungen in der DB und Statistik-Auswertungen, wurden zum Vergleich Parallelläufe durchgeführt. Die übrigen Programme wurden direkt in das BS2000 übernommen.

An das DV-Personal, insbesondere Programmierer, Arbeitsvorbereiter und Operateure, wurden während dieser Zeit erhöhte Anforderungen gestellt. Eine Unterstützung durch Siemens wurde nur sporadisch in Anspruch genommen.

Reinhard Rauth,

DV-Leiter, Heinz Kettler GmbH, Ense-Parsit (Siemens 7.5s1, BS2000)

Die Umstellung von BS1000 auf BS2000 wurde bei uns auf der vorhandenen 4004-220 durchgeführt. Erst nach den Produktionsläufen in BS2000 wurde die 7.531 installiert. Als reiner Batch-Anwender (ohne Bildschirme) standen 235 Jobs mit rund 300 Programmen zur Umstellung an. Vor dem Beginn der Umstellungsarbeiten wurde eine Bereinigung der vorhandenen Programme im Hinblick auf BS2000 und Jobs durchgeführt. Ziel dieser Bereinigung war die Konzentration auf zwei Programmiersprachen (Cobol und RPG), bei Verminderung der seit 1973 aufgebauten Jobs. Es wurden Assemblerprogramme in Cobol umgeschrieben und beschlossen, Neuprogrammierungen nur noch in Cobol durchzuführen. Nach Abschluß dieser Maßnahmen wurde als Umstellungskursus "BS2000 Anwendung - Umschulung" besucht.

Die Umstellung der Programme erfolgte ohne Schwierigkeiten. Noch 1979 steckten die Konvertierungshilfen für Jobs in den Anfängen. Ein Großteil wurde manuell ins BS2000 übersetzt. Als riesiger Nachteil erwies sich dabei die Tatsache, daß keine Bildschirme vorhanden waren.

Auszug aus einem Projektbericht von Siemens: "Die Korrektur der Jobs mit EDV über Lochkarten-Eingabe ist nicht sinnvoll, da sie umständlich und zeitaufwendig ist. Die Job-Korrektur über Bildschirm würde eine Zeitersparnis von 80 Prozent bringen."

Die Produktionsdaten wurden mittels Banddateien übernommen, auf Parallel-Läufe verzichteten wir.

Während der Umstellungsphase lief der RZ-Betrieb weiter. Die Konvertierungen und Tests wurden nach Schichtende durchgeführt. Der Zeitaufwand für die Umstellung betrug etwa ein Mannjahr.

Innerhalb der abgeschlossenen Verträge wurde von Siemens zusätzliche Manpower zur Verfügung gestellt. Wichtiger als externe Hilfe war jedoch die unbürokratische Beratungsphase vor Installation der BS2000 und die Zusammenarbeit während der Umstellung mit den Systemberatern des Herstellers, von der beide Partner profitieren.

Die reine Umstellung 4004-220 8S1000: BS2000 brachte für uns keine Veränderung. Der Mangel an Bildschirmen ließ den Änderungsaufwand für Programme und Jobs gegenüber BS1000 generell steigen. Erst die Installation der 7.531 ermöglichte uns, die Vorteile des BS2000 voll zu nutzen. So konnte durch "Programmieren im Dialog" die Produktivität der Programmierer um rund siebzig Prozent gesteigert werden.

Gerhard Gontermann

Leiter des Rechenzentrums Gontermann GmbH, Siegen (Siemens 7.730, BS2000)

Die Umstellung von BS1000 auf BS2000 kann sich als relativ problemlos erweisen, wenn der Anwender nicht bereits im BS1000 Dialog-Anwendungen hat. Der Zeitpunkt des Systemwechsels ist eine Personalfrage. Es müssen eine Menge Vorarbeiten im BS1000 gemacht werden, wie Programme abziehen als Source-Programme, oder Dateien sichern. Ideal wäre es, diese Arbeiten außerhalb der normalen Zeit durchzuführen, weil dann der DV-Alltagskram wegfällt. Die Mitarbeiter müßten gebeten werden, die Umstellung am Abend oder am Wochenende durchzuziehen. Voraussetzung für ein optimales Gelingen des Systemwechsels ist die Schulung der Mitarbeiter. Das Problem: Kaum ein Benutzer kann hierfür zuviel Zeit und Geld opfern. Besonders wichtig für die Mitarbeiter sind bestimmte Grundkenntnisse der Editor-Funktionen. Es würde aber genügen, wenn lediglich eine Person aus der DV-Crew einen Editor-Kurs besucht und das Wissen an die Kollegen weitergibt.

Der nächste Schritt, die Systemgenerierung, sollte rechtzeitig mit dem Hersteller geklärt werden. Grund: Mit BS2000 muß ein Betriebssystem generiert werden, auf das man für den Test und die Umstellung zurückgreifen kann. Wir haben festgestellt, daß Siemens während der Umstellung des mit Fragen und Begriffen konfrontiert hat, mit denen ein "BS1000-Mann" nicht viel anfangen kann. Hier müßte Siemens wesentlich mehr Vorarbeit leisten und nicht zuviel voraussetzen.

Der eigentliche Prozeß, von BS1000 in BS2000 zu wechseln, dauert vielleicht eine Viertelstunde. Die Umstellung der Programme ist mit Cobol fast problemlos. Bei Assembler muß man sich indessen die Dateien sehr genau anschauen. Hier gibt es andere Regeln, die jedoch in den Handbüchern nachgelesen werden können. Mit RPG sind Veränderungen notwendig, vor allem in den Datei-Definitionen und bei Schalterbehandlungen. Großer Wert sollte darauf gelegt werden, die Benennung von Dateien und Programmen vor der Umstellung vorzunehmen, weil es im BS2000 die Möglichkeit gibt, komplett durch eine Vergabe (beispielsweise eines Punktes) alle Dateien aufzurufen oder kenntlich zu machen. Die Fehlerhinweise und die Beschreibung der Fehler ist für einen DV-User, der aus dem BS1000 kommt, eine wahre Katastrophe. Es ist reine Glückssache, wenn man in den Broschüren das findet, was gerade benötigt wird. Dies hat Siemens nicht gut gelöst.

Nach einiger Zeit kennt man allerdings die Fehler, und die Schwierigkeiten bauen sich langsam ab. Wir haben, um eine Größenordnung zu nennen etwa 700 Programme für etwa 40 Arbeitsgebiete in fünf Monaten umgestellt. Die Programmierung im BS2000 ist ein Gedicht. Es gilt, die Programmierer in ihrer Arbeit eher zu stoppen als anzufeuern.