Beispielszenario

Bei der Konvertierung von SF- zu SM-Pubsets wird es i.A. nicht genügen, die SMPGEN-Funktionen CREATE- bzw. MODIFY-SYSTEM-MANAGED-PUBSET aufzurufen. Vielmehr hat der Systembetreuer die Aufgabe, durch vorbereitende Aktionen die Konvertierung für die Anwender möglichst problemlos zu gestalten. Im Anschluss an den SMPGEN-Lauf müssen u.U. noch Nacharbeiten erledigt werden, um den neuen SM-Pubset wie gewünscht betreiben zu können.
Insbesondere sind die von SMPGEN erzeugten Pubsets noch nicht HSMS-unterstützt. Um migrierte Dateien bearbeiten zu können, muss erst eine HSMS-Umgebung hergestellt werden. In Abhängigkeit von der Komplexität der bestehenden HSMS-Umgebungen gibt es verschiedene Möglichkeiten der Umstellung der HSMS-Umgebung, die ebenfalls verschiedene Vorbereitungen erfordern; siehe dazu Handbuch „System Managed Storage“ [8].

Im Folgenden wird dargestellt, welche Aktionen bei der Konvertierung zu SM-Pubsets notwendig und sinnvoll sein können:

• Falls mehrere SF-Pubsets zusammengefasst werden sollen, ist es u.U. sinnvoll, zunächst einen Konsistenz-Check auszuführen. Er soll herausfinden, ob eine Konvertierung möglich ist.

