Die Pubset-Verwaltung des BS2000 (siehe Handbuch „Einführung in die Systembetreuung“) bietet Ihnen die Möglichkeit, den Ort der Speicherung von Dateien auf gemeinschaftlichen Platten zu bestimmen. Dabei können sowohl Single-Feature-Pubsets (SF-Pubsets) als auch System-Managed-Pubsets (SM-Pubsets) genutzt werden.
Folgende Vorteile kann der Datenbankadministrator nutzen, wenn er die Möglichkeiten der Pubset-Verwaltung des BS2000 für UDS/SQL ausschöpft:
Er kann mit dem CREATE-FILE-Kommando UDS/SQL-Dateien einrichten und sie gezielt auf verschiedenen Public Volume Sets platzieren
Er kann unter Nutzung von physikalischer Allokierung Dateien gezielt auf Volume Sets bzw. auf einzelne Volumes platzieren. Dazu muss der BS2000-Systemverwalter den SF-Pubset mit dem entsprechenden Attribut zur Verfügung stellen bzw. der Benutzerkennung das Recht auf physikalische Allokierung pubset-spezifisch einräumen. Details hierzu siehe Handbücher „Einführung in die Systembetreuung“ und „Einführung in das DVS“.
Er kann durch exklusive Nutzung von Public Volume Sets, Volume Sets bzw. Volumes für Datenbankdateien sicherstellen, daß der bei dynamischer Erweiterung bzw. Online-Erweiterung benötigte Plattenplatz auch tatsächlich zur Verfügung steht.
Er kann möglichen Schaden eingrenzen, wenn er UDS/SQL-Dateien auf verschiedene Public Volume Sets legt, sodass bei Ausfall eines Public Volume Set Dateien auf anderen Public Volume Sets noch benutzbar sind
Er kann durch Ablage von Datenbankdateien und RLOG-Dateien in einem Public Volume Set moderne Hardwaretechnologie (Clones, Snaps) nutzen, um jederzeit sehr performant Datenbankkopien im laufenden Betrieb ziehen zu können. Aus Sicherheitsgründen sollte in diesen Fällen aber unter allen Umständen die RLOG-Datei auf einem anderen Volume Set doppelt geführt werden.
Er kann durch Einschränkung der UDS/SQL-Pubset-Umgebung (siehe Abschnitt „Pubset-Deklarations-Jobvariable“) verhindern, dass die Mehrdeutigkeit von Dateinamen störende Auswirkungen auf den UDS/SQL-Betrieb hat.
Er kann entsprechend den Vorschlägen zur Erhöhung der Sicherheit die Originaldateien und Sicherungskopien (.SAVE) auf verschiedene Public Volume Sets legen.
Er kann Performance-Verbesserungen erzielen durch sinnvolle Verteilung der UDS/SQL-Dateien auf verschiedene Public Volume Sets.
Folgendes muss der Datenbankadministrator beachten:
UDS/SQL behandelt bereits bestehende Datenbankdateien und Systemdateien anders als neu einzurichtende Dateien.
Datenbankdateien sind: Realms, ALOG-Datei, HASHLIB, COSSD
Systemdateien sind: SLF, Temporäre Realms, RLOG-Dateien, DB-Status-Datei.
Bestehende Datenbank- und Systemdateien
Für solche Dateien fordert UDS/SQL, dass es im lokalen Rechner innerhalb ihrer Benutzerkennung über alle relevanten Public Volume Sets keine zweite Datei gleichen Namens gibt. Die für den Betrieb von UDS/SQL relevanten Public Volume Sets können durch die Pubset-Deklaration (siehe Abschnitt „Pubset-Deklarations-Jobvariable“) für einen Programmlauf spezifiziert werden. Wenn keine Spezifikation angegeben ist, gilt die Eindeutigkeitsforderung für alle lokal verfügbaren Public Volume Sets.
Auf Grund dieser Eindeutigkeitsregel ist UDS/SQL in der Lage, die Katalogkennung :catid: jeder bestehenden Datenbank- und Systemdatei selbst zu ermitteln und dann intern zu benutzen. Deshalb ist für solche Dateien eine explizite Angabe der Katalogkennung an der Benutzerschnittstelle nicht erforderlich und wird von UDS/SQL teilweise sogar verboten, um Widersprüche zwischen angegebener und tatsächlicher Katalogkennung einer Datei zu vermeiden.
Auf diese Weise kann der Datenbankadministrator die Lage der wichtigsten UDS/SQL-Dateien flexibel bestimmen, ohne dass er UDS/SQL die Lage der einzelnen Dateien explizit mitteilen muss.
Bestehende sonstige Dateien
Für alle übrigen Dateien z.B. Ladeparameter-Dateien, DISTABLE-Datei, UDS/SQL-ENTER-Dateien, usw. kann im Allgemeinen die Katalogkennung zusammen mit der Benutzerkennung bei der Zuweisung angegeben werden. Hilfsdateien der Dienstprogramme (SCRTCH- und SORTWK-Dateien) werden aber gemäß Pubset-Deklaration auf Eindeutigkeit geprüft; insofern kann auch eine angegebene Katalogkennung ignoriert werden. Bereits eingerichtete Dateien, für die der Datenbankadministrator keine spezifische Zuweisung vorgenommen hat, müssen ansonsten in der Standard-Katalogkennung liegen (siehe die Kommando-Handbücher zu „BS2000 OSD/BC“, ADD-USER-Kommando).
Grundsätzlich ist es in folgenden Fällen immer erlaubt, die Katalogkennung anzugeben:
Beim Einrichten von Dateien mit dem CREATE-FILE-Kommando,
beim Zuweisen von Dateien für UDS/SQL mit dem ADD-FILE-LINK-Kommando und LINK-NAME und
bei der Bekanntgabe des Konfigurationsnamens mit dem SET-FILE-LINK-Kommando und dem Operanden LINK-NAME.
Durch UDS/SQL einzurichtende Dateien
Nicht vorhandene Dateien werden, sofern sie nicht explizit vom Anwender eingerichtet werden müssen, bei Bedarf durch UDS/SQL in der Standard-Katalogkennung der Datenbank- bzw. Konfigurationskennung angelegt (siehe die Kommando-Handbücher zu „BS2000 OSD/BC“, ADD-USER-Kommando).
Ausnahme
RLOG-Datei:
Katalogkennung wird mit PP LOG, PP LOG-2, PP RESERVE, MODIFY LOG, MODIFY-LOG-2 oder MODIFY RESERVE festgelegt.
ALOG-Datei:
Katalogkennung wird mit der BMEND-Anweisung START-LOG festgelegt.
Wenn die Standard-Katalogkennung im Benutzerkatalog geändert werden soll, ist zu beachten, dass alle Dateien, die nicht in den verfügbaren Pubsets gesucht werden („sonstige Dateien“), aus der alten in die neue Standard-Katalogkennung transportiert werden müssen, damit sie für UDS/SQL auffindbar sind (siehe die Kommando-Handbücher zu „BS2000 OSD/BC“, MODIFY-USER-ATTRIBUTES-Kommando).
UDS/SQL spricht auch bei Einsatz von Mehrfachrechnersystemen (MSCF) und Remote File Access (RFA) nur lokal verfügbare Public Volume Sets an.
UDS/SQL eröffnet jede Datenbank- und Systemdatei erst nach Ausführung des FSTAT-Makros (Kommando SHOW-FILE-ATTRIBUTES) über alle Public Volume Sets, die in der aktuell gültigen UDS/SQL-Pubset-Deklaration zugewiesen sind. Dabei wird nicht gewartet, bis Public Volume Sets, die sich im Zustand QUIET befinden, diesen Zustand wieder verlassen; insofern werden Dateien auf diesen Public Volume Sets in der Folgeverarbeitung nicht berücksichtigt, auch wenn sie in der UDS/SQL-Pubset-Deklaration enthalten sind.
Je mehr Public Volume Sets mit Datenbank- und Systemdateien belegt sind, die zu einer Datenbank gehören, umso größer ist der interne Verwaltungsaufwand. Um Performance-Einbußen zu vermeiden, sollten Sie daher nicht mehr Public Volume Sets in die Pubset-Deklaration einbeziehen als nötig.
Bei Anweisungen der Dienstprogramme sind Einschränkungen bei der Zuweisung von Dateien bzgl. der Katalogkennung möglich. Diese sind bei den Schnittstellen der einzelnen Dienstprogramme im jeweiligen Handbuch beschrieben.
Die folgende Tabelle zeigt, an welchen Schnittstellen zwischen Anwender und DBH die Angabe einer Katalogkennung :catid: erlaubt bzw. verboten ist:
Benutzerschnittstelle | Funktion |
| Konfigurationsnamen festlegen |
| Datenbank für Dienstprogrammlauf festlegen |
| Namen und ggf. die Kennung einer Datenbank angeben |
| Namen einer DISTABLE-Datei angeben |
| Ladeparameter-Datei zuweisen |
Tabelle 20: Übersicht über die Angabemöglichkeiten der Katalogkennung an UDS/SQL-Benutzerschnittstellen
1 In diesem Fall ist die Angabe einer :catid: erlaubt, damit für das ADD-FILE-LINK-Kommando ein existierender DBDIR ausgenutzt werden kann.
Erklärung:
userid dbuserid admuserid | Benutzerkennung Datenbankkennung Konfigurationskennung |