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.

27.02.1978

Haben Systemabstürze ihren Schrecken verloren?

27.02.1978

Systemabstürze, vor nicht allzu langer Zeit noch das am meisten gefürchtete Problem im Rechenzentrum, haben heute ihren Schrecken verloren. Allein die Hardware ist durch die Verwendung der Mikroprozessor-Technik inzwischen so ausgereift, daß Störungen im Speicherbereich sich teilweise selbst regenerieren, die modulare System-Architektur macht überdies das Austauschen bestimmter Speicherblöcke zum "Kinderspiel". Treten dennoch Störungen auf, gibt es eine ganze Reihe Hard- und Software-Diagnosesysteme, die Fehler lokalisieren und beseitigen helfen. Schwierigkeiten aber gibt es trotzdem: Bei Wolfgang Koopmeier in Ingolstadt ist es die Mixed Hardware, die unter Umständen ein System zum Stillstand bringen kann, Franz Axtner aus München leidet unter dem "Distributed Processing", weil man Fehlerursachen jetzt in mehreren Systemen suchen muß. CW befragte - um Einseitigkeit zu vermeiden - Anwender von Systemen der Firmen Honeywell, IBM, Siemens und Univac.

Jochen Kuhne Geschäftsführer der Rational GOD-Programm München

In unserer Honeywell-Anlage befinden sich zwei Diagnose-

Systeme: HEALS betätigt die laufende Überwachung des gesamten Systems und schreibt festgestellte Fehler über eine Konsol-Schreibmaschine heraus, damit der Operator eventuell Maßnahmen ergreifen kann, wie etwa eine Station ausschalten, die vom System nicht mehr angefordert wird, oder er kann Spuren ersetzen, die auf der Platte nicht mehr benutzbar sind. Bei größeren Fehlern in der Anlage kann unser Techniker über einen Job TOLTS tiefer in die Maschine gehen, wie etwa zu einer 300 bis 400 Kilometer entfernten Remote-Station.

Was bei uns zu Systemabstürzen führt, sind zwei Dinge: Einmal ein Kernspeicher-Fehler. Ist dieser so klein, daß er sich in der 1-Bit-Region befindet, kann die Maschine ihn selbst korrigieren. Sind ganze Teile fehlerhaft, werden diese aufgehoben - der Computer schrumpft sich selbst um 16 K-Schritte. Der gravierendste Systemzusammenbruch entsteht im Hardcore, die Maschine abortiert sich dann von selbst. In diesem Fall hat unser System-Spezialist die Möglichkeit, über ein Instruction Retry aus dem History-File die letzten vier bis fünf Befehle der zuletzt gelaufenen Jobs herauszuholen und daraus Schlüssen, zu ziehen. Außerdem hat er den Kernspeicher-Dump zur Verfügung.

Fehler in der Peripherie äußern Sich bei Band und Platte etwa gleich: Beim Lesen wird der Job abortiert, der diesen Fehler verursacht hat. Der operator muß dann durch einen Restore die entsprechende Datei zurücksichern.

Gravierende Abstürze gab es bei uns im vergangenen Jahr nur zweimal: Einmal blieb der Strotm nach einem Blitzschlag zu lange weg, das andere Mal trat ein Kernspeicherfehler auf. Hier mußte beim Restart über den History-File rekonstruiert werden, welche Jobs noch Wiederanlaufmöglichkeit hatten und welche neu gestartet werden mußten.

Wolfgang Koppmeyer Leiter der Organisation, Schubert & Salzer AG, Ingolstadt

Totale Systemzusammenbrüche gibt es heute eigentlich nicht mehr, es sei denn, sie werden durch Programme oder schlechtere periphere Geräte ausgelöst. Wir arbeiten mit einer IBM 370/135 und fahren für unseren Online-Betrieb mit CICS. Der Speicherbereich ist bei uns abgesichert, da wir nur mit 96 IBM-K's fahren und die Differenz zu 500 K von einem Fremdspeicher-Anbieter installiert haben. Vorteil dieser Speichererweiterung ist - und das war das wichtigste Auswahlkriterium -, daß wir jetzt die neue Mikroprozessor-Technologie der dynamischen Chips zur Verfügung haben und so bei Ausfall eines Speichermoduls automatisch ein zweites die Funktionen der Anlage übernehmen kann. Bei der nächsten fälligen Wartung kann sich der Service-Techniker die fehlerhaften Module per Programm-Aufruf oder über Disketten "ansehen" und den entsprechenden Chip austauschen. Diese Systemverbesserung gab es bei unserer 135 noch nicht, in größeren IBM-Rechnern ist sie heute selbstverständlich.

Kurzfristige Systemausfälle bringt derzeit der Einsatz von Mixed-Hardware mit sich. Wir fahren im Multiprogramming neben CICS laufen noch andere Programme. Mangelhafte Magnetbänder veranlassen einen Programmabsturz, und wir müssen das ganze CICS herunter- und wieder hinauffahren. Natürlich gibt es dann Ärger mit den Fachabteilungen. Aber auch gemixte Platten können unzumutbare Bildschirm-Response-Zeiten verursachen, wenn sie in eine falsche Routine laufen.

