Ein zentrales Problern bei der Konzeption von Lokalen Netzwerken stellen Dateizugriffsmechanismen dar. Während Software-Entwickler im Regelfall kaum mit dem Problem des Zugriffs auf gemeirtsame Daten konfrontiert werden, sieht es bei den LAN-Anwendern etwas anders aus: Dort ist man bei einem Systemabbruch selten in der Lage, genau festzustellen, welche Dateien noch stabil sind und welche Operationen noch durchgeführt werden müssen. Der Autor gibt im folgenden aus der Sicht eines Softwerkers einige Tips und Rezepte zur Vermeidung von Datenverlusten.

Bei einer LAN-Konfiguration muß gewährleistet sein, daß jeder Anwender-Zugriff auf jeweils nur eine aktuelle Dateiversion erfolgen darf. Und ebenso essentiell erscheint die Vermeidung sogenannter Deadlocks, die bei gegenseitiger Blockierung von Dateien durch Anwenderprogramme entstehen können. Damit wäre ein Datei-Management-System gefordert, das diese Funktion verwaltet und die Chance eines Deadlocks so weit wie möglich minimiert. Philosophie und Anforderungen, die an ein solches System geknüpft sind, werden hiermit einer eingehenden Betrachtung unterzogen. Entwickler und Programmierer von Anwendungssystemen setzen gewöhnlich zweierlei hinsichtlich der Dateien voraus, auf die sie zugreifen:

Erstens: Es wird nichts schiefgehen.

Diese Voraussetzung resultiert aus dem Glauben an die Zuverlässigkeit der Software und Hardware. Natürlich läuft meistens alles wie erwartet. Aber manchmal gibt es Probleme: die Stromversorgung fällt aus, ein Laufwerk setzt aus, jemand unterbricht das Netzkabel, verursacht einen Programmabsturz oder bootet das System zufällig neu. In einigen Mainframe-Konfigurationen konnten solche Ereignisse behandelt werden. Die "glücklichen" Betriebssysteme benutzten CICS, DL/I oder eine vergleichbare Systemsoftware, die manchmal automatisch Daten zurückholen konnte oder eine Möglichkeit bot, die gestrigen Backups auf den neuesten Stand zu bringen. Wenn all dies fehlschlug, wurden die Programmierer hinzugezogen, um die Dateien zu untersuchen, speziell um fehlerhafte Datensätze zu löschen oder zu aktualisieren und um dem Operator mitzuteilen, welche Informationen neu eingegeben werden mußten.

Aber was macht der computerunkundige Geschäftsmann, wenn diese Dinge seiner PC-orientierten Anwendung zustoßen? Kein automatisches Zurückholen der Daten. Keine Systemprogrammierer. Und das letzte Backup wurde vor Ewigkeiten gemacht! Er kann versuchen, alle verlorenen Daten neu einzugeben, wenn er weiß, welche es waren, und seinem unzufriedenen Kunden erzählen: "Der Computer war schuld."

Zweitens: Dieser Task läuft von selbst.

Diese Voraussetzung reflektiert das Bedürfnis nach Einfachheit. Wenn ein Programm auf Daten zugreift, so bleiben alle Datensätze, welche die bestehende Datei ausmachen, auch bestehen, es sei denn, dieser Task bringt sie auf den neuesten Stand. Wenn ein Datensatz früher gelesen werden konnte, gibt es ihn immer noch mit denselben Werten. Kein anderer Task belästigt die Dateien, aktualisiert die Daten, die dieser Task benötigt, und hindert ihn in irgendeiner Weise am Zugriff auf die Daten, die er braucht. Ein Bruch mit diesem Glauben kann das Programm veranlassen, die Dateien zu verfälschen oder das System zum Stillstand zu bringen.

Das Datei-Management-System (DMS) liefert Methoden, diese beiden und andere Datei-Integritäts-Probleme zu behandeln, und bietet für eine Vielfalt von Tasks die Möglichkeit, gleichzeitig auf die Daten zuzugreifen.

Wenn ein einzelnes Programm auf eine Datei zugreift, sind die Effekte der Cobol-I/O-Befehle stets gut geklärt. Zu jeder Zeit enthält eine Datei eine gewisse Anzahl Datensätze, und Cobol-I/O-Befehle wie etwa Write und Delete verändern die Datensätze auf eine leicht zu verstehende Art. Die Situation, in der zwei oder mehr Programme gleichzeitig auf eine Datei zugreifen, ist komplizierter, und zwei wichtige Überlegungen müssen angestellt werden.

Physikalische Datei-lntegrität

