Erzeugen neuer SM-Pubsets

Mit der Anweisung CREATE-SYSTEM-MANAGED-PUBSET kann der privilegierte Anwender bis zu 255 SF-Pubsets in einen SM-Pubset überführen, wobei jeder SF-Pubset zu einem Volume-Set des SM-Pubsets wird. Dabei bleiben die Anwenderdaten sowie die zugehörige Verwaltungs- und Schutzinformation bis auf einige Einschränkungen (siehe "Einschränkungen") erhalten.

Beim Erzeugen neuer SM-Pubsets aus bestehenden SF-Pubsets werden systemintern folgende Schritte ausgeführt:

1. Syntaktische Überprüfung der Anweisung und Vorschau auf das Ergebnis

   Falls die Task im Dialog läuft, wird nach der syntaktischen Überprüfung der Anweisung CREATE-SYSTEM-MANAGED-PUBSET der Aufbau des zu erzeugenden SM-Pubsets tabellarisch in der Bildschirmmaske 12 aufgelistet und nach erfolgtem Importieren der Pubsets erneut in Bildschirmmaske 13 aufgelistet; in beiden Masken hat der Anwender die Möglichkeit, den Abbruch der Funktion zu veranlassen.

2. Impliziter Konsistenz-Check

   Bevor die Platten verändert werden, erfolgt implizit ein Konsistenz-Check der beteiligten Pubsets (siehe auch Abschnitt „Prüffunktion (Konsistenz-Check)"). Werden hierbei Inkonsistenzen festgestellt, wird die Funktion mit Fehlermeldung abgebrochen; detaillierte Fehlerinformationen werden ausgegeben (siehe auch die Ausgaben der Prüffunktion im Abschnitt „Ausgaben").

   Können Guard-Bedingungen nicht angepasst werden (Punkt 2, "Was wird geprüft?"), so werden diese im Rahmen des Konsistenz-Checks gemeldet. Der Konsistenz-Check gilt als ohne Fehler (jedoch mit Warnungen) beendet.
   Die möglichen Folgen eines Abbruchs im Anschluss an einen erfolgreichen Konsistenz-Check sind dem Abschnitt „Fehlerverhalten" zu entnehmen.

3. Exklusive Belegung der Platten durch SMPGEN

   Sowohl während des Konsistenz-Checks als auch der nachfolgenden Bearbeitung sind die gemeinschaftlichen Platten durch SMPGEN exklusiv belegt. In den MRSCAT-Einträgen der Pubsets ist eine Anzeige gesetzt, dass sie gerade durch SMPGEN bearbeitet werden.

   Die Pubsets sind während des gesamten Vorgangs nicht importierbar, und ihre MRSCAT-Einträge können weder gelöscht noch modifiziert werden.

   Für den neu zu erzeugenden SM-Pubset wird ebenfalls ein MRSCAT-Eintrag angelegt, der während des Vorgangs nicht gelöscht oder modifiziert werden kann, und in dem der Pubset als im Entstehen gekennzeichnet ist.

4. Umwandlung der Pubsets

   Die Platten-SVLs werden im Laufe des Umwandlungsvorganges verändert, sodass die ehemaligen SF-Pubsets nicht mehr als solche importierbar sind. Ihre Zugehörigkeit zum SM-Pubset und zum Control-Volume-Set wird im SVL fest verankert.

   Als niedrigste Betriebssystem-Version, in der der Pubset unterstützt wird, wird BS2000/OSD-BC V6.0 im SVL hinterlegt.

5. Löschen aller MRSCAT-Einträge der umgewandelten Pubsets

   Im Anschluss an eine erfolgreiche Umwandlung in einen SM-Pubset werden die MRSCAT-Einträge der zu Volume-Sets umgewandelten Pubsets gelöscht. Der MRSCAT-Eintrag des neu erzeugten SM-Pubsets bleibt erhalten.
   Die im Pubset-MRSCAT-Eintrag einzustellenden Werte wie z.B. CACHE-SIZE-TOLERANCE werden auf den Standardwert gesetzt.

Simulations-Modus

Wenn der Operand OPERATIONAL-MODE=*SIMULATION angegeben wird, wird die Funktion nicht real ausgeführt. Es erfolgt lediglich ein Syntax-Check und eine Auflistung der angegebenen Volume-Sets. Nähere Informationen siehe Operandenbeschreibung.

Check-Modus

Wenn der Operand OPERATIONAL-MODE=*CHECK-NAME-CONSISTENCY angegeben wird, wird nur die Prüffunktion ausgeführt. Nähere Informationen siehe "Prüffunktion (Konsistenz-Check)".

Hinweise

Die auf den Pubsets befindlichen Dateien bleiben in ihrer Lage unverändert.

Die zugehörigen Katalogeinträge bleiben inhaltlich unverändert erhalten, bis auf die Ausnahme, dass die Datei auf einem Pubset liegt, der zum Volume-Set mit der Eigenschaft AVAILABLITY=*HIGH wird (und es sich nicht um eine temporäre Datei handelt):
In diesem Fall wird im Katalogeintrag die logische Dateieigenschaft AVAILABILITY=*HIGH gesetzt, was bewirkt, dass die Datei nicht durch Migration auf einen Volume-Set mit geringerer Verfügbarkeit verlagert wird.

Die Katalogeinträge von Dateien, die keine Platzzuweisung auf den SF-Pubsets besitzen (z.B. migrierte Dateien, Privatplatten- oder Banddateien) bleiben ebenso wie die Jobvariablen inhaltlich erhalten.

BS2000 OSD/BC bedient ab V11.0 nach Möglichkeit nur mehr das Katalogformat EXTRA LARGE, siehe Handbuch „Systembetreuung“ [5]. Die bisherigen Katalogformate NORMAL und LARGE sind obsolet. Es sind folgende Besonderheiten zu beachten:

1. Kataloge einer Vorgängerversion im Format NORMAL oder LARGE werden automatisch in das Format EXTRA LARGE konvertiert, sobald der Pubset exklusiv oder als Master importiert wird. Dabei werden auch die Spezialkataloge umbenannt. Derart konvertierte Kataloge können auch in einer Vorgängerversion wieder verwendet werden.

2. Der SM-Pubset wird mit Katalogformat EXTRA LARGE erzeugt. Die Konvertierung der Kataloge wird allerdings nicht während des SMPGEN-Laufs vorgenommen, sondern beim ersten Import nach diesem Lauf, siehe den vorherigen Punkt. Deshalb wird empfohlen, den SM-Pubset unmittelbar nach dem SMPGEN-Lauf zu importieren.

3. Bei der Neugenerierung eines SM-Pubsets wird jeweils nur je ein Spezialkatalog TSOSCAT.#M00, TSOSCAT.#J00 und TSOSCAT.#P00 angelegt.
   Reichen diese Kataloge in ihrer Größe nicht zur Aufnahme aller Spezialkatalogeinträge aus, so wird empfohlen, zunächst einen SM-Pubset zu erzeugen, der aus dem zukünftigen Control-Volume-Set besteht, und diesen Pubset dann zu importieren.
   Anschließend können mit /ADD-CATALOG-FILE zusätzliche Spezialkataloge anlegt und der SM-Pubset in einem zweiten SMPGEN-Lauf um die restlichen SF-Pubsets erweitert werden.

Wenn GUARDS im Einsatz ist, wird beim Exportieren der Volume-Sets nach erfolgreicher Pubset-Konvertierung die Meldung PRO6009  ERROR WHEN CLOSING GUARDS CATALOG für jeden betroffenen Volume-Set ausgegeben; diese Meldung kann ignoriert werden.

Auch die Guards bleiben inhaltlich erhalten. In Guards, die ein in den zu konvertierenden Pubsets katalogisiertes Programm referenzieren, wird die im Pfadnamen enthaltene Katalogkennung durch die neue Pubset-Kennung ersetzt.
(Dies gilt jedoch nur für die Guard-Einträge innerhalb des neuen SM-Pubset; Guards-Einträge in anderen Pubsets werden nicht angepasst, außerdem kann es nicht automatisch anpassbare Guards geben; siehe Abschnitt „Einschränkungen").

Die Benutzereinträge werden in das für SM-Pubsets gültige Format überführt, wobei Gruppenstrukturen evtl. verloren gehen (siehe Abschnitt „Einschränkungen"). Existiert eine Benutzerkennung zwar auf einem der Pubsets, jedoch nicht auf demjenigen Pubset, von dem die Logon-Information übernommen werden soll, so wird die Benutzerkennung im SM-Pubset als „gesperrt“ geführt (USER-LOCKED=*YES), da keine Accounting-Information zur Verfügung steht. Für die Benutzung des SM-Pubsets als Daten-Pubset ist dies nicht relevant.
Existiert eine Benutzerkennung auf mehreren der zum SM-Pubset zusammenzuführenden Pubsets, so wird dies so behandelt, als sei es ein identischer Anwender.

SMPGEN setzt eine korrekte SYSFILE-Umgebung voraus. Soll die Funktion in einer neu zu erzeugenden Batch-Task ausgeführt werden, so muss der Standard-Pubset der Ablauf-Benutzerkennung importiert sein. Scheitern SYSOUT- oder SYSLST-Ausgaben auch bei wiederholtem Versuch, so wird die SMPGEN-Funktion mit Fehler beendet.

Als DEFAULT FILE FORMAT wird das (physikalische) Format des Control-Volume-Sets eingetragen.

Werden mehrere Pubsets unterschiedlicher Formate zusammengefasst, so muss das von SMPGEN erzeugte DEFAULT FILE FORMAT evtl. geändert werden.

Beispiel 1

Das Format des Control-Volume-Sets ist NK4, die Anwendungen sind jedoch noch nicht auf NK4-Format eingerichtet und können die standardmäßig erzeugten Dateien nicht bearbeiten.

Beispiel 2

Das Format des Control-Volume-Sets ist K, alle anderen Volume-Sets sind keylos (NK); in diesem Fall werden standardmäßig die Dateien auf dem Control-Volume-Set angelegt und dieses überfüllt.

ACHTUNG!

• CREATE-SYSTEM-MANAGED-PUBSET OPERATIONAL-MODE= *OPERATION sollte nie ohne vorhergehende FDDRL-Sicherung der umzuwandelnden Pubsets aufgerufen werden, da bei einem fehlerhaften Abbruch alle Pubsets zerstört und nicht mehr zugreifbar sein können.

• Eine logische Sicherung mittels HSMS wird ebenfalls empfohlen. Hierbei kann ein neues Backup-Archiv erzeugt werden, das zur Herstellung der HSMS-Umgebung für den neuen SM-Pubset verwendet werden kann. Anleitungen zur Umstellung der HSMS-Umgebung sind im Leitfaden für die SMS-Migration gegeben, siehe Handbuch „System Managed Storage“ [8].

• Spool-Aufträge für Dateien, die in den zu konvertierenden Pubsets katalogisiert sind, sollten nicht mehr ausstehen, da sie durch die Umbenennung der Katalogkennung nicht mehr ausgeführt werden können.

• SECOS-spezifische Benutzerinformationen (z.B. Gruppeninformation, Privilegien) gehen auch bei Angabe von KEEP-USER-ATTRIBUTES=*ALL vollständig verloren, wenn das Betriebssystem während der Pubset-Konvertierung ohne SECOS betrieben wird.