Einen Totalausfall der CPU mit anschließender Reorganisation aller Daten kennen wir jedoch nicht mehr. Unser letztes größeres Problem in dieser Richtung entstand durch einen Kabelbrand, der nicht sofort zu lokalisieren war. Ober einen Zeitraum von 14 Tagen fiel das System immer wieder aus, allerdings nur bei bestimmten Temperaturen. Der Grund hierfür war leicht zu beheben: Der Schrank mit dem Fremdspeicher stand von der IBM-Box etwa 20 Zentimeter entfernt. Immer wenn die IBM-Techniker nun ihren Speicher warten wollten, mußten sie den Schrank wegrücken, und dadurch entstand offensichtlich der Kabelbrand. Nachdem der Fremdspeicher-Anbieter sich bereit erklärt hatte, einen neuen Speicher zu installieren und wir zudem das Rechenzentrum räumlich umgebaut hatten, waren auch diese Fehlerquellen beseitigt.

Meiner Meinung nach ist die Peripherie, die heute von Mixed Hardware-Firmen angeboten wird, technologisch nicht ausreichend untermauert. Trotz des Risikos bin ich der Meinung, daß sich her Einsatz lohnt. Die von uns auf diese Weise eingesparten 120000 Mark im Jahr beweisen es. Auch wenn man einen "halben Mann" für die Beseitigung der Fehlerquellen, bereitstellen muß, bleiben immer noch gute 90 000 Mark übrig. Die Wartung aller Geräte ist heute so gut aufgebaut, daß innerhalb von 12 Stunden die meisten Fehler beseitigt sind.

Systemzusammenbrüche sind also in der heutigen Zeit tatsächlich das geringere Übel innerhalb einer EDV-Abteilung.

Werner Conzelmann Leiter der Datenverarbeitung und Organisation, Otto Ficker AG, Kirchheim

Seit exakt zwei Jahren setzen wir ein System Univac 90/30 mit derzeit 224 KB ein, an das realtime sieben Uniscope-200-Bildschirme angeschlossen sind. Systemzusammenbrüche, die durch Schwachstellen in der Hardware in früheren Jahren öfter aufgetreten sind, kennen wir eigentlich nicht. Natürlich gab es im ersten halben Jahr nach der Installation Schwierigkeiten, die aber auch bei anderen Umstellungen auftreten. Zudem war Online damals für uns absolutes Neuland.

Den letzten echten Systemzusammenbruch hatten wir vor einer Woche, allerdings war daran nicht etwa die Hard- oder Software schuld, sondern ein Lehrer, der sich anläßlich einer Demonstration gegen die System-Grundstellungstaste lehnte und versehentlich abschaltete. Ein Ausfall im August 77 wurde durch Stromschwankungen im Netz verursacht, davor - im Februar 77 - hatten wir einen Zusammenbruch durch ein Software-Problem.

Aber auch solche Totalausfälle lassen uns nicht unbedingt in Panik geraten, denn die von uns eingesetzte Univac-Recovery-Software deckt sowohl das Realtime als auch das Datenbank-Handling ab. Von Vorteil ist zudem, daß das Betriebssystem OS30 nicht in Partitions unterschieden wird. Wir fahren derzeit maximal fünf Programme parallel, wobei die Zuordnung des Häuptspeichers vollkommen frei ist. Die Einteilung in Partitions wie beim IBM/DOS bringt doch eine gewisse Starrheit mit sich, während wir in der Zuteilung des Hauptspeichers vollkommen variabel sind. Beim Wiederanlaufverfahren nach einem System-Breakdown setzt das System genau zu dem Zeitpunkt wieder auf, in dem die letzte Transaktion entweder begonnen oder abgeschlossen wurde. Am Bildschirm wird dem Benutzer dann genau mitgeteilt, daß er eine Transaktion bereits beendet hatte, das System stellt ihm den nächsten Schritt vor.

Franz Axtner Leiter Zentrale Organisation, Rechenzentrale Bayerischer Genossenschaften e. G., München

Wir haben im Raum München drei Siemens-Anlagen 7755 installiert. Fällt einmal ein System für wenige Stunden aus, bekommen wir das nicht ganz so stark zu spüren, da wir bis zur Instandsetzung versuchen, die Anwendungen auf einem der beiden anderen Rechner umzuhängen. Die großen Zusammenbrüche, wie sie früher öfter aufgetreten sind, gibt es heutzutage kaum noch. Die Siemens-Serie 7700 ist durch den heutigen Stand der Technologie bereits so ausgestattet, daß Fehler im System sich selbst korrigieren oder sogar - bei Ausfall bestimmter Speichermodule - automatisch auf einen zweiten Speicherchip umgeschaltet wird. Aber dennoch bleiben noch genug kleine Probleme, die einem den Alltag erschweren können: Einmal hat sich das Betriebssystem "aufgehängt", das andere Mal funktioniert die Steuereinheit nicht richtig oder auf einem Plattenbereich kann die Spur nicht mehr richtig angesprochen werden. Solche " Kleinigkeiten" verursachen heute den Systemausfall.

Erst einmal fiel die Zentraleinheit aus, und einmal stand die Anlage über längere Zeiten immer wieder still, da unsere Panzersicherung überlastet war. Wir mußten also immer wieder neu hochfahren, bis der Schaden endgültig behoben war.

Von der Software-Seite her gibt es keine nennenswerten Schwierigkeiten, da das von uns eingesetzte ADABAS doch sehr ausgereift ist.