DE69033121T2

DE69033121T2 - Betriebssystem und Datenbank mit einer Regelsprache zum bedingungsgesteuerten Rechnerbetrieb

Info

Publication number: DE69033121T2
Application number: DE69033121T
Authority: DE
Inventors: Daniel T. Chong; Helge Knudsen; Zbigniew Plazak; Michael Robertson; James Taugher; John Yaffe
Original assignee: Amdahl Corp
Current assignee: Objectstar International Ltd
Priority date: 1989-09-01
Filing date: 1990-09-04
Publication date: 1999-10-28
Anticipated expiration: 2010-09-05
Also published as: AU671138B2; EP0588446A3; DE69033120T2; EP0588447A3; EP0588445B1; CA2284250A1; CA2284245C; US5586330A; DE69031040D1; DE69033121D1; ES2132175T3; DE69033120D1; EP0489861A1; CA2284250C; CA2284247A1; WO1991003791A1; EP0588447A2; ATE180336T1; EP0588445A2; EP0489861B1

Description

Hintergrund der Erfindung

Die vorliegende Erfindung bezieht sich auf höhere Computerschnittstellen für Datenzugriffs- und Programmentwicklungsumgebungen.

Beschreibung des verwandten Gebiets

Die Entwicklung von Anwendungsprogrammen durch Softwareingenieure ist eine komplizierte Aufgabe. Diese Komplikation entsteht teilweise infolge von Umgebungsparametern wie etwa der Vielzahl der Datentypen, der Hardwaretypen, der Betriebssystemtypen, der Programmrevisionsverfahren und weiterer Einzelheiten. Zum Handhaben aller dieser Umgebungsparameter wurden Computer-Programmiersprachen entwickelt, wobei sie üblicherweise eine explizite Erkennung der Parameter in dem Code erfordern. Zusätzlich zu dem Grundalgorithmus zum Ausführen der Anwendung, die er im Auge hat, hat der typische Anwendungsprogrammierer somit Datendefinitionen, das Editieren und Validieren von Eingangsdaten, die Auswahl und das Ordnen der für das Programm verfügbaren Daten, Schleifennebenbedingungen an das System für das Programm, das Editieren der Ausgaben und Validierungskonventionen, die Fehlerverarbeitung, die Programmrevision und weitere komplizierte Aufgaben zu bewältigen.
Diese Umgebungsparameter verkomplizieren auch den Lauf von mit höheren Sprachen geschriebenen Programmen. Diese Programme müssen vor der Ausführung kompiliert oder geladen werden, wobei während dieser Zeit alle zu der Anwendung gehörenden physikalischen Betriebsmittel, Daten und Regeln miteinander verbunden werden müssen.
Dieses für eine gegebene Anwendung zur Kompilierungszeit oder zur Ladezeit erforderliche Binden der Betriebsmittel erschwert das Realisieren wirklich ereignisgesteuerter oder datengesteuerter Programme.
Es wurden Versuche unternommen, einige Programmiersprachen interpretierend zu machen. Das heißt, daß sie bestimmte Betriebsmittel an das Programm binden können, während es läuft. Jedoch haben diese Interpreterprogramme eine sehr beschränkte Leistung, wobei sie in der Industrie keine weitverbreitete Akzeptanz gefunden haben.
Dementsprechend besteht ein Bedarf an einem Betriebssystem, an einer Datenbank und an einem Datenzugriffsverfahren, die ermöglichen, daß Anwendungsprogrammierer frei von den durch die Umgebungsparameter verursachten Komplikationen sind.
US-A-4860204 offenbart z. B. ein Computersystem, das für das interaktive Eingeben und Ausführen von Regeln sorgt, die eine Bedingung in Form eines logischen Ausdrucks enthalten, der einen Booleschen Wert wahr oder falsch und eine zugehörige nachfolgende Aktion besitzt.

Zusammenfassung der Erfindung

Die vorliegende Erfindung schafft einen programmierbaren Computer zum Ausführen einer Regel, wie er in Anspruch 1 definiert ist, ein Verfahren zum Programmieren eines Computers zum Ausführen einer Regel, wie es in Anspruch 16 angegeben ist, sowie ein Verfahren zum Ausführen einer Regel durch einen Computer gemäß Anspruch 21.
Weitere Aspekte und Vorteile der vorliegenden Erfindung sind anhand der folgenden Übersicht der Figuren, der ausführlichen Beschreibung und der Ansprüche ersichtlich.

Kurzbeschreibung der Figuren

Fig. 1 ist ein Übersichts-Blockschaltplan eines Datenverarbeitungssystems, das die vorliegende Erfindung realisiert.
Fig. 2 ist ein Block-Stromlaufplan der virtuellen Datenverarbeitungsmaschine.
Fig. 3 ist ein begriffliches Diagramm des Transaktionsprozessors.
Fig. 4 ist ein Stromlaufplan, der den Betrieb des Transaktionsprozessors zum Aufruf einer Regel zeigt.
Fig. 5 ist ein Diagramm des Regelnamen-Hash-Verfahrens.
Fig. 6 ist ein Stromlaufplan des Tabellennamen-Hash-Verfahrens.
Fig. 7 ist ein begriffliches Diagramm der Tabellenzugriffsmaschine mit mehreren Servern und Puffern.
Fig. 8 ist ein begriffliches Diagramm des Speichers in der Tabellenzugriffsmaschine.
Fig. 10 ist ein begriffliches Diagramm der CTABLE.
Fig. 11 ist ein begriffliches Diagramm einer Quelltabelle und einer Unteransichttabelle.
Fig. 12 zeigt die Operation der Absichtsliste.
Fig. 13 ist ein begriffliches Diagramm einer Transaktion in der virtuellen Maschine.
Fig. 14 ist ein schematisches Diagramm des Tabellendaten- Speicherzugriffsverfahrens.
Fig. 15 zeigt die Anordnung einer Datenseite in dem Tabellendatenspeicher.
Fig. 16 ist eine Übersicht der Regeleditorkomponenten.
Fig. 17 zeigt die von dem Regeleditor verwendete TOKENS- und LONG_STRINGS-Tabelle.
Die Fig. 18, 19, 20A-20C und 21A-21E zeigen den Betrieb des Rückübersetzers.

Ausführliche Beschreibung

I. Systemüberblick

Fig. 1 zeigt die Grundverwirklichung des Datenverarbeitungssystems gemäß der vorliegenden Erfindung. Dieses System wird als eine virtuelle Maschine auf einem Großrechner 10 realisiert. Auf dem Großrechner läuft ein Host-Betriebssystem, in dem zweckmäßigen System MVS. Unter dem Host-Betriebssystem kann ein Datenbank-Zugriffssystem wie etwa das IMS 11 laufen. Gleichzeitig läuft unter MVS das als das HOS 12 bekannte Datenverarbeitungssystem gemäß der vorliegenden Erfindung. An den Großrechner sind mehrere Anwenderterminals 13, 14 wie etwa die Modelle 3270 angeschlossen. Außerdem könnten an den Großrechner 10 Workstations 15 angeschlossen sein, auf denen andere Betriebssysteme wie etwa UNIX laufen.
An den Großrechner-Datenserver wie etwa an das IMS 11 sind die Direktzugriffs-Speichervorrichtungen 16 und 17 angeschlossen, in denen die Firmendaten gespeichert werden. Außerdem sind an das HOS-System 12 die Direktzugriffs-Speichervorrichtungen 18 und 19 angeschlossen.
Fig. 2 zeigt ein begriffliches Blockdiagramm des HOS-Datenverarbeitungssystems. Das System umfaßt einen Transaktionsprozessor 20, eine Tabellenzugriffsmaschine 21 und einen an die Direktzugriffs-Speichervorrichtung 23 angeschlossenen Tabellendaten-Speicherserver 22. Außerdem steuert die Tabellenzugriffsmaschine 21 einen an ein Anwenderterminal 25 angeschlossenen Bildschirmserver 24 sowie einen an weitere Quellen von Datendateien 27 und 28 angeschlossenen Import/Export-Server 26 an.
Außerdem schafft die Tabellenzugriffsmaschine 21 eine Schnittstelle zu einem heterogenen Datenbank-Systemserver wie etwa zu dem an die Direktspeicher-Zugriffsvorrichtungen 30 angeschlossenen IMS-Server 29.
Der Transaktionsprozessor 20 ist als eine Maschine mit einem virtuellen Stapel realisiert, die die Objektcodeebenen-Darstellung der Regeln ausführt. Diese Regeln sind in einer jeder Transaktion zugeordneten Regelbibliothek 31 gespeichert. Typischerweise umfaßt die Regelbibliothek einen Sitzungsmanager 39, der ein Bildschirmmenü und grundlegende Hilfsmittel für den Programmierer bereitstellt. Die Hilfsmittel umfassen den Regeleditor 32, einen Tabelleneditor-Browser 33, die RPW- und Druck-Hilfsmittel 34, bei Bedarf die Abfrageprozessoren 35 sowie die Anwendungsprogramme 36, 37, 38 wie etwa die für eine gegebene Transaktion aufgerufenen Anwendungsprogramme.
Über die Tabellenzugriffsmaschine 21 werden die in den Direktzugriffs-Speichervorrichtungen 23, 30, 27, 28 gespeicherten physikalischen Daten an den Transaktionsprozessor 20 so, als ob sie in dem Tabellendaten-Speichersystem gespeichert wären, übergeben.
Die Server 22, 24, 26, 29, die Tabellenzugriffsmaschine 21 und der Transaktionsprozessor 20 werden alle als virtuelle Maschinen in dem Host-Betriebssystem realisiert. Somit werden diese virtuellen Maschinen in dem zweckmäßigen System mit der Sy stem 370-Assemblersprache realisiert, wobei sie die unten ausführlich beschriebenen Funktionen ausführen.

II. Regelsprache

Die Regelsprache ist die Programmierschnittstelle für das System. Die Sprache umfaßt eine integrierte Menge von Datenbank-Zugriffsbefehlen, Konstruktionen der vierten Generation sowie herkömmlichen Sprachanweisungen, wodurch das strukturierte Programmieren eine natürliche Folge des Entwickelns einer Anwendung wird.
Die Regeln besitzen die folgenden vier Teile:
1. die Regeldefinition
2. Bedingungen
3. Aktionen
4. Ausnahmebehandlungsroutinen.

ALLGEMEINE FORM DER REGELN

Tabelle 1 zeigt eine Beispielregel namens LEAPYEAR, die ein Argument namens YEAR besitzt. LEAPYEAR ist eine Funktion, da sie im Ergebnis der Ausführung mit RETURN einen Wert - entweder 'Y' oder 'N' - zurückgibt.

Tabelle 1: Die Regel LEAPYEAR

LEAPYEAR(YEAR);
REMAINDER(YEAR, 4) = 0'; Y N
RETURN('Y'); ; 1
RETURN('N'); ; 1
Die Regeldefinition enthält den Regelanfangsblock "LEAPYEAR(YEAR);" wobei sie lokale Variablendefinitionen enthalten würde, falls solche vorhanden wären. Die Bedingungen bestimmen die Ausführungsfolge. In dieser Regel gibt es nur eine Bedingung, den Vergleich "REMAINDER(YEAR, 4) = 0;". Die Aktionen sind in der Regel ausführbare Anweisungen, von denen in irgendeinem besonderen Aufruf nur einige ausgeführt werden. Die erste Aktion, "RETURN('Y');", wird ausgeführt, falls die Bedingung erfüllt ist, während die zweite Aktion "RETURN('N');" ausgeführt wird, falls die Bedingung nicht erfüllt ist. In diesem Beispiel besitzt die Regel keine Ausnahmebehandlungsroutinen, so daß der vierte Teil der Regel keine Anweisungen enthält.
Tabelle 2 zeigt eine komplexere Regel. Die zwei GET-Anweisungen überprüfen, daß der Monat, auf den sich der Parameter mm bezieht, in der Tabelle MONTHS vorkommt, und daß der Tag, auf den sich der Parameter DD bezieht, kleiner oder gleich dem Maximum für diesen Monat ist. Ein Scheitern einer GET-Anweisung bewirkt die Ausnahme GETFAIL, wobei die Ausnahmebehandlungsroutine eine Nachricht erzeugt und den Wert 'N' zurückgibt.

Tabelle 2: Die Regel VALID_DATE

