Bei Ausfall eines Datenträgers bzw. bei einem partiellen Plattendefekt in einem SF-Pubset oder einem Volume-Set kann mit diesem Pubset/Volume-Set nicht mehr kontinuierlich gearbeitet werden.
Der Fehler kann nur durch eine Neuinitialisierung des betroffenen Datenträgers behoben werden. Damit verbunden ist der Verlust sämtlicher Daten, die sich auf der Platte befinden. Der Pubset kann nur nach einer vollständigen Rekonstruktion aus der Sicherung wieder in Betrieb genommen werden.
Es ist daher notwendig, solche Plattenbereiche rechtzeitig zu erkennen, um sie bei künftigen Speicherplatzanforderungen auszusparen. Nach der Erfassung des Plattenfehlers kann dann eine geeignete Maßnahme zur Beseitigung des Fehlers eingeleitet werden.
Erfassen von Hardware-Fehlern durch das DVS
Der DVS-Kontrollmechanismus sorgt bei gemeinschaftlichen Datenträgern (Pubsets) dafür, dass permanente Plattenfehler, die während eines Plattenzugriffs durch das DVS auftreten, der Allokierungskomponente bekanntgemacht und von der weiteren Vergabe von Plattenspeicher ausgenommen werden. Es wird damit sichergestellt, dass diese registrierten Plattenbereiche bei künftigen Speicherplatzanforderungen nicht mehr berücksichtigt werden und defekte Plattenbereiche nicht mehr auf andere Dateien übergehen.
Die Informationen über die defekten Plattenbereiche werden in der vom System erzeugten, pubset-spezifischen Defect-Garbage-Datei hinterlegt.
Bei der erstmaligen Registrierung eines Plattenfehlers innerhalb eines Pubsets wird die Datei auf diesem Pubset unter folgendem, vom Pubset-Typ abhängigen Pfadnamen erzeugt:
bei SF-Pubsets: :<catid>:$TSOS.SYSDAT.DEFECT.GARBAGE.<catid#>
bei SM-Pubsets: :<catid>:$TSOS.SYSDAT.DEFECT.GARBAGE.<volume-set-id#>
<volume-set-id#> bezeichnet die Katalogkennung des Volume-Sets, auf dem sich die Datei befindet. Ist die Katalogkennung des SF-Pubsets bzw. des Volume-Sets kleiner als vier Zeichen, werden die Variablen <catid#> und <volume-set-id#> auf vier Stellen aufgefüllt.
Die Extentliste dieser Datei besteht aus genau den Extents, die die gemeldeten defekten Plattenblöcke des Pubsets umfassen. Das bedeutet, dass die entsprechenden defekten Blöcke für die Lebensdauer der betroffenen Datei doppelt belegt sind, nämlich einmal in der Datei selbst und einmal in der Defect-Garbage-Datei.
Die Defect-Garbage-Datei darf ausschließlich durch die zuständigen Systemkomponenten bearbeitet werden, jeglicher Zugriff wird abgewiesen. Um einen Zugriff zu verhindern, wird ein Dateikennwort vergeben und das Dateischutzattribut ACCESS=READ eingestellt.
Die Defect-Garbage-Datei wird mit dem Backup-Level E versehen, d.h. sie wird nicht durch ARCHIVE oder HSMS gesichert. Damit werden inkonsistente Zustände vermieden.
Die Extentliste der Defect-Garbage-Datei hat – wie bei allen anderen Dateien – nur eine beschränkte Kapazität. Es können, je nach Plattenverteilung, ca. 140 bis 310 Extents aufgenommen werden, was dann der max. Anzahl von fehlerhaften Blöcken pro Pubset entspricht. Bei Überschreitung der Kapazität wird an der Konsole die Meldung DMS060C ausgegeben. Tritt dieser Fall ein, muss dringend eine Reorganisation des Pubsets mit der Beseitigung der Plattendefekte (z.B. mit VOLIN) durchgeführt werden.
Eine erzeugte Defect-Garbage-Datei kann ausschließlich durch die IMPORT-PUBSET-Verarbeitung des entsprechenden Pubsets gelöscht werden. Während der IMPORT-PUBSET-Verarbeitung wird geprüft, ob eine Defect-Garbage-Datei vorhanden ist und wenn ja, ob Blöcke daraus bereits repariert wurden. In diesem Fall können die reparierten Blöcke wieder in den normalen Prozess der Plattenspeicherplatzvergabe integriert werden. Das erfolgt implizit in der IMPORT-PUBSET-Verarbeitung über eine F5-Rekonstruktion. Existieren keine (registrierten) defekten Blöcke mehr für diesen Pubset, wird die Defect-Garbage-Datei gelöscht.
Die Defect-Garbage-Datei darf in keinem Fall von Hand gelöscht werden; dies muss ausschließlich den Mechanismen des Systems vorbehalten bleiben.
Anderenfalls wären Datenverlust und Zerstörung der F5-Etiketten die Folge!
Bei der F5-Rekonstruktion eines Pubsets während des Import-Vorgangs kann es zu Doppelallokierungen zwischen der Defect-Garbage-Datei und anderen Dateien kommen (Meldungen DMS0461 und DMS0462). Die Meldungen sind jedoch nicht als Hinweis auf Systemfehler oder Inkonsistenzen im F5-Bereich zu verstehen, sie weisen lediglich auf defekte Plattenbereiche im Allokierungsbereich der gemeldeten Dateien hin.
Eine weitere mögliche Fehlermeldung an der Konsole im laufenden Pubset-Betrieb ist DMS0608. In diesem Fall wurde gerade ein defekter Block gemeldet. Beim Versuch, ihn in die Defect-Garbage-Datei aufzunehmen, tritt folgender Fehler auf: Es existiert eine Datei mit der zu einer Defect-Garbage-Datei gehörenden Namensstruktur (siehe oben), ihre innere Struktur (Katalogattribute) weicht jedoch von der einer normalen Defect-Garbage-Datei ab. Die Meldung DMS0608 muss beantwortet werden. Dabei kann versucht werden, die existierende Datei als Defect-Garbage-Datei zu verwenden. Gelingt dies nicht, kann die Funktion abgebrochen werden, d.h. der defekte Block wird nicht erfasst, oder es wird eine neue Defect-Garbage-Datei vom System erzeugt und die existierende implizit gelöscht.
Manuelle Allokierungssperre vergeben
Eine Allokierung auf defekten Platten kann für SF- und für SM-Pubsets volume-spezifisch und für SM-Pubsets auch volume-set-spezifisch verboten werden (siehe Kommando MODIFY-PUBSET-RESTRICTIONS).
Bereits beim Importieren von SM-Pubsets besteht die Möglichkeit, die Allokierung von Volume-Sets mit defekten Platten zu verhindern. Die Volume-Sets können dabei in den Zustand „defect“ oder „in hold“ versetzt werden (siehe Kommando IMPORT-PUBSET, Operanden DEFECT-VOLUME-SET bzw. IN-HOLD-VOLUME-SET).