Einschränkungen und Nacharbeiten

Dateien auf Net-Storage beim Umbenennen von SF- oder SM-Pubsets

Wenn es in einem Pubset Dateien gibt, die auf einem Standard-Net-Storage-Volume liegen, dann werden die zugehörigen Metadaten der Datei im lokalen Pubset und auf dem Net-Storage-Volume an den neuen Pubset-Namen angepasst.

Wenn es in einem Pubset Dateien gibt, die auf einem Net-Storage-Volume mit einer benutzer-definierten VSN liegen, dann werden die zugehörigen Metadaten der Datei auf dem Net-Storage-Volume an den neuen Pubset-Namen angepasst.

In beiden Fällen kann nach der Umbenennung ohne Einschränkung auf die Net-Storage-Dateien zugegriffen werden.

Die Verwaltung von Net-Storage ist im Handbuch „Systembetreuung“ [5] beschrieben.

Dateien auf Net-Storage beim Erzeugen von Spiegel-Pubsets

Wenn es in einem abgetrennten Pubset Dateien gibt, die auf einem Standard-Net-Storage-Volume liegen, dann werden die zugehörigen Metadaten der Datei nur im lokalen Pubset an den neuen Pubset-Namen angepasst.

Wenn es in einem Pubset Dateien gibt, die auf einem Net-Storage-Volume mit einer benutzer-definierten VSN liegen, dann werden die zugehörigen Metadaten der Datei nicht angepasst.

In beiden Fällen kann nach der Abtrennung auf die Net-Storage-Dateien nicht zugegriffen werden. Gegebenfalls müssen die Metadaten aus dem abgetrennten Pubset entfernt werden.

Ändern der Standardkatalogkennung

Die Standardkatalogkennung kann nur dann geändert werden, wenn die Benutzerkennung das Systemprivileg USER-ADMINISTRATION hat.

Besitzt die Benutzerkennung dieses Privileg nicht, wird über die Meldung PVR0200 entschieden, ob die Umbenennung trotzdem durchgeführt werden soll. In diesem Fall kann die Standardkatalogkennung nachträglich mit der Anweisung MODIFY-JOINFILE geändert werden, sobald die Benutzerkennung das Privileg besitzt.

Maximale Anzahl von Volumes

Eine Umbenennung von Punkt- nach PUB-Notation kann nur dann durchgeführt werden, wenn die Anzahl der Volumes nicht größer als 32 ist.

Eine Umbenennung von Punkt- nach Punktnotation ist nicht möglich, wenn die neue Katalogkennung vierstellig und die Anzahl der Volumes größer als 36 ist, da nur eine Stelle für die Folgenummer zur Verfügung steht.

Dateischutz mit GUARDS

Bei einem Guard kann man auch das Programm definieren, mit dem der Zugriff auf die Datei erfolgen darf (z.B. $TSOS.EDT). Dabei wird im GUARDS-Katalog auch die Katalogkennung gespeichert.

Wenn der Pubset umbenannt wird, auf dem das Programm liegt, ist die Zugriffsbedingung nicht mehr erfüllt: die Katalogkennung im GUARDS-Katalog und die Katalogkennung des Pubsets, auf dem das Programm jetzt liegt, stimmen nicht mehr überein.
In diesem Fall müssen die Zugriffsbedingungen für alle Guards, die diese Katalogkennung enthalten, geändert werden. Betroffen sind nicht nur die Guards auf dem umbenannten und dem Home-Pubset, sondern auch die Guards auf allen anderen Pubsets.

PVSREN bietet für dieses Problem keine Unterstützung.

Katalogkennung in Benutzerdateien

PVSREN ändert nicht die Katalogkennung in Benutzerdateien.

Enthält eine Benutzerdatei die Katalogkennung eines Pubsets, der umbenannt wird (z.B. in Prozeduren), muss diese Katalogkennung vom Dateieigentümer geändert werden, falls dies notwendig ist.

Katalogkennung in IMON-Dateien

Nach einer Software-Installation mit dem Installations-Monitor (IMON) wird der Ablageort der Installations-Items im Software-Configuration-Inventory (SCI) vermerkt. Dabei wird auch die Katalogkennung gespeichert.

Wird ein Pubset umbenannt, auf dem Software mit IMON installiert wurde, müssen alle SCIs geändert werden, in denen diese Software registriert ist. Das SCI des HOME- und des umbenannten Pubsets ändert PVSREN. Das SCI weiterer Pubsets muss mit /MODIFY-IMON-SCI manuell geändert werden. Dabei muss für OLD-NAME der Name des Pubsets vor der Umbenennung und bei NEW-NAME der Name des Pubsets nach der Umbenennung angegeben werden.

Shared-Pubset

PVSREN kann die MRSCAT-Einträge nur auf dem System ändern, auf dem die Umbenennung durchgeführt wird.

Da es bei einem Shared-Pubset auf allen Systemen, die diesen Pubset verwenden, einen MRSCAT-Eintrag für diesen Pubset gibt, müssen die MRSCAT-Einträge auf allen Remote-Systemen von der Systemverwaltung angepasst werden.