VALID_DATE(YY, MM, DD);
DD < = 0; '; Y N N
LEAP YEAR (YY); Y N
CALL MSGLOG('INVALID DAY ENTERED'); 1
GET MONTHS WHERE MONTH = MM & LDAYS > = DD; 1
GET MONTHS WHERE MONTH = MM & DAYS > = DD; 1
RETURN('N'); 2
RETURN('Y'); 2 2
ON GETFAIL:
CALL MSGLOG('INVALID MONTH/DAY COMBINATION');
RETURN('N")4;
Tabelle 3 zeigt die Tabelle MONTHS, auf die sich die Regel VALD_DATE bezieht. Es wird besonders auf die zwei Spalten für die Anzahlen der Tage in einem Monat für Schaltjahre und für Nicht-Schaltjahre hingewiesen. Tabelle 3: Die Tabelle MONTHS
Tabelle 4 zeigt eine Regel, die eine FORALL-Anweisung enthält. Die Regel COUNT_CARS berechnet die Anzahl der Besitzer mit Autos eines gegeben Modells und Jahrs und druckt dann das Ergebnis (MODEL und YEAR sind Felder in der Tabelle CARS). Die Regel besitzt keine Bedingungen. Die Standardroutine MSLOG übergibt das Ergebnis der Summierung in dem Nachrichtenprotokoll (das Symbol g ist der Verknüpfungsoperator).
Tabelle 5 zeigt die Tabelle CARS, auf die sich die Regel COUNT_CARS bezieht.

Tabelle 4: Die Regel COUNT_CARS

COUNT_CARS(MDL, YY);
LOCAL COUNT;
FORALL CARS WHERE MODEL = MDL AND YEAR = YY; 1
COUNT = COUNT + 1;
END;
CALL MSGLOG('RESULT:' g COUNT); 2 Tabelle 5: Die Tabelle CARS

REGELDEFINITION

Die Regeldefinition, der erste Teil eine HOS-Regel, enthält einen (obligatorischen) Regelanfangsblock sowie eine (optionale) Deklaration der lokalen Variablen.
Der Regelanfangsblock gibt der Regel einen Namen und definiert ihre Parameter (falls vorhanden). Die Parameterübergabe zwischen den Regeln erfolgt durch den Wert: Eine aufgerufene Regel kann den Wert eines Parameters nicht ändern. Die Datendarstellung eines Parameters ist dynamisch: Sie ist an den semantischen Datentyp und an die Syntax des ihm zugeordneten Werts angepaßt. Der Gültigkeitsbereich eines Parameters ist die Regel, in der der Parameter definiert ist. Tabelle 6 gibt ein Beispiel eines Regelanfangsblocks.

Tabelle 6: Regelanfangsblock für die Regel LEAPYEAR

LEAPYEAR(YEAR);
Lokale Variablen sind unter dem Regelanfangsblock definiert. Der Gültigkeitsbereich einer lokalen Variablen sind die Regel, in der sie definiert ist, sowie irgendwelche Nachfolgeregeln. Einer lokalen Variablen kann ein arithmetischer Wert oder ein String zugeordnet und in einer Aktion an einer beliebigen Stelle verwendet werden. Die Datendarstellung einer lokalen Variablen ist dynamisch: Sie ist an den semantischen Datentyp und an die Syntax des ihr zugeordneten Werts angepaßt. Lokale Variablen werden auf null initialisiert (d. h., in Abhängigkeit von der Verwendung auf null, auf das logische 'N' oder auf den Nullstring). Tabelle 7 gibt ein Beispiel der Deklaration einer lokalen Variablen.

Tabelle 7: Deklaration der lokalen Variablen SUM und RESULT

LOCAL SUM, RESULT;

BEDINGUNGEN

Bedingungen, d. h. auf ihren Wahrheitswert hin ausgewertete logische Ausdrücke, bestimmen die Ablaufsteuerung in einer Regel. Die Bedingungen werden nacheinander ausgewertet, wobei dann, wenn eine von ihnen erfüllt ist, die ihr entsprechenden Aktionen ausführbar sind und keine weiteren Bedingungen ausgewertet werden. Falls es (wie in der Regel in Tabelle 4) keine Bedingungen gibt, sind die Aktionen der Regel ausführbar.
Tabelle 8 gibt einige Beispiele von Bedingungen. REMAINDER und SUPPLIER_LOC sind Funktionen, die Werte zurückgeben. Obgleich eine von ihnen eine von dem System bereitgestellte Standardroutine und eine von ihnen eine Anwenderroutine ist, besteht beim Aufruf kein Unterschied.

Tabelle 8: Bedingungen

CARS.PRICE > INPUT.MIN;
REMAINDER(YEAR, 4) = 0;
INVOICE.LOCATION = SUPPLIER_LOC(INPUT.SUPP#);
Die Beispielregeln in den früheren Tabellen zeigen, daß der Teil einer Regel, der die Bedingungen enthält, außerdem einen Y/N-Quadranten enthält, der die Werte Y/N ("ja/nein") anzeigt. Die Y/N-Werte koordinieren die Bedingungen und die Aktionen. Die Y/N-Werte liefert jedoch das HOS, nicht der Anwender. Die Funktion des Y/N-Quadranten wird in dem Abschnitt über die Aktionen klar.

AKTIONEN

Eine Aktion ist eine ausführbare Anweisung. Aktionsfolgenummern bestimmen, welche Aktionen für jede besondere Bedingung ausgeführt werden. Für verschiedene Bedingungen kann die gleiche Aktion ausgeführt werden.
Tatsächlich ist eine Regel eine erweiterte Case-Anweisung. Die Bedingungen und Aktionen können folgendermaßen lauten:
CASE:
condition 1: actions
condition 2: actions
...
condition n: actions
else: actions
END CASE;
Zum Beispiel wird die Regel in Tabelle 9 betrachtet.
Die Bedingungen und Aktionen in der Regel VALID-DATE können wie die untenstehende Case-Anweisung lauten:
CASE:
DD < = 0: CALL MSGLOG('INVALID DAT ENTERED'); RETURN('N');
LEAPYEAR(YY): GET MONTHS WHERE MONTH = MM & LDAYS > = DD; RETURN('Y');
ELSE: GET MONTHS WHERE MONTH = MM & DAYS > = DD; RETURN('Y');
END CASE;
Die in der Regelsprache verfügbaren Aktionen werden unten beschrieben.

Tabelle 9: Aktionsfolgenummern

VALID_DATE(YY, DD);
DD < = 0; Y N N
LEAPYEAR(YY); Y N
CALL MSGLOG('INVALID DAY ENTERED'); 1
GET MONTHS WHERE MONTH = MM & LDAYS > = DD; 1
GET MONTHS WHERE MONTH = MM & DAYS > = DD; 1
RETURN('N'); 2
RETURN('Y'); 2 2
ON GETFAIL:
CALL MSGLOG('INVALID MONTH/DAY-COMBINATION');
RETURN('N');
Es gibt zwei Arten von Zuweisungsanweisungen. In einer einfachen Zuweisung wird einem Feld einer Tabelle oder einer lokalen Variablen ein einzelner Wert zugeordnet. Tabelle 10 zeigt eine einfache Zuweisung.

Tabelle 10: Eine einfache Zuweisung

CARS.PRICE = (PRICES.BASE + PRICES.SHIPPING) *TAXES. RETAIL;
AMOUNT = PRINCIPAL * (1 + INTEREST) ** YEARS;
In einer Zuweisung durch den Namen werden alle rechtsstehenden Werte der Felder der Tabelle linksstehenden Feldern völlig gleichen Namens der Tabelle zugewiesen. Die Tabelle 11 zeigt ein Beispiel. Die Zuweisung durch den Namen ist eine zweckmäßige Art, alle Werte von Feldern einer Bildschirmtabelle den Feldern einer Datentabelle zuzuweisen oder umgekehrt.

Tabelle 11: Zuweisung durch den Namen

ORDERS.* = ORDER_SCREEN.*;
Eine Regel kann implizit über einen logischen oder arithmetischen Ausdruck, der die Funktionsschreibweise verwendet, oder explizit mit einer CALL-Anweisung eine weitere Regel aufrufen. Tabelle 12 zeigt den impliziten Aufruf der Funktion REMAINDER(YEAR, 4), bei der es sich um eine Standardroutine handelt, die eine ganze Zahl zurückgibt.

Tabelle 12: Impliziter Aufruf einer Regel

R = REMAINDER(YEAR, 4);
Falls eine Regel eine RETURN-Anweisung enthält, die das Ergebnis spezifiziert, ist sie eine Funktion. Die Tabelle 13 zeigt Beispiele von RETURN-Anweisungen.

Tabelle 13: RETURN-Anweisung

RETURN('Y');
RETURN(CARS.PRICE - REBATE);
Die CALL-Anweisung kann eine Regel direkt, indem sie auf die Regel durch ihren Namen Bezug nimmt, oder indirekt, indem sie auf ein Feld einer Tabelle oder auf einen Parameter, der den Namen der Regel enthält, Bezug nimmt, aufrufen. Es wird angemerkt, daß die Argumente in den CALL-Anweisungen durch eine Argumentliste oder durch eine WHERE-Klausel übergeben werden können. Ein Parameterschlüsselwort in einer WHERE-Klausel muß der Name eines Parameters in dem Regelanfangsblock einer aufgerufenen Regel sein. Beim Aufruf einer Regel müssen alle Parameter spezifiziert werden.
Eine HOS-Datenbank ist eine Sammlung von Tabellen. Die Regeln greifen auf Tabellen auf einer Häufigkeitsbasis zu. Wenn eine Regel auf eine Tabelle Bezug nimmt, erzeugt sie eine Tabellenschablone, die als ein Fenster in die Tabelle dient. Die Regeln geben neue Informationen in die Tabelle ein, indem sie zunächst die neuen Daten in den richtigen Feldern einer Tabellenschablone anordnen und dann entweder eine REPLACE- oder eine INSERT-Anweisung ausführen. Die Regeln gewinnen mit einer GET-Anweisung oder mit einer FORALL-Anweisung Informationen aus der Tabelle in einer Tabellenschablone wieder. Die Regeln löschen Informationen aus der Tabelle, indem sie die Informationen in einer Tabellenschablone anordnen und dann eine DELETE-Anweisung ausführen (nach einer DELETE-Anweisung ist die Tabellenschablone undefiniert).
Für eine GET-, FORALL- oder DELETE-Anweisung können in einer WHERE-Klausel Auswahlkriterien spezifiziert werden. Die WHERE- Klausel enthält eine aus einem oder aus mehreren Vergleichen bestehende Aussage. Bevor die Daten in der Tabellenschablone angeordnet werden, wird die Aussage ausgewertet.
Die Tabellenparameter können in Form einer Liste oder in einer WHERE-Klausel spezifiziert werden (wobei die zwei Formen den zwei Verfahren der Parameterübergabe in der CALL-Anweisung entsprechen).
Die GET-Anweisung gewinnt das erste den besonderen Auswahlkriterien genügende Auftreten in einer Tabelle wieder. Falls es keine Auftreten gibt, die den Auswahlkriterien genügen, wird die GETFAIL-Ausnahme gemeldet.
Die FORALL-Anweisung, die eine Schleifenkonstruktion ist, verarbeitet eine Menge von Auftreten. Der Hauptteil der Schleife besteht aus den Anweisungen, die für jedes Auftreten, das den Auswahlkriterien genügt, ausgeführt werden sollen. Das Verschachteln von FORALL-Anweisungen ist zulässig.
Eine FORALL-Anweisung enthält einen Tabellennamen, eine optionale WHERE-Klausel, optionale ORDERED-Klauseln, eine optionale UNTIL-Klausel sowie Aktionen. Nach den optionalen Klauseln (oder, falls es keine optionalen Klauseln gibt, nach dem Tabellennamen) kommt ein Doppelpunkt (:). Die Aktionen, die den Hauptteil der Schleife bilden, kommen in getrennten Zeilen nach dem Doppelpunkt. Eine "END; "-Klausel auf einer getrennten Zeile kennzeichnet das Ende der FORALL-Anweisung. Wie bei allen Tabellenzugriffsanweisungen können die Parameter in einer Argumentliste oder in einer WHERE-Klausel spezifiziert werden. Die Auswahl an Feldern wird ebenfalls in der WHERE- Klausel spezifiziert. Eine WHERE-Klausel hat in einer FORALL- Anweisung die gleiche Wirkung wie in einer GET-Anweisung. Eine WHERE-Klausel kann mit einem Stern (*) auf die momentane Tabelle Bezug nehmen.
Eine WHERE-Klausel kann den "Teilübereinstimmungs"-Operator LIKE enthalten, der den Vergleich unvollständig spezifizierter Datenstrings ermöglicht. Unvollständig spezifizierte Datenstrings können mit einem Stern (*) auf null oder mehr unspezifizierte Zeichen Bezug nehmen, während sie auf ein unbekanntes Zeichen mit einem Fragezeichen (?) Bezug nehmen können.
Wenn eine FORALL-Anweisung ausgeführt wird, werden die Tabellenauftreten in der Reihenfolge des primären Schlüssels wie dergewonnen, es sei denn, daß durch eine oder durch mehrere ORDERED-Klauseln eine andere Reihenfolge spezifiziert wird. In dem Beispiel aus Tabelle 18 werden die Auftreten nach den absteigenden Werten des Felds PRICE, dann nach aufsteigenden Werten des Felds MODEL und dann nach den aufsteigenden Werten des primären Schlüssels LICENSE sortiert dargestellt (wobei die Voreinstellung für das Ordnen ASCENDING ist).
Die Ausführung einer FORALL-Anweisung wird unter einem von zwei Umständen abgeschlossen: (1) Alle Auftreten, die das FORALL-Auswahlkriterium erfüllen, sind verarbeitet worden, oder (2) während der Ausführung der Anweisungen, die die Schleife bilden, wird eine Ausnahme erfaßt. Am Ende einer FORALL-Anweisung ist die Tabellenschablone undefiniert.
Die INSERT-Anweisung fügt einer Tabelle in der Datenbank ein neues Auftreten hinzu. Eine Feldauswahl ist nicht möglich: Die WHERE-Klausel kann nur Parameterwerte spezifizieren.
Die Auftreten in einer Tabelle müssen eindeutige primäre Schlüssel besitzen. Ein Versuch, ein Auftreten mit einem bereits existierenden primären Schlüssel einzusetzen, bewirkt die INSERTFAIL-Ausnahme.
Die REPLACE-Anweisung aktualisiert ein Auftreten in der Datenbank. Eine Feldauswahl ist nicht möglich: Die WHERE-Klausel kann nur Parameterwerte spezifizieren.
Falls das Auftreten nicht existiert, wird die REPLACEFAIL- Ausnahme gemeldet. Um den Wert des primären Schlüssels des Auftretens zu ändern, muß das alte Auftreten mit DELETE gelöscht und das neue mit INSERT eingesetzt werden.
Die DELETE-Anweisung entfernt ein Auftreten aus einer Tabelle in der Datenbank. Falls die spezifizierte Relation die Gleichheit ist, kann eine WHERE-Klausel anhand des Primärschlüsselfelds eine Feldauswahl spezifizieren. Eine weitere Feldauswahl ist nicht möglich. Wie üblich kann eine WHERE-Klausel Parameterwerte spezifizieren.
Falls der primäre Schlüssel in einer WHERE-Klausel spezifiziert ist, wird das Auftreten gelöscht. Falls kein primärer Schlüssel spezifiziert ist, wird das Auftreten, auf das der primäre Schlüssel in der Tabellenschablone Bezug nimmt, gelöscht. Falls das Auftreten in der Tabelle nicht existiert, wird die DELETEFAIL-Ausnahme gemeldet.
Die Standardanwenderschnittstelle sind Bildschirme. Sie unterstützen die Eingabe von einer Tastatur und erzeugen eine Ausgabe auf einem Terminal.
Die DISPLAY-Anweisung bewirkt, daß der spezifizierte Bildschirm angezeigt wird, wobei jede Eingabe, die auf dem Bildschirm eingegeben wird, für die Verarbeitung zur Verfügung steht.
Die UNTIL...DISPLAY-Anweisung, bei der es sich um eine Schleifenkonstruktion handelt, zeigt einen Bildschirm wiederholt an. Der Hauptteil der Schleife besteht aus Anweisungen, die bei jedem Anzeigen des Bildschirms ausgeführt werden. In dem Hauptteil der Schleife ist irgendeine Eingangsgröße für die Verarbeitung verfügbar.
Zwei Konstruktionen, die FORALL-Anweisung, die eine UNTIL- Klausel enthalten kann, und die UNTIL...DISPLAY-Anweisung, ermöglichen Schleifen. Die Anweisungen zwischen dem FORALL- Teil oder zwischen dem UNTIL...DISPLAY-Teil, der mit einem Doppelpunkt (:) und mit der "END;"-Klausel abgeschlossen wird, bilden den Hauptteil der Schleife.
Die UNTIL-Klausel spezifiziert eine Ausnahme oder zwei oder mehr durch das Schlüsselwort OR getrennte Ausnahmen. Die Schleife wird abgeschlossen, falls eine Ausnahme erfaßt wird.
Falls eine Schleife infolge einer Ausnahme abgeschlossen wird, wird die Steuerung wie folgt an neue Aktionen übergeben:
Falls die Ausnahme in einer UNTIL-Klausel für die Schleife spezifiziert ist, werden als nächstes die Aktionen ausgeführt, die auf die END-Klausel der Schleife folgen (die Steuerung wird auch dann an jene Aktionen übergeben, wenn es für diese Ausnahme in dem Ausnahmebehandlungsroutinenteil der Regel eine ON-Anweisung gibt). Beim Abschluß dieser Aktionen wird die Ausführung der Regel abgeschlossen, wobei die Steuerung an den Aufrufer übergeben wird. An dem Punkt, an dem die Ausnahme erfaßt wurde, wird die Ausführung mit NOT nicht fortgeführt.
Falls die Ausnahme nicht in einer UNTIL-Klausel für die Schleife, aber in einer ON-Anweisung in dem Ausnahmebehandlungsroutinenteil der Regel spezifiziert ist, wird die Ausnahme in der üblichen Weise behandelt: Als nächstes werden die in der ON-Anweisung aufgelisteten Aktionen ausgeführt.
Falls die Ausnahme nicht in einer UNTIL-Klausel für die Schleife oder in einer ON-Anweisung in dem Ausnahmebehandlungsroutinenteil der Regel spezifiziert ist, wird sie in der üblichen Weise behandelt: Entweder wird die Ausnahme in der üblichen Weise von einer Ausnahmebehandlungsroutine in einer in der Aufrufhierarchie höheren Regel abgefangen oder die Transaktion wird abgeschlossen.
Fünf Anweisungen, die COMMIT-Anweisung, die ROLLBACK-Anweisung, die SCHEDULE-Anweisung, die TRANSFERCALL-Anweisung und die EXECUTE-Anweisung, steuern die Synchronisierung der Transaktion.
Die Anweisungen COMMIT und ROLLBACK setzen Transaktionssynchronisierungspunkte fest. Entweder werden auf die Datenbank alle Änderungen zwischen den Synchronisierungspunkten angewendet oder keine.
Der normale Abschluß einer Transaktion beinhaltet CONNIT, während der anomale Abschluß ROLLBACK beinhaltet.
Die SCHEDULE-Anweisung ermöglicht die asynchrone Verarbeitung, indem sie ermöglicht, eine Transaktion unabhängig von der momentanen Transaktion in eine Warteschlange für die Ausführung einzureihen. Die Regel, die ausgeführt werden soll, muß beim Ausführen der SCHEDULE-Anweisung existieren. Der Name einer Warteschlange kann durch eine optionale TO-Klausel spezifiziert werden. Die Definition der Warteschlangen wird durch Systemparameter behandelt und erfolgt nicht in der Regelsprache.
Das Einreihen in die Warteschlange hängt vom normalen Abschluß der momentanen Transaktion, d. h. vom Abschluß in Übereinstimmung mit dem Transaktionsprotokoll, ab.
Die TRANSFERCALL-Anweisung schließt die momentane Transaktion ab und ruft eine neue auf. Die Steuerung wird nicht an die aufrufende Regel zurückgegeben. Wenn die Ausführung der aufgerufenen Regel abgeschlossen ist, ist die Transaktion abgeschlossen.
Die TRANSFERCALL-Anweisung kann wie die CALL-Anweisung eine Regel direkt, indem sie auf die Regel durch ihren Namen Bezug nimmt, oder indirekt, indem sie auf ein Feld einer Tabelle oder auf einen Parameter, der den Namen der Regel enthält, Bezug nimmt, aufrufen.
Die EXECUTE-Anweisung ruft eine nachfolgende Transaktion auf. Beim Abschluß der ausgeführten Transaktion wird die Steuerung zurück an die ursprüngliche Transaktion übergeben. (Es wird angemerkt, daß die CALL-Anweisung eine Regel in dem Gültigkeitsbereich der momentanen Transaktion aufruft, während die EXECUTE-Anweisung eine Regel aufruft, die eine unabhängige Transaktion startet.)
Wie die CALL-Anweisung kann die EXECUTE-Anweisung eine Regel direkt, indem sie auf die Regel durch ihren Namen Bezug nimmt, oder indirekt, indem sie auf ein Feld einer Tabelle oder auf einen Parameter, der den Namen der Regel enthält, Bezug nimmt, aufrufen.
Die SIGNAL-Anweisung bewirkt die in der Anweisung spezifizierte Ausnahme. Eine ON-Anweisung oder eine UNTIL-Klausel können nachfolgend eine durch die SIGNAL-Anweisung bewirkte Ausnahme erfassen und verarbeiten.

AUSNAHMEBEHANDLUNG

Eine Ausnahmebehandlungsroutine ist eine ON-Anweisung, die den Namen einer Ausnahme enthält, auf den eine Folge von Aktionen folgt, die ausgeführt werden sollen, falls die Ausnahme erfaßt wird.
Die ON-Anweisung ist nur während der Ausführung der Aktionen der Regel, in der sie auftritt, gültig. Sie fängt sowohl Ausnahmen ab, die in der Regel erzeugt wurden, als auch solche, die in irgendwelchen Nachfolgern der Regel (Regeln, die in der Aufrufhierarchie unter der Regel kommen) erzeugt wurden.
Falls die ON-Anweisungen in einer oder in mehreren Regeln auf verschiedenen Ebenen in der Aufrufhierarchie die gleiche Ausnahme behandeln können, wird die Ausnahme von der ON-Anweisung in der untersten Regel behandelt.
Die Systemausnahmen sind hierarchisch definiert (wobei die Hierarchie im nächsten Abschnitt dargestellt wird). Falls eine Ausnahme von mehr als einer Behandlungsroutine behandelt werden kann, wird sie von der spezifischsten Behandlungsroutine behandelt. Zum Beispiel ist GETFAIL in der Ausnahmehierarchie niedriger als ACCESSFAIL. Falls eine Regel sowohl eine GETFAIL-Behandlungsroutine als auch eine ACCESSFAIL-Behand lungsroutine besitzt und eine GETFAIL-Ausnahme auftritt, wird die GETFAIL-Behandlungsroutine aufgerufen. Falls die Regel keine GETFAIL-Behandlungsroutine, aber eine ACCESSFAIL-Behandlungsroutine besitzt, wird die ACCESSFAIL-Behandlungsroutine aufgerufen.
Die GETFAIL-Behandlungsroutine behandelt eine GETFAIL-Ausnahme, falls sie bei einem GET-Zugriff auf die Tabelle beim Aufruf der Regel erfaßt wird, oder falls sie in der GET-Anweisung auftritt.
Der Gültigkeitsbereich der Datenzugriffs-Ausnahmebehandlungsroutinen (der Behandlungsroutinen für GETFAIL, INSERTFAIL, DELETEFAIL, REPLACEFAIL, ACCESSFAIL und DEFINITIONFAIL) kann beschränkt werden, indem wie in der Ausnahmehierarchietabelle ein Tabellenname spezifiziert wird. Falls ein Tabellenname spezifiziert ist, fängt die Behandlungsroutine die entsprechende Ausnahme nur ab, falls sie während des Zugreifens auf diese Tabelle erfaßt wird. Falls keine Tabelle spezifiziert ist, fängt die Behandlungsroutine die Ausnahme unabhängig davon, auf welche Tabelle zugegriffen wird, ab.
Die Anweisungen, die eine Ausnahmebehandlungsroutine bilden, könnten die gleiche Ausnahme bewirken. Falls dies geschieht (und falls die zweite Ausnahme nicht irgendwo tiefer in der Aufrufhierarchie behandelt wird), wird die zweite Ausnahme nicht von der momentan ausgeführten Behandlungsroutine behandelt. Die ERROR-Ausnahme fängt sämtliche erfaßbaren Fehler ab, während die GETFAIL-Ausnahme nur ein Auftreten in der Tabelle abfängt, das bei der Ausführung einer GET-Anweisung nicht gefunden wird. Das folgende Diagramm zeigt sämtliche Namen von Systemausnahmen mit ihrer relativen Lage in der Hierarchie. Tabelle: Ausnahmehierarchie
Es sind drei Ebenen von Ausnahmen definiert, wobei eine Ausnahme irgendeinen der in der Hierarchie unter ihm liegenden Ausnahmenamen abfängt. Die Bedingungen, unter denen jede dieser Ausnahmen gemeldet wird, sind unten beschrieben.
ACCESSFAIL - es ist ein Tabellenzugriffsfehler erfaßt worden
COMMITLIMIT - die Grenze der Anzahl der Aktualisierungen für eine Transaktion ist erreicht
CONVERSION - Wert enthält ungültige Daten für die Syntax oder kann nicht in die Zielsyntax umgesetzt werden
DATAREFERENCE - es ist ein Fehler bei der Angabe des Auswahlkriteriums erfaßt worden
DEFINITIONFAIL - es ist ein Fehler bei der Definition einer Tabelle erfaßt worden
DELETEFAIL - Schlüssel für die DELETE-Anweisung existiert nicht
DISPLAYFAIL - es ist ein Fehler beim Anzeigen eines Bildschirms erfaßt worden
ERROR - es ist ein Fehler erfaßt worden
EXECUTEFAIL - es ist ein Fehler in der Kind-Transaktion erfaßt worden
GETFAIL - kein Auftreten erfüllt die Auswahlkriterien
INSERTFAIL - Schlüssel für die INSERT-Anweisung existiert bereits
LOCKFAIL ein Auftreten ist verriegelt oder eine Tabelle nicht verfügbar oder es ist eine Blockierung aufgetreten
OVERFLOW - Wert ist zu groß, um ihn der Zielsyntax zuzuordnen
REPLACEFAIL - Schlüssel für die REPLACE-Anweisung existiert nicht
RULEFAIL - Fehler rührt aus der arithmetischen Berechnung her
SECURITYFAIL - Berechtigung für die angeforderte Aktion verweigert
STRINGSIZE - es ist ein Größenfehler beim Zuordnen eines Strings zu einem anderen erfaßt worden
UNGSSIGNED - es wurde Bezug auf ein Feld einer Tabelle genommen, dem kein Wert zugeordnet worden ist
UNDERFLOW - Wert ist zu klein, um ihn in der Zielsyntax darzustellen (zumeist Exponentialfehler)
VALIDATEFAIL - Ausstieg aus der Validierung über Validierungsausstiegsschlüssel angefordert
ZERODIVIDE - es ist ein Versuch der Division durch null erfaßt worden

AUSDRÜCKE OPERATOREN UND DATENTYPEN

Bedingungen, Aktionen und Ausnahmebehandlungsroutinen enthalten Ausdrücke. Ausdrücke können arithmetische Operatoren und/oder einen Stringverknüpfungsoperator enthalten. Diese Operatoren sind an die herkömmliche Schreibweise angepaßt, wobei sie dem unten gegebenen Vorrang genügen (die Exponenzierung besitzt den höchsten Vorrang):
** Exponenzierung
*,/ Multiplikation, Division
+,- monadisches +, monadisches -
+,-,g Addition, Subtraktion, Stringverknüpfung
Eine Folge von arithmetische Operatoren oder von Stringverknüpfungsoperatoren des gleichen Vorrangs wird von links nach rechts ausgewertet. Die Ausdruckstabelle zeigt die Operatoren in den Ausdrücken.

Tabelle: Ausdrücke

(PRICES.BASE + PRICES.SHIPPING) * TAXES.RETAIL PRINCIPAL * (1 + INTEREST) ** YEARS
Jedes Element eines Ausdrucks besitzt eine Syntax und einen semantischen Datentyp. Die Syntax beschreibt, wie die Daten gespeichert werden, während der semantische Datentyp beschreibt, wie das Element verwendet werden kann.

Syntax

Die Syntax für die Werte eines Felds einer Tabelle wird in der Tabellendefinition spezifiziert. Die Maximallänge des Felds wird ebenfalls in der Tabellendefinition spezifiziert.
Gültige Spezifikationen für die Syntax sind:
B (Binärzahl) - gültige Längen sind 2 und 4 Bytes
P (gepackte Dezimalzahl) - gültige Längen schwanken von 1 bis 8 Bytes, die von 1 bis 15 Dezimalziffern halten können, wobei die Anzahl der Dezimalziffern in der Tabellendefinition spezifiziert wird
F (Gleitkommazahl) - gültige Längen sind 4, 8 und 16 Bytes für ein Primärschlüsselfeld oder 1 bis 256 Bytes für andere Felder
C (Zeichenstring mit fester Länge) - gültige Längen schwanken von 1 bis 128 Bytes für ein Primärschlüsselfeld oder von 1 bis 256 Bytes für andere Felder
V (Zeichenstring mit variabler Länge) - gültige Längen schwanken von 3 bis 128 Bytes für ein Primärschlüsselfeld oder von 3 bis 256 Bytes für andere Felder, wobei der Speicher für die angegebene Länge reserviert wird, während die Stringoperationen die momentane Länge verwenden

Semantische Datentypen

Der semantische Datentyp für die Werte eines Felds einer Tabelle wird in der Tabellendefinition angegeben. Der semantische Datentyp bestimmt, welche Operationen an den Werten des Felds ausgeführt werden können. Die Operatoren sind in der Sprache nur für sinnvolle semantische Datentypen definiert. Zum Beispiel sind das Negieren eines Strings oder das Addieren einer Zahl zu einem Identifizierer ungültige Operationen (es werde das Addieren von 3 zu einem Kfz.-Nummernschild betrachtet).
Gültige semantische Datentypen und ihre zulässige Syntax sind:
I (Identifizierer)
C (Zeichenstring mit fester Länge)
V (Zeichenstring mit variabler Länge)
B (Binärzahl)
P (gepackte Dezimalzahl)
S (String)
C (Zeichenstring mit fester Länge)
V (Zeichenstring mit variabler Länge)
L (logische Größe)
C (Zeichenstring mit der festen Länge 1) mögliche Werte Y (ja), N (nein)
C (Zählung)
C (Zeichenstring mit fester Länge)
V (Zeichenstring mit variabler Länge)
B (Binärzahl)
P (gepackte Dezimalzahl ohne Dezimalziffern)
Q (Größe)
C (Zeichenstring mit fester Länge)
V (Zeichenstring mit variabler Länge)
B (Binärzahl)
P (gepackte Dezimalzahl)
F (Gleitkommazahl)
Die Regelsprache enthält die folgenden Operatoren für das Ausführen von Vergleichen: = , H= , < , < = , > , > = . Das Ergebnis einer Vergleichs ist immer ein logischer Wert ('Y' oder 'N'). Die Regelsprache verwendet das Gleichheitszeichen (=) als den Zuweisungsoperator. Die Regelsprache enthält die folgenden Operatoren für das Ausführen der Arithmetik **, *, /, +, -. Die Regelsprache verwendet einen vertikalen Doppelstrich (g) als den Verknüpfungsoperator. Der Verknüpfungsoperator ist gültig zwischen zwei beliebigen semantischen Datentypen, wobei das Ergebnis immer ein String mit einer variablen Länge ist.
Um das Codieren auswählbarer Routinen und Dienstprogrammfunktionen zu unterstützen, ermöglicht die Regelsprache indirekte Referenzen auf Tabellen- und Feldnamen. Die Regel COUNT ist eine auswählbare Routine, die die über alle Auftreten genommene Summe eines Felds bestimmt. Diese Regel summiert irgendein Feld irgendeiner Tabelle ohne Parameter.

SYNTAX

Es folgt eine vollständige formale Syntax der Regelsprache in Backus-Naur-Form (BNF).

BNF-Schreibweise

(a) In spitzen Klammern < > eingeschlossene kleingeschriebene Wörter bezeichnen syntaktische Kategorien. Zum Beispiel:
< start character>
(b) In einer Liste von Alternativen beginnt jede Alternative auf einer neuen Zeile.
(c) Eine wiederholte Position wird in geschweiften Klammern { } eingeschlossen. Die Position kann nullmal oder mehrmals auftreten. Zum Beispiel:
{< digit> }
(d) Optionale Kategorien werden in eckigen Klammern eingeschlossen. Zum Beispiel:
{< exponent> }

Zeichensatz

Alle Regelsprachenkonstruktionen werden mit einem Zeichensatz dargestellt, der sich wie folgt untergliedert:

(a) Buchstaben

A B C D E F G H I J K L M N 0 P Q R S T U V W X Y Z

(b) Ziffern

1 2 3 4 5 6 7 8 9

(c) Sonderzeichen

@ # $ v H & * () - _ = + ; : ' , . / < >

Lexikalische Elemente

Eine Regel ist eine Folge lexikalischer Elemente. Lexikalische Elemente sind Identifizierer (einschließlich reservierter Wörter), numerische Literalkonstanten, Stringliteralkonstanten und Trennzeichen. Ein Trennzeichen ist eines der folgenden Sonderzeichen
v H & * () - + = : ; ', / < >
oder eines der folgenden zusammengesetzten Symbole
** < = > = H= g
Angrenzende lexikalische Elemente können durch Leerzeichen oder durch eine neue Zeile getrennt werden. Ein Identifizierer oder eine numerische Literalkonstante müssen auf diese Weise von einem angrenzenden Identifizierer oder von einer angrenzenden Literalkonstanten getrennt werden. Das einzige lexikalische Element, das ein Leerzeichen enthalten kann, ist die Stringliteralkonstante. Stringliteralkonstanten können sich über mehr als eine Zeile erstrecken; alle anderen lexikalischen Elemente müssen auf eine einzige Zeile passen.

Identifizierer

Die Länge der Regelsprachenidentifizierer darf 16 Zeichen nicht überschreiten.

Numerische Literalkonstanten

Die Regelsprache unterstützt die folgenden Formen numerischer Literalkonstanten:

Stringliteralkonstanten

Eine Stringliteralkonstante sind null oder mehr in Hochkomma eingeschlossene Zeichen:
Hochkommata in einer Stringliteralkonstanten werden doppelt geschrieben. Somit ist die folgende Stringliteralkonstante eine Hochkomma "".

Reservierte Wörter

Die Namen der folgenden Liste sind von dem System als Schlüsselwörter in der Regelsprache reserviert. Syntax der Regeln
Es wird angemerkt, daß die < where table ref> -Bildung die Angabe eines "*" als den Tabellennamen ermöglicht.

III. Tabellendatenspeicher

Der Tabellendatenspeicher speichert die Daten gemäß der eindeutigen Tabellendatenstruktur in relationalen Tabellen. Diese Struktur läßt sich am besten dadurch versehen, daß verstanden wird, wie die Tabellen über die Tabellenzugriffsmaschine aufgebaut werden.
- Das Logikzugriffsverfahren des HOS zum Wiedergewinnen von und Zugreifen auf Tabellen ist das Tabellenzugriffsverfahren (TAM).
- Das HOS stellt einen Zugriff auf weitere heterogene Datenbanken bereit. Sobald die Datendefinition erfolgt ist, ist diese Einrichtung für den Anwender transparent. Das TAM wirkt in Verbindung mit dem Transaktionsprozessor als ein Verkehrspolizist zum Zugreifen auf den richtigen Server - in anderen Gebieten resident
- Das physikalische Zugriffsverfahren und die Datenorganisation sind der TDS (Tabellendatenspeicher)
- Die Datenspeicher befinden sich in einer relationalen B&spplus;- Baum-Datenstruktur
- Da das HOS ein Transaktionssystem ist, beeinflußt der Zugriff eines Anwenders auf eine große Datenmenge nur ihren unabhängigen Bereich.

Definieren einer TDS-Tabelle

- Die Tabellendefinitionseinrichtung wird unter Verwendung eines Befehls DT < table name> aus einem Arbeitsplatzmenü oder aus einer von einer Sitzungsmanagerroutine erzeugten primären Befehlszeile aufgerufen. Die Bildschirmanordnung der Tabellendefinitionseinrichtung ist in der Tabellendefinitionstabelle dargelegt.
- Für den Tabellennamen können Standardnamenkonventionen befolgt werden.
- Der voreingestellte Tabellentyp ist TDS.
- Es sind weitere Tabellentypen wie etwa IMS, IMPORT-EXPORT (nacheinander) usw. verfügbar.
- Jeder Tabellentyp besitzt seinen eigenen Tabellendefinitionsbildschirm in dem Sitzungsmanager.
- Die Tabellen sind für ein System universell.
- Das Sicherheitssystem in einzelnen Tabellen verhindert einen unbefugten Zugriff auf die Definition und/oder auf die Daten.
- Die Syntaxspezifikationen der Parameter und Felder beschreiben, wie die Daten gespeichert werden.
- Die Semantikspezifikationen beschreiben, wie die Daten in den Anwendungen verwendet werden sollten.
- Die Ereignisverarbeitung kann zur Datendefinitionszeit aufgerufen werden, während die tatsächlichen Regeln unter Verwendung der verallgemeinerten Programmiersprache codiert werden. Die Ereignisverarbeitung wird beim Zugreifen auf die Daten aufgerufen. Tabelle: Tabellendefinitions-Bildschirmanordnung

Allgemeine Diskussion-TDS-Optionen

Die Felder der Tabellendefinitions-Bildschirmanordnung werden unten diskutiert.
TYPE: Der Tabellentyp spezifiziert das Zugriffsverfahren. Der Tabellendatenspeicher ('TDS') ist der voreingestellte Wert, wobei dieser als die Referenzschablone verwendet wird. Jedem Tabellentyp ist eine Schablone für die Anzeige zugeordnet. Wenn der Tabellentyp geän dert wird, wird die entsprechende Schablone durch Drücken irgendeiner der Funktionstasten oder der ENTER-Taste angezeigt. Gültige Tabellentypen umfassen 'TEM' (temporär), 'IMP' (Import), 'EXP' (Export), 'PRM' (Parameter), 'SUB' (Unteransicht) und 'IMS' (IMS) sowie weitere von einem Anwender definierte Tabellentypen.
UNIT: In dieses Feld wird die Anwendereinheit eingegeben, mit der die Tabelle verknüpft ist. Gültige Werte werden von der Datenbankadministration bereitgestellt.
IDGEN: Dies informiert das System, daß es für die Bereitstellung von eindeutigen primären Schlüsseln für jedes Auftreten verantwortlich ist.
PARAMETER: Die Parameterinformationskomponente ist ein Rollbereich für mehrere Einträge. Es ist ein Maximum von vier Einträgen zulässig.
Dieses Merkmal ermöglicht, daß das System seine Datenbanken auf der Grundlage eines eindeutigen Felds partitioniert. Dies ahmt eine hierarchische Datenstruktur nach, die in der Realität üblicher als eine genau relationale Datenstruktur ist.
NAME Der Feldname, der in der Tabelle eindeutig sein sollte.
TYPE Die Semantiktyp-Anwendungsentwicklungssteuerung.
SYNTAX Die interne Darstellung für den Speicher.
LENGTH Die Länge in Bytes. Um den Speicher zu optimieren, speichert das System seine Daten als Daten mit variabler Länge.
DECIMAL Gibt, falls es spezifiziert ist, die Anzahl der Dezimalstellen an.
KEY Der gültige Eintrag ist 'P' für primär sowie leer (Nichtschlüsselfeld). Eine Tabelle muß ein als ihr Schlüsselfeld definiertes Feld besitzen.
Die Spezifikation des primären Schlüssels macht das Feld tatsächlich zu einem erforderlichen.
Jedes Auftreten in der Tabelle wird durch den Wert seines primären Schlüssels eindeutig identifiziert.
RQD Der voreingestellte Wert für dieses Feld ist leer (nicht erforderlich). Weitere gültige Einträge sind 'Y' für erforderlich oder 'N' für nicht erforderlich. Das Einsetzen oder das Editieren eines Auftretens ohne die richtigen Werte in den erforderlichen Feldern ist nicht zulässig.
DEFAULT Der voreingestellte Wert des Felds, der eingegeben wird, falls das Feld beim Hinzufügen eines neuen Auftretens leer gelassen wird.

Semantischer Datentyp und Syntax

Alle Felder einer Tabelle sind an einen semantischen Datentyp und an eine Syntax gebunden. Die Syntax beschreibt, wie die Daten gespeichert werden, während der semantische Typ beschreibt, wie ein Feld verwendet werden kann. Gültige semantische Datentypen und ihre zulässigen Syntaxen sind:

I-Identifizierer

C Zeichenstring mit fester Länge
V Zeichenstring mit variabler Länge
P gepackte Dezimalzahl
B Binärzahl

S - String

C (Zeichenstring mit fester Länge)
V (Zeichenstring mit variabler Länge)

L - logische Größe

C Zeichenstring mit der festen Länge 1
- Wert "Y" für ja
- Wert "N" für nein

C - Zählung

C Zeichenstring mit fester Länge
V Zeichenstring mit variabler Länge
B Binärzahl
P gepackte Dezimalzahl ohne Dezimalziffern

Q - Größe

C Zeichenstring mit fester Länge
V Zeichenstring mit variabler Länge
B Binärzahl
P gepackte Dezimalzahl
F Gleitkommazahl

Spezifikationen gültiger Feldsyntaxen

B - Binärzahl
P - gepackte Dezimalzahl
F - Gleitkommazahl
C - Zeichenstring mit fester Länge
V - Zeichenstring mit variabler Länge

Tabellendokumentation

Allen Objekten einschließlich der Tabellen ist eine Dokumentation zugeordnet. Um irgendwelche definierten Tabellen zu dokumentieren, können die Anwender unter Verwendung eines wie in TABELLE 34 gezeigten Dokumentationsbildschirms, der von der Tabellendefinitionseinrichtung aufgerufen wird, eine kurze Zusammenfassung, Schlüsselwörter und eine lange Beschreibung angeben. Die Zusammenfassung ist auf eine Informationszeile beschränkt. Die besonderen Schlüsselwörter können zum Gebrauch durch die Schlüsselwort-Suchvorrichtung verfügbar gemacht werden. Es ist Platz vorhanden, um eine ausführliche Tabellenbeschreibung zu liefern. In die lange Beschreibung können Script-Formatierbefehle aufgenommen werden. Dokumentation TABELLE 34 DOKUMENTATIONSBILDSCHIRM FÜR DIE ANGESTELLTENTABELLE

Unteransichttabellen

Unteransichten schaffen Fenster in die Daten. Die Anwender können eine Untermenge der Felder einer Tabelle oder eine auf Auswahlkriterien beruhende Untermenge erhalten.
- Die Tabellendefinitionseinrichtung wird unter Verwendung eines DT-< subview table name> -Befehls aus dem Arbeitsbereichsmenü oder aus der Befehlszeile auf dem Bildschirm aufgerufen.
- Für den Namen der Unteransichttabelle werden Standardnamenkonventionen befolgt.
- Der Unteransichttabellen-Definitionseinrichtungs-Bildschirm wird dadurch aufgerufen, daß der voreingestellte Tabellentyp "TDS" in "SUB" geändert wird, was zu einem Definitionseinrichtungs-Bildschirm führt, wie ihn TABELLE 35 zeigt.
- Das Sicherheitssystem in den einzelnen Unteransichten verhindert einen unbefugten Zugriff auf die Definition und/oder einen unbefugten Gebrauch.
- Für eine Unteransicht wird kein getrennter Platz zugeordnet. Sämtliche Datenwartung wird tatsächlich in der zugeordneten Quell-TDS-Tabelle ausgeführt. TABELLE 35 Bildschirmanordnung einer Unteransichttabelle

Allgemeine Diskussion - UNTERANSICHTEN

Alle Felder sind die gleichen, wie sie für die 'TDS'-Tabelle beschrieben wurden. Felder, die für die Unteransicht einzig sind, sind unten beschrieben.
SOURCE: Name der Quelltabelle, deren Unteransicht durch diese Tabelle definiert wird. Die Quelltabelle muß existieren, bevor ihre Unteransicht definiert werden kann.
SELECT: Der Gültigkeitsbereich der Auswahlkriterien dient zum Erstellen von Untergruppen der Anzahl der aus gewählten Auftreten. Falls er nicht vorhanden ist, werden sämtliche Auftreten ausgewählt.
PARAMETERS: Falls es in der TDS-Tabelle ein entsprechendes Feld gibt, können in der Unteransicht neue Parameter angegeben werden. Die Quelltabellenparameter können umbenannt und der Quellname in dem SOURCE PARM angegeben werden.
ORDERING: Dies ist ein Rollbereich. Anhand eines in der Unteransicht nicht definierten Felds kann eine Reihenfolge spezifiziert werden. Die Reihenfolge wird lediglich für Anzeigezwecke verwendet.
SEQ - A (aufsteigend) oder D (absteigend)

Felddefinition-Unteransichten:

SRC: Dies ist das Quellindikatorfeld. Die Feldnamen können die gleichen, umbenannt oder für die Unteransichttabelle einzig sein. Das Quellindikatorfeld identifiziert den Status des Felds im Verhältnis zu der Quelltabelle.
Gültige Einträge sind:

- Leer

Die Felddefinition ist sowohl in der Quelle als auch in der Unteransicht die gleiche.

- S = Quelle:

Ein umbenanntes Feld wird mit seinem Eintrag angezeigt, auf den der Feldname in der Quelltabelle folgt.

- D = Abgeleitet:

- Ein Feld, das für die Unteransichttabelle einzig ist, wird durch seinen Eintrag als ein abgeleitetes Feld angezeigt.
- Anwendungsvorteile dieses Merkmals ermöglichen Tabellenmanipulationen sowie die Ad hoc-Meldung anhand einer Unteransichttabellenebene.
- In der ADHOC-Verarbeitung empfangen die abgeleiteten Felder die Werte, wenn z. B. beim Editieren der Tabelle auf die Tabelle zugegriffen wird:
ED (table name)

Ereignisregeln

Die Ereignisregeln in der Datendefinition bestehen üblicherweise aus einer Mischung von entweder Validierungen oder Auslösungen.
- Validierungen sind Regeln wie etwa die, daß die Daten bei der Eingabe von Informationen in eine Tabelle gegenüber einer anderen Tabelle validiert werden müssen. Zum Beispiel muß sich die Abteilungsnummer bei der Wartung der Angestelltentabelle in der Abteilungstabelle befinden. Dies könnte auf eine Reihe weiterer Tabellen oder auf externe Dateien erweitert werden.
- Auslöser bewirken anstelle lediglich von Validierungen das Ausführen von Aktionen wie etwa das Revidieren von Pfaden, das Aktualisieren weiterer Tabellen oder das Planen weiterer Aufträge.
Bei Ereignisregeln wird für einen Anwender eine vollständig "offene" Umgebung bereitgestellt, wobei an den Daten strenge Prüfungen und Kontrollen realisiert werden können.

Definition der Ereignisregeln:

- Der Ereignisregelabschnitt ist ein Rollabschnitt.
- Die Ereignisregeln werden in der Reihenfolge der Ausführung codiert.
- Die Ereignisregeln können für spezifische Datenzugriffscodes wie etwa für das Einsetzen oder allgemeiner - für das Holen und Schreiben - definiert werden.
- Bei der gleichen Aktion können verschiedene Ereignisregeln aufgerufen werden -
Beispiel Schreiben - Ereignisregel - Validierung Schreiben - Auslösen
- Falls eine Datenwartungsaktion - wie etwa das Einsetzen oder das Aktualisieren - aufgerufen wird, wird auch das Schreiben aufgerufen.
Die Ereignisregel, die ausgeführt werden sollte, kann von einer lokalen Bibliothek getestet werden, würde zur Erzeugungsszeit aber in der Standortbibliothek liegen.
- Falls ein Test z. B. unter Verwendung des Tabelleneditors erforderlich ist, kann die Mehrbenutzeranlagen-Funktion nicht verwendet werden, falls sich die Regel in einer lokalen Bibliothek befindet.
Um zu erzwingen, daß der Suchpfad auf die lokale Bibliothek zugreift, ist der Tabelleneditor in der Weise auszuführen, als ob er eine Regel wäre:
EX = = = = = > STE('table name(parameters)')
oder
Command line = = = > EX STE('tablename(parameters)')
- Beim Codieren der Ereignisregel ist nicht zu vergessen, daß das Auftreten der Tabelle bereits erhalten wurde - für diese Tabelle ist kein Datenzugriff erforderlich.
- Beim Codieren der Ereignisregel muß das folgende wahr sein:
TRIGGERS - Unterprogramme
VALIDATIONS - Funktionen, die 'Y', 'N' oder, falls nicht 'Y' ist, eine Nachricht zurückgeben.

IV. Wörterbuchdaten

Sämtliche Daten in der HOS-Datenverarbeitungsmaschine werden gemäß der Tabellenzugriffsmaschine entweder direkt in dem Tabellendatenspeicher oder virtuell in anderen Datenspeichersystemen gespeichert. Der tatsächliche Ort und der Typ der Tabelle, in der ein gegebenes Auftreten gespeichert wird, wird durch mehrere Wörterbuchtabellen in dem Tabellendatenspeicher definiert. Dadurch, daß diese Wörterbuchtabellen im voraus angegebene Tabellen mit einer dem Tabellendatenspeicher und der Tabellenzugriffsmaschine bekannten Struktur sind, können sie als Metadaten betrachtet werden, so daß sie automatisch untersucht werden können, um für das Zugreifen auf Auftreten in auswählbaren Tabellen verwendete Steuertabellen aufzubauen.
Die Wörterbuchtabellen enthalten die Tabelle namens TABLE, die eine Struktur besitzt. Diese Tabelle umfaßt den Namen und den Typ aller Tabellen, die für eine gegebene Sitzung in der Maschine verfügbar sind.
Außerdem umfaßt das Wörterbuch eine Tabelle namens FIELDS (table name), bei der es sich um eine Tabelle handelt, die die Attribute aller Datenelemente in dem System enthält. Diese Tabelle ist in dem Tabellennamen parametrisiert. Somit erzeugt die Tabellenzugriffsmaschine eine auf die Felder einer gegebenen Tabelle beschränkte Ansicht der FIELDS genannten Tabelle.
Außerdem enthält das Wörterbuch eine Tabelle namens PARMS (table name).
Diese Tabelle identifiziert die jeder Tabelle zugeordneten Parameter, sofern vorhanden.
Außerdem enthält das Wörterbuch die Tabelle namens SELECTION (table name), in der ein auf Zugriffe auf die Tabelle anzuwendender Auswahlstring oder -filter gespeichert ist.
Weitere Wörterbuchtabellen umfassen ORDERING (table name), die eine Menge von Ordnungsoperationen definiert, die bei Zugriffen auf die Tabelle zu realisieren sind, EVENTRULES (table name), die Regeln spezifiziert, die bei Zugriffsereignissen auf die Auftreten in der Tabelle auszuführen sind, @RULESLIBRARY (library name), die den tatsächlichen Objektcode für die ausführbaren Regeln für die Sitzung speichert. Der Parameterbibliotheksname ist ein Grundverfahren für das Aufteilen der Regelbibliothek vermittels einer Anzahl von Namen.
Außerdem enthält das Wörterbuch Wörterbuchtabellen, die für Zugriffe über die von dem Tabellendatenspeicher verschiedenen Server erforderlich sind. Zum Beispiel werden von dem IMS- Server die Tabellen IMSTABFIELDS (table name), IMSSEGFIELDS, (db Name, seg Name) und die Tabelle IMSACCESS (table name) verwendet. Die IMSTABFIELDS-Tabelle bildet den Tabellenzugriffsverfahrens-Feldnamen auf einen IMS-Feldnamen ab. Die IMSSEGFIELDS-Tabelle liefert die Syntax und die Abbildungsparameter für einen Zugriff auf der Grundlage der aus der IMSTABFIELDS-Tabelle wiedergewonnenen Parameter. Die IMSACCESS-Tabelle wird von dem Server zum Erzeugen tatsächlicher Zugriffsfolgen für die Übertragung an die IMS-Datenbank verwendet.
Außerdem enthält die Wörterbuchtabelle die von den Bildschirm- Servern verwendeten Tabellen. Die Tabelle SCREENS identifiziert sämtliche Bildschirme, auf die über die Tabellenzugriffsmaschine in einer gegebenen Sitzung zugegriffen werden kann. Die Tabelle SCREENTABLES (screen) liefert eine Bildschirmdefinition für ein Fenster innerhalb einer LAge in einem Bildschirm für das Fenster.
Die Tabelle SCREENFIELDS (screen table) schafft weiter eine direkte Abbildung auf den Bildschirm selbst.
Diese Wörterbuchdaten können in der Weise erweitert werden, daß sie irgendeine Anzahl von Servern bedienen, wobei ihre Struktur ("Meta-Metadaten") in dem zweckmäßigen System aber hart codiert ist.
Nach der Beschreibung des Systems aus der Grundsicht des Anwendungsprogrammierers und der Darstellung der Daten und Wörterbuchdaten in dem System läßt sich nun eine interne Beschreibung des Betriebs der virtuellen Maschinen verstehen.

V. Interne Darstellung der Regeln

Die Regeln werden in einer internen Darstellung gespeichert, die von der Maschine mit dem virtuellen Stapel direkt ausgeführt werden kann. Das Verfahren des Sicherns einer Regel in dem Regeleditor umfaßt eine Übersetzung aus ihrem Textquellcode in den Objektcode für die virtuelle Maschine. Wenn die Textdarstellung einer Regel erforderlich ist, führt ein Rückübersetzungsverfahren eine Umsetzung aus dem Ob jektcode für die virtuelle Maschine in einen Text durch. Der offensichtliche Vorteil des Speicherns nur einer Darstellung einer Regel besteht darin, daß nie eine Diskrepanz zwischen der Darstellung auftreten kann.
Dieser Abschnitt beschreibt ausführlich die interne Darstellung einer Regel. Er beginnt mit der Beschreibung der Gesamtanordnung des Objektcodes. Es folgt eine ausführliche Beschreibung der verschiedenen Datenpositionen und Opcodes der virtuellen Maschine. Es sind Beispiele des Objektcodes enthalten, die verschiedenen Arten von Regelanweisungen entsprechen.

DAS FORMAT EINER REGEL

Der Regelobjektcode wird in der Tabelle @RULESLIBRARY gespeichert. Diese Tabelle wird durch den Bibliotheksnamen parametrisiert und besitzt den Regelnamen als ihren primären Schlüssel.
Der Objektcode für eine Regel kann begrifflich in vier Komponenten unterteilt werden: 52 Bytes Anfangsblockinformationen; "n" Bytes Code; "m" Bytes statischer (nicht modifizierbarer) Daten; und "p" Bytes modifizierbarer Daten. Tatsächlich werden in dem Objektcode nur die ersten drei dieser Komponenten gespeichert. Der modifizierbare Bereich wird zugeordnet, wenn die Regel zur Ausführung geladen wird.
Die Tabelle "Anordnung des Regelobjektcodes" zeigt die ausführliche Anordnung des Regelobjektcodes. Der Anfangsblock- und der Codeabschnitt enthalten Referenzen auf Objekte in dem Bereich der statischen Daten. Diese Referenzen sind binäre Zweibyte-Distanzadressen bezüglich des Beginns des Anfangsblocks. Der Parameterabschnitt, der Abschnitt für die lokalen Variablen, der Ausnahmebehandlungsroutinen-Namenabschnitt, der Tabelle.Feld-Namenabschnitt, der Regelnamenabschnitt und der Konstantenabschnitt gehören sämtlich zu dem Bereich der statischen Daten.

Tabelle: Anordnung des Regelobjektcodes

Anfangsblock (52 Bytes)
Parameter (optional)
Lokale Variablen (optional)
Code für Bedingungen
Code für Aktionen
Code für Ausnahmen (optional)
Namen von Ausnahmebehandlungsroutinen (optional)
Regelnamen (optional)
Table.Field-Namen (optional)
Konstanten (optional)

REGELANFANGSBLOCK

Der in der Tabelle "Anordnung des Regelobjektcode-Anfangsblocks" gezeigte Anfangsblockabschnitt des Objektcodes enthält den Namen der Regel zusammen mit verschiedenen weiteren Werten, die den Code, den Bereich der statischen Daten und den Bereich der modifizierbaren Daten beschreiben.
Die in dem Anfangsblock gespeicherte Länge ist die Anzahl der Bytes rechts von dem Längenwert. Somit ist die Gesamtlänge der Regel der Wert in Length zuzüglich 28 (die Anzahl der Bytes links von dem Wert Length einschließlich diesem). Tabelle 47: Anordnung des Regelobjektcode-Anfangsblocks

STATISCHE REGELDATEN

Dieser Abschnitt umreißt den Inhalt des Bereichs der statischen Daten. Bestimmte Objektnamen in dem Abschnitt der statischen Daten enthalten Referenzen auf Positionen in dem Bereich der modifizierbaren Daten. Jede Referenz ist eine Zweibyte- Distanzadresse relativ zu dem Beginn des Bereichs der modifizierbaren Daten.
Falls zutreffend, werden die Werte in dem Anfangsblock, die die Anordnung des Bereichs der statischen Daten beschreiben, identifiziert.

Parameter

Der Parameterabschnitt des Objektcodes enthält die Liste der Namen der für diese Regel deklarierten formalen Parameter. Jede Position in der Liste ist ein 16 Bytes-Name. "Num parms" enthält die Anzahl der für diese Regel deklarierten formalen Parameter, während der Wert "parm off" eine Distanzadresse zu dem Beginn dieser List ist.

Lokale Variablen

Der Abschnitt des Objektcodes für die lokalen Variablen enthält die Liste der Namen der in dieser Regel deklarierten lokalen Variablen. Jede Position in der Liste enthält einen 16 Bytes-Namen, auf den eine Zweibyte-Distanzadresse zu dem Bereich der modifizierbaren Daten folgt. "Num locs" enthält die Anzahl der in dieser Regel deklarierten lokalen Variablen, während "Locs off" eine Distanzadresse zu dem Beginn dieser Liste enthält; die Liste wird mit einem Zweibyte null abgeschlossen.

Namen von Ausnahmebehandlungsroutinen

Der Abschnitt der Namen der Ausnahmebehandlungsroutinen enthält die Liste der Namen der von dieser Regel behandelten Ausnahmen. Jede Position in der Liste besteht aus einem 16 Bytes-Namen, auf den ein Paar Zweibyte-Distanzadressen folgt. Die erste Zweibyte-Distanzadresse nimmt auf den Namen der dieser Ausnahme zugeordneten Tabelle Bezug. Der Tabellen name wird als ein 16 Bytes-Name in dem Bereich der statischen Daten gespeichert. Falls es keinen zugeordneten Tabellennamen gibt, ist diese Distanzadresse null. Die zweite Distanzadresse nimmt auf den Code, der die Ausnahme behandelt, Bezug. "Excp off" enthält eine Distanzadresse zum Beginn dieser Liste; die Liste wird mit einer Zweibyte-Null abgeschlossen.

Felder der Tabellen

Der Abschnitt table.field des Regelobjektcodes ist eine Liste aller table-field-Namen in der Regel. Jede Position in der Liste besteht aus zwei 16 Bytes-Namen (einem für die Tabelle und einem für das Feld), auf die eine Zweibyte-Distanzadresse zu dem Bereich der modifizierbaren Daten folgt. "TabFld off" nimmt Bezug auf den Beginn der Liste; die Liste endet bei der Distanzadresse "Const off".

Regelnamen

Der Regelnamenabschnitt ist eine Liste der Namen aller von dieser Regel aufgerufenen direkten Regeln (oder der Namen der in dieser Regel nicht deklarierten lokalen Variablen). Jede Position in der Liste besteht aus einem 16 Bytes-Namen, auf den eine Zweibytes-Distanzadresse zu dem Bereich der modifizierbaren Daten folgt. "Rule off" nimmt Bezug auf den Beginn der Liste; die Liste endet bei der Distanzadresse "TabFld off".

Konstanten

Der Konstantenabschnitt ist eine Liste aller Konstanten in der Regel (entweder Literalkonstanten oder intern von dem Übersetzer erzeugter Konstanten). Jede Position in der Liste besitzt einen Sechsbyte-Beschreiber, auf den die Daten folgen. Den Daten selbst ist eine Länge von einem oder von zwei Bytes vorangestellt (ein Byte, falls die Daten eine Länge von 0..127 Bytes haben, zwei Bytes für 128+). Falls CLen zwei Bytes ist, ist das höherwertige Bit von CLen an, während CLen andernfalls ein Byte ist.
Der Typ ist ein einzelnes Byte, das den semantisches Typ der Konstante enthält. Alle Konstanten besitzen einen unbekannten (leeren) semantischen Typ. Die Syntax ist ein Byte, das die Darstellung der Daten angibt. Gültige Syntaxen sind B (Binärzahl) P (gepackte Dezimalzahl) F (Gleitkommazahl) C (festes Zeichen) und V (variables Zeichen). DLen beträgt zwei Bytes und enthält die definierte (oder maximale) Länge der Daten. CLen enthält die momentane Länge der Daten. Dec beträgt ebenfalls zwei Bytes und enthält die Anzahl der Dezimalstellen rechts von dem Dezimalkomma. Dec ist nur sinnvoll für gepackte Dezimalkonstanten. "Const off" nimmt Bezug auf den Beginn der Liste der Konstanten; die Liste wird am Ende des durch "Length" + 28 gegebenen Objektcodes abgeschlossen.

REGEL-OPCODES

Die Maschine mit dem virtuellen Stapel beruht auf einer Stapelarchitektur. Die meisten Befehle für die virtuelle Maschine manipulieren die Positionen am oberen Ende des Stapels. Sämtliche Stapelpositionen haben eine Länge von vier Bytes. Viele Positionen sind Zeiger auf Werte, die entweder Felder einer Tabelle, Regelkonstanten oder während der Ausführung aufgebaute temporäre Werte sind. Alle Werte bestehen aus einem Sechsbytes-Beschreiber, auf den ein Vierbytes-Zeiger auf die tatsächlichen Daten folgt. Die Daten selbst besitzen ein Präfix von einem oder von zwei Bytes. Der Stapel kann weitere Informationen wie etwa die zum Realisieren des Regelaufrufs und zum Zurückkehren benötigten Informationen enthalten.
Für Werte, die während der Ausführung aufgebaut werden, unterhält die virtuelle Maschine einen temporären Bereich. Wenn temporäre Werte aus dem Stapel entnommen werden, wird ihr Speicher in dem temporären Bereich freigegeben.
Alle Befehle für die virtuelle Maschine enthalten einen Einbyte-Opcode. In Abhängigkeit von dem Opcode können sie null, einen oder zwei Zweibytes-Operanden benötigen.
Zwecks Beschreibung der Semantik jedes Opcodes stelle Item1 die oberste Position auf dem Stapel und Item² die zweite Position auf dem Stapel dar. Operand1 und Operand 2 bezeichnen den ersten bzw. den zweiten Zwischenoperanden.
Name Opcode #Ops Semantik @ADD 4 0 Addiere zwei Werte zueinander. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2 + Item1 und schieben ihn.
@SUB 8 0 Subtrahiere einen Wert von dem anderen. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2 - Item1 und schieben ihn.
@MULT 12 0 Multipliziere zwei Werte miteinander. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2 * Item1 und schieben ihn.
@DIV 16 0 Dividiere einen Wert durch einen anderen. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2/Item1 und schieben ihn.
@EXP 20 0 Erhebe einen Wert zur Potenz des anderen. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2 ** Item1 und schieben ihn.
@UNM 24 0 Bilde die arithmetische Negation eines Werts. Entnehme Item1, Erzeuge einen temporären Wert von -(Item1) und schieben ihn.
@CAT 28 0 Verknüpfe zwei Werte miteinander. Entnehme Item1 und Item2. Erzeuge einen tem porären Wert von dem mit Item1 verknüpften Item2 und schieben ihn.
@EQ 32 0 Vergleiche zwei Werte auf ihre Gleichheit. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2 = Item1 ('Y" oder 'N') und schiebe ihn.
@NE 36 0 Vergleiche zwei Werte auf ihre Ungleichheit. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2 - = Item1 ('Y' oder 'N') und schiebe ihn.
@LT 40 0 Vergleiche, um zu bestimmen, ob ein Wert kleiner als ein anderer ist. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2 < Item1 ('Y' oder 'N') und schiebe ihn.
@LE 44 0 Vergleiche, um zu bestimmen, ob ein Wert kleiner als ein anderer oder gleich einem anderen ist. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2 < = Item1 ('Y' oder 'N') und schiebe ihn.
@GT 48 0 Vergleiche, um zu bestimmen, ob ein Wert größer als ein anderer ist. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2 > Item1 ('Y' oder 'N') und schiebe ihn.
@GE 52 0 Vergleiche, um zu bestimmen, ob ein Wert größer als ein anderer oder gleich einem anderen ist. Entnehme Item1 und Item2. Erzeuge einen temporären Wert von Item2 > = Item1 ('Y' oder 'N') und schiebe ihn.
@CALL 56 2 Rufe eine Prozedurregel oder Standardroutine auf. Operand1 ist die Anzahl der zu übergebenden Argumente; sie wurden bereits in den Stapel geschoben. Operand2 ist eine Distanzadresse zu dem Namen der aufzurufenden Regel; eine positive Distanzadresse ist eine Referenz auf einen Namen in dem Bereich der statischen Daten. Eine nichtpositive Distanzadresse bedeutet den Namen einer indirekten Regel, wobei Item1 in diesem Fall den Namen der aufzurufenden Regel enthält. Bei einem indirekten Aufruf wird Item1 entnommen. Die Umgebung des Aufrufers wird gesichert, wobei die Ausführung bei dem Beginn der aufgerufenen Regel beginnt.
@FN 60 2 Rufe eine Prozedurregel oder Standardroutine auf. Operand1 ist die Anzahl der zu übergebenden Argumente; sie wurden bereits in den Stapel geschoben. Operand2 ist eine Distanzadresse zu dem Namen der aufzurufenden Regel. Die Umgebung des Aufrufers wird gesichert, wobei die Ausführung bei dem Beginn der aufgerufenen Regel beginnt.
64 UNGENUTZT @RETURN 68 0 Kehre von einer Funktionsregel oder von einer Prozedurregel zurück. Entnehme alle an die aufgerufene Regel übergebenen Argumente und stelle die Umgebung des Aufrufers wieder her. Schiebe den Rückgabewert in Stapel, falls die aufgerufene Regel eine Funktion war.
@UNTIL 72 2 Initialisiere für die Ausführung einer UNTIL-Schleife. Operand1 ist eine Distanzadresse zu dem Opcode, der ausgeführt werden soll, sobald die Schleife abgeschlossen wird. Operand2 gibt an, ob dies eine UNTIL..DISPLAY-Schleife (1) oder nur eine UNTIL-Schleife (0) ist.
@PARM 76 1 Schiebe den formalen Parameter einer Regel in den Stapel. Operand1 ist die An zahl der formalen Parameter. (Für eine Regel mit N Parametern wird der I. numeriert (N - I)). Schiebe den Parameterwert in den Stapel.
@CONST 80 1 Schiebe eine Konstante in den Stapel. Operand1 ist eine Distanzadresse zu dem Wert in dem Bereich der statischen Daten. Kopiere den Beschreiber des Werts in den temporären Bereich und hänge einen Vierbytes-Zeiger an ihn an. Stelle den Zeiger in der Weise ein, daß er auf die Daten des Werts in dem Bereich der statischen Daten Bezug nimmt. Schiebe den konstanten Wert in den Stapel.
@TEMP 84 0 Erzeuge eine temporäre Kopie eines Werts. Erzeuge eine temporäre Kopie, entnehme Item1 und schiebe dann den temporären Wert, falls Item1 kein temporärer Wert ist.
@RFIELD 88 1 Schiebe ein Feld einer Tabelle in den Stapel. Operand1 ist eine Distanzadresse zu dem Namen table.field; eine positive Distanzadresse nimmt auf einen Namen in dem Bereich der statischen Daten Bezug. Eine nichtpositive Distanzadresse bedeutet ein indirektes table.field, wobei Item1 in diesem Fall der Name der Tabelle und Item2 der Name des Felds ist. Bei einer indirekten Referenz werden Item1 und Item2 entnommen. Schiebe den Feldwert in den Stapel. Während das Feld geschoben wird, stellt eine Überprüfung sicher, daß das Feld einen Wert hat; falls das nicht der Fall ist, tritt die Ausnahme UNGSSIGNED ein.
@WFIELD 92 1 Schiebe ein Feld einer Tabelle in den Stapel. Operand1 ist eine Distanzadresse zu dem Namen table.field; eine positive Distanzadresse nimmt auf einen Namen in dem Bereich der statischen Daten Bezug. Eine nichtpositive Distanzadresse bedeutet ein indirektes table.field, wobei Item1 in diesem Fall der Name der Ta belle und Item2 der Name des Felds ist. Bei einer indirekten Referenz werden Item1 und Item2 entnommen. Schiebe den Feldwert in den Stapel.
@AEND 96 0 Markiere das Ende des momentanen Codeabschnitts. Wird verwendet, um die Bedingungen und die Aktionen von den Ausnahmen zu trennen. @AEND wird von der virtuellen Maschine NIE ausgeführt.
@SET 100 0 Weise einem Feld einer Tabelle einen Wert zu. Item1 ist ein Feld einer Tabelle. Item2 ist ein Wert. Stelle die Daten von Item1 auf die Daten von Item2 ein und entnehme beide Items.
@ABN 104 0 Weise üblicherweise aufgeführte Felder in Tabellen zu. Item1 ist der Name der Quelltabelle. Item2 ist der Name der Zieltabelle. Stelle die Daten aller üblicherweise aufgeführten Felder in der Zieltabelle auf Daten von Feldern in der Quelltabelle ein. Entnehme Item1 und Item2.
@SCHED 108 2 Plane die asynchrone Ausführung einer Regel. Operand1 ist die Anzahl der zu übergebenden Argumente; sie wurden bereits in den Stapel geschoben. Operand2 ist eine Distanzadresse zu dem Namen der zu planenden Regel. Entnehme alle Argumente aus dem Stapel. Entnehme die Position Item1, die der Name der Warteschlange für das asynchrone Ereignis ist, und fahre fort.
@DROP 112 1 Verzweige bedingt zu einer Distanzadresse in einer Regel. Entnehme Item1. Verzweige zu der durch Operand1 gegebenen Distanzadresse, falls Item1 nicht 'Y' ist.
@NEXT 116 1 Verzweige unbedingt zu einer Distanzadresse in einer Regel. Verzweige zu der durch Operand1 gegebenen Distanzadresse.
@BRC 120 1 Verzweige bedingt zu einer Distanzadresse in einer Regel. Überprüfe den im Ergebnis des letzten @TAM-Opcodes eingestellten Rückkehrcode. Verzweige zu der durch Operand1 gegebenen Distanzadresse, falls sie von null verschieden ist.
@FORI 124 0 Initialisiere für die Ausführung einer FORALL-Schleife.
@TAM 128 1 Rufe das TAM auf, um eine Tabellenzugriffsanforderung auszuführen. Operand1 enthält die Anzahl der Argumente in dem Stapel. Baue aus diesen Argumenten eine Parameterliste auf und rufe das TAM auf. Entnehme die Argumente aus dem Stapel, falls der Zugriff verschieden von einem FORALL oder von einem UNTIL..DISPLAY war. Entnehme die Argumente, falls der Zugriff ein FORALL oder ein UNTIL..DISPLAY war und der Rückgabecode null ist (Ende der Auftreten), lasse die Argumente andernfalls in dem Stapel. Sichere den Rückgabecode von dem TAM-Aufruf.
@TAMP 132 1 Setze eine Referenz in einen TAM-Auswahlstring oder in eine Parameterliste ein. Item1 ist ein in den Auswahlstring oder in die Parameterliste einzusetzender Wert. Item2 ist der Auswahlstring oder die Parameterliste. Operand1 ist eine Distanzadresse in Item2, wobei die Referenz auf Item1 einzusetzen ist. Erzeuge erforderlichenfalls temporäre Kopien sowohl von Item1 als auch von Item2. Setze die Referenz auf Item1 in Item2 ein und entnehme Item1. (Item2 wird während der Dauer der Ausführung des @TAM-Opcodes entnommen).
@TAMN 136 1 Kopiere einen Tabellennamen in das Argument eines TAM-Tabellennamens. Item1 ist ein an das TAM zu übergebender Tabellenname. Item2 ist ein 16 Bytes-Leerzeichenstring. Operand1 ist eine Distanzadresse in Item2, an die der Tabellenname zu kopieren ist. Erzeuge erforderlichenfalls temporäre Kopien sowohl von Item1 als auch von Item2. Setze die Referenz auf Item1 in Item2 ein und entnehme Item1. (Item2 wird während der Dauer der Ausführung des @TAM-Opcodes entnommen).
@SIGNAL 140 0 Lasse eine Ausnahme eintreten. Item1 ist der Name der Ausnahme, die eintreten soll. Entnehme Item1 und lasse die Ausnahme eintreten.
144 UNGENUTZT @ACALL 148 l Rufe von den Bedingungen eine Aktion auf. Schiebe die Distanzadresse zu dem nächsten Befehl (zu der "Rückkehradresse") und verzweige zu der durch Operand1 gegebenen Distanzadresse.
@ARETURN 152 0 Kehre von einer Aktion (zu den Bedingungen) zurück. Item1 ist die Distanzadresse des nächsten auszuführenden Opcodes. Entnehme Item1 und verzweige zu dieser Distanzadresse.
@EXEC 156 2 Führe eine Prozedurregel aus. Operand1 ist die Anzahl der zu übergebenden Argumente; sie wurden bereits in den Stapel geschoben. Operand2 ist eine Distanzadresse zu dem Namen der auszuführenden Regel; eine positive Distanzadresse ist eine Referenz auf einen Namen in dem Bereich der statischen Daten. Eine nichtpositive Distanzadresse bedeutet den Namen einer indirekten Regel, wobei in diesem Fall Item1 den Namen der auszuführenden Regel enthält. Bei einer indirekten Ausführung wird Item1 entnommen. Die Umgebung der momentanen Transaktion wird gesichert, während beim Beginn der ausgeführten Regel eine neue Transaktion beginnt.
160 UNGENUTZT @SETL 164 1 Weise einer lokalen Variablen einen Wert zu. Item1 ist der zuzuweisende Wert. Operandl ist die lokale Variable. Stelle die Daten von Operandl auf die Daten von Item1 ein und entnehme Item1.
@WARG 168 2 Setze eine Liste durch den Namen übergebener Argumente in eine Liste durch die Position übergebener Argumente um. Der Stapel besteht aus Parametername/Parameterwert-Paaren. Operand1 ist die Anzahl der Name/Wert-Paare. Operand2 ist eine Distanzadresse zu dem Namen der Regel, an die dort Argumente übergeben werden; eine positive Distanzadresse ist eine Referenz auf einen Namen in dem Bereich der statischen Daten. Eine nichtpositive Distanzadresse bedeutet den Namen einer indirekten Regel, wobei Item1 in diesem Fall den Namen der Regel enthält. Bei einer indirekten Referenz wird Item1 entnommen. Entnehme alle Namen/Wert-Paare und schiebe alle Werte in der Reihenfolge der Stellen.
@NOT 172 0 Negiere logisch einen Wert. Entnehme Item1. Erzeuge einen temporären Wert von - (Item1) und schiebe ihn.
176 UNGENUTZT 180 UNGENUTZT @XCALL 184 2 Übertragungsaufruf einer Prozedurregel. Operand1 ist die Anzahl der zu übergebenden Argumente; sie wurden bereits in den Stapel geschoben. Operand2 ist eine Distanzadresse zu dem Namen der Regel für den Übertragungsaufruf; eine positive Distanzadresse ist eine Referenz auf einen Namen in dem Bereich der statischen Daten. Eine nichtpositive Distanzadresse bedeutet einen indirekten Regelnamen, wobei Item1 in diesem Fall den Namen der Regel für den Übertragungsaufruf enthält. Bei einem indirekten Übertragungsaufruf wird Item1 entnommen. Die Umgebung der momentanen Transaktion wird verworfen, während beim Start der Regel für den Übertragungsaufruf eine neue Transaktion beginnt.

DATEN, DIE DURCH REGELN MODIFIZIERT WERDEN KÖNNEN

Die virtuelle Maschine führt die Laufzeitbindung von Referenzen auf in dem Bereich der statischen Daten genannte Objekte, auf spezifische Regeln, auf lokale Variablen und auf Felder von Tabellen aus. Das Binden umfaßt eine Suche nach dem Objekt und geschieht bei der ersten Referenz auf ein Objekt. An das Binden wird dadurch erinnert, daß die Adresse des Objekts (oder der "Thread") in dem Bereich der modifizierbaren Daten gespeichert wird. Da die Adresse eines Objekts während einer gesamten Transaktion konstant ist, können nachfolgende Referenzen auf ein gebundenes Objekt einfach den Thread nutzen.
Die Größe des modifizierbaren Bereichs wird berechnet, wenn eine Regel aus dem Quell- in den Objektcode übersetzt wird. Diese Größe wird als der "Mod data"-Wert in dem Regelanfangsblock gespeichert. Beim ersten Aufruf einer Regel während der Dauer einer Transaktion wird ihr modifizierbarer Datenbereich zugeordnet und in der Weise eingestellt, daß er Nullen enthält. Während der Ausführung der Regel werden Referenzen auf Felder von Tabellen, auf lokale Variablen und auf Regeln dadurch gebunden, daß ihre Adressen bei der zugeordneten Distanzadresse in dem modifizierbaren Bereich dieser Regel gesichert werden. Beim Abschluß der Transaktion wird die Zuweisung des Bereichs der modifizierbaren Daten einer Regel aufgehoben. TABELLE A5: Eine table.field-Referenz vor dem Binden
Der Bereich der modifizierbaren Daten wird außerdem zum Sichern der Namen der indirekten Regel- und der indirekten table.field-Referenzen verwendet. Wie in dem Regel-Opcode- Abschnitt wird eine indirekte Referenz durch eine nichtpositive Distanzadresse als ein Operand für die @RFIELD-, @WFIELD- , @CALL-, @EXEC-, @XCALL- oder @WARG-Opcodes bezeichnet. Die nichtpositive Distanzadresse gibt an, daß sich der Name der Regel oder des table.field, auf die Bezug genommen wird, in dem Stapel der virtuellen Maschine befindet. Dieser Name wird zusammen mit seinem Thread an dem absoluten Wert der Distanzadresse in dem Bereich der modifizierbaren Daten gesichert. Tabelle: B - Eine table.field-Referenz nach dem Binden Tabelle C - Ein indirekter Regelaufruf vor dem Binden Tabelle D - Ein indirekter Regelaufruf nach dem Binden

REGELCODEFOLGEN

Nachdem nun die verschiedenen verfügbaren Befehle für die virtuelle Maschine gezeigt wurden, ist es Zeit zu untersuchen, wie sie zum Realisieren der verschiedenen Sprachmerkmale zusammengesetzt werden.

Bedingungen und Aktionen

Der für den Bedingungsabschnitt einer Regel erzeugte Code ergibt Folgen von "Aufrufen" (@ACALL) für die Aktionen (die Aktionsliste) die ausgeführt werden sollen, wenn die Bedingungen erfüllt sind. Diese @ACALL-Opcodes können durch Code zum Auswerten einer Bedingung und durch einen @DROP-Opcode, der zu der nächsten Bedingung verzweigt, falls diese nicht erfüllt ist, "geschützt werden". Eine nicht geschützte Folge von @ACALL-Opcodes kann auftreten, wenn keine weiteren Bedingungen auszuwerten sind.
Der @ACALL-Opcode schiebt die Distanzadresse zu dem nächsten Befehl in den Stapel und verzweigt dann zu der Aktion. Der letzte Opcode in einer Aktion ist ein @ARETURN, das die gesicherte Distanzadresse verwendet, um zu der Verarbeitung der nächsten Aktion für die Bedingung zurückzukehren. Um von der Regel zurückzukehren, folgt dem letzten @ACALL in jeder Folge ein @RETURN-Opcode.
Der Hauptnutzen davon, daß von den Bedingungen Aktionen "aufgerufen" werden, besteht darin, daß der Code für eine Aktion selbst dann, wenn die Aktion ein Mitglied der Aktionsliste von mehr als einer Bedingung ist, nur einmal erzeugt zu werden braucht.
In Tabelle E ist ein Beispiel dargestellt.

Regelobjektcode:

Distanzadresse Opcode Operanden Bemerkung Tabelle: E - Quell- und Objektcode für Bedingungen und Aktionen

Zuweisungen

Der für eine Zuweisungsanweisung erzeugte Code besteht aus der Postfix-Darstellung eines Ausdruck, auf die entweder ein @SETL (einer lokalen Variablen zuweisen) oder ein @SET (einem Feld einer Tabelle zuweisen) folgt. Tabelle F zeigt eine Referenz auf einen Identifizierer G. In dem Moment, wo die Regel ASSIGN übersetzt wird, ist nicht bekannt, ob G eine lokale Variable ist, die in einem Vorgänger von ASSIGN definiert ist, oder ob sie eine Funktion ist, die keine Argumente annimmt. Der Über setzer erzeugt Code, der voraussetzt, daß G eine Funktion ist, wobei dann, wenn der @FN-Opcode ausgeführt wird, eine Überprüfung durchgeführt wird, um zu bestimmen, ob G wirklich eine lokale Variable ist.

Regelaufrufe

Die Argumente für eine Regel können (unter Verwendung einer WHERE-Klausel) durch die Position oder durch den Namen übergeben werden. Der Code, der für Regelaufrufe erzeugt wird, wenn die Parameter durch die Position übergeben werden, ist sehr unkompliziert. Zunächst wird jedes Argument ausgewertet und zu einer temporären Größe in dem Stapel gemacht. Darauf folgt ein @CALL-Opcode (oder ein @FN-Opcode für eine Funktionsregel), der die Anzahl der Argumente und den Namen der Regel als seine Operanden verwendet. Wenn der @RETURN-Opcode in der aufgerufenen Regel ausgeführt wird, werden alle an die aufgerufene Regel übergebenen Argumente entnommen. Falls die aufgerufene Regel eine Funktion ist, wird der Rückgabewert oben in dem Stapel gelassen.
Wenn die Argumente durch den Namen übergeben werden, ist der erzeugte Code etwas komplizierter. Ebenso, wie wenn die Parameter durch die Position übergeben werden, wird jedes Argument ausgewertet und zu einer temporären Größe gemacht. Jedoch wird der Name des formalen Parameters, dem jedes Argument entspricht, unmittelbar nach dem Argument ebenfalls geschoben. Dies führt dazu, daß in dem Stapel für jedes Argument auf den Parametername der Parameterwert folgt. Auf den @CALL-Opcode folgt direkt der @WARG-Opcode. @WARG meldet die Name/Wert- Paare in dem Stapel in der gleichen Form, wie wenn die Argumente durch die Position übergeben werden. Dies ermöglicht, den @CALL-Opcode in Unkenntnis dessen auszuführen, daß die Argumente tatsächlich durch den Namen übergeben wurden.
Ein Beispiel des von einem Regelaufruf erzeugten Codes ist in Tabelle F gezeigt.

Tabellenzugriffe

Das Tabellenzugriffsverfahren oder TAM wird verwendet, um die verschiedenen Sprachanweisungen zu realisieren, die auf die Datenbank zugreifen. Die Schnittstelle zu dem TAM ist recht einfach: ein @TAM-Opcode und N (zwischen eins und fünf) Argumente auf dem Laufzeitstapel. Der für die Tabellenzugriffsanweisungen erzeugte Code schiebt zunächst die erforderlichen Argumente in den Stapel und ruft dann das TAM auf. Nach der Rückkehr von dem TAM entnehmet der @TAM-Opcode seine Argumente (es sei denn, dies ist mitten in der Ausführung eines UNTIL..DISPLAY oder eines FORALL) und sichert den von dem TAM zurückgegebenen Code.
Das erste in den Stapel geschobene Argument ist immer der TAM- Operationscode. Er sagt dem TAM, welche Art von Tabellenzugriffen ausgeführt werden. Der TAM-Operationscode ist das einzige erforderliche Argument. Alle anderen sind optional und werden nur übergeben, wenn sie benötigt werden. Tabelle: F - Quell- und Objektcode für Zuweisungen
Das zweite Argument ist der Name der Tabelle oder des Bildschirms, auf die bzw. auf den zugegriffen wird. Der Name wird immer so aufgefüllt, daß er eine Länge von 16 Zeichen hat. Das dritte Argument enthält die Liste der Parameterwerte für die Tabelle. Jedes Element in dieser Liste ist ein Vierbytes- Zeiger auf einen Wert. Die Elemente in der Parameterliste werden von dem @TAMP-Opcode eingesetzt.

Tabelle G Für einen Regelaufruf erzeugter Code

Am kompliziertesten ist die Beschreibung des vierten Arguments, das die auf die Tabelle anzuwendende Auswahl enthält. Im wesentlichen enthält es eine Postfix-Darstellung der WHERE- Klausel. Es besteht aus einem oder aus mehreren durch logische Operatoren verbundenen Ausdrücken. Jeder Ausdruck beginnt mit einer Feldreferenz, auf die ein (aus Feldreferenzen, Werten und arithmetischen Operatoren bestehender) Ausdruck folgt, und wird mit einem Vergleichsoperator abgeschlossen. Jede Feldreferenz ist 17 Bytes lang: Ein Einbyte-Binärcode, der angibt, daß dies eine Feldreferenz ist, gefolgt von dem Namen des Felds. Jeder Wert ist ein Einbyte-Binärcode für den Wert, auf den ein Vierbytes-Zeiger auf den Wert folgt. Jeder Operator ist ein Einbyte-Binärcode, der den besonderen Operator darstellt. Wie bei den Elementen in der Parameterliste wird der @TAMP-Opcode dazu verwendet, um Referenzen auf Werte in dem Auswahlstring einzusetzen.
Das fünfte Argument enthält irgendeine Ordnung, die auf die wiedergewonnenen Auftreten anzuwenden ist. Jeder Ausdruck in dem Ordnungsstring enthält einen 16 Bytes-Feldnamen, auf den entweder ein "A" oder ein "D" folgt, um anzugeben, ob dieses Feld in aufsteigender oder in absteigender Weise zu ordnen ist.
Ein Beispiel des Tabellenzugriffscodes ist in Tabelle H gezeigt.

Indirekte Referenzen

Indirekte Referenzen können verwendet werden, um in den verschiedenen Tabellenzugriffsanweisungen, Tabellen- und Feldnamen auf der linken Seite einer Zuweisung oder in einem Ausdruck einen Regelnamen (in der CALL-, TRANSFERCALL- oder EXECUTE-Anweisung), einen Tabellen- oder einen Bildschirmnamen anzugeben.
Der für die indirekten Referenzen erzeugte Code wertet zunächst die Referenz aus, indem er sie in den Stapel schiebt. Der Opcode, der die indirekten Referenzen verwendet, besitzt als einen seiner Operanden eine nichtpositive Distanzadresse. Die nichtpositive Distanzadresse gibt an, daß sich der Name auf dem Laufzeitstapel (und nicht in dem Bereich der statischen Daten, wie es für direkte Referenzen der Fall ist) befindet. Ein Beispiel eines indirekten Referenzcodes ist in Tabelle I dargestellt.
Indirekte Tabellen- und Bildschirmnamen für Tabellenzugriffsanweisungen verhalten sich etwas anders, als es oben beschrieben wurde. Nachdem der Wert des Tabellen- oder Bildschirmnamens in den Stapel geschoben wurde, wird ein Spezialopcode (@TAMN) erzeugt. Er entnehmet diesen Wert und kopiert ihn in einen temporären Wert oben auf dem Stapel. Tabelle H: Für den Tabellenzugriff erzeugter Code Tabelle I: Für indirekte Referenzen erzeugter Code

VI. Transaktionsprozessor

Fig. 3 ist ein Blockschaltplan des Transaktionsprozessors, der die Maschine mit dem virtuellen Stapel für die Ausführung der Regeln auf der Objektcodeebene, wie sie in dem vorangehenden Abschnitt beschrieben wurden, realisiert.
Die Maschine mit dem virtuellen Stapel ist ein Softwaremodul 100, das das Management der Ausführung der Regeln durchführt. Wenn eine Sitzung beginnt, gewinnt die Maschine 100 mit dem virtuellen Stapel mehrere Regelbibliotheken 101 wieder und stellt eine Menge von Puffern 102 her. Außerdem wird eine Opcode-Tabelle 103 hergestellt und ein Stapel 104 eingerichtet. Die Puffer enthalten einen Datenmanagementbereich 102A, einen Arbeitsbereich 102B und einen temporären Bereich 102C.
Bei der Ausführung erzeugt die Maschine mit dem virtuellen Stapel über die Leitung 105 einen Befehlszeiger auf die Regelbibliotheken 101. Es wird ein Stapelzeiger erzeugt und über die Leitung 106 an den Stapel geliefert. Die Maschine 100 mit dem virtuellen Stapel kommuniziert über die Leitung 107 mit der Opcode-Tabelle 103 und über die Leitung 108 mit den Puffern 102. Die Datenzugriffsbefehle werden über die Leitung 109 an die Tabellenzugriffsmaschine übergeben. Die Maschine mit dem virtuellen Stapel führt den Algorithmus wie folgt aus:
1. Abrufen des Opcodes, auf den der Anweisungszeiger in der Regel zeigt;
2. Nachschlagen des Opcodes in der Opcode-Tabelle 103, um die durch den Opcode identifizierte Host-Systemroutine wiederzugewinnen;
3. Abfertigen der Host-Systemroutine;
4. Vorrücken des Befehlszeigers;
5. Rückkehr zu dem Schritt des Abrufens des Opcodes.
Fig. 4 liefert ein Beispiel dafür, wie die Maschine mit dem virtuellen Stapel den Aufruf einer Regel namens "CHECKTRAIL" ausführt. Die CHECKTRAIL-Regel umfaßt in diesem Beispiel zwei Parameter, die 'TORONTO' und PERSON umfassen. Der Objektcode der Regel wird in der Regelbibliothek an dem Platz 120 gespeichert. Der Befehlszeiger wird von dem oberen Code @CONST 'TORONTO' zu dem letzten Objekt @CALL 2, offset vorgerückt, wobei die Distanzadresse mit der Linie 121 bezeichnet ist. Die Distanzadresse identifiziert in dem Bereich der statischen Daten die Position der Regel, an der der Regelname CHECKTRAIL mit der Distanzadresse 122 gespeichert wird. Die Distanzadresse 122 speichert einen Platz in dem modifizierbaren Bereich der Regel, an dem der Wert für den CHECKTRAIL-Objektcode gespeichert wird. Der Wert zeigt über die Linie 123 auf den Platz in der Regelbibliothek 124, an dem CHECKTRAIL zu finden ist. Auf den Stapel 125 hat das folgenden Einfluß:
Zunächst wird als Antwort auf den @CONST-Opcode der Wert der Variablen TORONTO in dem Arbeitsbereich der Maschine mit dem virtuellen Stapel angeordnet. Als Antwort auf den @TEMP-Opcode wird eine temporäre Kopie des Parameters TORONTO gespeichert. Der Stapel wird mit einer Distanzadresse 126 zu dem Wert 127 für die temporäre Kopie 128 geladen. Als nächstes wird der Parameter 'PERSON' in den Arbeitsbereich der Maschine mit dem virtuellen Stapel verschoben und eine temporäre Kopie erzeugt. Der Stapel wird mit einem Zeiger 129 auf den Wert 130 der temporären Kopie der Konstanten PERSON 131 geladen. Als nächstes wird der @CALL 2, die Distanzadressenregel, ausgeführt. Falls die Distanzadresse in dem @CALL-Opcode auf den Namen und auf die Distanzadresse in dem Bereich der statischen Daten der aufzurufenden Regel zeigt, wird der Wert, der den Platz der aufzurufenden Regel in dem Regelspeicher identifiziert, in dem Bereich der modifizierbaren Daten an dem durch die Distanzadresse 122 identifizierten Platz 132 gespeichert. Der Befehlszeiger in der Maschine mit dem virtuellen Stapel wird dann an den Platz in dem Regelspeicher 124 verschoben, an dem CHECKTRAIL zu finden ist, wobei CHECKTRAIL ausgeführt wird.
Die in Fig. 3 gezeigten Regelbibliotheken 101 bestehen aus mehreren Regelbibliotheken. Wenn ein @CALL-Opcode ausgeführt wird, wird von dem Regelnamen eine Suche nach der richtigen Regel ausgeführt. Die Regel kann als ein Regelobjektcode in einer der Bibliotheken, als eine eingebaute Funktion, als ein Unterprogramm (z. B. das Unterprogramm der ENTER-Taste, das auf die Eingabe eines Anwenders reagiert), als eine durch den Anwender definierte externe Routine, die vielleicht in einer anderen Quellsprache wie Cobol oder PL1 geschrieben ist, gefunden werden, oder es könnte anstelle eines Aufrufs einer tatsächlichen Regel eine Referenz auf eine lokale Variable sein. Somit wird die Regelnamensuche zunächst durch die Liste der lokalen Variablen in der Regel, von der die Anweisung ausgeführt wurde, zweitens durch die lokale Regelbibliothek, die für eine gegebene Sitzung durch den Anwender aufgestellt wird, als nächstes durch eine Installationsregelbibliothek, die eine Standardmenge von durch einen Anwender für eine gegebene Ausführungs- und Programmierumgebung festgesetzten Routinen ist, viertens durch eine eingebaute Routinenbibliothek, die alle Standardfunktionen des Betriebssystems umfaßt, fünftens durch eine Systemregelbibliothek, die die HOS-System regeln speichert, die bei dem Datenmanagement und bei anderen eingebauten Operationen verwendet werden, und schließlich sechstens durch eine Bibliothek externer Routinen fortgesetzt.
Wenn eine Regel von einer früheren Regel wie etwa von einem Sitzungsmanager aufgerufen wird, wird vor dem Beginn der Ausführung der nachfolgenden Regel der Stapel der früheren Regel in einem Kontextsicherungsbereich in dem Stapel gesichert. Bei der Ausführung einer Rückgabeanweisung kehrt der Stapelzeiger zu der früheren Regel zurück.
Der Datenmanagementbereich 102A in der Maschine mit dem virtuellen Stapel enthält die Tabellen, über die die Regelnamensuchen ausgeführt werden. Diese Tabellen sind in Fig. 5 gezeigt. Für die Regelnamen wird eine Regelnamen-Hash-Tabelle 150 erzeugt, die 127 Einträge lang ist. Jeder Eintrag in der Regelnamen-Hash enthält einen Zeiger auf eine erste Regel, die in diesen Eintrag umgesetzt wird. Zum Beispiel kann ein Zeiger 151 auf die CHECKTRAIL-Regel der erste Eintrag sein. Die CHECKTRAIL-Regel speichert einen Zeiger 152 auf eine zweite Regel, die diesem Eintrag in der Hash-Tabelle (d. h. der in der Figur gezeigten SHORT-Regel) entspricht. Die SHORT-Regel enthält dann einen Zeiger 153 auf einen nachfolgenden Eintrag bis nach unten zum Ende der Liste, der in einen gegebenen Platz in der Regelnamen-Hash-Tabelle umgesetzt wird.
Falls eine aufgerufene Regel nicht in der Hash-Tabelle vorhanden ist, muß sie über die Tabellenzugriffsmaschine wiedergewonnen und in die Regelbibliothek für die Sitzung eingesetzt werden.
Fig. 6 zeigt die in den Datenmanagementbereich in der Maschine mit dem virtuellen Stapel eingebaute Tabellendefinition. Zunächst wird der Tabellenname in eine Tabellennamen-Hash- Tabelle umgesetzt. Der Eintrag in der Hash-Tabelle 160 zeigt auf eine Tabellenliste 161, die durchsucht wird, um den Namen der interessierenden Tabelle "FRUIT" zu finden. Dieser Eintrag enthält einen ersten Zeiger 162 auf eine Parameterliste 163 sowie einen zweiten Zeiger 164 auf eine Feldliste 165 für die Tabelle. Diese Feldliste enthält einen Zeiger 166 auf den Zeilenpuffer 167 für das Auftreten der Tabelle, die das interessierende Feld besitzt.
Die Maschine mit dem virtuellen Stapel unterhält einen Puffer für alle Datenzugriffe und lokalen Variablen. Somit hat die VMS jedesmal, wenn ein Regelprogramm
GET CARS WHERE LIC_PLATE = '878BBC';
besagt, die Wörterbuchinformationen für die Tabelle CARS zu erfassen und einen Puffer für sie herzustellen.
In ähnlicher Weise muß die Maschine mit dem virtuellen Stapel die Wörterbuchinformationen für die Tabelle CUSTOMER erfassen und einen Puffer für sie herstellen, wenn ein Regelprogramm
CUSTOMER.NAME = INPUT.NAME;
besagt, ohne einen Datenzugriffsbefehl ausgegeben zu haben.
Sobald für eine besondere Tabelle ein Puffer hergestellt worden ist, ist er künftig für alle Regeln in der momentanen Transaktion verfügbar. Die Maschine mit dem virtuellen Stapel verfolgt entweder über einen GET- oder FORALL-Befehl oder über eine Zuweisungsanweisung, welchen Feldern und welchen Tabellen ein Wert zugeordnet worden ist.
Die Maschine mit dem virtuellen Stapel erfaßt das Wörterbuch, um seinen Datenmanagementbereich durch Ausgeben einer Menge von Zugriffsbefehlen genau in der gleiche Weise zu bevölkern, wie es irgendein Anwendungsprogramm tun würde:
GET TABLES WHERE NAME = TABLE NAME;
FORALL FIELDS (TABLE NAME);
FORALL PARMS (TABLE NAME).
Die einheitliche Ansicht der Wörterbuchdaten sowie weiterer Daten wird oberhalb der Tabellenzugriffsmaschine genau be wahrt. Keine Komponente des Systems oberhalb der Tabellenzugriffsmaschine sieht unnormierte Wörterbuchdaten.

VII. Die Tabellenzugriffsmaschine

Die Tabellenzugriffsmaschine ist in Fig. 7 in Form eines Blockschaltplans gezeigt.
Diese Maschine oder dieses Verfahren besteht aus einem Host- Assembler-Softwaremodul 200, das über die Leitung 201 mit der Maschine mit dem virtuellen Stapel kommuniziert. Dieses Modul 200 stellt Puffer 202 einschließlich eines Datenmanagementbereichs-Puffers 202A und eines Arbeitsbereichs 202B her. Außerdem schafft des Tabellenzugriffsverfahrens-Modul 200 eine Schnittstelle 401 für mehrere Server einschließlich eines TDS- Servers 203 für den ursprünglichen Tabellendatenspeicher, eines IMS-Servers 204 für Daten, die in einer der Host-Maschine zugeordneten IMS-Datenbank gespeichert werden, eines Bildschirmservers 205, der eine Schnittstelle zu mit der Host- Maschine gekoppelten Anzeigesystemen schafft, eines (nicht gezeigten) Import/Export-Servers sowie weiterer Server, die erforderlich sind, um die Daten über das Tabellenzugriffsverfahren 200 in der Maschine mit dem virtuellen Stapel wiederzugewinnen. Über die Schnittstelle 402 ist an die Server ein Auswahlauswertermodul 206 angeschlossen, das die Auswahlstrings auf der Serverebene interpretiert.
Das Tabellenzugriffsverfahren (TAM) ist die Komponente des Systems, die das Management aller Datenzugriffe in dem System ausführt, wobei es der tatsächliche Besitzer der Wörterbuchtabellen und der Aufbewahrungsort aller weiteren von einer Sitzung verwendeten Tabellen ist.
Ein Aufruf des TAM weist die folgenden Informationen auf:
1. Operation
2. Adresse der Daten- und Rückkehrbereiche
3. Tabellenname
4. Parameter
5. Auswahlstring
6. Ordnungsstring
Die Operationen sind:
A: Erste Anforderung eines FORALL
B: Nachfolgende Anforderung eines FORALL
I: Einsetzen
G: Mit Schlüssel erhalten
N: Ohne Schlüssel erhalten
R: Ersetzen
D: Löschen
S: Bildschirm anzeigen
C: Einspeichern
O: Wiederholen
T: Ende der Transaktion
Bei der ersten Anforderung für eine besondere Tabelle erfaßt das TAM eine CTABLE aus dem Tabellendatenspeicher. Die CTABLE ist ein Steuerblock, der aus den Wörterbuchdaten in unnormierter Form besteht. Die CTABLE wird für die Verarbeitung sowohl durch das TAM als auch durch die Datenserver, wobei einer von ihnen der TDS ist, verwendet. Die CTABLE enthält die gleichen Daten wie in TABLES, FIELDS, PARMS, SELECTION, ORDERING und EVENTRULES.
Es wird angemerkt, daß das TAM die CTABLE für eine Tabelle erfaßt, sobald es einen Aufruf wie:
GET TABLES WHERE NAME = tablename;
erhält.
Normalerweise bedeutet das, daß eine Komponente oberhalb des TAMs einen Puffer für < tablename> aufbauen möchte und somit sofort nach der GET-Anforderung ein
FORALL FIELDS(tablename); und ein
FORALL PARMS(tablename);
ausgibt.
Diese Anforderungen werden von dem TAM aus der CTABLE bedient.
Neben der CTABLE richtet das TAM Datenstrukturen für die Datenzeilen ein, in denen die letzte Zeile, auf die zugegriffen wurde, sowie eine Absichtsliste anstehender Aktualisierungen für die Datenserver unterhalten werden.
Das TAM führt das Management der Positionierung in den Datenbanken aus. Die Datenserver wie die TDS verarbeiten die Anforderungen von dem TAM einzeln, ohne irgendwelche Informationen von einer Anforderung zur anderen aufzubewahren. Nur der LOCK MANAGER (in dem TDS) bewahrt die Informationen während der Dauer einer Transaktion auf.
Im Fall einer parametrisierten Tabelle unterhält das TAM für jede Tabelle in der Tabellenmenge, auf die zugegriffen wird, einen Puffer und eine Position.
Wenn das TAM eine REPLACE-, eine INSERT- oder eine DELETE- Anforderung empfängt, stellt es dadurch, daß es den Server fragt, ob das Auftreten vorhanden ist (DELETE und REPLACE) oder nicht vorhanden ist (INSERT), sicher, daß die Anforderung möglich ist, und erfaßt die erforderliche ausschließliche Verriegelung in dem Auftreten. Danach ordnet das TAM das REPLACE-, das INSERT- oder das DELETE-Auftreten in der Absichtsliste (in der Liste der zu verrichtenden Arbeit) an, bis es eine COMMIT-, eine ROLLBACK- oder eine TRANSACTION_END- Anforderung empfängt.
Das TAM führt die Umsetzungen zwischen den Unteransichten und den logischen Ansichten aus, die aus:
* Datenumsetzungen zwischen verschiedenen Darstellungen
* Projektionen (die Unteransicht enthält weniger Felder als die logische Ansicht)
* Auswahl (die Unteransicht enthält weniger Zeilen als die logische Ansicht)
* Ordnen (von der logischen Ansicht verschieden)
* abgeleiteten oder berechneten Feldern bestehen.
Eine Unteransicht ist tatsächlich ein Fenster in eine logische Ansicht, die sich nie in dem Speicher verwirklicht, sondern nur während der Ausführung in den Puffern erscheint. Für den Anwender und für die VSM gibt es jedoch zwischen einer Tabelle in der Unteransicht und in der logischen Ansicht keinen offensichtlichen Unterschied.
Abgeleitete Felder sind Felder einer Unteransicht, die während der GET- oder FORALL-Verarbeitung berechnet werden. Die Validierungs- und Auslösungsregeln werden auf der Grundlage der EVENTRULES-Informationen ausgeführt.
In allen drei Fällen gibt das TAM zum Ausführen einer Regel an die Maschine mit dem virtuellen Stapel einen (rekursiven) Aufruf aus. Der Tabellenpuffer, in dem die Validierung oder Auslösung geplant ist, wird ebenso wie die Absichtsliste von den Rekursionsebenen gemeinsam genutzt.
Das TAM realisiert das Konzept der temporären Tabellen, die nur während einer Transaktion (in den TAM-Datenbereichen) existieren, aber nicht in irgendeinem Datenserver wie dem TDS verwirklicht werden.
Das TAM führt sowohl für die Unteransichten als auch für die FORALL-Anforderungen die gesamte erforderliche Sortierung mit einer Reihenfolge, die von der von dem Datenserver unterhaltenen Reihenfolge verschieden ist, aus.
Die Datenzugriffsanforderungen werden auf der Grundlage der Informationen in der TABLES-Tabelle für die besondere Tabelle an den richtigen Server gerichtet.
Fig. 8 ist ein Diagramm des TAM-Pufferspeicherbereichs. Der TAM-Pufferspeicherbereich enthält einen Ankerspeicherbereich 250, der den Tabellenindex enthält. Dieser Tabellenindex zeigt auf eine Menge von CTABLES 251, die die CTABLE für jede der Tabellen T1-T3 usw. puffern.
Außerdem zeigt der Pufferzeiger für eine gegebene Tabelle T1 auf eine Menge 252 von Puffern für die Tabelle T1. Diese Menge 252 enthält einen Index 253 für die Auslöser und Parameter für die Tabelle 1. Dieser Index zeigt erforderlichenfalls auf die Puffer 254, 255, 256 usw. für das tatsächliche Auftreten der Daten. Außerdem zeigt die Indexseite 253 auf weitere T1-Informationen wie etwa Auswahlstrings usw. in der Seite 257. Außerdem wird in den Seiten 258 und 259 erforderlichenfalls die Absichtsliste für die Tabelle T1 unterhalten.
Außerdem zeigt der Ankerspeicher 250 auf freie Puffer in einer Menge 260, die mehrere einzeln gebundene leere Puffer enthält.
Die Pufferung erfolgt nacheinander und vorwärts gerichtet. Bei einem Transaktionsende werden die Tabellenanker als Antwort auf den "T"-Opcode gelöscht.
Fig. 10 zeigt die CTABLE-Informationen in der Tabellenzugriffsmaschine. Die CTABLE ist eine Tabelle der Eigenschaften einer entsprechenden in einem Puffer 280 gespeicherten Tabelle. Dieser Puffer wird aus den Rohdaten 281 erzeugt, die aus den Wörterbuchtabellen 282 in dem Tabellendatenspeicher wiedergewonnen werden. Wie alle anderen Daten in dem System werden diese Wörterbuchtabellen ihrerseits in den symmetrischen Speicherstrukturen 283 des Tabellenspeichers unterhalten. Somit werden die Metadaten in einer CTABLE in der relationalen, objektorientierten Datenbank, an der die Transaktion ausgeführt wird, gespeichert.
Die "Meta-Metadaten" sind dagegen hart codiert. Das heißt, daß die Wörterbuchstruktur für den Anwender aufgestellt ist und nicht geändert werden kann. Damit eine gegebene Transaktion zufriedenstellend abgeschlossen werden kann, muß somit die Minimalmenge der Wörterbuchtabellen vorhanden sein.
Eine gegebene CTABLE wird während der Dauer einer Transaktion gebunden. Nachdem sie wiedergewonnen wurde, werden somit von der CTABLE in dem Transaktionsspeicherbereich der Tabellenzugriffsmaschine bei dem ersten Aufruf eines Teils einer Tabelle alle nachfolgenden Aufrufe dieser Tabelle bedient.
Fig. 11 ist eine Darstellung einer Quelltabelle (T) und einer Unteransichttabelle (S). Eine Unteransicht ist eine Abbildung eines Rechtecks in der Quelltabelle. Somit umfaßt die Unteransicht, wie in Fig. 11 gezeigt ist, die ersten und dritten Spalten der Zeilen 2, 3 und 5 der Quelltabelle T. Diese Unteransicht wird durch die Tabellenzugriffsmaschine mit einer Datenpuffermenge, aber mit zwei CTABLES realisiert. Für jedes Auftreten wird zur Schnittstellenzeit eine Unteransicht aufgebaut. Abgeleitete Felder werden jedoch nur aus der Quelltabelle erzeugt. Somit baut die Tabellenzugriffsmaschine als Antwort auf eine Anforderung in der Regel, die einen Zugriff auf die Unteransichttabelle S erfordert, eine Steuertabelle sowohl für die Quelltabelle T als auch für die Unteransichttabelle S auf.
Der Zugriff auf die Quelltabelle T findet in dem Tabellendatenspeicher statt. Somit wird eine Quelltabellenseite an die Tabellenzugriffsmaschine zurückgegeben. Die Tabellenzugriffsmaschine puffert dann die Seite, setzt sie in die logische Unteransicht um und gibt das erste Auftreten in der Unteransicht an die ausführende Einrichtung zurück.
Für eine gegebene Tabelle können die Auslöser aus Unteransichten als Ereignisregeln und ansonsten als Antwort auf Einträge in der CTABLE ausgeführt werden. Wenn eine Regel aufgerufen wird, wird die Ausführungsumgebung der aufrufenden Regel gesichert, wobei das TAM die ausgelöste Regel zur Interpretation an die ausführende Einrichtung sendet. Die ausgelöste Regel kann außerdem Tabellenoperationen ausgeben, die bewirken, daß die ausführende Einrichtung zu der Tabellenzugriffsmaschine wiederkehrt. Beim Abschluß der ausgelösten Regel wird die Steuerung an die aufrufende Regel zurückgegeben.
Die parametrisierten Tabellen werden in dem Zugriffsmodell, nicht jedoch auf der Ebene des Auftretens realisiert. Somit werden sie in ähnlicher Weise wie Unteransichten ausgeführt. Diese parametrisierten Tabellen ermöglichen verknüpfte Schlüssel, eine verbesserte Gleichzeitigkeit, sie sparen Speicherplatz in den virtuellen Maschinen und sie vereinfachen die Archivierung. Sie werden dadurch ausgeführt, daß in der Tabellenzugriffsmaschine aus dem Wörterbuch in dem Tabellendatenspeicher eine Parametertabelle aufgebaut wird. Diese Steuertabelle wird als Antwort auf den "P"-Aufruf des Tabellendatenspeichers aus dem TAM aufgebaut. Die Tabellenzugriffsmaschine überträgt dann die Auftreten der Parameter an die ausführende Einrichtung zum Eintragen in die Tabellennachschlageindexe.
Das TAM gewinnt die Daten aus dem Tabellendatenspeicher von der Quelltabelle wieder. Es baut einen Puffer für die Quelltabelle auf und führt dann, bevor es die Auftreten an die ausführende Einrichtung sendet, die Parameterauswahlen aus.
Außerdem kann die Unteransichtsauswahl einen Quellparameternamen auf der rechten Seite des Operators angeben.
Mit dem gleichen Code werden von der Tabellenzugriffsmaschine temporäre Tabellen und Absichtslisten erzeugt. Die temporären Tabellen ermöglichen ebenfalls eine Auswahl. Diese Tabellen werden linear durchsucht. Der Zugriff kann jedoch wahlfrei erfolgen.
Fig. 12 zeigt für eine gegeben Operation den Code und die Einsetzungen in eine Absichtsliste. Es wird darauf hingewiesen, daß die Absichtsliste den Wert k = 5 und den Wert k = 4 speichert. Die am Ende ausgeführte FORALL-Anweisung ruft das Sortieren auf, um die Einsetzung auszuführen. Weitere Operatoren wie replace, delete und get verwenden die Absichtsliste in ähnlicher Weise.
Fig. 13 ist ein Diagramm der Transaktionen. Dieses objektorientierte Betriebssystem ist gemäß der vorliegenden Erfindung transaktionsorientiert. Somit bestimmt die ausführende Einrichtung eine Transaktion, während die Tabellenzugriffsmaschine bei der Erkennung der Transaktion arbeitet. Dies ermöglicht, Operationen für die Gleichzeitigkeit und Integrität in kleine Teile zu zerlegen. Außerdem können sie bis auf die Übertragungsaufruf- und Ausführungsfunktionen für den Anwender transparent oder implizit sein. Beim Beginn der Transaktion wird, wie in Fig. 13 gezeigt ist, am Punkt 300 eine erste Regel mit CALL aufgerufen. Diese Regel wird ausgeführt, bis am Punkt 301 eine zweite Regel aufgerufen wird. Diese zweite Regel wird von der ausführenden Einrichtung mit wiederkehrenden Aufrufen der Tabellenzugriffsmaschine realisiert. Die zweite Regel kann am Punkt 302 eine dritte Regel aufrufen. Diese dritte Regel wird ausgeführt, bis sie die Operation abschließt und am Punkt 303 eine Rückkehr zu der zweiten Regel ausgibt. Die Ausführung der zweiten Regel wird dann abgeschlossen, wobei sie am Punkt 304 eine Rückkehr zu der ersten Regel ausgibt. Dann wird die Ausführung der ersten Regel abgeschlossen, womit diese abgeschlossen wird. Begrifflich könnte die erste Regel als ein Sitzungsmanager betrachtet werden, in dem sie die Menübildschirme für einen Betreiber darstellt. Der Betreiber ruft dann eine zweite Regel zum Ausführen einer gegebenen Anwendung auf. Diese zweite Regel kann irgendeine Anzahl von Transaktionsebenen, wie sie von der gegeben Anwendung angefordert werden, umfassen.
Außerdem führt die Tabellenzugriffsmaschine ein Zweiphasen- Verriegelungsprotokoll für die Objekte in der Datenbank aus. Beim Abschluß der Transaktion werden alle Verriegelungen gelöscht, während diese während einer Transaktion nicht "abgeschwächt" werden können. Die Verriegelungen werden von der Tabellenzugriffsmaschine angefordert und von dem natürlichen Zugriffsverfahrensserver, wie etwa von dem Tabellendatenspeicher oder von dem Server anderer Arten von Datenquellen, bewilligt oder nicht bewilligt.
Außerdem baut die Tabellenzugriffsmaschine Auswahlstrings für die Übertragung an einen Auswahlauswerter auf, der dem Tabellendatenspeicher-Server oder einem anderen natürlichen Datenspeicherserver zugeordnet ist. Der Auswahlauswerter wird von einem Server aufgerufen. Der Server liefert eine Zeile aus einer Tabelle zusammen mit einem Auswahlstring. An den Auswahlauswerter werden keine Datendefinitionen übergeben. Der Auswahlauswerter führt die Auswahloperation aus. Die Ergebnisse der Auswahl werden von dem richtigen Server an die Tabellenzugriffsmaschine zurückgeleitet.
Zum Zugreifen auf die verschiedenen Tabellen, Bildschirme sowie weiteren Untersysteme in dem Sachgebiets-Datenverarbeitungssystem bauen Objektcoderoutinen in der VSM @TAM-Argumente auf, die in der VSM < ---> TAM-Schnittstelle an das TAM weitergeleitet werden. Das TAM übermittelt verschiedene Anforderungen an die Server, die das tatsächliche Zugreifen auf die Tabellen, Bildschirme usw. ausführen. Die Server können ihrerseits Anforderungen an den Auswahlauswerter weiterleiten, der Auswertungen ausführt und Antworten an die Server zurückleitet. Die Server geben dann die Daten oder die Antworten an das TAM zurück, das sie an die VSM-Objektcoderoutinen weiterleitet.

TAM < --> Server-Schnittstelle

Das TAM kommuniziert mit den verschiedenen Subjekten der Rechenumgebung über Server. Es gibt Server für Bildschirme, für das IMS, für den Import/Export, für den natürlichen Tabellendatenspeicher sowie für weitere Subjekte. Das TAM sendet eine Anforderung, auf die einer oder mehrere Datenstrings folgen, an einen Server. Ein Datenstring beginnt mit einem 1 Byte-Längenindikator, falls der String eine Länge von weniger als 128 Bytes besitzt (das Bit 0 gelöscht ist), oder mit einem 2 Bytes-Längenindikator (das Bit 0 ist gesetzt), falls der String eine Länge von mehr als 127 Bytes hat. Die Tabelle 64 listet die gültigen Server-Anforderungen, die das TAM vornehmen kann, auf:

Tabelle 64 (Gültige TAM --> Server-Anforderungen)

Code Name

C Ctable-Anforderung
R Verriegelungen lösen
G Erhalten
N Nächster
P Nächster Parameter
Die Tabellen 65-69 geben ausführliche Informationen über den Dateninhalt der Anforderungs- und Rückgabe-Kommunikationen für jeden Anforderungscode:
Außerdem kann von dem TAM eine Aktualisierungsmeldung (Synchronisierungsmeldung) gesendet werden. Die Tabelle 70 gibt ausführliche Informationen über den Dateninhalt dieser Meldung und über ihre Rückantwort:

Server --> Auswahlauswerter-Schnittstelle

Das TAM kann an die Server verschiedene Nachrichten senden, die Informationen enthalten, die zur Verarbeitung an den Auswahlauswerter weitergeleitet werden müssen. Der Auswahlauswerter erwartet, daß die folgenden Register die angegeben Daten enthalten:

Register Inhalt

15 Adresse des Eintrittspunkts in den Auswahlauswerter
13 Adresse des Standardsicherungsbereichs
01 Adresse der Parameterliste
Die Parameterliste enthält an den gegebenen Byte-Distanzadressen die folgenden Informationen:

Byte-Distanzadresse Inhalt

0 Adresse des Auswahlstrings
4 Adresse der zu vergleichenden Tabellenzeile
8 Adresse des 4080 Bytes-Arbeitsbereichs
Ein Auswahlstring besteht aus einem Feld mit einer Länge von 2 Bytes, auf das einer oder mehrere Auswahlausdrücke in der Postfix-Schreibweise folgen. Jeder Auswahlausdruck beginnt mit einem 1 Byte-Opcode und kann in die in Tabelle 71 aufgelisteten Kategorien gruppiert werden:

Tabelle 71 (Auswahlausdrücke)

Ausdruckstyp Funktion

Operator arithmetischer 1 Byte-, relationaler oder logischer Opcode
Feldreferenz 1 Byte-Opcode ('44'), gefolgt von einem 6 Bytes-Feldbeschreiber und von einer 2 Bytes-Feldnummer
Distanzadressen-Referenz 1 Byte-Opcode ('4C'), gefolgt von einem 6 Bytes-Feldbeschreiber und von einer 2 Bytes-Distanzadresse des Felds in der Zeile. Wird für temporäre, Import-, Bildschirm- und IMS-Tabellen verwendet.
Wert 1 Byte-Opcode ('48'), gefolgt von einem 6 Bytes-Wertbeschreiber und von einem Wert. Der Wert beginnt mit einem Präfix mit einer Länge von 1 Byte (Länge < 128, Bit 0 gelöscht) oder von 2 Bytes (Länge > 127, Bit 0 gesetzt).
Ausführliche Informationen über den Inhalt der Feld- und Wertbeschreiber sowie über den Auswahlstringausdruck-Opcode sind in den Tabellen 72 bzw. 73 gegeben: Tabelle 72 (6 Bytes-Feld- und Wertbeschreiber)

Tabelle 73 (Hexadezimal-Opcodes)

Opcode Funktion

(arithmetisch)
'04' + (Addition)
'08' - (Subtraktion)
'0C' * (Multiplikation)
'10' / (Division)
'14' ** (Exponentialfunktion)
'18' - (monadisches Minus)
'1C' (Verknüpfung)
(Vergleich)
'20' = (gleich)
'24' = (ungleich) -
'28' < (kleiner als)
'2C' < = (kleiner als oder gleich)
'30' > (größer als)
'34' > = (größer als oder gleich)
(logisch)
'38' & (und)
'3C' # (oder)
'40' (nicht) -
(weitere)
'44' R (Referenz auf das i. Feld in der Zeile)
'48' V (Wert)
'4C' O (Referenz auf ein Feld bei der Distanzadresse in der Zeile)
'S4' @ (Parameter in der Auswahl ersetzt, wobei dessen Auswertung immer wahr ergibt)
'BC' LIKE(Relation)
Der LIKE-Vergleichsoperator besitzt zwei Operanden: einen Feldnamen und ein Muster. Das Ergebnis des Vergleichs ist wahr, wenn der Wert des Felds in der Zeile mit dem Muster übereinstimmt. Das Muster kann die Ersatzzeichen: '*' (irgendein String aus null oder mehr Zeichen) und '?' (irgendein Zeichen) enthalten.
Die durch die Adresse an den Auswahlauswerter übergebene Tabellenzeile kann eines von zwei Formaten besitzen: Das erweiterte Zeilenformat variabler Länge (das bei temporären, Import-, Bildschirm- und IMS-Tabellen verwendet wird) oder das Zeilenformat variabler Länge (das ansonsten verwendet wird).
Das Zeilenformat variabler Länge beginnt mit einem 2 Bytes- Zeilenlängenindikator, der die Länge der Gesamtzeile einschließlich des Indikators selbst gibt. An den Zeilenlängenindikator werden eines oder mehrere Felder angehängt, wobei das erste Feld ein "Schlüssel"-Feld ist. Jedes solche Feld beginnt mit einem 1 Byte-Feldlängenindikator, falls die Feldlänge ausschließlich des Längenindikators weniger als 128 Bytes beträgt (Bit 0 gelöscht) oder mit einem 2 Bytes-Feldlängenindikator, falls die Länge ausschließlich des Längenindikators mehr als 127 Bytes beträgt (Bit 0 gesetzt). Der Wert des Felds wird in der gegebenen Anzahl der Bytes dargestellt. Leerzeichen werden vom rechten Ende aller Felder, die Syntaxzeichen enthalten, entfernt. Falls ein angefordertes Feld in der Zeile nicht vorhanden ist, wird angenommen, daß das Feld den Wert null hat.
Das erweitere Zeilenformat variabler Länge unterscheidet sich geringfügig dadurch, daß kein Zeilenlängenindikator verwendet wird. Außerdem wird für den Wert jedes Felds eine feste Anzahl von Bytes reserviert, wobei der Längenindikator für jedes Feld lediglich angibt, wieviel dieser Bytes tatsächlich verwendet werden. Der letzte Unterschied besteht darin, daß eine Zeile nicht ausgewählt wird, wenn ein angefordertes Feld in der Zeile nicht vorhanden ist, es sei denn, daß das Feld mit einem Nullstring vergleichen wird.

Auswahlauswerter --> Server-Schnittstelle

Bei der Rückkehr übergibt der Auswahlauswerter im Register 15 die folgenden Rückgabecodes an die Server:

Rückgabecode Ursache

0 Zeile stimmt mit den Auswahlkriterien überein
4 Zeile stimmt nicht mit den Auswahlkriterien überein
8 Fehler erfaßt
Falls ein Fehler erfaßt wird, gibt der Auswahlauswerter die in Tabelle 74 gezeigten Daten an den Arbeitsbereich zurück.
Der Fehlermeldungstext kann Strings der Form "%Fnnnn" enthalten, wobei "nnnn" eine vierstellige Feldnummer für das Zeilenformat variabler Länge oder eine vierstellige Felddistanz adresse für eine Zeile mit einem Format mit einer festen Länge ist. Zum Beispiel kann eine Fehlermeldung 'TYPE ERROR, FIELD "%F0010" COMPARED WITH TYPE IDENTIFIER' lauten, wobei das aufrufende Subjekt dann den richtigen Feldnamen anstelle von "%F0010" in den String einsetzen kann.
Somit kann ein Tabellenzugriff in der Weise zusammengefaßt werden, daß er mit einer Tabellenzugriffsanweisung in dem Objektcode der ausführenden Einrichtung beginnt. Der Objektcode enthält somit den Code, der die @TAM-Argumente aufbaut, sowie Konstanten, die von den Argumenten verwendet werden sollen. Dieser Code kann durch den Regeleditor in einzelner Form neu aufgebaut werden. Die Tabellenzugriffsanweisung in dem Objektcode wird dann in ein @TAM-Opcode-Format übersetzt. Dieses umfaßt den Opcode, die Tabellennamen, die Parameter, die Auswahlstrings, die Ordnungsinformationen in dem Stapel. Die Werte werden in einem Beschreiberformat gespeichert und beruhen auf Datenmanagement-Datenstrukturen. Die Zugriffe erfolgen unter Verwendung von Feldnamen. Als nächstes wird das von dem Opcode, von den Tabellennamen, von den Parametern, von den Auswahlstrings und von der Reihenfolge im Maschinencodeformt angegebene TABLE ACCESS MACHINE INTERFACE ausgeführt.
Der Server führt dann eine erforderliche Kommunikation mit dem natürlichen Datenspeicher aus, um die identifizierten Auftreten zurückzuleiten. Erforderlichenfalls wird von dem Server der Auswahlauswerter aufgerufen.

VIII. Dynamisches Binden

Das in der Maschine mit dem virtuellen Stapel ausgeführte dynamische Binden kann als eine Realisierung mit drei Hauptschritten zusammengefaßt werden. Zunächst wird der Regelobjektcode mit einem Bereich der modifizierbaren Daten realisiert. Als zweites baut die ausführende Einrichtung Hash- Tabellen für die Regeln und Tabellen auf, mit denen die zu bindenden Objekte schnell gefunden werden können. Als drittes puffert die Maschine mit dem virtuellen Stapel bei der Anmeldung einer Sitzung die festen Daten einschließlich der Regeln aus den System- und Installationsbibliotheken sowie die festen Tabellendefinitionen für die Wörterbücher und dergleichen.
Die Objekte in einer Regel, die nicht gebunden sind, enthalten in Tabellen gespeicherte Regeln oder Daten. Wenn eine Regel eine weitere Regel durch einen Namen aufruft, enthält die Regel eine Distanzadresse zu einer Position der Regel in dem Bereich der modifizierbaren Daten, bei der der Wert der aufzurufenden Regel gespeichert werden kann. Die ausführende Einrichtung sucht dann über die Hash-Tabellen und über ihre Puffer durch den Namen nach der Regel. Falls sie in den Hash- Tabellen nicht gefunden wird, wird dann ein Aufruf der Tabellenzugriffsmaschine zum Einsetzen des Puffers sowie der richtigen Werte in den Hash-Tabellen ausgeführt. Wenn die ausführende Einrichtung den Puffer für die aufzurufende Regel findet, wird der Wert des Puffers in den modifizierbaren Abschnitt der Regel eingesetzt. Ähnlich wird beim Aufruf eines Objekts durch eine Tabelle und eines Feldnamens durch eine Regel diese Tabelle von der Maschine mit dem virtuellen Stapel über die Hash-Tabellen oder -Bibliotheken gefunden. Der Wert des Auftretens der Tabelle, in der das aufgerufene Feld gefunden wird, wird dann bei der besonderen Distanzadresse in dem modifizierbaren Abschnitt der Regel gespeichert.
Unter Verwendung dieser Formate können alle Objekte in der Datenbank zur Ausführungszeit gebunden werden. Tatsächlich ist die Regelbindung die gleiche Bindung wie die table.field- Bindung mit Ausnahme dessen, daß wie oben beschrieben die Tabelle, in der eine Regel gefunden wird, dadurch bestimmt wird, daß eine vorgegebene Menge von Bibliotheken durchsucht wird.
Um die Aufrufe über die Tabellenzugriffsmaschine und über die natürlichen Datenspeicher während der Ausführung einer Regel zu minimieren, kann bei der Anmeldung einer Sitzung eine große Anzahl der Datentabellen aus dem Tabellendatenspeicher sowie aus weiteren dem Host zugeordneten Speichersystemen in die Puffer der Maschinen mit dem virtuellen Stapel wiedergewonnen werden.

IX. Tabellendatenspeicher

Der Tabellendatenspeicher ist das natürliche Zugriffsverfahren für das objektorientierte Betriebssystem gemäß der vorliegenden Erfindung. Die Daten werden in diesem System in einer symmetrischen Struktur gespeichert, wobei jede Tabelle in dem primären Schlüssel in der Tabelle geordnet wird. Die Grundstruktur des durch den Tabellendatenspeicher realisierten Zugriffsverfahrens ist in Fig. 14 gezeigt. Der Tabellendatenspeicher besteht aus einer Tabellenindexseite 500. Gegebenenfalls enthält die Tabellenindexseite eine Liste von Tabellennamen mit Zeigern auf eine Parameterindexseite 501. Die weiteren Einträge in der Tabellenindexseite zeigen direkt auf einen Primärschlüsselindex 503. Die Einträge in der Parameterindexseite 501 zeigen auf einen Primärschlüsselindex 502. Der Primärschlüsselindex ist ein auf der B&spplus;-Baumorganisation beruhender symmetrischer binärer Baum 507, der in dem primären Schlüssel geordnet ist (wobei der Index 502 die Spitze des Baums ist). Der Fuß des B&spplus;-Baums zeigt auf die tatsächliche Verbindung zu den Datenseiten, die die Auftreten für die Tabelle speichern.
Der Parameterindex 501 oder die Tabellenindexseite 500 können außerdem auf einen Sekundärschlüsselindex 508 zeigen. Auf der Grundlage der B&spplus;-Schlüsselstruktur zeigt der Sekundärschlüsselindex 508 auf die untere Mengen 509 von Indexen in einem sekundären Schlüssel. Diese Indexe zeigen auf die gleichen verbundenen Datenseiten 510 wie der B&spplus;-Baum in dem primären Schlüssel 507.
In Fig. 15 ist die Seitenanordnung für alle Seitentypen gezeigt. Die Seite enthält einen 32 Bytes-Anfangsblock 520. Der Anfangsblock besteht aus der Seitennummer 521, aus einem Zeiger 522 auf die vorangehende Seite, aus einem Zeiger 523 auf die nächste Seite, aus einem Seitentypindikator 524 und aus einem Datenwert 525. Er enthält einen Zeitstempel 526 sowie eine Transaktions-ID 527, eine Prüfpunktnummer 528, die Anzahl der Zeilen in der Seite 529 sowie die Größe jeder Zeile in der Seite 530. Ein Datenbereich 531 besteht aus 4051 Bytes Rohdaten. Am Ende der Seite ist ein 13 Bytes-Datensatz-Definitionsbereich für die von dem Host-System verwendete VSAM INFORMATION 532 reserviert.
Ein Datensatz in der Seite speichert eine Zeile der Tabelle in dem folgenden Format:
LL/1/Wert/1/Wert/1/Wert...1/Wert/1/Wert,
wobei LL gleich einer 2 Bytes-Länge der Zeile, 1 gleich einer 1 Byte- oder 2 Bytes-Länge für den Wert und der Wert der tatsächliche Dateneintrag oder ein Nullwert ist.
Ein Primärindex-Datensatz besitzt das folgende Format:
Wert/Zeiger.
Ein Sekundärindex-Datensatz besitzt das Format:
Sekundärschlüsselwert/Primärschlüsselwert/Zeiger.
Ein Gruppenindexeintrag besitzt das Format:
Parameter/Parameter/.../Zeiger.
Der B&spplus;-Baum symetrisiert automatisch die Datenstruktur. Jedesmal, wenn auf einer gegebenen Ebene der Baums mehr als zwei Einträge erzeugt werden, realisiert der B&spplus;-Baum gemäß wohlbekannten Verfahren automatisch eine unabhängige Ebene des Baums.
Dementsprechend werden die Suchen nach den Auftreten in einer Tabelle durch den primären Schlüssel sehr schnell ausgeführt. Für Suchen in ungeordneten Feldern muß für die Auswahl in den Server oder zum Erzeugen einer Unteransicht in die Tabellenzu griffsmaschine oder für dergleichen eine vollständige Tabelle wiedergewonnen werden.

X. Übersetzer/Rückübersetzer

Die Erzeugung und Modifikation der Regeln wird durch die Wechselwirkung dreier Komponenten: eines Editors, eines Übersetzers und eines Rückübersetzers, erreicht. Der Regeleditor ist ein interaktives Hilfsmittel, das es einem Anwender ermöglicht, Textänderungen an dem Inhalt einer Regel vorzunehmen. Der Übersetzer setzt das Textbild einer Regel in einen "virtuellen Maschinencode" um, der von der virtuellen Maschine des HOS ausgeführt werden kann. Der Rückübersetzer führt die inverse Transformation aus: Er erzeugt eine Textdarstellung einer Regel aus ihrem Bild in der virtuellen Maschine.
Wenn eine Regel editiert wird, transformiert der Rückübersetzer ihren Code für die virtuelle Maschine in eine Token-Darstellung der Quelle. Der Composer nimmt dann die Token-Form und baut die zeilenweise Textdarstellung der Regel auf. Diese wird von dem Editor für den Anwender angezeigt. Wenn der Anwender Änderungen vornimmt, führt der Abtaster eine lexikalische Analyse der aktualisierten Zeilen aus. Die lexikalische Analyse setzt die Zeilen in ihre Token-Form um, in der sie zur Eingabe in den Übersetzer bereit sind. Wenn der Anwender eine Regel sichert, analysiert sie der Übersetzer und erzeugt, wenn sie gültig ist, für die Regel den Code für die virtuelle Maschine. Sobald die Regel in ihrer ausführbaren Form gesichert ist, wird der Text der Regel verworfen.
Fig. 16 gibt eine Übersicht des Übersetzer/Rückübersetzer- Systems. Es arbeitet in der Weise, daß es den Quellcode 600 der Regel abtastet, wobei es ihn in einen Token-Quellcode 601 übersetzt. Der Übersetzer erzeugt dann den Code 602 für die virtuelle Maschine. Wenn ein Anwender ihn zum Editieren anfordert, wird der Code für die virtuelle Maschine in einen Token- Quellcode 603 zurückübersetzt. Von einem Composer wird er als Regelquellcode zurück an den Anwender geliefert.
Der Token-Quellcode besteht aus Daten, die in einer TOKENS- Tabelle gespeichert werden, die von dem Rückübersetzer aufgebaut und durch eine Logikzeile parametrisiert wird. Zum Modifizieren der TOKENS-Tabelle wird ein lexikalischer Analysator verwendet. Diese Tabelle besteht aus den folgenden Feldern:
INDEX - der primäre Schlüssel;
STRING - der Text des Tokens;
TYPE - der Typ des Tokens;
LEN - die Zeichenlänge des Tokens;
DEC - die Anzahl der Ziffern rechts von dem Dezimalkomma des Tokens;
TABREF.MARK - gibt an, ob dieses Token Teil einer table.field-Referenz ist.
Token, die zu lang für die TOKENS-Tabelle sind, werden in der LONG_STRINGS-Tabelle gespeichert. Diese enthält Token mit einer Länge von mehr als 16 Zeichen, Strings in Anführungszeichen sowie große Zahlen. Diese Tabelle umfaßt die folgenden Felder:
INDEX - der primäre Schlüssel;
STRING - Text des Tokens;
TYPE - Typ des Tokens;
LEN - Zeichenlänge des Tokens;
DEC - die Anzahl der Ziffern rechts von dem Dezimalkomma.
Diese LONG_STRING-Tabelle wird in der TOKENS-Tabelle dadurch identifiziert, daß in das TYPE-Feld "long string" eingesetzt wird, während in das LEN-Feld ein Index auf die LONG_STRINGS- Tabelle eingesetzt wird.
In Fig. 17 sind eine typische TOKENS-Tabelle sowie eine typische LONG_STRINGS-Tabelle gezeigt. Die Logikzeile ist bei 1000 gezeigt, während die Token-Darstellung der Zeile in den Tabellen 1001, 1002 gezeigt ist.
Der Übersetzer setzt die Token-Darstellung der Regel in den Code für die virtuelle Maschine um. Er führt eine kontextfreie Syntaxprüfung und eine kontextsensitive Syntaxprüfung aus. Weiter erzeugt er den für die Laufzeitbindung geeigneten verbundenen Objektcode.
Die Algorithmenstruktur wird in die Regeln des objektorientierten Betriebssystems geschrieben. Sie führt einen von oben nach unten rekursiven absteigenden Übersetzungsalgorithmus aus, in dem die Sprachsyntax in den Bedingungen hart codiert ist. Der Übersetzer setzt die Infix-Form der Regelsprache in die für die Ausführung auf der Stapelmaschine geeignete Postfix-Form der Objektsprache um. Schließlich sichert er die Informationen über die Regeldaten. Der Übersetzer erzeugt den Regelobjektcode in dem obenbeschriebenen Format. Der Bereich der modifizierbaren Daten wird tatsächlich nur zur Laufzeit zugeordnet.
Eine Regel kann mehrere Datentypen einschließlich Konstanten, die Literalkonstanten in dem Programm sind oder von dem Übersetzer erzeugt werden, Namen von Ausnahmebehandlungsroutinen, globale (ungebundene) Namen wie etwa eine Regel oder eine lokale Variable und table.field-Namen enthalten. Der Übersetzer unterhält für jede Art von Datenposition namens CONSTANTS, EXCEPTIONS, SYMTAB bzw. TABLE_REFS eine Tabelle. Er unterhält außerdem eine als RELOCATION bekannte Tabelle, die ermöglicht, daß der Übersetzer formale Referenzen auf Datenpositionen auflöst.
Die CONSTANT-Tabelle enthält die folgenden Felder:
INDEX_PRIMARY KEY;
STRING_TEXT OF CONSTANT;
TYPE - Semantiktyp (immer "S");
SYNTAX - interne Darstellung;
LEN - Anzahl der Bytes;
DEC - Anzahl der Ziffern rechts von dem Dezimalkomma;
REAL_ADDRESS - Distanzadresse zu der Konstanten.
Somit kann das Objektcodeformat einer Konstanten aus der CONSTANTS-Tabelle erzeugt werden.
Die SYMTAB-Tabelle enthält Informationen über die Regeln wie etwa eine lokale Variable, Parameter und globale ungebundene Namen, die in der Regel direkt oder indirekt aufgerufen werden. Die Felder der SYMTAB-Tabelle umfassen:
IDENT - primärer Schlüssel (Identifizierername);
KIND - Parameter, lokal oder global;
REF - die Distanzadresse zu der Datenposition (negativ, falls ein indirekter Name);
INDEX - in der Art eindeutig (Schlüssel).
Die Parameter und die lokalen und globalen Größen können in dem Objektcodeformat wiederum aus der SYMTAB-Tabelle erzeugt werden. Die TABLE_REFS-Tabelle enthält Informationen über die table.field-Referenzen. Es sind folgende Felder enthalten:
INDEX - primärer Schlüssel;
TABLE_NAME - Name der Tabelle (Anführungszeichen, falls indirekt);
FIELD_NAME - Name des Felds (Anführungszeichen, falls indirekt);
REAL_ADDRESS - die Distanzadresse zu der Datenposition (negativ, falls einer der Namen indirekt ist).
Wieder ist zu sehen, daß die table.field-Referenzen in dem Objektcode aus dieser Tabelle erzeugt werden können.
Die RELOCATION-Tabelle enthält Informationen über "formale" Referenzen auf Datenobjekte. Sie wird verwendet, um diese Referenzen aufzulösen, sobald die Datenobjekte zugeordnet worden sind. Die RELOCATION-Tabelle umfaßt die folgenden Felder:
OCCUR_ADDR - die Distanzadresse zu der formalen Referenz;
TYPE - die Art der formalen Referenz (konstant, global, ...);
TABLE_INDEX - der Index auf die entsprechende Tabelle;
OFFSET - dieses enthält die Distanzadresse zu dem Objekt.
Sobald alle Datenobjekte zugeordnet worden sind, durchläuft der Übersetzer die RELOCATION-Tabelle und löst sämtliche Referenzen auf diese Objekte auf.
Die EXCEPTION-Tabelle enthält die folgenden Felder:
EX_NUM - der primäre Schlüssel;
IDENT - der Name der Ausnahme;
FORALL# - falls in einer until-Klausel die Schleifennummer, andernfalls null;
OFFSET - die Distanzadressendecodierung für die Behandlungsroutine;
TABLE NAME - der zugeordnete Tabellenname, sofern vorhanden;
TABLE OFFSET - die Distanzadresse zu dem Namen der Tabelle in dem Objektcode.
Die Namen der Ausnahmebehandlungsroutinen werden aus der EXCEPTIONS-Tabelle erzeugt. Falls der Behandlungsroutine ein Tabellenname zugeordnet ist, kann er auch aus dieser Tabelle erzeugt werden.
Der Rückübersetzer setzt den Code für die virtuelle Maschine in die Token-Darstellung der Regelsprache um. Die Algorithmenstruktur wird in die Regeln in dem objektorientierten Betriebssystem geschrieben. Sie setzt die Postfix-Form der Objektebenendarstellung in die Infix-Form der Regelsprache um. Der Rückübersetzer ist tabellengesteuert. Fast die gesamte Objektcodestruktur ist in Tabellen codiert, auf die der Rückübersetzer Bezug nimmt.
Für die Umsetzung aus Postfix in Infix verwendet der Rückübersetzer mehrere Stapel.
Der Rückübersetzer ist im wesentlichen eine Stapelmaschine. Anstatt Postfix-Code auszuführen, transformiert er ihn in seine Token-Darstellung. Jeder Opcode bewirkt die Manipulation des internen Stapels des Rückübersetzers. Sobald der Opcode für die linke Seite einer Anweisung erreicht ist, wird der Inhalt des Stapels oder der Stapel in die Token-Tabelle verschoben. Der Rückübersetzer unterhält drei Stapel, die in Einklang arbeiten, wobei sie in den entsprechenden Tabellen identifiziert werden. Die erste ist die DET. STACK-Tabelle. Die Objekte werden während des Durchsuchens jedes Opcodes in diesen Stapel geschoben. Da die Stapelelemente zwischen den Markierungen als ein Element verschoben werden, ist er ein markierter Stapel. Die DET.STACK-Tabelle umfaßt die folgenden Felder:
INDEX - primärer Schlüssel;
TYPE - der Rückübersetzungstyp (Parameter, Konstante, table.field-Referenz, ...);
OFFSET - die Distanzadresse zu der Datenposition in dem Bereich der statischen Daten;
ITEM - Symboltext;
SUBTYPE - dies ist der Übersetzertyp (Operator, reserviertes Wort, ...).
Die nächste Tabelle ist als die DET_PRED_ST-Tabelle bekannt. Diese Tabelle enthält die Priorität einer Position des DET.STACK. Es sind folgende Felder enthalten:
INDEX - primärer Schlüssel;
PRECEDENCE - die Priorität der Position.
Der abschließende Stapel wird in der DET_WORKAREA-Tabelle identifiziert. In dieser Tabelle werden Positionen aus der DET_STACK-Tabelle angeordnet. Sie hilft während des Umsetzens aus Postfix in Infix. Die Positionen werden aus dem DET_WORKAREA in den DET_STACK zurück übertragen. Sie enthält die gleichen Felder wie die DET_STACK-Tabelle.
In den Fig. 18-21E ist ein Beispiel der Rückübersetzung gezeigt. Die Quelle für die Rückübersetzung ist L = 1 + 2; das Objekt ist wie folgt: 1: @CONST 1, 2: @CONST 2, 3: @ADD, 4: @SETL L.
Der erste Schritt ist in Fig. 18 gezeigt. Der Wert "1" wird mit dem Merker X zur Angabe eines Randelements in den DET_STACK eingesetzt. Der DET_PRED_ST wird mit der Priorität 10 des ersten Datenelements gefüllt. Der DET_WORKAREA ist leer.
Der nächste Schritt ist in Fig. 19 gezeigt. In diesem Schritt wird die Wertekonstante 2 als ein Element des DET STACK eingegeben, wobei ihre Priorität in dem DET_PRED_ST als ein Wert 10 eingestellt wird. Der Arbeitsbereich bleibt leer. In dem nächsten Schritt tritt der @ADD-Operator auf. In diesem Schritt wird die Konstante 2 in den Arbeitsbereich verschoben, während ihre Priorität aus dem Stapel entfernt wird. Als nächstes wird der "+"-Operator zu dem Arbeitsbereichsstapel als Teil des Elements, das die 2 enthält, hinzugefügt. Schließlich wird die Konstante 1 als Teil des gleichen Elements wie die Konstante 2 und das "+', aus dem Stapel in den Arbeitsbereich verschoben. Diese Schritte sind in den Fig. 20A, 20B und 20C aufeinanderfolgend gezeigt.
In Fig. 21A wird der Inhalt des Arbeitsbereichs zurück in den Hauptstapel übertragen. In den Fig. 21B, 21C, 21D und 21E wird die TOKENS-Tabelle gefüllt. Dies geschieht als Antwort auf den @SETL-Opcode, der, wie in Fig. 21B gezeigt ist, das erste und das zweite Token einsetzt. Somit werden die Felder der Tokenstabelle für das erste Token mit dem Wert L, einem Identifizierer I, gefüllt. Er ist ein Einzeichenstring mit null Stellen rechts von dem Dezimalkomma. Er ist kein Teil einer table.field-Referenz. Der nächste Eintrag 2 ist das Gleichheitszeichen. Es ist ein Operator mit einer Länge von einem Zeichen ohne Punkt rechts vom Dezimalkomma und kein Teil einer table.field-Referenz. Der Inhalt des Stapels wird dann so in dem Arbeitsbereich in die Infix-Form, in der er in der in Fig. 21C gezeigten Regelsprache erscheint, umgeordnet. Wie in Fig. 21D gezeigt ist, wird schließlich aus den Arbeitsbereichseinträgen die Symmetrie der TOKENS-Tabelle aufgebaut. Die 1 wird dem oberen Ende des Arbeitsbereichs entnommen und als der dritte Eintrag in die TOKENS-Tabelle eingesetzt. Der "+"-Operator wird als der vierte Eintrag eingesetzt. Die Konstante 2 wird als der fünfte Eintrag eingesetzt, während das "; ", das das Zeilenende ist, als der letzte Eintrag eingesetzt wird. Nachdem dies geschehen ist, werden der Stapel, die Prioritätstabelle und der Arbeitsbereich, wie in Fig. 21E gezeigt ist, gelöscht.
Das Übersetzer/Rückübersetzer-Paar schafft die Einrichtung zum Unterhalten nur einer einzigen Version oder Darstellung irgendeines gegebenen Programms in dem Computer. In dem sekundären Speichermedium wird nur die Objektcodeversion eines Programms gespeichert. Die Quellcodeversion wird nur bei Bedarf durch das Rückübersetzen aus dem Objektcode erzeugt. Die Objektcodeversion enthält alle erforderlichen Informationen zum Unterstützen des Rückübersetzungsverfahrens. Dies schafft wesentliche Verringerungen der Wartungskosten, da kein Aufwand zum Sicherstellen der Synchronisierung der Quell- und Objektcodeversionen der Programme aufgebracht wird. Da nur die Objektcodeversion gespeichert werden muß, wird der Bedarf an dem sekundären Speicher reduziert. Weiter könnten mehrere Übersetzer/Rückübersetzer-Paare realisiert werden, so daß das gleiche Programm für verschiedene Programmierer verschieden dargestellt werden kann. Der Gebrauch dieses Verfahrens würde die Realisierung der Regelsprache in mehreren verschiedenen gesprochenen Sprachen wie französisch, deutsch oder englisch, eine andere graphische oder diagrammatische Darstellung der Programmstrukturen oder die Darstellung in anderen Kommunikationsmedien, z. B., sichtbar oder durch Schall, ermöglichen.

Claims

1. Programmierbarer Computer zum Ausführen einer Regel, wobei der Computer enthält:

eine Einrichtung zum Speichern der Regel, wobei die Regel enthält:

i) einen Regelnamen für die Regel sowie eine Menge von Parametern, durch die der Computer Eingangsdaten für die Regel bereitstellt,

ii) eine Menge von Bedingungen in Form logischer Ausdrücke, wovon jeder einen Boolschen Wert wahr oder falsch hat, wobei einer der Boolschen Werte ein erster Boolscher Wert ist und der andere ein zweiter Boolscher Wert ist, und

iii) eine Menge von Aktionen in Form ausführbarer Anweisungen;

