Pubsets als Dateibehälter

Dateien und Job-Variablen werden in BS2000 auf Pubsets abgelegt, ebenso die zugehörigen, auf DVS-Ebene benötigten Metadaten (Dateikatalog, Benutzerkatalog, GUARDS-Katalog usw.). Auf den Pubsets sind also (u.a.) die zur Adressierung von Dateien und Dateiinhalten erforderlichen Metadaten verfügbar (Dateikatalog). Ein Pubset stellt im Hinblick auf die Daten und die zugehörigen Metadaten somit eine Einheit dar.

Die Inbetriebnahme eines Pubsets auf einem Rechner setzt voraus, dass auf dem Rechner für den Pubset zusätzliche Metadaten verfügbar sind, die teils statischer, teils dynamischer Natur sind. Die Metadaten umfassen Eigenschaften wie Name (= Katalogkennung), Zustand, Verbundeigenschaften und Betriebsparameter. Diese Eigenschaften sind pro Pubset in einem Eintrag des MRSCAT zusammengefasst, der während einer BS2000-Session als Tabelle im Speicher gehalten wird. Zusätzlich sind die statischen Teile eines MRSCAT-Eintrags auf dem Home-Pubset als Sätze der Datei $TSOS.SYSTEM.MRSCAT abgelegt.
Durch Hinzufügen oder Löschen eines entsprechenden Eintrags im MRSCAT wird ein Pubset auf einem Rechner bekannt gemacht oder entfernt (vgl. "Kommandos ").
Nähere Informationen zu diesem Thema enthalten die Handbücher „Einführung in die Systembetreuung“ [5] und „System Managed Storage“ [17].

Die Adressierung von Dateien und Job-Variablen erfolgt von einem Rechner aus zweistufig über MRSCAT sowie den Dateikatalog TSOSCAT, wie im folgenden Bild für einen an zwei Rechnern bekannten Pubset dargestellt; dies entspricht der Adressierung über Katalogkennung (CATID) und Dateiname mit Benutzerkennung.

Bild 7: Zweistufige Adressierung von Dateien über MRSCAT und Dateikatalog TSOSCAT

In einem MRSCAT-Eintrag werden u.a. folgende für den Betrieb eines MSCF-Verbunds notwendige Daten geführt:

• Katalogkennung (Catid)
  Die Katalogkennung identifiziert jeden SF- oder SM-Pubset eindeutig. Für die Eindeutigkeit der Katalogkennungen in einem MSCF-Verbund muss die Systembetreuung der jeweiligen am Verbund beteiligten Rechner Gewähr leisten.

• Betriebszustand:

  • INACC: Der Katalog ist vom Rechner aus nicht erreichbar.

  • QUIET: Die Verbindung zum Katalog ist vorübergehend unterbrochen.

  • ACCESSIBLE:
    Ist der Katalog zugreifbar („accessible“), so wird durch Unterzustände unterschieden, wie der Pubset in Betrieb genommen ist:

    LOCAL‑HOME:	Zustand des Home-Pubsets nach erfolgreicher Systemeinleitung. Der Home-Pubset muss während des gesamten Systemlaufs verfügbar sein.
    LOCAL‑IMPORTED:	Der Pubset wurde mit dem Kommando IMPORT-PUBSET als Daten-Pubset in Betrieb genommen. Dies kann exklusiv für einen Rechner oder aber als Shared-Pubset erfolgen. In letzterem Fall enthält der MRSCAT zusätzlich die Angabe, ob der Rechner die Rolle des Master- oder Slave-Rechners übernommen hat. Bei Slave-Rechnern enthält er darüber hinaus den Processor-Namen des Master-Rechners.
    REMOTE‑HOME/ REMOTE‑IMPORTED:	Hier handelt es sich um eine (aus lokaler Sicht) stark eingeschränkte Inbetriebnahme eines Pubsets; dabei ist der Pubset an einem Remote-Rechner, zu dem eine MSCF-Verbindung besteht, als Home-Pubset bzw. als Daten-Pubset exklusiv oder im Master-Modus importiert. Es steht lediglich die LCS-Funktionalität zur Verfügung.

    Weitere Einzelheiten zum Betriebszustand eines Shared-Pubsets siehe "Betriebszustände eines Shared-Pubsets ".

• Host-Name:
  In einem MRSCAT-Eintrag ist der Name des Rechners, der den Pubset verwaltet, hinterlegt. Im Betriebszustand INACCESSIBLE ist der Name nicht zwingend aktuell. Bei Inbetriebnahme des Pubset erfolgt eine Aktualisierung beim Übergang in den Zustand ACCESSIBLE.

  An den Schnittstellen zur Verwaltung des MRSCAT erfolgt die Identifizierung

  von Rechnern stets über „HOST“ oder „PARTNER-NAME“; im Sinne der für HIPLEX MSCF eingeführten Terminologie (vgl. "Rechneridentifikation ") handelt es sich dabei jedoch um den Processor-Namen des Rechners.

Da auf den Pubsets neben den Daten auch die verarbeitungsbezogenen Metadaten abgelegt sind, ergibt sich bei Shared-Pubsets das Problem der rechnerübergreifenden Koordination bei der Aktualisierung dieser Daten. Dieses Problem wird dadurch gelöst, dass der Master-Rechner zum Eigentümer der Metadaten erklärt wird; alle Änderungen der Metadaten müssen über den Master-Rechner erfolgen. Dieses Prinzip wird auf zwei Arten umgesetzt:

• Betriebssystemfunktionen zur Aktualisierung stehen nur auf dem jeweiligen Master-Rechner zur Verfügung.

• Auf einem Slave-Rechner werden Funktionen zum Zugriff auf Metadaten als Aufträge an den Master-Rechner verschickt; der Master-Rechner ist also in Bezug auf die Slave-Rechner eines Pubsets ein Server zur Durchführung von Operationen auf Metadaten dieses Pubsets.

In BS2000 ist vorwiegend die zweite Variante realisiert. Für die meisten Schnittstellen im Umfeld der Dateiverwaltung sind die Master-/Slave-Eigenschaft eines Rechners damit ebenso transparent wie die Shareability eines Pubsets.