Daten werden typischerweise aus Blöcken gelesen und in solche geschrieben. Wenn zwei Programme versuchen, zur gleichen Zeit den gleichen Block zu beschreiben, könnte das Betriebssystem, bedingt durch den Mangel an entsprechenden Kontrollen, die beiden Schreibzugriffe verschachteln, sodaß der sich ergebende Block einige Sektoren des einen Blocks und einige des anderen Blocks enthält und sich eine verfälschte Datei ergibt. Dies geschieht sicher, wenn zwei Programme zur gleichen Zeit den gleichen Datensatz aktualisieren, aber es kann ebenso vorkommen, wenn zwei Programme logisch unterschiedliche Datensätze, die zufällig im gleichen physikalischen Block stehen, aufdatieren.

Das DMS behandelt das Problem der physikalischen Datei-Integrität und stellt sicher daß Verfälschungen dieses Typs niemals vorkommen können. Wenn zwei Programme versuchen, denselben Block zu aktualisieren, wird entweder der eine oder der andere Block geschrieben, aber es wird nie möglich sein, einen "vermischten" Block zu erhalten. Dieser Schutz ist mehr oder weniger automatisch, und der Anwendunsprogrammierer kann das Problem der physikalischen Datei-Integrität weitgehend unbeachtet lassen, wenn er das DMS benutzt (vergleiche hierzu Bild 1).

Selbst wenn das Problem der physikalischen Datei-Integrität völlig gelöst ist und sichergestellt ist, daß das Datei-Format physikalisch korrekt ist, können Probleme der logischen Abfolge in nicht korrekten Informationen, die gespeichert werden, resultieren. Die folgende Abfolge könnte vorkommen:

Operator 1 liest den Datensatz für Zimmer, Zimmer 317 ist frei.

Operator 2 liest den Datensatz für Zimmer, Zimmer 317 ist frei.

Operator 1 aktualisiert den Datensatz und weist Zimmer 317 Herrn Schmitz zu.

Operator 2 aktualisiert den Datensatz und weist Zimmer 317 Herrn Schulze zu.

Selbst wenn das System die physikalische Datei-Integrität gewährleistet, gibt die Abfolge der Operationen keinen Sinn, und die Datei zeigt sicherlich nicht die Tatsache an, daß Herr Schmitz und Herr Schulze sich das gleiche Zimmer teilen müssen.

Das DMS umfaßt ein Spektrum an Möglichkeiten, sich mit dem Problem der logischen Datei-Integrität zu befassen. Es ist nicht möglich, diese Schwierigkeiten völlig automatisch zu lösen, da sie von der Reihenfolge der logischen Verarbeitung abhängen. Das allgemeine Ziel ist jedoch, das Schreiben eines Programmes so zu gestatten, als ob alles allein liefe, mit einem Minimum an Interesse für die Tatsache, daß es eigentlich vielfältige Instanzen des Programms (oder anderer Programme, die auf dieselbe Datei zugreifen) gibt, die zur gleichen Zeit ablaufen (Abb. 2). Das DMS liefert eine Reihe von Alternativen, die eine Lösung zwischen zwei Extremen erlauben:

Entweder fordern sie vom Programmierer, sorgfältig das Problem des File-sharing im Auge zu behalten, mit dem Ziel, ein Maximum an Effizienz aus der Nutzung des Netzwerkes zu ziehen. Bei dieser Methode analysiert der Programmierer, wann Abfolgen von Operationen Schwierigkeiten verursachen können, und befaßt sich eingehend mit ihnen.

Sie gestatten dem Programmierer, das File-sharing weitgehend außer Acht zu lassen, auf Kosten einer effizienten Nutzung des Netzwerkes. Bei dieser Methode geht das System davon aus, daß alle Operationen Probleme verursachen können, und trifft automatisch die geforderten Vorsichtsmaßnahmen zur Vermeidung von Konflikten.

Backup und Recovery

Obwohl die Methoden des Backup (Datensicherung) und der Recovery (Regenerierung) nicht spezifisch für das File-sharing sind, ist es bezeichnenderweise wichtiger, sich in diesem Bereich damit zu beschäftigen. Wenn lediglich Batch-Dateien verarbeitet werden, ist es ausreichend, kritische Dateien in regelmäßigen Abständen auf Band zu kopieren.

Das Problem bei dieser Methode in einer interaktiven Umgebung liegt im nächsten Schritt. Der Neustart von Programmen kann eine Neueingabe aller Daten, die verlorengegangen sind, durch den Operator erforderlich machen. (Dieses kann undurchführbar sein, falls keinerlei Hilfsdatensätze verblieben sind. Es wäre beispielsweise in einem Hotel kaum möglich, von allen Gästen zu verlangen, sich an der Rezeption neu anzumelden.)