iv) ein Mittel zum Zuordnen jeder gegebenen Bedingung aus der Menge von Bedingungen an eine gegebene geordnete Untermenge von Aktionen aus der Menge von Aktionen; wobei der Computer ferner enthält:

eine Einrichtung, die mit der Speichereinrichtung gekoppelt ist, um nacheinander die Menge von Bedingungen für die jeweiligen Boolschen Werte der Bedingungen in der Menge während der Ausführung der Regel durch den Computer auszuwerten und um die Boolschen Werte anzugeben; und

eine Einrichtung, die an die Auswerteeinrichtung so gekoppelt ist, daß sie auf diese antwortet, um als Antwort auf die Angabe des ersten Boolschen Werts für die der ersten Untermenge von Aktionen zugeordnete gegebene Bedingung der Reihe nach eine erste Untermenge von Aktionen durch die Auswerteeinrichtung auszuführen.

2. Computer nach Anspruch 1, wobei:

die Regel ferner eine Menge von Ausnahmen enthält, wovon jede einen mit einer Menge von Ausnahmeaktionen gekoppelten Ausnahmenamen enthält; wobei der Computer ferner enthält:

eine Einrichtung, die an die Ausführungseinrichtung gekoppelt ist, um während der Ausführung der Regel Ausnahmen zu erfassen und als Antwort auf die Erfassung eines gegebenen Ausnahmeereignisses einen das gegebene Ausnahmeereignis identifizierenden Ausnahmenamen zurückzuleiten; und

