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.

23.10.1981

Verunsicherte Univac-Anwender: Wie lange lebt VS9?

Daß Univacs Betriebssystemwelt zweigeteilt ist, macht den Anwendern zu schaffen. Außerdem ist ihnen - wie den Kunden anderer Hersteller - klar, daß es töricht wäre, vom "großen Zampano" die Lösung aller Probleme zu erwarten. Joachim Strahlendorf prangert Univacs Firmenpolitik an, die Kunden über künftige Hardware- und Software-Entwicklungen zu sehr im dunkeln zu lassen. Kopfzerbrechen bereitet dem DV-Leiter, daß sich das Betriebssystem VS/9 keines langen Lebens mehr erfreuen wird, wie er erkannt haben will. Friedhelm Schulte hat Kummer mit der Fremdsoftware "Paisy". Obwohl es inzwischen eine auf Univac-Anlagen lauffähige Version gibt, wartet er heute noch auf das entsprechende Umsetzungspaket. Er tröstet sich mit den Worten des Mainframers, man sei "sehr bemüht".

Günter Ebersberger, DV-Leiter, Elektrizitätswerk Rheinhessen AG, Worms (Univac 90/30-9300, OS/3)

Es wäre für jeden Anwender töricht, sich alleine auf die Unterstützung des Herstellers zu verlassen und zu erwarten, daß er alle Probleme zum Zeitpunkt der Umstellung löst. Die Unterstützungsleistungen des Herstellers sollten nach Möglichkeit bereits beim Abschluß der Hardware-Verträge exakt formuliert und schriftlich vereinbart werden. Es ist wichtig zu ermitteln, wie hoch der Organisations-Programmierungsaufwand bis zum Installationstermin sein wird. Die einzelnen Arbeiten müssen so rechtzeitig in Angriff genommen werden können, daß sie zum vorgegebenen Termin beendet sind. Da normalerweise die eigene Kapazität an Programmierern für den erhöhten Arbeitsanfall bei einer Umstellung nicht ausreicht, ist man gezwungen, entsprechend viel Zeit einzuplanen oder man muß sich rechtzeitig um eine geeignete Unterstützung durch ein Software-Haus oder den Hersteller bemühen.

Entscheidend ist auch festzustellen, welche Testmöglichkeiten zur Verfügung stehen. Die geänderten oder gar neuen Programme können vor Installation der neuen Anlage ausgetestet werden. Deshalb die Frage an den Hersteller, wo und zu welchen Bedingungen er eine geeignete Anlage zur Verfügung stellen kann, möglicherweise im Rechenzentrum des Herstellers oder bei einem anderen Kunden in der nähe??? Umgebung. Wir selbst haben damit gute Erfahrungen gemacht. Es ist für den Programmierer angenehmer, bei einem befreundeten Anwender in Ruhe an dessen Anlage arbeiten zu können, selbst wenn er dafür die Abend- oder Nachtstunden nutzen muß, als bei der Hektik in einem großen Rechenzentrum. Wir waren ebenfalls bereit, unsere Anlage nach der Installation anderen Unternehmen zu Testzwecken zur Verfügung zu stellen.

In diesem Zusammenhang ist es ratsam, auch einmal die Frage nach Ausweichmöglichkeiten für die Praxis in der Zukunft zu stellen. Es kann immer von Nutzen sein, wenn man weiß, wo eine gleiche Anlage steht und man zu den verantwortlichen Leuten dieses Unternehmens ein gutes Verhältnis hat.

An den Hersteller ist auch die Frage zu richten, welche Umstellungshilfen oder Unterstützungen er bietet. Dabei geht es einmal und die programmtechnischen Umstellungshilfen wie Emulatoren, Simulatoren, Umwandlungsprogramme und zum anderen um die personelle Unterstützung. Außer der vertraglichen Festlegung über Ausmaß und Dauer der vereinbarten Unterstützung ist es angebracht, sich auch über den in Frage kommenden Personenkreis zu unterhalten. Man sollte sich dabei die Hilfe von Leuten mit der nötigen Qualifikation zusichern lassen, die nach Möglichkeit schon mit der speziellen Aufgabenstellung des Anwenders vertraut sind.

