Bei verdrängten Dateien kann HSMS alle benötigten Sicherungsdaten nur dann geschlossen verwalten, wenn alle Daten der verdrängten Dateien mitgesichert werden. Nur in diesem Fall lassen sich bei Ausfallsituationen die Daten einfach wiederherstellen.
Beim Restaurieren behandelt HSMS verdrängte Dateien folgendermaßen:
Versionshaltung
Beim RESTORE (Restore, Aktivierung, Import) durch den nicht-privilegierten Benutzer werden verdrängte Dateien immer auf die Speicherebene S0 gebracht.
Behebung eines S0-Crashs
Der HSMS-Verwalter kann für verdrängte Dateien wahlweise nur den Katalogeintrag restaurieren. Dazu steht ihm der Operand MIGRATED-FILES=*CATALOG-ONLY in der RESTORE-FILES-Anweisung zur Verfügung. Dabei werden die Katalogeinträge so geändert, dass sie auf die jüngsten passenden Daten im Migrationsarchiv zeigen (impliziter EXCHANGE).
Wenn im Migrationsarchiv für eine Datei keine passenden Daten vorhanden sind, wird dies als Fehler gemeldet. Der Katalogeintrag bleibt dabei bestehen. Eine solche Fehlermeldung tritt für Dateien auf, die nach der letzten Sicherung zurückgeholt oder gelöscht wurden, wobei danach der Migrationsbereich reorganisiert wurde. Diese übrig bleibenden Inkonsistenzen können behoben werden durch:
Restore der betroffenen Dateien nach S0 oder auf eine gewünschte Migrationsebene. Dazu steht die HSMS-Anweisung REPAIR-CATALOG-BY-RESTORE zur Verfügung.
Löschen des Katalogeintrags
Behebung eines S1-Crashs
Dazu können unterschiedliche Verfahren angewandt werden:
Anweisung REPAIR-CATALOG-BY-EXCHANGE, falls Kopien der Daten auf der Speicherebene S2 in einem anderen Migrationsarchiv vorhanden sind.
Anweisung REPAIR-CATALOG-BY-RESTORE, falls im Backup-Archiv Sicherungen der nach S1 migrierten Daten vorliegen.
Beide Verfahren können auch kombiniert werden. Zuerst werden für die Dateien, für die noch Daten im Migrationsarchiv vorhanden sind, mit REPAIR-CATALOG-BY-EXCHANGE die Lokalisierungsinformationen auf die entsprechenden Sicherungsdateien gerichtet. Anschließend werden die Dateien, für die keine Daten mehr im Migrationsarchiv vorhanden sind, die aber noch Daten im Backup-Archiv besitzen, mit REPAIR-CATALOG-BY-RESTORE aus dem Backup-Archiv restauriert. Beide Anweisungen wirken nur für migrierte Dateien, die in der ungültig gewordenen und der zur Reparatur verwendeten Sicherungsdatei denselben Dateistand (CFID) haben.
Behebung eines S2-Crashs
Zur Behebung eines S2-Crashs bzw. bei Zerstörung einer Sicherungsdatei im Migrationsarchiv können unterschiedliche Verfahren angewandt werden:
Anweisung REPLACE-SAVE-FILE-BY-EXCHANGE, falls im Migrationsarchiv eine Kopie der Sicherungsdatei vorliegt.
Anweisung REPLACE-SAVE-FILE-BY-RESTORE, falls im Backup-Archiv Sicherungen der Daten der Sicherungsdatei vorliegen.
Anweisung COPY-SAVE-FILE aus einem Langzeitarchiv in ein Migrationsarchiv mit anschließendem REPAIR-CATALOG-BY-EXCHANGE bzw. REPLACE-SAVE-FILE-BY-EXCHANGE.
Behebung eines Crashs auf S0 und den Migrationsebenen
Dazu kann zuerst mit dem Operanden MIGRATED-FILES=*CATALOG-ONLY der RESTORE-FILES-Anweisung die Speicherebene S0 wiederhergestellt werden. Anschließend können dann mit den HSMS-Anweisungen REPAIR-CATALOG-BY-EXCHANGE und REPAIR-CATALOG-BY-RESTORE die Daten auf der Migrationsebene aktiviert bzw. restauriert werden.
Zur Behebung von S1 bzw. S2-Crashes ist es grundsätzlich nötig, Kopien der migrierten Daten vorzuhalten. Zum Zeitpunkt der Migration wird dies gewährleistet, indem mit dem globalen bzw. SM-Pubset-spezifischen HSMS-Parameter BACKUP-MANDATORY=*YES nur Dateien migriert werden können, die zuvor gesichert worden sind. Die hier erstellten Sicherungen werden jedoch üblicherweise nach Ablauf der Retention-Period der Sicherung freigegeben (//MODIFY-ARCHIVE ... SAVE-FILE=*DELETE( ...) ) und stehen dann nicht mehr als Sicherheitskopie zur Verfügung. Es muss daher unbedingt darauf geachtet werden, dass von Zeit zu Zeit auch die migrierten Daten gesichert werden: dies geschieht mit //BACKUP-FILES ... SAVE-OPTIONS=*PARAMETERS(SAVE-DATA=*S2-S1-S0)