eine Einrichtung, die an die Speichereinrichtung gekoppelt ist und auf die Rückleitung eines gegebenen Ausnahmenamens durch die Erfassungseinrichtung anspricht, um dann, wenn der gegebene Ausnahmename der Name einer Ausnahme in der Menge von Ausnahmen ist, die Menge von Ausnahmeaktionen, die mit dem gegebenen Ausnahmenamen gekoppelt sind, auszuführen.

3. Computer nach Anspruch 2, wobei die Zuordnungseinrichtung eine zeichnerische Darstellung von Bedingungen und Aktionen durch objektcodierte Regelbefehle umfaßt, die enthalten:

jede Bedingung, die zugeordnete Aktionen einschließlich einer Reihe von Instanzen eines ersten Befehls (@ACALL) besitzt, wovon die Ausführung die Ausführung eines Sprungs zu einer der momentanen Bedingung zugeordneten gegebenen Aktion bewirkt;

jede Aktion, die in einem zweiten Befehl (@ARETURN) endet, wovon die Ausführung die Ausführung einer Rückkehr von der Ausführung der gegebenen Aktion zu einem Punkt, an dem die gegebene Aktion aufgerufen wurde, bewirkt;

einen fünften Befehl (@SIGNAL), dessen Ausführung ein Ausnahmeereignis erzeugt und einen Namen des erzeugten Ausnahmeereignisses spezifiziert.