Die Vorbereitung und Schulung der Mitarbeiter ist besonders wichtig und sollte einen breiten Raum einnehmen. Neben den Lehrgängen des Herstellers, die ja vorwiegend von den Programmierern besucht werden, müssen auch die übrigen Mitarbeiter durch Gespräche und Diskussionen vorbereitet werden. Auch an Kleinigkeiten ist dabei zu denken.

So haben wir beispielsweise durch die Vermittlung von Univac einen Operator acht Tage zu einem anderen Univac-Kunden geschickt, der bereits eine neue Anlage hatte so daß unser Mitarbeiter die Möglichkeit bekam, sich in das Handling der neuen Anlage einzuarbeiten.

Von einer gleichzeitigen Umstellung der Hardware, des Betriebssystems und der Anwendungssoftware ist dringend abzuraten, wenn nicht wirklich zwingende Gründe dafür vorliegen. Im übrigen kann man davon ausgehen daß eine Systemumstellung so gut über die Bühne geht, wie sie vorbereitet wurde.

Peter Gruse, DV-Leiter, Edeka-Handelsgesellschaft mbH, Berlin (Univac, 90/30, OS/3)

Unser Unternehmen ist seit 1958 Anwender von Univac-Anlagen. Nicht weil wir mit Univac versippt oder verschwägert sind, sondern aufgrund des Preis-/Leistungsverhältnisses und der positiven Erfahrung mit System und Technik in Berlin. Bei unserer jetzigen Anlage handelt es sich um eine Univac 90/30, 512 KB, 17 Bildschirme. Bisher wurden drei Anlagenumstellungen mit gleichzeitigem Neuaufbau der Programm-Organisation und interner Reorganisation durchgeführt. Da weder ein Parallellauf möglich war, noch ein Liefertag ausfallen konnte, blieb eine maximale Zeit für die Umstellung von 48 Stunden. Der tatsächliche Zeitaufwand betrug nur 19 Stunden. Die Umstellung erfolgte in folgenden Schritten: Rechtzeitige Absprache mit allen Betriebsteilen über das neue Anlagensystem, Unterbreitung und Absegnung der organisatorischen Änderungen.

Frühzeitiger Aufbau des neuen Organisationsablaufes und Verteilung der Programmpakete im richtigen Zeitplan. Termineinhaltung bei der Erstellung der Programmvorgaben. Es ist wichtig, daß es keine organisatorischen Änderungen nach dem Stichtag gibt. Genaueste Erstellung von Testdaten, die möglichst durch den gesamten Programmablauf mit Fehlerprotokollen und Werten verfolgt werden können. Die Ausgabe des einen Programmpaketes sollte die Eingabe des nächsten sein.

Entscheidend ist die laufende Überwachung der Termine, was in der letzten Phase täglich und stündlich geschehen muß. Anfangs verschenkte Zeit kann nie mehr eingeholt werden. Der Installationstermin muß genau und verbindlich festgelegt werden. Dies gilt nicht nur für den Hersteller, sondern auch für den Elektriker, die Klima-Firma bis hin zur Reinemachefrau, die den letzten Schrott der alten Anlage herausfegen soll. Es ist empfehlenswert, drei Wochen vorher fertig zu sein und eine Vorinstallation im Werk des Herstellers vertraglich zu vereinbaren, um die wichtigsten Programme mit Echtdaten auf der "eigenen" Anlage im Beisein von Systemberatern und Technikern kurz durchtesten zu können. Wenn keine Probleme aufgetreten sind, sollte die Anlage so rechtzeitig geliefert werden, daß sie ein paar Tage vor der Uminstallation schon im Unternehmen steht.

Der Anwender sollte nie vergessen: Installationstermine sind interne Daten. Nach draußen genügt eine Erfolgsmeldung hinterher. Trotz aller Vorbereitung ist es besser, sich vorsorglich bei einem Benutzer der gleichen Anlage einen Ausweichtermin freizuhalten. Bisher war wegen des Aufwands in der Vorbereitung ein Ausweichen noch nicht erforderlich, aber die nächste Umstellung kommt bestimmt, und wir wissen auch mit wem und warum.

