Bei der Einführung der Verdrängung sind bestimmte Maßnahmen zu treffen:
Nicht alle Dateien dürfen dem Verdrängungsmechanismus unterliegen. Der HSMS-Verwalter sollte die Hinweise im Abschnitt „Ausnahmedatei“ beachten, alle Benutzer die Hinweise im Abschnitt „Migrationssperre“.
Es muss unbedingt beachtet werden, dass in vielen Fällen Dateien für sehr lange Zeit migriert bleiben. Es wird zwar empfohlen nur Dateien zu migrieren, die bereits gesichert worden sind (dies wird gewährleistet durch den HSMS-Parameter MIGRATION-CONTROL(BACKUP-MANDATORY=*YES), allerdings werden diese Sicherungen nach Ablauf der Retention-Period obsolet und werden aus dem Backup-Archiv gelöscht (//MODIFY-ARCHIVE SAVE-FILE=*DELETE). Ab diesem Zeitpunkt liegt keine Kopie der Datei mehr vor.
Deshalb sollten die migrierten Dateien, wenn die Sicherungszeitfenster es zulassen, wenigstens von Zeit zu Zeit Sicherungen der Migrations-Archive durchgeführt werden: BACKUP-FILES ... SAVE-OPTIONS=*PARAMETER(SAVE-DATA=*S2-S2-S0). So kann gewährleistet werden, dass stets Kopien der Daten von allen Speicherebenen existieren. Versions-Backup kann dazu auch verwendet werden.
Abgesehen davon sollte HSMS möglichst frühzeitig nach der Systemeinleitung gestartet werden, um das Zurückholen der Dateien so schnell wie möglich zu gewährleisten.
Jobs, die bisher mit /SHOW-FILE-ATTRIBUTES oder /ADD-FILE-LINK geprüft haben, ob während des Ablaufs benötigten Dateien vorhanden sind, sollten dies stattdessen mit /SECURE-RESOURCE-ALLOCATION mit Wartezeit tun (siehe Abschnitt „Implizites Zurückholen bei Dateizugriff“).
Anwendungen, die den Internen Dateinamen (CFID) zur Prüfung und Bearbeitung von Dateien (z.B. UPAM) benutzen, müssen Folgendes beachten: Der Vergleich des Katalogeintrags vor und nach dem OPEN ist nicht zulässig, da beim OPEN auf eine verdrängte Datei diese zurückgeholt und der Interne Dateiname (CFID) dabei geändert wird. Beim Absetzen eines FSTAT-Makros vor der Verarbeitung darf man sich also den Katalogeintrag nicht für eine Prüfung merken. Besser ist ein /SECURE-RESOURCE-ALLOCATION mit Wartezeit, da die Datei dann bereits zurückgeholt wird.
Für die Benutzerkennung SYSHSMS sollte der Speicherplatz (PUBLIC-SPACE-LIMIT) nicht begrenzt werden, wenn sehr große Dateien implizit zurückgeholt werden. Beim Zurückholen wird die Datei auf dem Pubset, auf der sie vor der Migration lag, zuerst unter der Benutzerkennung SYSHSMS importiert, bevor die Zuweisung auf die endgültige Benutzerkennung geändert wird. Beim Einrichten der Benutzerkennung SYSHSMS sollte aus diesem Grund die Speicherplatzerweiterung (PUBLIC-SPACE-EXCESS) zugelassen werden
Hinweis
Im Anhang sind die Informationen, die Benutzer vor der Einführung der Verdrängung erhalten sollten, noch einmal gesondert gesammelt. Deshalb ist der Anhang vom Kopierverbot ausgenommen. Der Systemverwalter darf Kopien an zukünftige Benutzer bzw. von der Verdrängung betroffene Benutzer verteilen.