4. Computer nach Anspruch 2, wobei der Computer eine Einrichtung zum Betreiben eines virtuellen Stapels entsprechend objektcodierter Befehle, die in einer Opcode-Tabelle innerhalb des Computers gespeichert sind, enthält.

5. Computer nach Anspruch 2, ferner mit:

einer Texteingabeeinrichtung zum Eingeben von Text der Regel einschließlich des Texts des Regelnamens, der Parameter, der Bedingungen, Aktionen und Ausnahmen;

eine Einrichtung zum grammatischen Auswerten des Texts der Regel und zum Angeben der grammatischen Richtigkeit oder Unrichtigkeit der Regel;

eine Einrichtung, die auf die Angabe von der Einrichtung zum grammatischen Auswerten der grammatischen Richtigkeit eine ausführbare Darstellung der Regel erzeugt;

wobei die Einrichtung zum grammatischen Auswerten den Text der Regel in Übereinstimmung mit der Grammatik auswertet, die in einer Backus-Naur-Form in Übereinstimmung mit der Regelsyntax-Tabelle der obigen genauen Beschreibung definiert ist.

6. Computer nach Anspruch 1, ferner mit:

einer Texteingabeeinrichtung zum Eingeben von Text, der den Regelnamen, die Menge von Parametern; die Menge von Bedingungen und die Menge von Aktionen angibt;

