Der Benutzer kann auch ohne ausdrücklichen HSMS-Aufruf eine verdrängte Datei zurückholen. Wenn der Benutzer bzw. ein Benutzerprogramm auf eine verdrängte Datei zugreifen will, stellt das Datenverwaltungssystem (DVS) des BS2000 durch den Katalogeintrag fest, dass diese Datei nicht auf der Verarbeitungsebene verfügbar ist, sondern erst zurückgeholt werden muss. Beim Anfordern einer Datei mittels /SECURE-RESOURCE-ALLOCATION mit Wartezeit und bei Zugriffen wie OPEN INPUT, INOUT oder UPDATE holt das DVS die Datei dann automatisch (implizit) zurück.
Beim impliziten Zurückholen wird die Datei aus der letzten Sicherungsdatei (auch Kopie) auf der Speicherebene geholt, die im Katalog eingetragen ist.
Die Bearbeitung beim impliziten Zurückholen ist davon abhängig, ob der Zugriff auf die Datei durch das Kommando SECURE-RESOURCE-ALLOCATION oder durch ein OPEN erfolgte. Die Anforderung mit dem Kommando
/SECURE-RESOURCE-ALLOCATION FILE=<dateiname>,WAIT=...
mit Wartezeit vor Beginn der Verarbeitung hat folgende Vorteile:
Alle für einen Job benötigten Dateien (bis zu 48) können mit einem Kommando angefordert und mit einem Auftrag zurückgeholt werden. Dadurch sind weniger HSMS-Aufrufe und evtl. weniger Bandanforderungen erforderlich.
Es existiert ein definierter Wartepunkt, nachdem die Verarbeitung entweder starten kann oder abgebrochen werden muss. „Unliebsame Überraschungen“ während der Verarbeitung durch fehlende Dateien lassen sich so vermeiden.
Für dermaßen angestoßene Zurückholaufträge gibt das HSMS einen zusammenfassenden Report aus, der sonst bei implizitem Zurückholen nur im Fehlerfall ausgegeben wird.
Die Wartezeit mit dem WAIT-Operanden sollte so lang gewählt werden, dass auch Zugriffe auf S2 in dieser Zeit möglich sind. Ohne Angabe einer Wartezeit meldet das DVS einen Fehler bei der Reservierung der Datei.
Wenn der Rückholauftrag nach einem OPEN gestartet wird, sind folgende Fälle zu unterscheiden:
Zurückholen im Dialog von der Speicherebene S1:
Das Zurückholen wird immer ausgeführt; es wird keine Meldung ausgegeben.Zurückholen im Dialog von der Speicherebene S2:
HSMS gibt zuerst eine Meldung aus, dass ein Zugriff auf die Speicherebene S2 erforderlich ist und fragt den Benutzer, ob das Zurückholen gestartet werden soll.
Wenn der Benutzer einverstanden ist oder nicht innerhalb der voreingestellten Wartezeit antwortet, gibt HSMS eine zweite Meldung aus. Anschließend startet HSMS das Zurückholen, das dann nicht mehr unterbrochen werden kann.
Wenn der Benutzer mit dem Zurückholen nicht einverstanden ist, wird das Zurückholen nicht gestartet und der Zugriff auf die Datei wird abgewiesen.Der HSMS-Verwalter kann das Verhalten von HSMS beeinflussen. Er kann den Unterbrechungsmechanismus mit dem Operanden CANCEL-AT-RECALL der HSMS-Anweisung MODIFY-HSMS-PARAMETERS ausschalten: HSMS gibt dann keine Meldung aus und das Zurückholen wird immer gestartet. Außerdem kann der HSMS-Verwalter die maximale Wartezeit mit dem Operanden MAXIMUM-WAIT-TIME zwischen 10 Sekunden und 60 Minuten einstellen. Der Unterbrechungsmechanismus sollte aber so eingestellt werden, dass er bereits nach einer kurzen Wartezeit ausgelöst wird.
Zurückholen im Stapelbetrieb:
Das Zurückholen wird immer durchgeführt.Beim Zurückholen wird die Datei zuerst unter den Speicherplatz der Benutzerkennung SYSHSMS importiert, bevor die Zuweisung auf die endgültige Benutzerkennung geändert wird. Deshalb muss für die Benutzerkennung SYSHSMS genügend Speicherplatz vorgesehen werden – auch für sehr große Dateien. Beim Einrichten der Benutzerkennung SYSHSMS sollte aus diesem Grund die Speicherplatzerweiterung (PUBLIC-SPACE-EXCESS) zugelassen werden.
Wenn im Dialog gearbeitet wird, werden Dateien nur während der festgelegten Bandverarbeitungszeiten automatisch von der Speicherebene S2 zurückgeholt; ansonsten wird beim Zugriff auf eine verdrängte Datei eine Fehlermeldung ausgegeben.
Backup-Server nutzen
Ab HSMS V11.0 kann für das implizite Zurückholen von Dateien, die von Shared-Pubsets verdrängt wurden, der vereinbarte Backup-Server genutzt werden (siehe Abschnitt „Backup-Server“). Dazu muss für das Archiv-Attribut BACKUP-SERVER-USAGE des zugewiesenen Standard-Systemarchivs SYSMIGRATE in der entsprechenden Pubset-Umgebung ein entsprechender Wert vereinbart werden.
In einer SF-Pubset-Umgebung ist SYSMIGRATE ein Pubset-spezifisches, oder falls nicht definiert, ein global definiertes Migrations-Archiv. In einer SM-Pubset-Umgebung ist SYSMIGRATE immer ein Pubset-spezifisches Migrations-Archiv.
Mit der Einstellung BACKUP-SERVER-USAGE=*STD wird, falls definiert, der im lokalen System vereinbarte Backup-Server genutzt.
Mit der Einstellung BACKUP-SERVER-USAGE=*‘NO wird die Backup-Server-Funktionalität nicht genutzt, selbst wenn im lokalen System ein Backup-Server vereinbart ist. Die Verarbeitung erfolgt im Master- bzw. Slave-Modus.
Wenn kein Standard-Systemarchiv SYSMIGRATE definiert ist, erfolgt das Zurückholen ebenfalls im Master- bzw. Slave-Modus.