Schwierigkeiten bei Release-Wechsel ?

21.03.1975

Mit der Frage "Gibt oder gab es bei Ihnen Schwierigkeiten bei der Einführung eines neuen Software-Release?" glaubte CW, ein heißes Eisen anzufassen. Befragt wurden Anwender aller Herstellertypen - geantwortet haben ausschließlich IBM-Benutzer.

Hier darf wohl mit Recht unterstellt werden, daß die EDV-Leiter der befragten Firmen eine gewisse Zurückhaltung bei der Beantwortung der Frage geübt haben. Trotzdem gab es Klagen wie "ältere Releases werden nicht mehr gewartet", "Schwierigkeiten gab es bei jeder Umstellung", "nur nichts übereilen" und "es wäre für uns besser gewesen, die Umstellung mit dem älteren Release durchzuführen".

CW betrachtet deshalb die Diskussion als noch nicht abgeschlossen und hofft auf lebhafte Reaktion aus Anwenderkreisen.

Klaus Danecki, Chefprogrammierer der Raab Karcher GmbH in Essen

Am 1. 12. 1974 wurde unsere Tochtergesellschaft in Frankfurt von einem System IBM 360/20 auf 370/115 umgestellt.

Dieser Wechsel bereitete nicht nur uns als Mieter der Anlage, sondern auch der IBM erhebliche Schwierigkeiten. Diese traten sowohl in der Hardware als auch in der Software auf.

Das System arbeitet unter DOS/VS Release 30 mit drei Partitions, zur Zeit wird nur der Background benutzt. Vor allem die IBM-Service-Programme, wie zum Beispiel Sort und Merge, waren nicht auf dem neuesten Stand und deshalb nicht einsetzbar. Das Release wurde durch die IBM wiederholt ergänzt oder korrigiert.

Erst nach circa drei Wochen konnte das System, wenn auch noch mit kleineren Mängeln, von uns ohne längere Unterbrechung benutzt werden.

Man kann abschließend sagen, daß es für uns besser gewesen wäre, die Umstellung mit dem älteren Release (DOS/VS 29) durchzuführen.

Clemens Herrmann, Referatsleiter der Gruppe Programmierung des ADAC e. V., München

Bei uns ist derzeit installiert eine IBM 370-145 mit 12 Plattenlaufwerken, vier Bandeinheiten, einem Drucker, Leser, Stanzer sowie 32 Bildschirmen. Wir fahren zur Zeit das Relase 29. Bei uns heißt die Devise "nur nichts übereilen". Erstens haben wir gar nicht die Zeit, ein neues Release sofort einzusetzen und zum anderen warten wir ab, was andere Anwenderkollegen für Erfahrungen mit einem neuen Release gemacht haben. Es gibt IBM-Kunden, die sind sehr schnell und da bei uns die Kommunikation mit anderen Firmen sehr gut ist, erfahren wir auch bald, welche Fehler im neuen Release sind oder was nicht funktioniert. Das ist dann wiederum für uns ausschlaggebend, noch länger zu warten. Wir haben zum Beispiel gehört, daß das Release 30 nicht so gut sein soll, deshalb warten wir jetzt auf das Release 31, werden es aber auch nicht sofort einsetzen, denn die Neuerungen, die Release 30 und 31 mit sich bringen, sind nicht unbedingt erforderlich. Wir können es uns nicht leisten daß im Betriebssystem Fehler auftreten. Allein in unserer Mitgliederverwaltung stehen 32 Bildschirme, die auf keinen Fall ausfallen dürfen, Unsicherheiten im Betriebssystem sind daher für uns nicht tragbar.

Schwierigkeiten gab es bei uns bei der Umstellung von DOS auf VS. Da bei uns das CICS der IBM läuft, wollten wir zuerst warten, bis CICS/VS angeboten wird. Nachdem aber der Kernspeicheraufwand zu groß war und die Fachabteilungen mit den wesentlich längeren Wartezeiten an den Bildschirmen nicht einverstanden waren, sind wir wieder zurück auf CICS Standard gegangen und haben das System im VS zum Laufen gebracht. Heute fahren wir das Betriebssystem VS, alles virtuell, lediglich CICS real.