eine Anzeigeeinrichtung, die mit der Texteingabeeinrichtung gekoppelt ist, um

i) den Text, der den Regelnamen und die Menge von Parametern angibt, als eine Textzeile anzuzeigen,

ii) den Text, der jede Bedingung aus der Menge von Bedingungen angibt, als eine Zeile aus Bedingungstext und die jeweiligen Zeilen des Bedingungstexts als eine Spalte anzuzeigen, und

iii) den Text, der jede Aktion aus der Menge von Aktionen angibt, als eine Zeile aus Aktionstext und die jeweiligen Zeilen aus Aktionstext als eine Spalte anzuzeigen;

eine Einrichtung, die mit der Texteingabeeinrichtung gekoppelt ist, um einen Ja/Nein-Quadranten aus Boolschen Indikatoren zu erzeugen und anzuzeigen, die in Ja/Nein-Zeilen, wovon jede eindeutig einer Zeile aus Bedingungstext und der entsprechenden Bedingung zugeordnet ist, und in Ja/Nein-Spalten, wovon jede genau einen Indikator des ersten Boolschen Wertes enthält, angeordnet sind, wobei der genau eine Indika tor, der sich in einer Ja/Nein-Zeile befindet, eine der Bedingungen eindeutig mit der gegebenen Ja/Nein-Spalte in der Weise koppelt, daß jede Bedingung eindeutig mit genau einer Ja/Nein- Spalte gekoppelt ist; und

