Gemeinschaftliche Platten werden zu Volume-Sets oder SF-Pubsets zusammengefasst. Ein oder mehrere Volume-Sets bilden einen SM-Pubset.
Mit MPVS (Multiple Public Volume Set) können mehrere Pubsets in einem Systemlauf gleichzeitig installiert sein.
An einen Pubset können Net-Storage-Volumes angehängt werden. Sie sind aber nicht Bestandteil des Pubsets (IMPORT-PUBSET ist auch ohne gemountete Net-Storage-Volumes möglich).
Es gibt einen ausgezeichneten Pubset, den „Home-Pubset“, der während des gesamten Systemlaufs verfügbar sein muss, da er die zum Laden, Betreiben und Beenden des Systems benötigten Daten enthält. Die anderen Pubsets können von der Systembetreuung importiert und exportiert werden. Die Default-Pubsets der Benutzer sollten immer importiert werden.
Alle Datenträger eines Pubsets werden vom System als eine Einheit betrachtet und verwaltet. Jeder Benutzer, der dazu durch die Systembetreuung über das Kommando ADD-USER bzw. durch den Systemparameter FSHARING berechtigt ist, kann auf importierten Pubsets mit allen DVS-Funktionen Dateien erzeugen, verarbeiten und löschen.
Es gibt zwei verschiedene Typen von Pubsets: den SF-Pubset (Single Feature Pubset) und den SM-Pubset (System Managed Pubset). Sie unterscheiden sich durch ihre Eigenschaften, Betriebsparameter und Service-Attribute.
SF-Pubsets
Ein SF-Pubset besteht aus Volumes, die die gleichen physikalischen Eigenschaften aufweisen. Er repräsentiert ein begrenztes, in sich homogenes Service-Angebot.
SM-Pubsets
Ein SM-Pubset besteht aus einem oder mehreren Volume-Sets. Die Volume-Eigenschaften müssen nur innerhalb eines Volume-Sets homogen sein. Eine Datei kann sich nicht über mehrere Volume-Sets erstrecken. Jeder Volume-Set repräsentiert anhand seiner Eigenschaften einen speziellen Service-Typ innerhalb eines SM-Pubsets, der bei der Auswahl des Ablageortes einer Datei berücksichtigt wird. Grundlage für die Auswahl sind die vom Benutzer über die Angabe von logischen Dateiattributen angeforderten Services.
Betriebsarten von Pubsets
Shared-Pubset
Bei Einsatz des Produkts MSCF (Mehrrechnersystem) und einer entsprechenden Hardware-Konfiguration ist der gleichzeitige und gemeinsame Zugriff über mehrere BS2000-Systeme hinweg auf einen Pubset möglich.
Maximal 16 BS2000-Systeme, die in einem gemeinsamen MSCF-Verbund gekoppelt werden, können über einen direkten Hardware-Pfad als „Sharer“ auf diesen mehrbenutzbaren Pubset zugreifen. Einer dieser Verbund-Teilnehmer wird zum temporären Eigentümer dieses Pubsets ernannt und wickelt für die anderen Systeme die Funktionen zur Verwaltung der Dateien, der Benutzer und der Zugriffe ab. Alle Verwaltungs-Anforderungen seitens der untergeordneten Teilnehmer, der sog. „Slave-Sharer“, müssen über MSCF an das Eigentümersystem, den „Master“ gerichtet werden.
Bei Ausfall des Eigentümersystems wird an allen abhängigen Systemen eine pubsetspezifische Jobvariable gesetzt. Wurde von der Systembetreuung über das Kommando SET-PUBSET-ATTRIBUTES ein Backup-Eigentümer definiert, kann dieser Slave-Sharer dann die Rolle des ausgefallenen Master-Sharer übernehmen (Master-Wechsel).
Ist kein Backup-Eigentümer vorgesehen, kann die Systembetreuung am Slave-Sharer den Pubset exportieren und bei einem nachfolgenden IMPORT-PUBSET-Kommando einen neuen Eigentümer bestimmen.
Das gesamte Konzept des Shared-Pubset (Hardware-Konfiguration, Verwaltung der Pubsets, Datenzugriffe) ist ausführlich im Handbuch „HIPLEX MSCF“ [11] beschrieben.
XCS-Pubset
Mit HIPLEX MSCF steht eine erweiterte Verbundfunktionalität zur Verfügung: der XCS-Verbund (Cross Coupled System), der eine engere Koordination der beteiligten Systeme bietet. Jedes System hat eine konsistente und vollständige Sicht des gesamten Verbunds. Der XCS-Verbund bietet damit Mechanismen zur Realisierung verteilter Anwendungen.
Er ist in erster Linie als Verfügbarkeits- und Lastverbund des BS2000 konzipiert. Dem Benutzer werden u.a. folgende, im DVS-Umfeld wichtige Funktionen angeboten:
Distributed Lock Manager (DLM):
Diese Funktion realisiert eine system-übergreifende Sperrenverwaltung und unterstützt damit system-übergreifende Synchronisation und Serialisierung. Sie ist Basisfunktion für SFS.Shared File System (SFS):
Das SFS erlaubt innerhalb des XCS-Verbunds die system-übergreifende Aktualisierung von Dateien auf Shared-Pubsets, die nicht notwendig XCS-Pubsets sein müssen. In HIPLEX MSCF wird dieser globale Shared-Update für die block- bzw. bytestrom-orientierten Zugriffsmethoden UPAM, FASTPAM und DIV unterstützt.
Voraussetzungen für einen XCS-Verbund sind:
ein System kann max. einem XCS-Verbund angehören
die Teilnehmer müssen voll vermascht sein, d.h. es müssen MSCF-Verbindungen zwischen allen Systemen des Verbunds bestehen
dem XCS-Verbund muss mindestens ein XCS-Pubset angehören, zu dem von allen Systemen aus Zugriffspfade vorhanden sein müssen
Ein XCS-Pubset dient als zentraler Ablageort für verbundweit benötigte Daten. XCS-Pubsets werden automatisch durch das System importiert.
Das gesamte Konzept des XCS-Verbunds (Funktionalität, Generierung und Betrieb) ist ausführlich im Handbuch „HIPLEX MSCF“ [11] beschrieben.
Mit SHC-OSD erstellte Pubset-Kopien
Für die Datensicherung von Pubsets in Plattenspeichersystemen können mit Hilfe von SHC-OSD auf dem jeweiligen Plattenspeichersystem spezielle Pubset-Kopien (Spiegelplatten) lokal erstellt werden. Es gibt zwei Ausführungen:
Pubset-Kopie, die auf Basis von Clone-Units erstellt wurde (z.B. für die Sicherung (Backup) eines konsistenten Stands des Pubsets mit HSMS oder FDDRL)
Pubset-Kopie, die auf Basis von Snap-Units erstellt wurde, auch Snapset genannt (siehe Abschnitt „Pubset-Sicherung mit Snapsets")
Die Pubset-Kopien sind dem Pubset fest zugeordnet. Die VSNs ihrer Volumes genügen einer speziellen Syntax (siehe „Spezielle VSN-Benennung bei Pubset-Kopien" im nachfolgenden Abschnitt). Auf diese Kopien ist nur lesender Zugriff möglich. Für Einzelheiten siehe die Handbücher „HSMS“ [10] und „Systembetreuung“ [7].
Namensgebung von Pubsets
Die Namen von Platten, die einem Volume-Set/SF-Pubset zugeordnet sind, müssen syntaktisch zum Namen des Volume-Sets/SF-Pubsets passen. Dabei ist zwischen ein- und mehrstelligen Volume-Set- bzw. Pubset-Namen zu unterscheiden:
für einstellige Namen gibt es die PUB-Notation
für zwei- bis vierstellige Namen gibt es die Punkt-Notation
Standard-Namen von Net-Storage-Volumes, die einem Pubset zugeordnet sind, haben, abhängig von der Pubset-Notation, eine besondere Form, siehe „Notation von Net-Storage- Volumes“ im Handbuch „Systembetreuung“ [7].
VSN in PUB-Notation
Diese Art der Pubset-Adressierung hat ihren Namen aus der Verwendung der Zeichenkette „PUB“ als festen, unveränderlichen Bestandteil der VSN. Dabei weist „PUB“ (public) darauf hin, dass es sich um gemeinschaftliche Platten handelt.
Eine VSN in PUB-Notation besteht immer aus 6 Zeichen und hat folgendes Format:
PUBpxx
| unveränderlicher Bestandteil zur Unterscheidung von privaten Platten (3 Zeichen „PUB“) = Typbezeichner |
| Katalogkennung (Catid), (1 Zeichen; A..Z, 0..9) |
| laufende Nummer innerhalb eines Pubsets/Volume-Sets, (2 Zeichen; 00..31) = Folgenummer |
Mit der einstelligen Katalogkennung können maximal 36 Pubsets bzw. Volume-Sets adressiert werden, die aus bis zu 32 Platten bestehen können.
Beispiele: PUBA00, PUBA25, PUB502
VSN in Punkt-Notation
Der Name dieser Notation ist durch die Verwendung eines Punktes als Trennungszeichen zwischen der Katalogkennung und der Folgenummer im Pubset bzw. Volume-Set entstanden. Auch die Punkt-Notation bezeichnet immer gemeinschaftliche Platten.
Eine VSN in Punkt-Notation besteht immer aus 6 Zeichen und hat folgendes Format:
pp[pp].[xy]z
| Katalogkennung (Catid), (2-4 Zeichen; je A..Z, 0..9), der Präfix „PUB“ ist nicht erlaubt |
. | Punkt (1 Zeichen) = Typbezeichner |
| laufende Nummer innerhalb eines Pubsets/Volume-Sets, (1-3 Zeichen; je 0..9) = Folgenummer |
Ein Pubset bzw. Volume-Set in Punkt-Notation kann aus bis zu 255 Platten bestehen.
Beispiele: AA.001, AB.309, XYZ.23, OTTO.0, J19P.8
Die Katalogkennung bei SF-Pubsets korrespondiert direkt mit dem Namensteil „Katalogkennung“ in der VSN. Bei SM-Pubsets ist die Katalogkennung verschieden von allen Volume-Set-Namen dieses SM-Pubsets, und damit auch verschieden vom VSN-Namensteil „Katalogkennung“ aller Platten des Pubsets.
Spezielle VSN-Benennung bei Pubset-Kopien
Die VSNs einer mit SHC-OSD auf Basis von Clone-Units erstellten Pubset-Kopie werden aus den Original-VSNs gebildet, wobei bei der PUB-Notation das „U“ der Zeichenfolge „PUB“ bzw. bei der Punkt-Notation der Punkt durch einen Doppelpunkt ersetzt wird.
Die VSNs einer mit SHC-OSD auf Basis von Snap-Units erstellten Pubset-Kopie, d.h. eines Snapsets werden nach folgender Regel aus den Original-VSNs gebildet:
- Bis zum 26. Snapset (d.h. für die Snap-Ids a bis z):
- Bei der PUB-Notation werden das „U“ und das „B“ der Zeichenfolge „PUB“ jeweils durch die Snapset-Id in Kleinbuchstaben ersetzt.
- Bei der Punkt-Notation wird der Punkt durch die Snapset-Id in Kleinbuchstaben ersetzt.
Ab dem 27. Snapset (d.h. für die Snap-Ids A bis Z):
Bei der PUB-Notation werden das „P“ und das „U“ der Zeichenfolge „PUB“ jeweils durch die Snapset-Id in Kleinbuchstaben ersetzt.
Bei der Punkt-Notation wird der Punkt durch die Snapset-Id in Kleinbuchstaben ersetzt und gleichzeitig seine Zeichenposition verändert:
Bei 4-stelliger Catid wird die Snapset-Id nach dem ersten Zeichen der Catid eingefügt.
Bei 3-stelliger Catid wird die Snapset-Id vor dem ersten Zeichen der Catid eingefügt.
Bei 2-stelliger Catid wird die Snapset-Id als letztes Zeichen der VSN eingefügt.
Beispiele
Datenträgerkonfiguration eines SF-Pubsets:
Der SF-Pubset mit der Katalogkennung ABC besteht aus drei Platten.
Existiert eine Datei mit dem Dateinamen „MEINE.LISTE“ unter der Benutzerkennung „ALLERLEI“ auf einer der Platten des SF-Pubsets ABC, so lautet ihr Pfadname:
„:ABC:$ALLERLEI.MEINE.LISTE“
Ein zugehöriger Snapset mit der Snapset-Id x würde dann aus den Volumes mit den VSNs ABCx00, ABCx01 und ABCx02 bestehen.
Datenträgerkonfiguration eines SM-Pubsets:
Der SM-Pubset mit der Katalogkennung XYZ besteht aus drei Volume-Sets.
Existiert eine Datei mit dem Dateinamen „TELEFONLISTE“ unter der Benutzerkennung „EINERLEI“ auf einer der Platten, die zu einem der Volume-Sets des SM-Pubsets XYZ zusammengefasst sind, so lautet ihr Pfadname: „:XYZ:$EINERLEI.TELEFONLISTE“, d.h. für die Adressierung ist es nicht relevant, wie der SM-Pubset intern aufgebaut ist und wo genau seine Datei vom System abgelegt wurde.
Ein zugehöriger Snapset mit der Snapset-Id m würde dann aus den Volumes mit den VSNs PmBA00, B12m00, B12m01, B12m02, PmBC00 und PmBC01 bestehen.
Benutzerkatalog
Jeder Pubset enthält einen Benutzerkatalog und seinen eigenen Dateikatalog.
Durch Einträge im Benutzerkatalog ist geregelt, wer bzw. welche Benutzerkennung (Userid) auf einen Pubset zugreifen kann. Benutzer ohne Eintrag im Benutzerkatalog für den Pubset können nicht auf diesen Pubset zugreifen, auch nicht auf mehrbenutzbare Dateien, es sei denn, dies ist durch den Systemparameter FSHARING generell erlaubt.
Im Benutzerkatalog sind auch für jeden Benutzer, der darin eingetragen ist, pubset-spezifische Berechtigungen festgelegt. Enthält der Eintrag im Benutzerkatalog z.B. die Angabe PUBLIC-SPACE-LIMIT=0, kann der Benutzer auf diesem Pubset keine permanenten Dateien anlegen; er kann jedoch auf alle mehrbenutzbaren Dateien, die in diesem Pubset katalogisiert sind, zugreifen.
Das Anlegen von temporären Dateien kann durch die Angabe TEMP-SPACE-LIMIT=0 verhindert sein (zur Speicherplatzverwaltung siehe „Anfordern von Speicherplatz").
Die Angabe NET-STORAGE-USAGE=*ALLOWED legt fest, dass der Benutzer Speicherplatz auf Net-Storage belegen darf.
Mit dem Kommando SHOW-USER-ATTRIBUTES kann sich der Benutzer über seinen Eintrag im Benutzerkatalog informieren.