Pubset importieren
Komponente: | BS2000 |
Funktionsbereich: | Pubset- und MRSCAT-Verwaltung |
Anwendungsbereich: | MULTI-CATALOG-AND-PUBSET-MGMT |
Privilegierung: | TSOS |
Berechtigungsschlüssel: | R |
Funktionsbeschreibung
Das Kommando erzeugt unter der Steuerung der aufrufenden Task eine eigene Task, die asynchron zur aufrufenden Task die IMPORT-Verarbeitung durchführt. Diese Task fordert sämtliche Betriebsmittel an.
Beim Importieren eines SM-Pubsets wird für jeden zugehörigen Volume-Set eine eigene Import-Verarbeitung durchgeführt.
Die F5-Kennsätze werden eingelesen und ggf. rekonstruiert. Die mnemotechnischen Namen der zum Pubset gehörenden Platten werden im SVL der Systemplatte (Pubres) eingetragen bzw. aktualisiert. Der Name der Systemplatte wird im MRSCAT-Eintrag des Pubsets hinterlegt. Der Benutzerkatalog wird eröffnet und der angegebene Pubset auf „erreichbar“ gesetzt. Dabei werden die Benutzertabellen im Speicher aufgebaut, die die aktuellen Benutzerinformationen enthalten. Danach sind Zugriffe auf diesen Pubset erlaubt. In Abhängigkeit der Angaben, die die Systembetreuung im Kommando ADD-MASTER-CATALOG-ENTRY getroffen hat, wird das automatische Starten von SPEEDCAT mit oder ohne Taskwechsel unterstützt. SPOOL wird benachrichtigt und die SPOOLOUT-Aufträge werden in den TYPE5/KP bzw. TYPE4 übernommen. Benutzeraufträge, die sich im Wartezustand HELD-BY-CALENDAR bzw. HELD-BY-PUBSET befinden, weil der importierte Pubset bisher nicht verfügbar war, werden wieder freigegeben.
Beim Importieren mit ACTUAL-JOIN=*FIRST bleiben alle Dateien und Jobvariablen der Benutzerkennung TSOS erhalten. Dateien und Jobvariablen aller anderen Benutzer werden gelöscht.
Die Änderung der Verfügbarkeit eines Pubsets wird an alle aktiven Rechner eines Rechnerverbundes gemeldet.
Es können mehrere verschiedene Pubsets an einen Rechner importiert werden.
Format
IMPORT-PUBSET | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Operandenbeschreibung
PUBSET = <cat-id 1..4>
Katalogkennung des Pubsets, der importiert werden soll.
ACTUAL-JOIN = *STD / *ZIP / *FIRST
Legt die Behandlung des Benutzerkataloges beim Importieren fest.
ACTUAL-JOIN = *STD
Die Wirkung des Operanden ist abhängig vom Operanden RECONSTRUCT-USERCAT. Mit RECONSTRUCT-USERCAT=*NO wird der bestehende Benutzerkatalog
($TSOS.SYSSRPM) eröffnet. Die Wirkung der Operandenwerte *RESET und *BACKUP ist beim Operanden RECONSTRUCT-USERCAT beschrieben.
ACTUAL-JOIN = *ZIP
Der Operandenwert darf nur bei Platten-Speicherplatz-Problemen angegeben werden, um dabei zu vermeiden, dass von der Benutzerkatalogverwaltung eine Logging-Datei und die .BACKUP-Datei des Benutzerkatalogs angelegt wird.
Ansonsten ist die Behandlung dieses Operandenwertes identisch mit Operandenwert *STD, d.h. die Bearbeitung ist abhängig vom Wert des Operanden RECONSTRUCT-USERCAT.
ACTUAL-JOIN = *FIRST
Erzeugt einen neuen Benutzerkatalog, der nur die Benutzerkennungen des Systems enthält. Die Daten der Benutzerkennung TSOS bleiben erhalten. Der Operand RECONSTRUCT-USERCAT wird ignoriert.
MONJV = *NONE / <filename 1..54 without-gen-vers>
Vereinbart, ob eine überwachende Jobvariable versorgt wird, die während des Importierens auf folgende Werte gesetzt wird:
$I | zu Beginn des Importierens |
| $R | am Ende des Importierens, wenn der gesamte Pubset erfolgreich importiert wurde |
| $A | wenn das Importieren fehlerhaft abgebrochen wurde |
| $W | wenn ein Shared-Pubset importiert wurde und die Verfügbarkeit von dem Master-Rechner noch nicht bestätigt wurde |
Die Angabe des Operanden ist nur sinnvoll bei Einsatz des Software-Produktes JV.
Hinweise
- Die angegebene Jobvariable wird nur zur überwachenden Jobvariable, wenn der Pubset noch nicht importiert war.
- Die Jobvariable muss bereits katalogisiert sein, andernfalls wird sie nicht versorgt. Die IMPORT-Verarbeitung wird aber auch bei nicht definierter Jobvariable fortgeführt.
JV-PASSWORD = *NONE / <c-string 1..4> / <x-string 1..8> / <integer -2147483639..2147483639>
Kennwort der Jobvariablen, falls diese mit einem Schreibschutz versehen ist. Der Operand JV-PASSWORD hat folgende Besonderheiten:
Der eingegebene Wert wird nicht protokolliert.
Im geführten Dialog ist das Eingabefeld automatisch dunkelgesteuert.
Bei Angabe von *SECRET oder ^ stellt SDF im ungeführten Dialog und in Vordergrundprozeduren ein dunkelgesteuertes Eingabefeld zur verdeckten Eingabe des Kennwortes zur Verfügung.
RESIDENT-BUFFERS = *STD / *NO / *YES
Vereinbart, ob residente oder nicht-residente Puffer angelegt werden sollen (siehe auch „Hinweise" im Abschnitt "IMPORT-PUBSET").
RESIDENT-BUFFERS = *STD
Es gilt die Angabe im MRSCAT-Eintrag.
RESIDENT-BUFFERS = *NO
Es wird ein nicht-residenter Puffer angelegt.
RESIDENT-BUFFERS = *YES
Es wird ein residenter Puffer angelegt.
NUMBER-OF-BUFFERS = *STD / <integer 1..255>
Legt die Anzahl der Puffer fest.
NUMBER-OF-BUFFERS = *STD
Es gilt die Angabe im MRSCAT-Eintrag.
NUMBER-OF-BUFFERS = <integer 1..255>
Es wird die angegebene Anzahl angelegt; Minimum: 6 (siehe auch „Hinweise" im Abschnitt "IMPORT-PUBSET").
USE = *STD / *SHARE / *EXCLUSIVE(...) / *FROM-REMOTE(...)
Definiert den Zugriffsmodus auf den importierten Pubset.
Dabei sind die notwendigen Bedingungen und Voraussetzungen zu beachten.
USE = *STD
Es gilt die Angabe im MRSCAT-Eintrag.
USE = *SHARE
Diese Angabe dieses Wertes ist nur sinnvoll bei gegebener Sharability-Einstellung im MRSCAT. Der Pubset soll als Shared-Pubset importiert werden.
USE = *EXCLUSIVE(...)
Der Pubset soll exklusiv importiert werden. Zur Durchführung einer Rekonstruktion kann auch ein Volume-Set importiert werden.
CONVERT-VOLUME-SET = *NO / *YES
Gibt an, ob ein normaler Import durchgeführt oder der Volume-Set eines zerstörten SM-Pubsets in ein SF-Pubset konvertiert werden soll.
CONVERT-VOLUME-SET = *NO
Es soll ein normaler Import durchgeführt werden.
CONVERT-VOLUME-SET = *YES
Im Operanden PUBSET wurde ein Volume-Set angegeben, das in einen SF-Pubset konvertiert werden soll. Mit dieser Funktion können die Daten von Volume-Sets eines SM-Pubsets, dessen Control-Volume-Set nicht mehr funktionsfähig ist, wieder zugreifbar gemacht werden. Zu beachten ist auch "Hinweis zum Importieren eines Volume-Set mit Konvertierung in einen SF-Pubset" im Abschnitt "IMPORT-PUBSET".
USE = *FROM-REMOTE(...)
Macht den Katalog eines remote-importierten Pubsets verfügbar, wenn nach dem Start des HIPLEX-MSCF-Verbundes MRSCAT-Einträge definiert werden.
HOST-NAME = *NONE / <alphanum-name 1..8>
BCAM-Name des Partnerrechners, der Eigentümer des Pubsets ist. Zu diesem Rechner muss eine MSCF-Verbindung bestehen.
SHARER-TYPE = *STD / *SLAVE / *MASTER(...)
Die Angabe dieses Operanden ist nur sinnvoll bei gegebener Sharability-Einstellung im MRSCAT. Vereinbart die Eigentümerschaft des Pubsets.
Dabei sind die notwendigen Bedingungen und Voraussetzungen zu beachten.
SHARER-TYPE = *STD
Das System wählt die Einstellung anhand der Eigenschaften des Pubsets automatisch:
Wenn der Shared Pubset bereits einen Master besitzt, oder explizit ein anderes System als Master voreingestellt ist (mit /SET-PUBSET-ATTRIBUTES), wählt das System SHARER-TYPE=*SLAVE.
In allen anderen Fällen wählt es SHARER-TYPE=*MASTER.
SHARER-TYPE = *SLAVE
Die eigene Anlage soll Slave-Sharer werden.
SHARER-TYPE = *MASTER(...)
Die eigene Anlage soll die Eigentümerschaft über den zu importierenden Pubset übernehmen.
MASTER-CHANGE = *NO
Die eigene Anlage soll die bislang noch nicht vergebene Eigentümerschaft
übernehmen. Das Kommando wird abgewiesen, wenn der Pubset bereits importiert ist.
MASTER-CHANGE = *YES
Mit dieser Angabe kann die Systembetreuung nach einem Ausfall des Masters, oder nachdem am Master ein EXPORT-PUBSET-Kommando mit MASTER-CHANGE=*YES gegeben wurde, explizit an einem Slave-Rechner den Master-Wechsel einleiten.
Der explizite Master-Wechsel ist nicht möglich, wenn BACKUP-MASTER=*NONE und ALTERNATE-BACKUP=*NONE vereinbart wurde (siehe Kommando SET-PUBSET-ATTRIBUTES).
Der explizite Master-Wechsel ist in folgenden Situationen anwendbar:
Der automatische durch Watchdog eingeleitete Master-Wechsel am vorbestimmten Backup-Master wurde mit Fehler abgewiesen.
Der automatische Master-Wechsel wird durch die Einstellung BACKUP-MASTER= *NONE und ALTERNATE-BACKUP=*BY-OPERATOR verhindert.
SESSION-CHECK-MSG = *YES / *NO
Legt fest, ob eine Meldung ausgegeben werden soll, wenn bei der Import-Verarbeitung festgestellt wird, dass der Pubset bereits an einem anderen System importiert ist oder dass der letzte Systemlauf fehlerhaft beendet wurde.
SESSION-CHECK-MSG = *YES
Wenn die Prüfung ergibt, dass der Pubset bereits an einem anderen System importiert bzw. dass der letzte Systemlauf fehlerhaft beendet wurde, wird die Meldung DMS038C ausgegeben.
SESSION-CHECK-MSG = *NO
Die Überprüfung wird bei einem Import-Auftrag für ein Daten-Pubset ausgeschaltet und die Ausgabe der Meldung DMS038C unterdrückt.
Diese Option sollte von der Systembetreuung allerdings nur genutzt werden, wenn das System mit automatischem Startup geladen wird.
RECONSTRUCT-USERCAT = *NO / *RESET / *BY-BACKUP(...)
Der Operand ermöglicht es dem Aufrufer des Import, den Benutzerkatalog auf der Basis eines gesicherten Standes vollständig bzw. auf Basis der im TSOSCAT bekannten Benutzerkennungen rudimentär neu aufzubauen. Dieser Operand wird nur für die Einstellungen ACTUAL-JOIN=*STD/*ZIP ausgewertet; für ACTUAL-JOIN=*FIRST wird er ignoriert.
RECONSTRUCT-USERCAT = *NO
Es findet keine Rekonstruktion statt.
RECONSTRUCT-USERCAT = *RESET
Der Benutzerkatalog wird neu aufgebaut. Die Benutzerkennungen werden dem aktuellen TSOSCAT entnommen. Die Einträge werden zurückgesetzt.
RECONSTRUCT-USERCAT = *BY-BACKUP(...)
Der Benutzerkatalog wird auf Basis eines vorher mit ARCHIVE gesicherten und wieder eingespielten Backup-Benutzerkatalogs ($TSOS.SYSSRPM.BACKUP) neu aufgebaut.
SCOPE = *ALL / BACKUP / *TSOSCAT
Die festzulegenden Angaben vereinbaren die Behandlung von Benutzerkennungen, die nur im Backup bzw. nur im TSOSCAT bekannt sind.
SCOPE = *ALL
Es werden alle Einträge des Backup übernommen. Die darüber hinaus im TSOSCAT bekannten Benutzerkennungen werden neu eingerichtet.
SCOPE = BACKUP
Die Einträge im Backup bestimmen die Menge der Benutzerkennungen. Dateien nicht darin enthaltener Benutzerkennungen werden gelöscht.
SCOPE = *TSOSCAT
Die Einträge im TSOSCAT bestimmen die Menge der Benutzerkennungen. Nur die darin bekannten Benutzerkennungen werden aus dem Backup übernommen bzw. neu eingerichtet.
RECONSTRUCT-F5-LABEL = *NO / *YES
Legt fest, ob eine F5-Label- Rekonstruktion explizit angestartet werden soll.
RECONSTRUCT-F5-LABEL = *NO
Es wird explizit keine F5-Label-Rekonstruktion angestartet. Unabhängig davon kann das System jedoch intern eine Rekonstruktion veranlassen (z.B. nach einem Crash). Außerdem erfolgt auch eine Rekonstruktion, wenn eine Überprüfung der TSOSCAT-Benutzerketten angefordert wurde (Operand REPAIR-TSOSCAT=*YES) .
RECONSTRUCT-F5-LABEL = *YES
Es wird in jedem Fall eine F5-Label- Rekonstruktion durchgeführt. Bei einem SM-Pubset werden dabei alle Volume-Sets erfasst.
DEFECT-VOLUME-SET = *NONE / list-poss(256): <cat-id 1..4>
Dieser Operand wird nur bei SM-(System-Managed-)Pubsets ausgewertet, die exklusiv bzw. als Master importiert werden.
Der Operand legt fest, welche Volume-Sets als defekt aus dem SM-Pubset entfernt werden sollen. Diese Volume-Sets sollen auch aus der Pubset-Konfigurationsdatei und dem MRSCAT ausgetragen werden.
Der Control-Volume-Set kann nicht entfernt werden.
DEFECT-VOLUME-SET = *NONE
Es werden alle Volume-Sets importiert, die in die Pubset-Konfigurationsdatei eingetragen sind. Werden ein oder mehrere Volume-Sets als defekt erkannt, so wird der Import-Vorgang abgebrochen. Der Katalogname eines jeden als defekt erkannten Volume-Sets wird ausgegeben. Der Importvorgang muss daraufhin unter Nennung aller defekten Volume-Sets wiederholt werden.
DEFECT-VOLUME-SET = list-poss(256): <cat-id 1..4>
Legt die Katalognamen der Volume-Sets fest, die nicht mehr dem SM-Pubset angehören sollen und aus der Pubset-Konfigurationsdatei und dem MRSCAT auszutragen sind. Alle sich auf einem defekten Volume-Set befindlichen Dateinamen werden aus dem Datei-Index des jeweils betroffenen SM-Pubsets ausgetragen und in die Datei
$TSOS.SYS.PUBSET.DEFECT.<volset-id>.<date>.<time> eingetragen, wobei <date> das Datum (Format yyyy-mm-dd) und <time> die Uhrzeit (Format hhmmss) des Erstellungszeitpunkts bezeichnen. Die eingetragenen Dateinamen bilden die Grundlage für eine spätere Rekonstruktion mit dem Dienstprogramm HSMS.
IN-HOLD-VOLUME-SET = *NONE / list-poss(256): <cat-id 1..4>
Dieser Operand wird nur bei SM-(System-Managed-)Pubsets ausgewertet, die exklusiv bzw. als Master importiert werden.
Der Operand legt fest, welche Volume-Sets beim Importieren in den Status IN-HOLD versetzt werden sollen, d.h. diese Volume-Sets sind temporär als nicht betriebsfähig gekennzeichnet. Die Volume-Sets können mit dem Kommando MODIFY-PUBSET-RESTRICTIONS wieder aktiviert werden.
Ein Volume-Set, der im Status IN-HOLD exportiert wurde, wird beim Importieren implizit wieder aktiviert, falls er nicht explizit im Operanden IN-HOLD-VOLUME-SET angegeben wird.
IN-HOLD-VOLUME-SET = *NONE
Es wird kein Volume-Set in den Status IN-HOLD versetzt.
IN-HOLD-VOLUME-SET = list-poss(256): <cat-id 1..4>
Legt die Volume-Sets fest, die beim Importieren in den Status IN-HOLD versetzt werden.
REPAIR-TSOSCAT = *NO / *YES
Legt fest, ob eine Reparatur von TSOSCAT-Benutzerketten in der CMS-Startphase des Imports erfolgen soll.
REPAIR-TSOSCAT = *NO
Es erfolgt keine Reparatur der TSOSCAT-Benutzerketten.
REPAIR-TSOSCAT = *YES
Diese Angabe sollte nur erfolgen, wenn das Importieren wegen eines defekten TSOSCAT nicht möglich war! Bei der Reparatur können Katalogeinträge verloren gehen!
In der CMS-Startphase des Import werden TSOSCAT-Benutzerketten analysiert und bei Bedarf repariert. Bei der Reparatur werden defekte Blöcke entfernt. Dateien, deren Katalogeinträge auf solchen Blöcken liegen, sind nicht mehr zugreifbar. Weitere Hinweise zur Rekonstruktion des Dateikatalogs enthält das Handbuch „Einführung in die Systembetreuung“ [14].
Es wird in jedem Fall eine F5-Label-Rekonstruktion des gesamten Pubsets durchgeführt.
CHECK-PUBSET-MIRRORS = *NO / *YES
Legt fest, ob die Homogenität des Pubsets überprüft werden soll. Auch bei einem nicht gespiegelten Pubset wird geprüft, ob nicht nur einzelne Platten gespiegelt werden. Ein Pubset ist homogen, wenn alle Volumes des Pubsets identische Spiegelungs-Merkmale aufweisen.
Die Homogenitätsprüfung wird für die aktuell unterstützten vollständigen Replikationsformen durchgeführt (siehe dazu das jeweils gültige Handbuch „SHC-OSD“ [37]).
CHECK-PUBSET-MIRRORS = *NO
Es wird keine Homogenitätsprüfung durchgeführt.
CHECK-PUBSET-MIRRORS = *YES
Eine Homogenitätsprüfung wird durchgeführt.
Kommando-Returncode
(SC2) | SC1 | Maincode | Bedeutung |
|---|---|---|---|
0 | CMD0001 | Kommando ohne Fehler ausgeführt | |
1 | 0 | DMS0350 | Pubset bereits verfügbar |
1 | CMD0202 | Syntaxfehler | |
32 | DMS0352 | Fehler beim Zugriff auf MRSCAT-Eintrag | |
64 | DMS0360 | Keine Berechtigung für Kommando | |
64 | DMS036B | Fehlender MRSCAT-Eintrag, falscher Typ | |
64 | DMS037B | Import als Shared-PVS nicht möglich | |
64 | DMS13C9 | Pubset ist bereits remote importiert; Import-Modus kann nicht geändert werden | |
130 | DMS0351 | Andere Import/Export-Task aktiv | |
130 | DMS035A | Maximale Task-Anzahl erreicht | |
130 | DMS0362 | Klasse-4-Speicherfehler |
Hinweise
Der Home-Pubset kann nicht explizit importiert werden. Das Importieren des Home-Pubsets erfolgt automatisch während der Systemeinleitung (STARTUP-Phase).
Das Kommando IMPORT-PUBSET erzeugt eine neue Task, die IMPORT-Task, und startet sie. Das eigentliche Importieren wird von dieser IMPORT-Task asynchron zur Aufrufer-Task durchgeführt. Nach erfolgreichem Erzeugen der IMPORT-Task wird folgende Meldung an der Konsole ausgegeben:
DMS035B IMPORT PUBSET TASK WITH TSN '(&00)' FOR PUBSET WITH PUBSET ID'(&01)' HAS BEEN CREATED AND STARTED.Alle vom IMPORT-Auftrag ausgegeben Meldungen gehen an die Konsole.
Angaben über
RESIDENT-BUFFERSundNUMBER-OF-BUFFERSkönnen indirekt Einfluss auf den Working-Set bzw. die Paging-Rate der Anlage nehmen. Werden z.B. bei kleineren Anlagen viele speicherresidente Puffer angelegt, so werden zwar die Katalogoperationen schneller, die Paging-Rate für die restlichen Anwendungen steigt jedoch.
Werden keine Pufferangaben gemacht, so treten die System-Standardwerte in Kraft. Hier liegt eine 3-Stufen-Hierarchie in der folgenden Reihenfolge vor:
Explizite Parameterangabe im Kommando IMPORT-PUBSET.
Angaben über das Kommando ADD- bzw. MODIFY-MASTER-CATALOG-ENTRY.
Wird nur einer der Parameter RESIDENT-BUFFERS oder NUMBER-OF-BUFFERS angegeben, gilt für den anderen jeweils der Standardwert (RESIDENT-BUFFERS= *NO, NUMBER-OF-BUFFERS=32).
Vereinbarungen laut Systemparameter CATBUFR und BMTNUM.
Bei der Anzahl der CMS-Puffer wird vom System aus Sicherheits- und Performancegründen ein unterer Schwellwert festgelegt. Liegt die explizite Angabe im Operanden NUMBER-OF-BUFFERS darunter, wird dieser Schwellwert gesetzt.
Ist der Pubset, der importiert werden soll, durch einen früheren Systemabbruch noch belegt, kann der Operator diese Belegung mit dem Kommando UNLOCK-DISK löschen. Der Operator muss sich jedoch vorher vergewissern, dass der Pubset nicht von einem anderen derzeit laufenden System belegt ist.
Im MRSCAT des Pubsets muss statisch definiert sein, wie die Import-Verarbeitung reagieren soll, wenn es bei der Neureservierung eines Cache-Bereichs zu einem Fehler kommt (siehe auch Kommando MODIFY-PUBSET-CACHE-ATTRIBUTES), weil der Cache-Bereich nicht in der gewünschten Größe bereitgestellt werden kann:
Die Import-Verarbeitung wird unter Nutzung des Restkontingentes an Cache fortgesetzt.
Die Import-Verarbeitung wird abgebrochen.
Bei Neuaufnahme eines MRSCAT-Eintrages ist jeweils der Standardwert, d.h. Abbruch im Fehlerfall, gültig.
Hinweis zum Importieren eines Volume-Set mit Konvertierung in einen SF-Pubset
Die Funktion „Konvertierendes Importieren von Volume-Sets“ (siehe Operand USE=*EXCLUSIVE(CONVERT-VOLUME-SET=*YES im Abschnitt "IMPORT-PUBSET")) ist eine Basisfunktion zur Recovery von SM-Pubsets, deren Control-Volume-Set ausgefallen ist: Durch die Konvertierung der restlichen intakten Volume-Sets in SF-Pubsets werden die dort abgelegten Dateien wieder zugreifbar, und es kann im Anschluß eine Rekonstruktion des SM-Pubsets mit SMPGEN erfolgen (siehe auch Handbuch „System Managed
Storage“ [45]).
Bei der Konvertierung von Volume-Sets entstehen funktionsfähige SF-Pubsets. Dennoch sollte diese Funktion ohne sorgfältige Vorüberlegungen ausschließlich für die Recovery von SM-Pubsets genutzt werden. Das spezifische Problem der Maximallänge von Dateinamen wird nachfolgend betrachtet. Grundsätzlich ist zu bedenken, dass in einem SM-Pubset die von einer Anwendung bearbeiteten Dateien nicht notwendigerweise alle im gleichen Volume-Set liegen. Nach einer Zerlegung eines SM-Pubset in SF-Pubsets mit Hilfe des Konversionsimports wäre daher eine einheitliche Adressierung per Defcat (oder über eine Katalogkennung) von zu einer Anwendung gehörenden Dateien nicht mehr möglich. Auch die entsprechenden Metadaten sind nicht mehr vollständig vorhanden.
Für die Vorbereitung eines SMPGEN-Laufs im Rahmen der Recovery eines SM-Pubsets gilt grundsätzlich die im Kapitel „SMPGEN“ des Handbuchs „Dienstprogramme“ [9] beschriebene Vorgehensweise. Die FDDRL-Sicherung der beteiligten Volumes sollte jedoch in einem Recovery-Szenario vor dem Schritt „Konversionsimport“ erfolgen, damit dieser Schritt zusätzlich auch durch einen physikalischen Backup abgesichert ist.
Bei der Konvertierung sind bezüglich Control-Volume-Set, Länge von Dateinamen, Dateigenerationen und DAB-Caches folgende Punkte zu beachten:
Control-Volume-Set
Die Konvertierung von Control-Volume-Sets ist nicht möglich und auch nicht sinnvoll, da die Funktion „Konvertierendes Importieren“ zur Recovery bei Ausfall eines Control-Volume-Set dient. Die auf dem ausgefallenen Control-Volume-Set abgelegten Metadaten müssen nach der Wiederherstellung des SM-Pubset mit SMPGEN aus Sicherungen o.Ä. rekonstruiert werden.
Länge der Dateinamen
Bei der Konvertierung wird die Katalogkennung des Volume-Set als Katalogkennung des daraus erzeugten SF-Pubset übernommen. Falls die Länge dieser Katalogkennung größer ist als die (vorher gültige) Katalogkennung des SM-Pubsets, muss verhindert werden, dass die maximal mögliche Dateinamenslänge von 54 Zeichen überschritten wird. Dazu wird im Rahmen der Konvertierung eine Umbenennung derjenigen Dateien vorgenommen, bei denen diese Maximallänge überschritten würde. Mit einer beantwortbaren Meldung an der Konsole wird gefragt, ob die Umbenennung vorgenommen werden soll. Die Namen der umbenannten Dateien haben folgende Struktur:
:<catid>:$<userid>.S.RENAME.<timestamp>.<tempfile_indicator>.<counter>
Dabei bedeuten:
<catid> | Katalogkennung des SF-Pubset |
<userid> | Benutzerkennung |
<timestamp> | Zeitstempel im ISO4-Format |
<tempfile_indicator> | zeigt an, ob es sich um eine temporäre Datei handelt: T: temporäre Datei N: „normale“ Datei |
Die durchgeführten Umbenennungen werden in einer ISAM-Datei auf dem Home-Pubset protokolliert. Der Name der Datei ist:
:<catid_home>:$TSOS.TSOSCAT.CONV.<catid>.<timestamp>
Dabei bezeichnen <catid_home> die Katalogkennung des Home-Pubsets, <catid> die Katalogkennung des bei der Konvertierung erzeugten SF-Pubset und <timestamp> den Zeitstempel im ISO4-Format.
Die Protokollsätze stellen die Zuordnung der bei der Konvertierung erzeugten zu den ursprünglichen Dateinamen dar. Besonders zu beachten ist, dass auch Dateigenerationen mit zu langen Dateinamen umbenannt werden. Bei der Umbenennung erhalten sie ebenfalls den oben dargestellten Standardnamen und verlieren die Eigenschaft „Dateigeneration“.
Beispiel
Der SM-Pubset K enthält einen Volume-Set F64K. Nach einem Fehler des Control-Volume-Set werden die restlichen Volume-Sets, darunter F64K, in einem ersten Schritt in SF-Pubsets konvertiert. Dabei ist die Umbenennung einiger Dateien erforderlich. Die Protokolldatei liegt auf dem Home-Pubset A:
:A:$TSOS.TSOSCAT.CONV.F64K.2011-10-05.112950
Inhalt der Protokolldatei:
:F64K:$USER1234.S.RENAME.2011-12-06-090300.N.000002 ,:F64K:$USER1234.FILEA901234567890123456789012345678901234 :F64K:$USER1234.S.RENAME.2011-12-06-090300.N.000004 ,:F64K:$USER1234.FILEGROUP3456789012345678901234567(*0001) :F64K:$USER1234.S.RENAME.2011-12-06-090300.N.000005 ,:F64K:$USER1234.FILEGROUP3456789012345678901234567(*0003) :F64K:$USER1234.S.RENAME.2011-12-06-090300.T.000003 ,:F64K:$USER1234.FILEXXX1234567890123456789012345678901234 :F64K:$USER1234.S.RENAME.2011-12-06-090300.N.000001 ,:F64K:$USER1234.FILE8901234567890123456789012345678901234 ... ... ,:F64K:$USER1234.FGG1(*0002)
Nach Rekonstruktion des SM-Pubsets kann mit Hilfe der Protokolldatei die Rückbenennung der umbenannten Dateien erfolgen. Wie für Dateigenerationsgruppen vorzugehen ist, wird im nächsten Absatz („Dateigenerationsgruppen“) dargestellt.
Nach erfolgreicher Rekonstruktion und Rückbennung müssen die Protokolldateien unbedingt gelöscht werden, ggf. nachdem sie gesichert wurden. Andernfalls besteht die Gefahr von Namenskonflikten bei zukünftigen Konversionsimports namensgleicher Volume-Sets, die im Einzelfall zu Fehlfunktionen führen können.
Dateigenerationsgruppen
Bei SM-Pubsets befindet sich der Katalogeintrag der Dateigruppe auf dem Control-Volume-Set, die Katalogeinträge der einzelnen Dateigenerationen können beliebig über die Volume-Sets verteilt sein. Nach der Konvertierung der Volume-Sets in SF-Pubsets sind daher einzelne Dateigenerationen und deren Katalogeinträge, nicht aber Gruppeneinträge vorhanden. Auf die Umbenennung von Dateigenerationen mit „zu langen“ Dateinamen im Rahmen der Konvertierung wurde bereits hingewiesen; die Namen der restlichen Dateigenerationen werden ohne Umbenennung protokolliert, wobei im Protokollsatz an Stelle des neuen Dateinamens Leerzeichen stehen (siehe Beispiel, "IMPORT-PUBSET").
Um auf die Dateigeneration zugreifen zu können, müssen neue Katalogeinträge für die Dateigenerationsgruppen angelegt werden. Folgende Vorgehensweise wird empfohlen:
Für jede einzelne Generation mit der Nummer <n> wird ein Gruppeneintrag erzeugt:
/CREATE-FILE-GROUP <filename>,*GENERATION-PARAMETER(MAXIMUM=1,
FIRST-GENERATION=<n>, LAST-GENERATION=<n>)
Anschließend wird der Inhalt der Dateigeneration in eine Datei kopiert, wobei der Dateiname beliebig gewählt werden kann. Der Name der Dateigeneration und der Zieldatei werden protokolliert. Anschließend wird diese Dateigenerationsgruppe gelöscht.
Nach Wiederherstellung des SM-Pubsets kann die Rekonstruktion der Dateigenerationsgruppen erfolgen:
Der Gruppeneintrag wird neu angelegt. Anschließend werden die Dateien, die im Rahmen der Konvertierung oder manuell aus Dateigenerationen entstanden sind, mithilfe des Kommandos MODIFY-FILE-ATTRIBUTES wieder als Dateigenerationen der Gruppe hinzugefügt. Zu beachten ist, dass Dateigenerationen, die auf dem Control-Volume-Set des ursprünglichen SM-Pubset abgelegt waren, verloren sind. Dies kann zu Lücken in den Versionsnummern der Generation führen. Dieser Umstand ist bei der Rekonstruktion zu berücksichtigen.
DAB-Caches
Bei Caching mit DAB (siehe auch Handbuch „DAB“ [5]) sind die Fälle ADM-PFA-Caching und (User-)PFA-Caching zu unterscheiden. In beiden Fällen erfolgt im Rahmen des Pubset-Import mit Konvertierung eine Synchronisation mit evtl. vorhandenen Cache-Daten.
ADM-PFA Caching
ADM-PFA-Caching kann wahlweise für gesamte SM- oder SF-Pubsets, Volume-Sets oder einzelne Dateien eingestellt werden. Dabei führt DAB als Metadaten die betroffenen Volumes und die Namen der gepufferten Dateien. Für den Ausfall des Control-Volume-Sets eines SM-Pubsets sind folgende 3 Szenarien zu unterscheiden:Export der intakten Volume-Sets ist möglich und wird durchgeführt
In diesem Fall werden die Daten der Volume-Sets zurückgeschrieben. Lediglich Daten des Control-Volume-Set könnten sich noch im Cache befinden. Zur Vorbereitung der Pubset-Recovery ist das DAB-Caching für die betroffenen Objekte zu beenden mit /STOP-DAB-CACHING oder, falls Daten des defekten Control-Volume-Set im Cache sind, zusätzlich mit /FORCE-STOP-DAB-CACHING; dabei wird ein Liste der „pinned“ Dateien geliefert.Import mit Konvertierung bei noch vorhandenem Cache in der laufenden SessionDies ist die Situation, die entsteht, wenn im Fall a) der Abbau des Caches unterbleibt. Der Cache enthält jedoch unter dieser Voraussetzung keine Daten. Aufgrund des Konversionsimport wird das Caching der betroffenen Datenbereiche unterbunden.
Da nach dem Konversionsimport die von DAB verwalteten Dateinamen nicht mehr mit den Daten auf dem Pubset übereinstimmen, sind die betroffenen Cache-Bereiche unbedingt mit /STOP-DAB-CACHING aufzulösen.
User-PFA
Bei User-PFA ist (für SM-Pubsets) ein Cache-Bereich immer einem Volume-Set zugeordnet. Der Cache-Bereich für das defekte Control-Volume-Set kann wahrscheinlich nicht aufgelöst werden und ist mittels /FORCE-DESTROY-CACHE-Kommando abzubauen. Für alle anderen Volumesets wird der zugeordnete Cache-Bereich beim Export nach dem Ausfall des Control-Volume-Sets ordnungsgemäß abgebaut. Beim nachfolgenden Konversionsimport erfolgt kein Einrichten eines neuen Cache-Bereichs.
Nutzung der Funktion „Import mit Homogenitäts-Prüfung“
Die Homogenitäts-Prüfung für einen zu importierenden Pubset wird durch Angabe des Operanden CHECK-PUBSET-MIRRORS =*YES durchgeführt.
Wird im Verlauf des Import ein Volume ermittelt, das unterschiedliche Spiegelungs-Eigenschaften im Vergleich zu bereits bearbeiteten Volumes aufweist, so wird an der Konsole die beantwortbare Meldung DMS1369 ausgegeben. Abhängig von der eingegebenen Antwort des Operatings wird eine der folgenden Vorgehensweisen gewählt:
Das Importieren des Pubsets wird abgebrochen.
Die Import-Verarbeitung wird trotz festgestellter Inhomogenität für das gerade bearbeitete Volume des Pubsets fortgesetzt. Dabei wird für jedes weitere Volume mit unterschiedlichen Spiegelungs-Eigenschaften die Meldung
DMS136Ban der Konsole ausgegeben.