Der independent DBH besteht aus mehreren Tasks (im Folgenden auch UDS/SQL-Tasks genannt):
der Mastertask
einer oder mehreren Servertasks
(ihre Anzahl bestimmt der Ladeparameter PP SERVERTASK)der Administratortask
Die Mastertask (Modul UDSSQL) bereitet beim DBH-Start die eigentliche Sessionphase vor und führt alle dafür notwendigen Prüfungen durch; ebenso steuert sie das DBH-Ende.
Beim DBH-Start lädt die Mastertask die Servertask(s) als ENTER-Job und beendet sie am DBH-Ende.
Die Mastertask hat darüberhinaus auch während der Session Sonderaufgaben durchzuführen, die einen reibungslosen Ablauf gewährleisten sollen.
Es wird empfohlen, aus Sicherheitsgründen die Mastertask in einem ENTER-Job zu starten.
Es ist auch möglich, die Mastertask im Dialog zu starten. In diesem Fall ist dann unbedingt darauf zu achten, dass die Mastertask nie unnötig unterbrochen wird und dass nach der Eingabe von BS2000-Kommandos immer RESUME-PROGRAM eingegeben wird.
Die Servertask (Modul UDSSUB) nimmt im Communication Pool den Auftrag entgegen und führt ihn aus. Dabei greift sie über den Common Pool auf die Datenbank zu und transportiert Daten, die das Anwenderprogramm in die Datenbank schreiben oder aus ihr lesen will, vom Communication Pool in den Common Pool und umgekehrt. Hat die Servertask den Aufruf fertig bearbeitet, so verständigt sie das Anwenderprogramm.
Die Eingaben und Ausgaben von den Servertasks werden standardmäßig asynchron durchgeführt (Ladeparameter PP IO=ASYNC). Damit genügt es, auf einem Monoprozessor eine Servertask zu starten. Bei Multiprozessoren genügt es, pro Prozessor maximal eine Servertask zu starten (siehe Abschnitt „Prozessornutzung mit independent DBH optimieren“). Die Priorität der Servertasks muss dann geeignet eingestellt sein (siehe „RUN-PRIO“ im Kapitel "DBH-Startkommandos" und insbesondere Abschnitt „Leistungsbezogene BS2000-Einstellungen“).
Mit der Administratortask (Modul UDSADM) steuert der Datenbankadministrator die Session. Die Nutzung der Administratortask garantiert einen unterbrechungsfreien Betrieb der Mastertask sowie einen einfachen Anschluss des Datenbankadministrators an die Session (siehe Abschnitt „UDS/SQL über UDSADM administrieren“). Diese Form der Administration sollte im Allgemeinen verwendet werden.
Im Communication Pool ist für jede Transaktion ein Bereich reserviert, in dem bei einem Aufruf folgende Informationen gespeichert werden:
die Transaktionskennung
der Aufruf mit seinen Parametern
die zu übertragenden Daten
Der Common Pool ist ein Speicherbereich, auf den alle UDS/SQL-Tasks des DBH zugreifen können. Er enthält unter anderem
Systemtabellen
die System Buffer Pools und die exklusiven Buffer Pools für Datenbankseiten.
Die System Buffer Pools enthalten 2-, 4- oder 8-Kbyte große Puffer, von denen jeder eine Datenbankseite aufnehmen kann. Die Größe der System Buffer Pools in Mbyte bestimmen Sie mit den Ladeparametern PP 2KB-BUFFER-SIZE, PP 4KB-BUFFER-SIZE bzw. PP 8KB-BUFFER-SIZE.
Zusätzlich zu den System Buffer Pools können Sie je Datenbank einen exklusiven Buffer Pool anlegen. Die Größe eines exklusiven Buffer Pools bestimmen Sie entweder mit dem Ladeparameter PP DBNAME oder mit dem DAL-Kommando ADD DB.
Jede Datenbankseite, die von einer Servertask bearbeitet werden soll, wird in einen Puffer des entsprechenden System Buffer Pools bzw. eines exklusiven Buffer Pools eingelesen und bleibt dort,
bis die Session beendet wird oder
bis die Datenbank mit DROP DB ausgeschlossen wird oder
bis der Puffer für eine andere Datenbankseite benötigt wird.
Dadurch muss die Servertask nicht bei jedem DML-Aufruf auf die Datenbank zugreifen, sondern kann in den System Buffer Pools bzw. exklusiven Buffer Pools arbeiten.
Falls mit SQL gearbeitet wird, existiert für jede SQL-Anwendung ein Vorgang bei UDS/SQL (siehe Kapitel „Der SQL-Vorgang“). Bezüglich des Vorgangs existieren Systemtabellen im Communication Pool und im Common Pool.
Bild 3: Der independent DBH
Bearbeiten einer COBOL-DML-Anweisung durch den independent DBH
Im Folgenden wird am Beispiel eines COBOL-Programms die Bearbeitung einer DML-Anweisung durch den independent DBH kurz dargestellt, wobei das folgende Bild den Ablauf verdeutlichen soll:
Bild 4: Abwicklung einer COBOL-DML-Anweisung durch den independent DBH
Dem Anwenderprogramm steht durch das Subschemamodul ein Arbeitsbereich, der Satzbereich, zur Verfügung. Der Satzbereich ist gleichzeitig Teil des BASE INTERFACE BLOCK (BIB), der Schnittstelle zwischen UDS/SQL und dem jeweiligen Datenbankanwender.
In dem Satzbereich des BIB übergeben Sie die zu einer DML-Anweisung gehörenden Daten.
In den Parameterbereich des BIB setzt das COBOL-Laufzeitsystem die notwendigen Parameter der DML-Anweisung ein.
Über einen CALL-Aufruf übergibt das COBOL-Laufzeitsystem dem Verbindungsmodul die Adresse des BIB.Das Verbindungsmodul überträgt den BIB in den Communication Pool, in dem zu Beginn einer Transaktion dafür ein Bereich reserviert wird.
Dieser BIB wird einer Servertask übergeben und bearbeitet.
Ist keine Servertask verfügbar, so muss der BIB warten, bis eine Servertask frei wird. Das Verbindungsmodul versetzt sich in den Wartezustand bis die DML-Anweisung bearbeitet worden ist.Zur Bearbeitung der DML-Anweisung greift die Servertask auf den BIB im Communication Pool und die Buffer Pools im Common Pool zu.
Soll die DML-Anweisung Daten aus der Datenbank lesen, so überträgt die Servertask die in den Buffer Pools stehenden Daten in den entsprechenden BIB im Communication Pool. Umgekehrt beim Schreiben: soll die DML-Anweisung Daten in die Datenbank schreiben, so überträgt die Servertask die im BIB stehenden Daten in die Buffer Pools. Die Servertask schreibt aus den Buffer Pools einen Puffer jedoch erst dann in die Datenbank zurück, wenn eine andere Datenbankseite den Platz im Puffer benötigt.Befindet sich die Datenbankseite, in der die DML-Anweisung die Daten des BIB schreiben soll oder aus der sie Daten lesen soll, nicht in den Buffer Pools, so wird auf der angegebenen Datenbank die entsprechende Datenbankseite gesucht und in die Buffer Pools eingelesen.
Nach der Bearbeitung der DML-Anweisung aktiviert die Servertask die zur Transaktion gehörende Anwendertask und hebt damit den Wartezustand des Verbindungsmoduls auf.
Das Verbindungsmodul schreibt den bearbeiteten BIB aus dem Communication Pool in das Anwenderprogramm zurück.
Das Verbindungsmodul gibt die Steuerung an das Anwenderprogramm zurück. Das Anwenderprogramm kann nun die Daten in dem Satzbereich bearbeiten.
Bearbeiten einer CALL-DML-Anweisung durch den independent DBH
Im Folgenden wird am Beispiel eines CALL-DML-Programms die Bearbeitung einer DML-Anweisung dargestellt, wobei das folgende Bild den Ablauf verdeutlichen soll.
Bild 5: Abwicklung einer CALL-DML-Anweisung durch den independent DBH
Die Rolle des SSITAB-Pools und des Verbindungsmoduls UDSCON wird hier erläutert.
Ist das Anwenderprogramm das erste CALL-DML-Anwenderprogramm der laufenden UDS/SQL-Session, so wird vom Verbindungsmodul der SSITAB-Pool eingerichtet.
Alle Prozesse der UDS/SQL-Task-Familie müssen sich zu diesem Zeitpunkt ebenfalls an den SSITAB-Pool anschließen. Gelingt dies, ist ab diesem Zeitpunkt dasArbeiten mit der CALL-DML bis zum Session-Ende möglich. Der SSITAB-Pool bleibt bis zum Session-Ende bestehen.
Jedes Anwenderprogramm, das mit der CALL-DML arbeitet, hängt sich an den Pool an und überprüft, ob sich das SSITAB-Modul bereits im SSITAB-Pool befindet. Ist dies nicht der Fall, wird versucht, das SSITAB-Modul aus einer Bibliothek nachzuladen, die vor dem Start des Anwenderprogramms mit dem Linknamen $UDSSSI zugewiesen wurde. Detaillierte Informationen zum Nachladen von SSITAB-Modulen finden Sie im Kapitel "DBH-Startkommandos" und im Handbuch „Anwendungen programmieren“, Abschnitt „UDS/SQL-TIAM-Anwendungen binden, laden und starten“.
Wird nun vom Anwendermodul an der CALL-Schnittstelle ein DML-Auftrag abgesetzt, so übernimmt ihn das Verbindungsmodul. Das Verbindungsmodul gibt den Auftrag an den CALL-DML-Umsetzer weiter, der die Anforderung in einen UDS/SQL verständlichen BIB umsetzt. Der BIB wird dann vom Verbindungsmodul in den Communication Pool geschrieben.
Dieser BIB wird einer Servertask übergeben und bearbeitet. Ist keine Servertask verfügbar, so muss der BIB warten, bis eine Servertask frei wird. Das Verbindungsmodul versetzt sich in den Wartezustand bis die DML-Anweisung bearbeitet worden ist. Das Anwenderprogramm bekommt erst danach die Kontrolle zurück.
Zur Bearbeitung der DML-Anweisung greift die Servertask auf den BIB im Communication Pool und die Buffer Pools im Common Pool zu.
Soll die DML-Anweisung Daten aus der Datenbank lesen, so überträgt die Servertask die in den Buffer Pools stehenden Daten in den entsprechenden BIB im Communication Pool. Umgekehrt beim Schreiben: soll die DML-Anweisung Daten in die Datenbank schreiben, so überträgt die Servertask die im BIB stehenden Daten in die Buffer Pools. Die Servertask schreibt im Allgemeinen aus den Buffer Pools einen Puffer jedoch erst dann in die Datenbank zurück, wenn eine andere Datenbankseite den Platz im Puffer benötigt.Befindet sich die Datenbankseite, in der die DML-Anweisung die Daten des BIB schreiben soll oder aus der sie Daten lesen soll, nicht in den Buffer Pools, so wird auf der angegebenen Datenbank die entsprechende Datenbankseite gesucht und in die Buffer Pools eingelesen.
Nach der Bearbeitung der DML-Anweisung aktiviert die Servertask die zur Transaktion gehörende Anwendertask und hebt damit den Wartezustand des Verbindungsmoduls auf.
Ist der BIB von UDS/SQL bearbeitet, übernimmt das Verbindungsmodul diesen, und gibt ihn an den CALL-DML-Umsetzer weiter, der die Ergebnisse aus dem BIB in die benutzerverständliche CALL-Schnittstelle umsetzt.