Joachim Strahlendorf, DV-Leiter, Itzehoer Versicherungsverein, Itzehoe, (Univac 90/80, VS/9)

Wir haben 1980 von OS/4 auf VS/9 und von einer 90/70 auf eine 90/80 umgestellt. Die Voraussetzungen waren gut, da wir zwei Anlagen während der Umstellungszeit parallel betreiben konnten. Einmal die alte 90/70, auf der auch die normale Produktion gefahren wurde und die 90/80, die in der ersten Zeit nur als Test- und Anpassungsmaschine diente. Nach Abschluß der Testphase fungierte sie als Produktionsmaschine und das alte System wurde abgebaut.

Die Hauptprobleme lagen in der Schulung und Einarbeitung der Mitarbeiter. Das galt sowohl für das Rechenzentrumspersonal als auch für Systemanalyse und Programmierung. Die Umstellung der Programme läßt sich in drei Programmiersprachenprogramme, also Assembler, RPG und Cobol unterteilen. Bei Cobol gab es relativ wenig Probleme, bei RPG und Assembler und bei den TP-Programmen die meisten, weil wir einen total neuen TP-Monitor einzusetzen hatten. Das heißt, die gesamte alte TP-Software mußte ersatzlos gestrichen und total neu konzipiert werden.

Univac unterstützte uns bei der Umstellung. Zusätzlich schalteten wir noch ein Softwarehaus ein. Der Grund hierfür war unsere relativ dünne Personaldecke. Es wäre besser, ohne externes Personal auszukommen, weil eine Umstellung eine gute Übung für die eigenen Mitarbeiter ist.

Es traten noch einige Randprobleme auf, die durch den Parallel-Lauf beider Anlagen entstanden. Die Klimaanlage war zum Beispiel nur auf einen Rechner ausgerichtet.

Seit der Umstellung arbeiten wir von den Hardware-Kosten her mit einem weitaus geringeren Budget als vorher. Kopf zerbrechen bereitet uns allerdings der Gedanke, daß das Betriebssystem VS/9 auch keine lange Lebensdauer mehr haben wird. - Ein Faktum, das uns bei der damaligen Auswahl des Rechners oder des Betriebssystem nicht bekannt war. Das heißt, wir müssen uns jetzt schon gedanklich mit einer neuen Umstellung auf OS/1100, oder was auch immer, beschäftigen. Das ist natürlich eine sehr schlechte Startbedingung.

Schuld daran ist die Firmenpolitik von Univac. Daß in der Produktpalette Abstriche gemacht werden, ist relativ neu. Das heißt, bei der damaligen Hardwareauswahl, was zwei bis zweieinhalb Jahre zurückliegt, war vom Hersteller diesbezüglich noch nichts zu hören. Univac hat erst von etwa einem Jahr, nachdem wir die Installation mit einigen Mühen erfolgreich durchgeführt hatten, die Katze aus dem Sack gelassen. Das Ganze ist eine außerordentlich mißliche Geschichte.

Die Unterstützung durch Univac bei der Umstellungsphase selbst war gut. Das heißt, die Qualität und die Intensität der Beratung war so gut, daß wir die gesamte Umstellung, eben auch bedingt durch diesen Parallelbetrieb, relativ problemlos über die Bühne gebracht haben.

Friedhelm Schulte, DV-Leiter, R.&G. Schmöle Metallwerke GmbH & Co. KG, Menden (Univac 90/40, OS/3)

Bei der letzten Umstellung mußten Hardware und Betriebssystem gewechselt werden. Wir waren zeitlich später dran als andere Benutzer und konnten auf Erfahrungen der Kollegen zurückgreifen. Neben der wichtigen Schulung eigener Mitarbeiter hatten wir Gelegenheit, unsere Anwendungen vorher zu einem Teil bei der Voranwendern umzustellen.