Für den Einsatz eines neuen Release haben wir ein Verfahren entwickelt: Nach einem Kursbesuch habe ich damit begonnen, sämtliche Steuerkarten und den gesamten Ablaufplan anhand von Karten zu dokumentieren. Wenn jetzt ein neues Release kommt, studieren wir die Hersteller-Broschüre und gehen chronologisch die Aufstellung durch, ersetzen oder ergänzen sie, ziehen nicht mehr aktuelle Daten heraus. So hat man relativ wenig Aufwand mit der Steuerkarte und erhält eine Vorgabe, wie gezielt vorgegangen werden kann.

Ausfallzeiten im Betriebssystem gab es bei uns nicht, allerdings werden bei uns sehr umfangreiche Vorarbeiten geleistet, bevor wir an die Maschinen gehen.

Otto Schleicher, Leiter Entwicklungsprojekte und Programmierung des Autocomp-Rechenzentrum Oberursel

Umstellungen auf eine andere Version des Betriebssystems werden bei uns nach eingehender Prüfung der Zweckmäßigkeit und Erfordernis durchgeführt.

Ein Wechsel der Release wurde bisher durchgeführt bei

- Hardware-Änderungen (IBM 360 in 370 und umgekehrt)

- Hardware-Erweiterungen (Teleprocessing)

- Fehlerhafter Release und

- um auf dem neuesten Stand zu bleiben.

Zur Zeit benutzen wir zwei Systeme IBM 360-50 mit je 512 K unter DOS, Release 26.2.

Schwierigkeiten hat es bei jeder Umstellung gegeben. Wir müssen damit auch in Zukunft rechnen. Alle aufgetretenen Schwierigkeiten entstanden nicht durch die Übernahme der Anwenderprogramme, sondern durch Fehler in dem vom Hersteller mitgelieferten Routinen (zum Beispiel in Release 26.2.: Ismod und Mcrr-Routine, in Release 29.0: Btmod und Potenzierung bei Cobol).

Sofern man eines der neuesten Release für DOS (29 oder 30 DOS/VS) verwendet, bekommt man vom Hersteller nach Schilderung der erkannten Fehler umgehend die notwendigen Änderungen zur Verfügung gestellt. Bei älteren Betriebssystemen (zum Beispiel Release 26.2 als letztes für die 360-Serie), die nicht mehr vom Hersteller gewartet, aber ausgeliefert werden, erfolgen Fehlersuche und Fehlerbehebung nur noch kostenpflichtig. Da diese Verfahren neben den Kosten auch noch sehr zeitraubend sind, übernehmen wir einfach die betreffenden Routinen aus einem anderen Release.

Für die Zukunft wäre es wünschenswert, wenn eine Release mit groben Fehlern nicht ausgeliefert wird.

Wil Wijnands, Leiter der EDV-Abteilung, Alcan Folien GmbH, Lüdenscheid

In den vergangenen fünf Jahren wurde bei uns vier Mal eine neue Release übertragen, wobei es nur bei der letzten Übertragung (im November 1974) Schwierigkeiten und zwar auf dem Gebiet der Datei-Sicherung gab. Allgemein sollten bei einer Übertragung folgende Regeln berücksichtigt werden:

1. Frühzeitige schriftliche Vorabinformation (besonders dann wichtig, wenn der Ablauf mittels Control-Strings durchgeführt wird).

2. Hinweise auf Einschränkungen insbesondere auf Hardware-Einheiten bezogen (externe Speicher).

3. In Anwesenheit des zuständigen Herstellerspezialisten eine Arbeitsbesprechung zur Information des Teams (Operator, Programmierer) durchführen, um alle Konsequenzen berücksichtigen und Vorarbeit sinnvoll gestalten zu können.

4. Vornehmen der gegebenenfalls erforderlichen Änderungen der eigenen Hantierungsvorschriften.

5. Die Gültigkeit einer neuen Release sollte mindestens ein bis eineinhalb Jahre betragen.

6. Sorgfältigere Planung des Übernahmetermins unter Berücksichtigung einer angemessenen Zeitreserve für eventuell auftretende Schwierigkeiten.

Der Termin sollte nicht zu weit zurückgestellt werden, da die Dokumentation des Herstellers sich (nach der Freigabe) auf die neue Version bezieht.

7. Besondere Aufmerksamkeit bei der Kontrolle der Arbeiten während der ersten Zeit nach der Übernahme.