• Bei Pubsets muss der alte MRSCAT-Eintrag gelöscht und ein MRSCAT-Eintrag mit der neuen Katalogkennung angelegt werden. Für SM-Pubsets ist dabei der (ggf. ebenfalls neue) Name des Control-Volume-Sets anzugeben.

  Die MRSCAT-Einträge für die Volume-Sets eines SM-Pubsets müssen zusammen mit dem Pubset-Eintrag gelöscht werden (voreingestellt beim Kommando REMOVE-MASTER-CATALOG-ENTRY). Sie werden automatisch neu erzeugt. Siehe auch den Hinweis unten.

• Beim Umbenennen des Control-Volume-Sets muss der MRSCAT-Eintrag des Control-Volume-Sets gelöscht werden. Der Eintrag für den neuen Control-Volume-Set wird beim Importieren des SM-Pubsets automatisch neu angelegt. Siehe auch den Hinweis unten.

  Im MRSCAT-Eintrag des SM-Pubsets, zu dem der Control-Volume-Set gehört, muss zusätzlich mit /MODIFY-MASTER-CATALOG-ENTRY die neue Katalogkennung des Control-Volume-Sets eingetragen werden.

• Beim Umbenennen eines „normalen“ Volume-Sets muss nur der MRSCAT-Eintrag dieses Volume-Sets gelöscht werden. Er muss nicht neu angelegt werden, da dies beim Importieren des SM-Pubsets erfolgt. Siehe auch den folgenden Hinweis.

Ein Volume-Set kann dann nicht automatisch in den MRSCAT eingetragen werden, wenn dort bereits ein gleichnamiger SF-Pubset oder ein gleichnamiger Volume-Set eines anderen SM-Pubsets eingetragen ist. In diesem Fall muss der vorhandene Eintrag zuvor manuell aus dem MRSCAT gelöscht werden.

 

Storage-Klassen

Auf allen SM-Pubsets existieren Kataloge für Storage-Klassen und Volume-Set-Listen. Storage-Klassen haben keine direkten Bezüge zu Katalogkennungen. Volume-Set-Listen hingegen ordnen einer Storageklasse eine oder mehrere Voume-Sets zu. Die Einträge des Katalogs der Volume-Set-Listen enthalten daher ein oder mehrere Katalogkennungen von Volume-Sets des SM-Pubset.

Bei der Umbenennung eines Volume-Sets wird diese Umbennung auch im Volume-Set-Katalog nachgezogen, damit die Allokierung von Speicherplatz für Dateien über Storage-Klassen (explizit angegebene oder Default Storage-Klassen im Benutzerkatalog) auf dem Pubset durch die Umbenennung nicht beeinflusst wird.

Beim Erzeugen eines Pubsets aus einem Spiegel-Pubset können die Storage-Klassen des Ausgangs-Pubset wahlweise übernommen oder gelöscht werden. Dazu wird die beantwortbare Meldung PVR0207 ausgegeben. Bei Übernahme der Storage-Klassen werden die Volume-Set-Listen (wie bei der Umbenennung) an die Katalogkennungen der Volume-Sets des Ziel-Pubsets angepasst.

Startup-Parameterdatei

Beim Umbenennen eines Home- oder Paging-Pubsets muss ggf. die Startup-Parameterdatei angepasst werden. Sie kann neben den VSNs der Paging-Platten vollständige Dateinamen mit Katalogkennung enthalten.

SDF-Parameterdatei

Mit /MODIFY-SDF-PARAMETERS kann eine Syntaxdatei aktiviert und ihr Dateiname mit der Katalogkennung angegeben werden.

Mit /SHOW-SDF-PARAMETERS kann festgestellt werden, ob sich eine Syntaxdatei auf dem umbenannten Pubset befindet. Ist das der Fall, muss diese mit /MODIFY-SDF-PARAMETERS deaktiviert und mit dem neuen Dateinamen wieder aktiviert werden.

MIP-Parameterdatei

Mit /MODIFY-MIP-PARAMETERS kann eine Meldungsdatei aktiviert und ihr Dateiname mit der Katalogkennung angegeben werden.

Mit /SHOW-MIP-PARAMETERS kann festgestellt werden, ob sich eine Meldungsdatei auf dem umbenannten Pubset befindet. Ist das der Fall, muss diese mit /MODIFY-MIP-PARAMETERS deaktiviert und mit dem neuen Dateinamen wieder aktiviert werden.

SLED-Parameterdatei

Enthält der umbenannte Pubset eine SLEDFILE, die in der SLED-Parameterdatei referenziert wird, dann muss diese angepasst werden.

REPEAT-Jobs

REPEAT-Jobs, bei denen sich die Enterdatei auf dem umbenannten Pubset befindet, müssen neu gestartet werden.

Druckaufträge

Druckaufträge, die sich auf Dateien auf dem umbenannten Pubset beziehen, können nach der Umbenennung nicht mehr ausgeführt werden. Sie müssen gelöscht und neu gestartet werden.

 

Migrierte Dateien auf einem Pubset