eine Einrichtung, die mit der Erzeugungseinrichtung gekoppelt ist, um Aktionsfolgenummern in einem Aktionsquadranten anzunehmen und anzuzeigen, der in Aktionszeilen, wovon jede eindeutig einer Zeile aus Aktionstext und dessen Aktion zugeordnet ist, und in Aktionsspalten, wovon jede eindeutig einer Ja/Nein-Spalte und der mit der einen Ja/Nein-Spalte gekoppelten Bedingung zugeordnet ist, angeordnet ist, wobei jede gegebene Aktionsfolgenummer über ihre Aktionszeile und Aktionsspalte eine gegebene Aktion einer gegebenen Bedingung zuordnet, wobei die Aktionsfolgenummern in jeder Aktionsspalte die Untermenge von Aktionen definieren, die der gegebenen Bedingung zugeordnet sind, und wobei die Reihenfolge der Ausführung der Untermenge von Aktionen durch die relativen Größen der Aktionsfolgenummern in der gegebenen Aktionsspalte definiert sind.

7. Computer nach Anspruch 6, ferner mit:

der Texteingabeeinrichtung, die ferner der Eingabe von Text dient, der eine Menge von Ausnahmen angibt, wovon jede einen mit einer Menge von Ausnahmeaktionen gekoppelten Ausnahmenamen enthält, wobei die Anzeigeeinrichtung ferner Text der Menge von Ausnahmen anzeigt;