• Soll eine Konvertierung erfolgen, so werden die Anwender darüber benachrichtigt, dass in allen BS2000-Prozeduren Verweise auf ehemalige Pubset-Kennungen durch eine Referenz auf die neue Pubset-Kennung zu ersetzen sind.

  Normalerweise sind die Anwender davon nur wenig betroffen, da sie die Dateien über die Standard-Katalogkennung im Benutzerkatalog adressieren.
  Auch Datenhaltungssysteme sind i.A. wenig betroffen, da sie eine Oberfläche besitzen, die durch eine spezifische Adressierungslogik die Lage der Datei vor dem Anwender verbirgt.
  Falls Anwendungen existieren, die mit bestimmten Pubsets arbeiten sollen, müssen sie beim Anlegen der Dateien neben der Pubset-Kennung des SM-Pubsets in Zukunft die betreffende Volume-Set-Kennung oder eine den gewünschten Volume-Set referenzierende Storage-Klasse angeben. Die Angabe einer Volume-Set-Kennung ist jedoch nur zulässig, wenn die entsprechende Benutzerkennung das Recht auf physikalische Allokierung im Pubset hat. Dieses Recht muss der Benutzerkennung im Anschluss an die Konvertierung explizit erteilt werden.

  Falls nur ein SF-Pubset umgewandelt werden soll, ist es sinnvoll, diesen Pubset zunächst mittels PVSREN umzubenennen und die ehemalige Pubset-Kennung als Pubset-Kennung des SM-Pubsets anzugeben. Dadurch ist gewährleistet, dass sich die Katalogkennung in den Dateinamen nicht ändert und die JCL der Anwender nicht angepasst werden muss. Ebenso kann die Katalogkennung als Standard-Katalogkennung im Benutzerkatalog beibehalten werden.

  Analog kann verfahren werden, wenn mehrere SF-Pubsets zusammengefasst werden sollen, aber eines davon eine ausgezeichnete Rolle im System spielt; es kann dann sinnvoll sein, diesen Pubset umzubenennen und seine ehemalige Pubset-Kennung als Pubset-Kennung des SM-Pubsets anzugeben.

  Der Control-Volume-Set sollte möglichst ausfallsicher und deshalb auch nicht allzu groß sein. Auf jeden Fall muss er jedoch genug Platz für die neu anzulegenden Kataloge bieten (siehe Beschreibung im Abschnitt „Erzeugen neuer SM-Pubsets").

• Falls bereits ein Konsistenz-Check erfolgt ist und Konflikte bei Dateinamen oder Guards ermittelt wurden, fordert der Systembetreuer die Anwender auf, sie zu beseitigen.

• Der Systembetreuer beseitigt die Namenskonflikte bei Systemdateien. Systemdateien, die im SVL verankert sind (IPL, SLEDSAVE usw.), sollten nicht gelöscht, sondern entweder umbenannt oder mit der SIR-Anweisung DELETE-IPL-FACILITY entfernt werden.
  Zur Lösung von Namenskonflikten bei (HSMS-) Migration-Directories sind die Directories umzubenennen und die zugehörigen Archivdefinitionen den neuen Directory-Namen anzupassen.

• Paging-Dateien müssen ggf. mit /REDUCE-PAGING-AREA deaktiviert werden.

• Der Systembetreuer prüft, ob zu den SF-Pubsets Snapsets existieren. Wenn dies der Fall ist, löscht er die Snapsets.

• Der Systembetreuer bereitet die Eingaben für den SMPGEN-Lauf und evtl. eine Prozedur zum Importieren des SM-Pubsets vor.

• Falls der SM-Pubset mit HSMS-Unterstützung betrieben werden soll (immer notwendig, falls migrierte Dateien existieren), bereitet der Systembetreuer die Umstellung bzw. Anpassung der HSMS-Umgebung vor.
  (Die Katalogeinträge der migrierten Dateien bleiben bei der Umstellung erhalten, doch ist kein Recall dieser Dateien möglich, solange keine HSMS-Unterstützung etabliert ist. Auch existiert zunächst noch keine Backup-Umgebung. Es ist kein direkter Zugriff auf vorangegangene Dateisicherungen möglich.)

• Eventuell ist ein erneuter Konsistenz-Check im Offline-Modus sinnvoll. Die Anwender werden ggf. zur Beseitigung von Inkonsistenzen aufgefordert.

• Sind alle Inkonsistenzen beseitigt, so kann zu einem mit den Anwendern vereinbarten Zeitpunkt, zu dem die SF-Pubsets nicht in Betrieb sind, mit der Konvertierung zu SM-Pubsets begonnen werden.

  Eventuell sind letzte Vorbereitungen für die Umstellung der HSMS-Umgebung erforderlich, z.B. die Verlagerung der auf die S1-Ebene migrierten Dateien auf die S2-Ebene, damit eine ordnungsgemäße Konvertierung erfolgen kann.

  Zunächst wird eine logische Vollsicherung und eine FDDRL-Sicherung der Pubsets erstellt. Anschließend werden die Pubsets mit der SMPGEN-Anweisung CREATE- bzw. MODIFY-SYSTEM-MANAGED-PUBSET konvertiert.

  Falls zu diesem Zeitpunkt noch oder schon wieder Inkonsistenzen bestehen, werden sie aufgelistet; es erfolgt keine Konvertierung, die Pubsets bleiben als SF-Pubsets importierbar.

• Nach erfolgreicher Konvertierung sind in den Benutzerkatalogen aller Systeme, in denen der Pubset importiert werden soll, die Standard-Katalogkennungen, die den Volume-Set-Kennungen entsprechen, durch die Pubset-Kennung des SM-Pubsets zu ersetzen.

• In den Guards anderer Pubsets, in denen auf ein Programm im neuen SM-Pubset Bezug genommen wird, muss der Programmname modifiziert werden. Der Systembetreuer kann den Anwendern eine entsprechende SDF-P-Prozedur zur Verfügung stellen.

• Der neue SM-Pubset kann jetzt normal importiert werden, wobei ACTUAL-JOIN=*STD gelten muss.
  Ein erweiterter SM-Pubset muss erneut importiert werden, um noch nach dem SMPGEN-Lauf ausstehende Recovery-Maßnahmen durchzuführen. Auch hier ist ACTUAL-JOIN=*STD (Default-Wert) anzugeben.
  SIZE-TOLERANCE=*YES muss, falls nötig, zuvor im MRSCAT-Eintrag des SM-Pubsets eingetragen werden (mit /MODIFY-PUBSET-CACHE-ATTRIBUTES) und gilt dann einheitlich für alle Volume-Sets.

• Falls der SM-Pubset Volume-Sets mit USAGE=*WORK enthalten soll, müssen diese mit /MODIFY-PUBSET-DEFINITION-FILE dem importierten Pubset hinzugefügt und mit /MODIFY-PUBSET-PROCESSING in Betrieb genommen werden.

• Jetzt kann - falls gewünscht - die HSMS-Unterstützung und -Umgebung etabliert bzw. angepasst werden.

• Die Kontingente und pubset-weiten Berechtigungen können den speziellen Bedingungen angepasst werden, z.B. durch Einschränkung der Work-Kontingente. Gruppen können erzeugt bzw. die Gruppenkonstellation vervollständigt werden. Falls gewünscht, können die gruppenspezifischen Kontingente geändert werden.

• Falls gewünscht, kann das Standard-Dateiformat (FILE-FORMAT) geändert werden.

• Falls Guard-Bedingungsfehler gemeldet wurden, müssen die Guard-Eigentümer die betreffenden Guard-Einträge überprüfen und ggf. an die neue Pubset-Kennung anpassen.

• Falls auf einem der konvertierten SF-Pubsets Software mit IMON installiert wurde und sich die Katalogkennung der installierten Dateien geändert hat, muss das Software-Configuration-Inventory (SCI) mit /MODIFY-IMON-SCI geändert werden. Dabei muss für OLD-NAME der Name des SF-Pubsets vor der Konvertierung und bei NEW-NAME der Name des SM-Pubsets angegeben werden.

• Nach erfolgreicher Pubset-Konvertierung benachrichtigt der Systembetreuer die Anwender.