Wenn ein SF-Pubset oder ein SM-Pubset umbenannt wird, auf dem migrierte Dateien vorhanden sind, muss das ARCHIVE-Directory mit dem Tool DIRCONV bearbeitet werden. PVSREN gibt keine Meldungen aus, die darauf hinweisen, dass auf dem Pubset migrierte Dateien vorhanden sind.

Beispiel

/START-DIRCONV
//RENAME-CATID DIRECTORY-NAME = <directory name>
               OLD-CATID = *BY-SPECIFICATION(CATID = <old catid>),
               NEW-CATID = <new catid>,
               NEW-DIRECTORY-NAME = <new directory name>
//END 

Danach muss das neu erzeugte Directory mit dem alten Directory vertauscht werden.

Wenn ein HSMS-CONTROLLED-Volume-Set (S1-Ebene) umbenannt wird, muss der S1-Volume-Set mit der HSMS-Anweisung MODIFY-SM-PUBSET-PARAMETERS geändert werden.

Fehlerbehandlung beim Erzeugen von Pubsets aus Spiegel-Pubsets

Wird von der PVSREN-Verarbeitung während Erzeugens eines Pubsets aus einem Spiegel-Pubset ein Fehler erkannt, so werden alle bereits durchgeführten Schritte zurückgesetzt.

Im Einzelnen:

• Falls BCVs im Rahmen der Verarbeitung abgetrennt wurden, wird die Spiegelung wieder aufgenommen. Andernfalls werden BCVs auf ihren Ausgangzustand zurückgesetzt.

• Für Snap- und Clone-Units wird die Sychronisation nicht wieder automatisch aufgenommen. Die Volumes behalten ihren aktuellen Zustand bei.

• Wenn PVSREN eine Snap-Session erzeugt hat, so wird diese wieder abgebaut.

Bei einer Systembeendigung während des Erzeugens eines Pubset können sich die Volumes des neu zu erzeugenden Pubsets in einem inkonsistenten Zustand befinden.

Zum Wiederaufsetzen ist es erforderlich,

• BCVs mit Hilfe des SHC-OSD-Kommandos /RESUME-MULTI-MIRRORING wieder mit den Standardvolumes zusammenzuführen.

• Clone- bzw. Snap-Sessions mit den SHC-OSD-Kommandos /START-CLONE-SESSION bzw. /START-SNAP-SESSION neu zu starten.

Falls Pubsets aus bereits abgetrennten BCVs, Clone-Units oder Snap-Units erzeugt werden sollen, ist der Ausgangszustand auf diese Weise nicht mehr rekonstruierbar. In diesem Fall sollte vor dem Erzeugen der neuen Pubsets eine Sicherung des Stands der BCVs, Clone-Units oder Snap-Units durchgeführt werden.

Eine Restart-Funktion, wie beim Umbenennen von Pubsets, wird nicht angeboten.

 

Anpassung der Speicherebenen S1 und S2 beim Erzeugen von Pubsets aus Spiegel-Pubsets

Die Backup-Archive für den Pubset werden neu initialisiert, da es sich um einen neuen Pubset handelt.

Migrationsarchive werden von PVSREN an die neue, erweiterte Umgebung angepasst. Für SF-Pubsets existiert entweder ein globales Migrationsarchiv oder, bei der empfohlenen „dezentralen“ Organisation, ein pubsetspezifisches Migrationsarchiv.
SM-Pubsets haben stets eigene Migrationsarchive, deren Directories im SM-Pubset liegen, d.h. bei Migration nach S1 liegt auch das entsprechende Migrationsarchiv im Pubset.

Trotz der Unterschiede zwischen SF- und SM-Pubsets kann die Anpassung der Migrationsarchive nach einer Pubset-Erzeugung aus Spiegel-Pubsets im Wesentlichen auf die gleiche Weise erfolgen.

Die Anpassung erfolgt in folgenden Schritten:

1. Das Migrationsdirectory für den Ausgangs-Pubset wird als Datei kopiert. In dieser Datei wird mit DIRCONV die Katalogkennung des Ausgangspubset in die Katalogkennung des neuen Pubset umbenannt. (Es wird vorausgesetzt, dass diese Katalogkennung nicht im Directory vorhanden ist.)

2. Als vorübergehende Hilfskonstruktion wird das kopierte Directory mit der umbenannten Katalogkennung als Directory des Archivs SYSBACKUP eingesetzt.

3. Für den neuen Pubset wird nun, falls es sich um einen SM-Pubset oder um einen SF-Pubset mit dezentraler Organisation handelt, ein neues Migrationsarchiv definiert. An dieser Stelle sollten auch nicht mehr benötigte, migrierte Dateien gelöscht werden.

4. Für den neuen Pubset wird die HSMS-Anweisung REPAIR-CATALOG-BY-RESTORE aufgerufen. Dort wird für alle migrierten Dateien geprüft, ob der Verweis im Katalog gültig ist; dies ist hier aber nicht der Fall. Dann wird SYSBACKUP ins Migrationsarchiv kopiert und der Verweis im Katalogeintrag wird aktualisiert.

5. Das als Hilfskonstruktion genutzte Directory (siehe Schritt 2) wird gelöscht. Seine Nutzung als SYSBACKUP wird beendet.