einer Einrichtung, die mit der Ausführungseinrichtung gekoppelt ist, um Ausnahmeereignisse während der Ausführung der Regel zu erfassen und als Antwort auf die Erfassung eines gegebenen Ausnahmeereignisses einen Ausnahmenamen, der das gegebene Ausnahmeereignis identifiziert, zurückzuleiten; und

einer Einrichtung, die mit der Speichereinrichtung gekoppelt ist und auf die Rückleitung eines gegebenen Ausnahmenamens durch die Erfassungseinrichtung anspricht, um dann, wenn sich der gegebene Ausnahmename in der Menge von Ausnahmen befindet, die Menge von Ausnahmeaktionen, die mit dem gegebenen Ausnahmenamen gekoppelt sind, auszuführen.

8. Computer nach Anspruch 1, wobei die Zuordnungseinrichtung die zeichnerische Darstellung von Bedingungen und Aktionen durch objektcodierte Regelbefehle umfaßt, die enthalten:

jede Bedingung, die zugeordnete Aktionen einschließlich einer Reihe von Instanzen eines ersten Befehls (@ACALL) besitzt, wovon die Ausführung die Ausführung eines Sprungs zu einer gegebenen Aktion, die der momentanen Bedingung zugeordnet ist, bewirkt;

jede Aktion, die in einem zweiten Befehl (@ARETURN) endet, wovon die Ausführung die Ausführung der Rückkehr von der Ausführung der gegebenen Aktion zu einem Punkt, an dem die gegebene Aktion aufgerufen wurde, bewirkt.

9. Computer nach Anspruch 8, wobei die objektcodierten Regelbefehle ferner enthalten:

einen dritten Befehl (@AEND), der nicht ausgeführt wird, der jedoch die Menge von Bedingungen von der Menge von Aktionen trennt.

10. Computer nach Anspruch 8, wobei der Computer eine Einrichtung zum Betreiben eines virtuellen Stapels enthält, der Daten hält, die ein erstes Datum (D1) und ein zweites Datum (D2) umfassen und objektcodierte Arithmetikbefehle an Daten im virtuellen Stapel ausführt, wobei die Arithmetikbefehle enthalten:

einen sechsten Befehl (@ADD), dessen Ausführung zwei Daten aus dem virtuellen Stapel entnimmt, die Addition der beiden Daten ausführt und die Summe in den virtuellen Stapel schiebt (D2 + D1);

einen siebten Befehl (@SUB), dessen Ausführung zwei Daten aus dem virtuellen Stapel entnimmt, die Subtraktion der beiden Daten ausführt und die Differenz in den virtuellen Stapel schiebt (D2 - D1);

einen achten Befehl (@MULT), dessen Ausführung zwei Daten aus dem virtuellen Stapel entnimmt, die Multiplikation der beiden Daten ausführt und das Produkt in den virtuellen Stapel schiebt (D2 · D1);

einen neunten Befehl (@DIV), dessen Ausführung zwei Daten aus dem virtuellen Stapel entnimmt, die Division der beiden Daten ausführt und den Quotienten in den virtuellen Stapel schiebt (D2/D1);

einen zehnten Befehl (@EXP), dessen Ausführung zwei Daten aus dem virtuellen Stapel entnimmt, die Exponenzierung der beiden Daten ausführt und das Ergebnis in den virtuellen Stapel schiebt (D2 ↑ D1);

einen elften Befehl (@UNM), dessen Ausführung ein Datum aus dem virtuellen Stapel entnimmt und die Negation des einen Datums in den virtuellen Stapel schiebt (-(D1)); und

einen zwölften Befehl (@CAT), dessen Ausführung zwei Daten aus dem virtuellen Stapel entnimmt, die Verknüpfung der beiden Daten ausführt und das verknüpfte Ergebnis in den virtuellen Stapel schiebt (D1D2).

11. Computer nach Anspruch 8, wobei der Computer eine Einrichtung zum Betreiben eines virtuellen Stapels enthält, der Daten hält und objektcodierte relationale Befehle an den Daten im virtuellen Stapel ausführt, wobei:

zur Ausführung eines gegebenen relationalen Befehls der Computer ein erstes Datum (D1) und ein zweites Datum (D2) aus dem virtuellen Stapel entnimmt und das erste Datum mit dem zweiten Datum in Übereinstimmung mit einer Relation vergleicht, die durch den gegebenen relationalen Befehl spezifiziert ist, und einen Boolschen Indikator des Ergebnisses des Vergleichs in den virtuellen Stapel schiebt, wobei die relationalen Befehle enthalten:

einen dreizehnten Befehl (@EQ), der das zweite Datum mit dem ersten Datum in bezug auf Gleichheit vergleicht (D2 = D1);

einen vierzehnten Befehl (@NE), der das zweite Datum mit dem ersten Datum in bezug auf Ungleichheit vergleicht (D2 ≠ D1);

einen fünfzehnten Befehl (@LT), der vergleicht, ob das zweite Datum kleiner als das erste Datum ist (D2 < D1);

einen sechzehnten Befehl (@LE), der vergleicht, ob das zweite Datum nicht größer als das erste Datum ist (D2 ≤ D1);

einen siebzehnten Befehl (@GT), der vergleicht, ob das zweite Datum größer als das erste Datum ist (D2 > D1);

einen achtzehnten Befehl (@GE), der vergleicht, ob das zweite Datum nicht kleiner als das erste Datum ist (D2 > D1).

12. Computer nach Anspruch 8, wobei der Computer eine Einrichtung zum Betreiben eines virtuellen Stapels enthält, der Daten hält, die ein erstes Datum (D1) und ein zweites Datum (D2) enthalten, und objektcodierte logische Befehle an den Daten im Stapel ausführt, wobei die logischen Befehle enthalten:

einen neunzehnten Befehl (@AND), dessen Ausführung ein erstes und ein zweites Datum aus dem virtuellen Stapel entnimmt und eine Boolsche Angabe, ob sowohl das erste Datum als auch das zweite Datum Wahr-Werte besitzen (D2 & D1), in den virtuellen Stapel schiebt;

einen zwanzigsten Befehl (@OR), dessen Ausführung ein erstes und ein zweites Datum aus dem virtuellen Stapel entnimmt und eine Boolsche Angabe, ob entweder das erste oder das zweite Datum oder beide einen Wahr-Wert besitzen (D2 v D1), in den virtuellen Stapel schiebt;

einen einundzwanzigsten Befehl (@NOT), dessen Ausführung ein erstes Datum aus dem virtuellen Stapel entnimmt und die Boolsche Inverse des ersten Datums (HD1) in den virtuellen Stapel schiebt.

13. Computer nach Anspruch 8, wobei der Computer eine Einrichtung zum Betreiben eines virtuellen Stapels enthält und eine Datenbank mit Tabellen hält und ein Tabellenzugriffsverfahren TAM enthält, das auf eine Tabelle zugreift, die in einer TAM- Parameterliste aufgeführt ist, wobei der Computer ferner objektcodierte Tabellensteuerbefehle in der Datenbank ausführt, wobei die Tabellensteuerbefehle enthalten:

einen zweiundzwanzigsten Befehl (@WFIELD), der ein gegebenes Feld in einer gegebenen Tabelle identifiziert und dessen Ausführung das gegebene Feld der gegebenen Tabelle in den virtuellen Stapel schiebt;

einen dreiundzwanzigsten Befehl (@RFIELD), der ein gegebenes Feld in einer gegebenen Tabelle identifiziert und dessen Ausführung

i) das gegebene Feld der gegebenen Tabelle in den virtuellen Stapel schiebt, falls die Inhalte des gegebenen Feldes einen zugewiesenen Wert enthalten, jedoch

ii) das Auftreten eines Ausnahmeereignisses bewirkt, falls Inhalte des gegebenen Feldes keinen zugewiesenen Wert enthalten, wodurch dem Computer gemeldet wird, daß, obwohl das gegebene Feld keinen zugewiesenen Wert besitzt, ein Versuch gemacht wurde, die Inhalte des Feldes zu verwenden;

einen vierundzwanzigsten Befehl (@SET), der ein gegebenes Feld in einer gegebenen Tabelle identifiziert und einen Wert spezifiziert, wobei die Ausführung des Befehls den Wert dem gegebenen Feld der gegebenen Tabelle zuweist;

einen fünfundzwanzigsten Befehl (@ABN), der einen Feldnamen und einen Wert angibt, wobei seine Ausführung den gegebenen Wert jedem Feld mit dem gegebenen Namen in allen Tabellen, die ein Feld mit dem gegebenen Namen enthalten, zuweist;

einen sechsundzwanzigsten Befehl (@TAM), der eine Tabellenzugriffsanforderung spezifiziert und dessen Ausführung das Tabellenzugriffsverfahren aufruft, um die spezifizierte Tabellenzugriffsanforderung auszuführen;

einen siebenundzwanzigsten Befehl (@TAMP), der einen Referenzparameter spezifiziert und dessen Ausführung den spezifizierten Referenzparameter in die TAM-Parameterliste einfügt; und

einen achtundzwanzigsten Befehl (@TAMN), der einen Tabellennamen spezifiziert und dessen Ausführung den spezifizierten Tabellennamen in die TAM-Parameterliste einfügt.

14. Computer nach Anspruch 1, ferner mit:

der Speichereinrichtung, die ferner mehrere der Regeln speichert, wobei in jeder der mehreren Regeln die Menge von Bedingungen eine geordnete Menge von Bedingungen in Form Boolscher Ausdrücke ist, wobei die geordnete Menge von Bedingungen eine letzte Bedingung enthält, die eine Voreinstellungsbedingung ist, die nicht in Form eines Boolschen Ausdrucks vorliegt, und wobei jede Bedingung eine Entsprechung mit einer der Mengen von Aktionen hat;

einem virtuellen Stapel;

einer Einrichtung zum Schieben von Daten in den virtuellen Stapel und zum Entnehmen von Daten aus dem virtuellen Stapel, wobei die Daten Parameterdaten für eine Regel sein können und Null-Daten sein können;

einer Aufrufeinrichtung, die mit der Schiebe- und Entnahmeeinrichtung gekoppelt ist, um eine nächste Regel für die Ausführung aufzurufen (bei @CALL);

einer Eingabeeinrichtung, die auf die Aufrufeinrichtung anspricht, um das erste Datum aus dem virtuellen Stapel in einen ersten Eingangsparameter der nächsten Regel zu entnehmen, wobei irgendeine momentane Regel eine frühere Regel wird und die nächste Regel eine momentane Regel wird;

wobei die Einrichtung zum Auswerten in Abhängigkeit von Inhalten der momentanen Bedingung

i) einen Vergleich des ersten Datums mit einem Wert ausführt (bei @EQ, @NE, @LT, @LE, @GT oder @GE),

ii) einen Aufruf der Aufrufeinrichtung zum Auswerten einer Regel als eine nächste Regel ausführt und bei Abschluß der nächsten Regel eine Rückkehr zur momentanen Regel ausführt (bei @CALL), und/oder

iii) eine Arithmetik ausführt (bei @ADD, @SUB, @MULT, @DIV oder @EXP);

wobei die Einrichtung zum sequentiellen Ausführen die Menge von Aktionen, die der momentanen Bedingung entspricht, bei der auf den ersten Boolschen Wert ausgewerteten momentanen Bedingung kontingent ausführt, wobei die Ausführung jeder Aktion in Abhängigkeit von den Inhalten dieser Aktion enthalten kann:

i) Ausführen einer Arithmetik (bei @ADD, @SUB, @MULT, @DIV, @EXP),

ii) Aufrufen der Schiebe- und Entnahmeeinrichtung, um ein Datum in den virtuellen Stapel zu schieben oder aus diesem zu entnehmen,

iii) Ausführen relationaler Operationen (bei @AND, @OR oder @NOT),

iv) Aufrufen der Aufrufeinrichtung, um eine Regel als eine nächste Regel auszuwerten und eine Rückkehr zu einem momentanen Punkt der Aktionsausführung in der momentanen Regel bei Abschluß der nächsten Regel auszuführen (bei @CALL), und/oder

v) Aufrufen der Aufrufeinrichtung, um die Ausführung der momentanen Regel zu beenden und um zur Ausführung einer vorhergehenden Regel zurückzukehren (bei @RETURN);

einer Einrichtung, die mit der Auswerteeinrichtung und mit der Ausführungseinrichtung gekoppelt ist, um die Voreinstellungsbedingung als die momentane Bedingung anzugeben, falls sämtliche anderen Bedingungen in der Menge auf denselben Boolschen Wert ausgewertet werden, um die Ausführung der Menge von Aktionen, die der Voreinstellungsbedingung entspricht, durch die Ausführungseinrichtung anzuregen, wobei stets auf den ersten Boolschen Wert ausgewertet wird; und

einer Einrichtung, die als Antwort auf die Auswerteeinrichtung die Aufrufeinrichtung aufruft, um die Ausführung (bei @RETURN) der momentanen Regel zu beenden und zur Ausführung einer früheren Regel zurückzukehren, nachdem eine Bedingung in der Regel auf den ersten Boolschen Wert ausgewertet worden ist und die Aktionen dieser Bedingung ausgeführt worden sind.

15. Computer nach Anspruch 14, wobei im Computer Ausnahmeereignisse auftreten und wobei jede Regel ferner 4) eine optionale Mehrzahl von Ausführungsbehandlungsroutinen enthält, wovon jede so beschaffen ist, daß sie ein gegebenes Ausnahmeereignis behandelt, wobei jede Ausführungsbehandlungsroutine einen Namen und eine optionale Menge von Ausnahmeaktionen in Form ausführbarer Anweisungen besitzt, deren Inhalt dem Inhalt der Aktionen in der Menge von Aktionen ähnlich ist, die den Bedingungen der Regel entsprechen, wobei der Computer ferner enthält:

eine Einrichtung zum Erfassen eines Ausnahmeereignisses während der Ausführung der Aktionen oder der Auswertung der Bedingungen;

eine Einrichtung, die als Antwort auf die Erfassungseinrichtung prüft, ob irgendeine Ausnahmebehandlungsroutine in der momentanen Regel so beschaffen ist, daß sie das erfaßte Ausnahmeereignis behandelt;

eine Einrichtung, die als Antwort auf die Prüfeinrichtung die Ausführung durch die Ausführungseinrichtung der Ausnahmeaktionen der gegebenen Ausnahmebehandlungsroutine, für die die Prüfung ergeben hat, daß sie so beschaffen ist, daß sie das erfaßte Ausnahmeergebnis behandelt, aufruft.

16. Verfahren zum Programmieren eines Computers zum Ausführen einer Regel, mit den folgenden Schritten:

erstes Eingeben eines Regelnamens für die Regel und einer Menge von Parametern, durch die der Computer Eingangsdaten für die Regel bereitstellen kann;

zweites Eingeben einer Menge von Bedingungen in Form logischer Ausdrücke für die Regel, wovon jeder den Boolschen Wert wahr oder falsch besitzt, wobei einer der Boolschen Werte ein erster Boolscher Wert ist und ein anderer ein zweiter Boolscher Wert ist;

drittes Eingeben mehrerer Mengen von Aktionen in Form ausführbarer Anweisungen für die Regel;

erstes Angeben einer Eins-Zu-Eins-Zuordnung jeder einzelnen Menge von Aktionen zu einer einzelnen Bedingung, um zu spezifizieren, daß bei einer gegebenen Bedingung, die auf den ersten Boolschen Wert ausgewertet wird, der Computer die einzelne Menge von Aktionen, die der gegebenen Bedingung zugeordnet ist, ausführen soll.

17. Verfahren nach Anspruch 16, ferner mit den folgenden Schritten:

viertes Eingeben einer Menge von Ausnahmenamen;

fünftes Eingeben mehrerer Mengen von Ausnahmeaktionen in Form ausführbarer Anweisungen;

zweites Angeben einer Eins-Zu-Eins-Zuordnung jeder einzelnen Menge von Ausnahmeaktionen zu einzelnen Ausnahmenamen, um zu spezifizieren, daß der Computer dann, wenn er ein Ausnahmeereignis erfaßt und einen Ausnahmenamen zurückleitet, sofern der zurückgeleitete Ausnahmename in der Menge von Ausnahmenamen enthalten ist, die Menge von Ausnahmeaktionen, die dem zurückgeleiteten Ausnahmenamen zugeordnet sind, ausführt.

18. Verfahren nach Anspruch 16, bei dem:

der erste Angabeschritt einer Untermenge der Aktionen erlaubt, nicht irgendeiner Bedingung zugeordnet zu werden, die die Voreinstellungsbedingung enthält, um zu spezifizieren, daß der Computer niemals die eine Untermenge von Aktionen ausführen soll, damit die eine Untermenge von Aktionen in der. Regel verbleiben kann, ohne die Ausführung der Regel zu beeinflussen.

19. Verfahren nach Anspruch 16, bei dem:

der Schritt des zweiten Eingebens eine Liste von Bedingungen in Form logischer Ausdrücke eingibt, die während der Ausführung der Regel sequentiell auf ihre Wahrheitswerte ausgewertet werden sollen, wobei die logischen Ausdrücke entweder einen wahren Wert oder einen falschen Wert zurückleiten;

der Schritt des dritten Eingebens eine Liste von Aktionen in Form ausführbarer Anweisungen eingibt, wovon jede mit einer oder mehreren entsprechenden Bedingungen in der Liste von Bedingungen gekoppelt ist, um als Antwort auf die Auswertung der entsprechenden Bedingungen ausgeführt zu werden; und

wobei das Verfahren ferner den folgenden Schritt enthält:

Definieren eines Ja/Nein-Quadranten im Computer, indem für eine gegebene Bedingung der Ja/Nein-Quadrant eine Spalte für jede Folge aus einer oder mehreren Aktionen, die als Antwort auf eine Auswertung auszuführen ist, die einen wahren Wert zurückleitet, sowie eine Spalte für jede Folge aus einer oder mehreren Aktionen, die als Antwort auf eine Auswertung ausgeführt werden soll, die einen falschen Wert zurückleitet, enthält, wobei jede Aktion eine Folgenummer in der Spalte der gegebenen Bedingung besitzt, die ihre Position in der Folge von Aktionen angibt.

20. Verfahren nach Anspruch 19, ferner mit dem folgenden Schritt:

viertes Eingeben eines Ausnahmenamens, gefolgt von einer Folge von Aktionen, die ausgeführt werden sollen, falls das Ausnahmeereignis, das durch den Ausnahmenamen identifiziert wird, durch den Computer während der Ausführung einer Regel erfaßt wird.

21. Verfahren zum Ausführen einer Regel durch einen Computer, wobei die Regel enthält: 1) einen Regelnamen, 2) eine Menge von Bedingungen in Form logischer Ausdrücke, wovon jeder einen Boolschen Wert wahr oder falsch besitzt, wobei einer der Boolschen Werte ein erster Boolscher Wert ist und der andere ein zweiter Boolscher Wert ist, 3) mehrere Mengen von Aktionen in Form ausführbarer Anweisungen, wovon die einzelnen Mengen von Aktionen eine Eins-Zu-Eins-Zuordnung zu einzelnen Bedingungen besitzen, wobei das Verfahren die folgenden Schritte enthält:

Beginnen einer Auswertung der Menge von Bedingungen bei einer ersten momentanen Bedingung;

Auswerten des Boolschen Wertes der momentanen Bedingung; falls die momentane Bedingung auf

i) den ersten Boolschen Wert ausgewertet wird, Ausführen der Menge von Aktionen, die der momentanen Bedingung zugeordnet sind, und Verlassen der Ausführung der Regel,

ii) den zweiten Boolschen Wert ausgewertet wird, Ändern einer nächsten Bedingung in eine momentane Bedingung in kontingenter Weise, wenn Bedingungen in der Menge von Bedin gungen vorhanden sind, die noch nicht ausgewertet worden sind, andernfalls Verlassen der Ausführung der Regel; und

Zurückkehren zum Auswertungsschritt.

22. Verfahren nach Anspruch 21, bei dem die Regel ferner enthält: 4) eine Menge von Ausnahmebehandlungsroutinen, wovon jede einen Ausnahmenamen und eine Menge von Ausnahmeaktionen in Form ausführbarer Anweisungen enthält, wobei das Verfahren ferner die folgenden Schritte enthält:

Erfassen eines Ausnahmeereignisses während der Ausführung der Regel;

Spezifizieren eines Namens des erfaßten Ausnahmeereignisses für die Regel;

Bestimmen, ob der spezifizierte Name des erfaßten Ausnahmeereignisses mit dem Namen irgendeiner der Ausnahmebehandlungsroutinen übereinstimmt;

Ausführen der Menge von Ausnahmeaktionen einer Ausnahmebehandlungsroutine, deren Name mit demjenigen des erfaßten Ausnahmeereignisses übereinstimmt, falls das Vorhandensein irgendeiner Übereinstimmung festgestellt wird; und

Verlassen der Ausführung der Regel.

23. Verfahren nach Anspruch 21, bei dem der Computer eine Einrichtung zum Betreiben eines virtuellen Stapels enthält, der Daten und Adressen hält, und:

der Unterschritt i) des Ausführens der Menge von Aktionen, die der momentanen Bedingung zugeordnet ist, ferner für die Ausführung jeder Aktion in der Menge enthält:

a) Ausführen eines ersten Verzweigungsbefehls (@ACALL), der eine Adresse eines Befehls, der dem ersten Verzweigungsbefehl unmittelbar folgt, in den virtuellen Stapel schiebt und eine Adresse eines ersten Aktionsbefehls einer gegebenen einzelnen Menge von Aktionen, zu dem die Ausführung durch den Computer dann verzweigt, spezifiziert,

b) Ausführen eines zweiten Verzweigungsbefehls (@ARETURN), der aus dem virtuellen Stapel die Adresse des dem ersten Verzweigungsbefehl unmittelbar folgenden Befehls, zu dem die Adressenausführung durch den Computer dann zurückkehrt, entnimmt;

wobei der erste und der zweite Verzweigungsbefehl ermöglichen, daß sich in den Mengen von Aktionen, die mehreren Bedingungen zugeordnet sind, eine einzige Kopie einer gegebenen Aktion befindet.

24. Verfahren nach Anspruch 23, bei dem die Unterschritte des Verlassens der Ausführung der Regel den folgenden Schritt enthalten:

Ausführen eines dritten Befehls (@RETURN), wobei die Ausführung die Ausführung einer Rückkehr von der Regel zu einem Punkt der Ausführung, an dem die Regel aufgerufen wurde, bewirkt; und

die Aktionen, die der momentanen Bedingung zugeordnet sind, durch eine Reihe aufeinanderfolgender erster Verzweigungsbefehle (@ACALLs) aufgerufen werden, wobei der Reihe unmittelbar der dritte Befehl (@RETURN) folgt.