Ein weiteres Problem entsteht, falls verschiedene; unabhängige Computer über ein Netzwerk auf dieselbe Datei zugreifen; einer dieser Computer könnte inmitten einer Operation fehlerhaft arbeiten. In diesem Fall wird man sicherlich nicht das ganze Netzwerk abschalten wollen. Andererseits will man sichergehen, daß der fehlerhafte Computer die Datei in einem logisch korrekten Zustand zurückläßt, was eventuell nicht der Fall ist, wenn er inmitten einer Operation abstürzt.

Roll Forward zur Wiederherstellung

Das DMS bietet eine Möglichkeit des Roll Forward, welche die Regeneration der Dateien vom letzten Backup bis zum Systemabsturz erlaubt. Wie bereits oben ausgeführt, verlangt dies in einer interaktiven Umgebung das Vorhandensein zusätzlicher Informationen. Eine Methode wäre, vom Anwendungsprogramm zu verlangen, eine separate Protokolldatei zu führen, die Auskunft darüber gibt, welche Operationen durchgeführt worden sind. Ein Roll Forward könnte folgendermaßen erreicht werden: Man zieht eine Sicherungskopie der fehlerhaften Datei und regeneriert diese, indem man die Protokolldatei liest und die Updates wiederverwendet, die nach dem letzten Backup und vor dem Absturz gemacht wurden.

Zur maximalen Sicherheit können eine Vielzahl von Kopien dieser Protokolldatei - sogenanntes "Mirrored Log" - auf gesonderten Datenträgern oder sogar separaten Computern eines Netzwerkes angelegt werden, um die Möglichkeit einer Zerstörung der Protokoll-Datei ihrerseits durch Hardwarefehler zu minimieren (Abbildung 3).

Roll Back als alternative Möglichkeit

Die Möglichkeit des Roll Back befaßt sich mit dem Problem eines einzelnen Computers, der inmitten einer Operation abstürzt. Wenn der Prozessor, der abgestürzt ist, eine Operation nur teilweise beendet hat, macht ein Roll Back die Updates, die er als Teil dieser Operation bereits durchgeführt hat, wieder rückgängig und stellt den logischen Zustand der Datei zum Zeitpunkt des Beginns der fehlerhaften Operation wieder her. Natürlich geht die zum Zeitpunkt des Absturzes laufende Transaktion verloren und muß neu eingegeben werden (eventuell auf einem anderen Terminal, wenn es sich um einen Hardwarefehler handelt).

Das Roll Back ist ebenfalls nützlich bei der Behandlung logischer Kontakte zwischen zwei Programmen, wie beispielsweise in dem vorher erwähnten Fall der Zimmerbelegung. Betrachten wir die folgende Sequenz von Operationen:

Programm 1 liest Datensatz 1 und ändert Datensatz 3.

Programm 2 liest Datensatz 2 und ändert Datensatz 4.

Programm 1 liest Datensatz 2, wird aber durch das Data Management System gezwungen zu warten, da

Programm 2 zur Zeit auf Datensatz 2 zugreift.

Programm 2 zur Zeit auf Datensatz 1, wird aber durch das DMS gezwungen zu warten, da Programm 1 zur Zeit auf Datensatz 1 zugreift.

Wenn ein Programm versucht, einen Datensatz zu lesen, der unter Zugriff eines anderen Programmes steht, wartet es normalerweise so lange, bis der Datensatz freigegeben wird. Dies ist einer der fundamentalen Mechanismen, Record Lock genannt, der verwendet wird, um potentielle Konflikte zu lösen. Jedoch wird aus dem oben angeführten Beispiel klar, daß beide Programme ewig warten müssen. Diese Situation bezeichnet man als Deadlock. Das Betriebssystem muß erkennen, wenn ein Deadlock eingetreten ist, und eines oder beide der betroffenen Programme informieren. Bleibt die Frage, was in diesem Fall zu tun ist. Ganz einfach, eines der beiden Programme muß zurücktreten, wie ein Auto an einer Kreuzung zurücksetzt, wenn zwei Wagen sich gegenseitig die Fahrbahn blockieren. Da beide Programme zu dem Zeitpunkt, an dem der Konflikt erkannt wird, bereits Datensätze geändert haben, muß das Programm, das zurücktritt, seine Updates rückgängig machen.

Logischerweise ist es in der gleichen Situation, als wenn es auf ein Hardware-Problem getroffen wäre, das den Abschluß einer Transaktion verhindert. Die Lösung ist in beiden Fällen die selbe: Die automatische Roll Back-Möglichkeit führt den notwendigen Rückzug durch, so daß das andere Programm ungehindert seine Aufgabe vollenden kann und die Datei in einem logisch konsistenten Zustand zurückgelassen wird.

*Hagen Cyrus ist Geschäftsfuhrer der Firma GFU Cyrus & Rölke GmbH in Köln.