Das alte System 9480 OS/4 blieb installiert, bis die Umstellung weitgehend abgeschlossen war. Die Einführung des System 90/40 unter OS/3 hat uns somit keine besonderen Probleme gebracht, zumal noch programmtechnische Umstellungshilfen von Univac zur Verfügung standen.

Die Hardware ist ohne Schwierigkeiten angelaufen und seitdem äußerst stabil. Die Unterstützung durch Univac war zuverlässig.

Bei späteren Betriebssystem-Releases gingen wir auf Nummer Sicher, indem wir nie die Version "0" einführten. Bei Anwenderprogrammen hatte Univac in der Vergangenheit einigen Nachholbedarf. Inzwischen gibt es für einzelne Gebiete auch auf dem Softwaremarkt entsprechende Angebote. Besondere Probleme hatten wir bei der Übernahme des Lohn- und Gehaltsprogrammes Paisy auf OS/4. Die Paisy-Vertreiber konnten keine Univac Version liefern. Die von uns zur Umstellung benutzte Siemens-Version benötigte einen umfangreichen Umbauaufwand zum Univac-Compiler Cobol 68. Inzwischen bietet Univac dieses Paket selbst an. Der Änderungsaufwand soll sich dadurch laut Univac erheblich verringern. Der genannte Termin wurde allerdings nicht eingehalten - man sei aber sehr bemüht.

Hermann Kietzmann, DV-Leiter, Clouth-Gummiwerke AG, Köln (Univac 1100/61, OS/11000)

Die Umstellung betrifft eine Univac 90/30 unter OS/3. Die neue Anlage ist die 1100/61 unter OS/1100. Unser Unternehmen wechselt Anfang 1982 vom Betriebssystem OS/3 auf OS/1100. Der Umstellungsaufwand ist entsprechend hoch, da es sich bei OS/3 um ein byteorientiertes und bei OS/1100 um ein wortorientiertes Betriebssystem handelt.

Darüber hinaus führen wir mit OS/1100 ein Datenbanksystem ein (DMS). Unter diesen Gesichtspunkten war eine klare Aufgabenstellung notwendig. Der eigentliche Umstellungsaufwand beläuft sich auf 30 Prozent, die restlichen 70 Prozent sind vollkommene Neuprogrammierung. Neuprogrammierung ist wegen Überalterung von bestehenden Programmen, vor allem aber wegen DMS erforderlich. Wichtig war erst einmal eine genaue Zeitplanung, die noch genügend Luft zum Ausweichen läßt. Da die Univac-Anlage 1100/61 einer vollkommen anderen Philosophie unterliegt als unsere 90/30 unter OS/3, mußten alle Programmierer umgeschult werden. Dies haben wir in einem Zeitraum von zirka acht Wochen in Projektschulung beim Hersteller mit praktischer Bildschirmarbeit getan. Wenn die Schulungsleiter erstklassig sind, was bei uns der Fall war, ist eine wichtige erste Hürde genommen.

Direkt nach der Schulung sollten alle Programmierer für ihre Testphase eigene Bildschirme benutzen können. Wir konnten mit einem 1100-Anwender über eine Telefonstandleitung unseren Dialog aufnehmen.

Beim Erstellen des Datenbank-Designs sollte gerade in der ersten Phase ein DMS-Spezialist des Herstellers hinzugezogen werden. Auch bei anderen Problemen sollte auf eine vernünftige Unterstützung nicht verzichtet werden. Die dadurch entstehenden Kosten amortisieren sich auf jeden Fall.

Bei dieser systemspezifischen Einführung ist es wichtig, daß sich die eigenen Mitarbeiter genügend Know-how aneignen, um diese Arbeiten nach der Einführung selber durchführen zu können. Je schneller die eigenen Mitarbeiter "laufen" lernen, desto unproblematischer wird die Umstellung. Aber es wäre vermessen zu sagen, daß es keine Schwierigkeiten gibt. Bei einer Umstellung in dieser Größenordnung kommen die Probleme von allein - und meistens erst dann, wenn niemand mehr daran denkt. Deshalb ist es wichtig, in der Planungsphase kein Problem vor sich hinzuschieben.