Schlüsseltabellen

Die Tabelle CLAS wurde um eine Klasse REF - Schlüsseltabelle ergänzt. Siehe dazu MDB Änderung 1. Schlüsseltabellendefinitionen können in der MDB als generierbare Ressourcen markiert werden. Wenn dieser Bausteintyp als solches markiert ist, erscheinen die Schlüsseltabellendefinitionen in TaaGen als generierbare Ressourcen, und ist außerdem die Möglichkeit, sämtliche solche Bausteine zu generieren, aktiviert.

Der TAA Ressourcenviewer wurde um die Anzeige von Schlüsseltabellendefinitionen erweitert.

Über einen neuen InterfEdge-Befehl DSTRIMP können Schlüsseltabellendefinitionen sowie deren Inhalte (für Inhalte siehe die dazu gehörende MDB-Änderung) von Rochade gezielt in das EDB-Schattenverzeichnis exportiert werden. Bisher passierte dies als Nebeneffekt bestimmter Bearbeitungsoptionen von RefEdge. Mit diesem Feature lassen sich die Rochadedaten und das Schattenverzeichnis im Rahmen vom Konfigurationsmanagement kontrollierter verwalten.

Die Schlüsseltabellenzugriffsroutinen laufen in Abstimmung mit dem neuen Connecthandler um einen reibungslosen Einsatz der Schlüsseltabellenzugriffe unter sämtlichen Umgebungsbedingungen sicherzustellen. Der Connecthandler wurde ergänzt um notwendige Möglichkeiten für ReadOnly-Zugriffe auf einer MS-Access Datenbank. Die Schlüsseltabellendatenbank läßt sich vollständig, auch ohne vorregistrierte ODBC-Datenquelle, in der TAA Datenbank Konfiguration registrieren.

Die Klassen für Datenstruktur- und Datenelementdefinitionen wurden um folgende schlüsseltabellenspezifischen Eigenschaften erweitert:

• DstrRefTableName: liefert den Tabellennamen für die Schlüsseltabelle gemäß Namensgebungskonvention T<Anwendungskürzel><Schlüsseltabelle>. So ergibt sich bspw. für die Schlüsseltabelle SGT im Anwendungssystem VO den Tabellennamen TVOSGT.
• DstrItemSqlType: beschreibt den SQL C Datentyp, der am ehesten für die ODBC Übertragung dieses Elementes geeignet ist.
• DstrItemSqlLength: beschreibt die notwendige Pufferlänge um das Datenelement mit dem vorgeschlagenen Datentyp in ODBC-Queris zu binden.
• DstrItemIsNumeric: zur schnelleren Feststellung, ob das Datenformat ein numerisches ist.
• DstrItemIsGroup: zur schnelleren feststellung, od das Datenelement eine Gruppenstufe oder ein elementares Item ist.

Schlüsseltabellen können keine subscripted und redefined Datenelemente beinhalten. Diese Überprüfung wurde an den bestehenden Routinen hinzugefügt.

Der Objectmanager (taaOmObj) ist in der Lage, Objekte der Klasse REF zu deklarieren. Für solche Objekte wird ein Objekttyp (OBJT) simuliert, die Datenstruktur wird aus der Schlüsseltabellendefinition geladen.

Die feldweisen Zugriffsroutinen des Objektmanagers wurden um Routinen zur effizienten Übertragung von SQL C Datentypen in den COBOL-basierten Datenbereichen der TAA Objekten (PutFldSqlType), sowie um Routinen zur effizienten Übertragung von COBOL-basierten Datenbereichen der TAA Objekten in den SQL C Datentypen (GetFldSqlType) restrukturiert und ergänzt.

Die Schlüsseltabellenzugriffsroutinen (taaRefDB) unterstützen eine neue Methode (ObjCompleteRef) eine Schlüsseltabelle vollständig in ein Datenobjekt zu übertragen oder wahlweise die vorhandenen unvollständigen Angaben im Datenobjekt zu ergänzen um Inhalte der Schlüsseltabelle. Dazu werden die Key-Felder im Datenobjekt ausgewertet und als Suchkriterien für den Tabellenzugriff genutzt. Die Ergebnismenge kann, bei unvollständigen oder nicht eindeutigen Schlüsseln, größer sein als die Ausgangsmenge.

Der Objectmanager (taaOmObj) bietet eine neue Methode (CompleteRef), um ein (Mengen)objekt der Klasse REF mit Daten aus einer Schlüsseltabelle zu ergänzen, oder die Schlüsseltabelle vollständig zu laden.

Die TAA ISAPI-Extension kennt einen Befehl tref zum Laden einer gesamten Schlüsseltabelle in XML-Format.

Die TAA ISAPI-Extension kann Dateien simulieren, die on-the-fly erstellt werden, oder aus serverseitig gespeicherten Zwischenergebnissen stammen. So kann das Laden einer Schlüsseltabelle (bspw. SGT aus der Anwendung VO) mit folgender URL geladen werden: http://<www.domain.de>/<pathspec>/vo/sgt.trf. Ob die Daten tatsächlich aus der Schlüsseltabelle geladen werden, oder aus einer früheren serverseitig gespeicherten Abfrage geliefert werden, kann dynamisch entschieden werden (noch nicht implementiert).

Die TAA ISAPI-Extension unterstützt clientseitiges Caching für HTTP/1.0 und HTTP/1.1 über die HTTP-Header Pragma, Expires, Cache-Control/max-age, If-Modified-Since, Last-Modified und Date.

Der Befehl dstr der TAA ISAPI-Extensionunterstützt jetzt auch die Lieferung von Definitionen für Schlüsseltabellen.

Datenstrukturen, Objekttypstrukturen und Schlüsseltabellendefinitionen können auch als virtuelle Datei durch die TAA ISAPI-Extension geliefert werden. Der benutzte Suffix ist dst für Datenstrukturen, ost für Objekttypstrukturen und stb für Schlüsseltabellendefinitionen. Die letzten beiden Komponenten der Pfadangabe werden als Anwendung und Name benutzt, bspw. zum Laden der Schlüsseltabellendefinition für die Tabelle SGT aus der Anwendung VO kann folgende URL benutzt werden:http://<www.domain.de>/<pathspec>/vo/sgt.stb. Auch hierzu wird clientseitiges Caching für HTTP/1.0 und HTTP/1.1 unterstützt. Die Alterung der Ergebnisdaten können über die Registry (Config\MaxAgeDstr) gesteuert werden. Die Standardvorgabe beträgt zwölf Stunden. Die Vorgabe wird in Minuten gemacht. Eine explizite Vorgabe von 0 (Null) bedeutet, dass kein clientseitiges Caching angewandt werden darf.

Die TAA-Infrastruktur kann die Aufrufe von Schlüsseltabellenzugriffsmodulen simulieren und selbst die entsprechenden Zugriffe durchführen. Dafür müssen folgende Voraussetzungen erfüllt sein:

• In der TAA Datenbank Konfiguration muss für die Datenbank, die die Schlüsseltabellen enthält, der Eintrag ExecuteInternal = 1 gesetzt sein.
• Die Modulschnittstelle muss folgende Eigenschaften aufweisen: DBName-Eigenschaft verweist auf Schlüsseltabellen-Datenbank, Modulname = Name des einzigen Parameters.
• Das aufgelöste Ereignis muss „Lesen“ sein.
• Es muss eine Schlüsseltabellendefinition in den Ressourcen-DLLs gefunden werden mit dem Namen, der aus der 5. bis letzten Stelle des Namens des Parameterobjekts abgeleitet wird.

Das Verhalten der bisher eingesetzten COBOL-Zugriffsmodule wird möglichst genau simuliert; der Inhalt des Parameterobjekts ist nach dem Zugriff gleich. Einzige Einschränkung: Es dürfen beim Zugriff über ExecuteInternal nicht zwei Zugriffstypen gemischt werden, d.h. es können nicht in einem Modulaufruf sowohl die gesamte Tabelle als auch einzelne Sätze aus der Tabelle gelesen werden.

Zur Optimierung des Laufzeitverhaltens kann die TAA-Infrastruktur Schlüsseltabellenzugriffe cachen, und zwar sowohl Zugriffe auf Einzelsätze als auch ganze Tabellen. Um dieses Feature zu aktivieren, muss in der TAA Datenbank Konfiguration für die Datenbank, die die Schlüsseltabellen enthält, der Eintrag Caching = 1 gesetzt sein (s. auch hier). Ausnahme: Wenn für einen Zugriff mit Schlüssel mehr als 1 Satz als Ergebnis geliefert wird, werden diese nicht gecacht.

Der COBOL-Preprozessor unterstützt die Anweisung EXEC TAA COMPLETEREF für das Lesen des Inhalts einer Schlüsseltabelle (ohne simulierten Modulaufruf, s. unten), entsprechend der oben beschriebenen Methode objCompleteRef. Die Angaben Caching oder LoadStbcFromRes in der dbConfig-Section der Registry sind auch hierbei wirksam. Eine Beschreibung der genauen Syntax finden Sie in der COBOL-Hilfe.

In COBOL werden Modulaufrufe, die folgende Voraussetzungen erfüllen, als Schlüsseltabellen-Zugriffe intern ausgeführt:

• Der Name des einzigen Parameters muss identisch sein mit dem Namen des Moduls.
• Das ausgelöste Event ist LESEN.
• Die Beschreibung der Schlüsseltabelle ist als Ressource vorhanden.
• In der dbConfig-Section der Registry für die Referenzdatenbank ist ExecuteInternal=1.
• Der Kurzname der Schlüsseltabelle ist nicht in dem Registry-Settings $stbExclude enthalten.

Trifft eine dieser Voraussetzungen nicht zu, wird wie gehabt das in der Ispc angegebene Modul aufgerufen. Zur Kontrolle wird bei intern ausgeführten Modulen im TAA-Monitor eine Meldung vom Typ „Architecture Trace“ ausgegeben.

Wenn in der dbConfig-Section für die Referenzdatenbank zusätzlich der Wert Caching=1 gesetzt wird, werden einmal gelesene Schlüsseltabellen und Einzelsätze aus Schlüsseltabellen intern gespeichert, um mehrfache physische Zugriffe auf dieselbe Tabelle/denselben Satz zu vermeiden.

Um Laufzeitvergleiche durchzuführen, kann auf die BstnTime-Ausgaben im TAA-Monitor zurückgegriffen werden.

Eine Alternative zur Optimierung des Laufzeitverhaltens ist das Laden von Schlüsseltabelleninhalten aus einer Ressourcen-DLL. Dafür sind folgende Maßnahmen erforderlich:

• In der mdb müssen einige Einträge angepasst werden, s. MDB-Änderungen 3.
• Die Schlüsseltabelleninhalte müssen als csv-Datei abgelegt werden. Dies geschieht z.B. bei Ausführung des IEdge-Befehls DSTRIMP. Wichtig ist dabei, dass beim Aufruf von InterfEdge das Anwendungssystem angegeben wird, zu dem die Schlüsseltabelle gehört, bzw. dass dieses Anwendungssystem im Logon-Server eingestellt ist. Andernfalls werden die csv-Dateien unter falschem Namen erzeugt.
• Nun können Sie über taado den Schlüsseltabelleninhalt in die Ressourcen-DLL übernehmen. Der zu generierende Ressourcentyp ist STBC.
• ¹⁾Um die Schlüsseltabellen auch bei Simulation von COBOL-Modulen aus Ressourcen-DLLs laden zu können, müssen sie auch im Format der für die betreffende Schlüsseltabelle benutzten Datenstruktur (OSTR) abgelegt werden. Die dazugehörige Ressource heißt STBO. Sie wird gemeinsam mit der STBC-Ressource erzeugt, wenn in der Registry der Eintrag Config\RefGenResOstr = 1 gesetzt ist. Außerdem sind hierfür weitere MDB_Änderungen erforderlich 4.
• Damit zur Laufzeit die Schlüsseltabelleninhalte aus der Ressourcen-DLL geladen werden statt aus der Datenbank, muss der Eintrag LoadStbcFromRes = 1 in der in der TAA Datenbank Konfiguration für die Datenbank, die die Schlüsseltabellen enthält, gesetzt sein.

Wenn eine Schlüsseltabelle in der Ressourcen-DLL nicht gefunden wird, versucht das Laufzeitsystem, diese Tabelle trotzdem aus der konfigurierten Datenbank zu laden. Dieses Verhalten können Sie über die Einstellung LoadStbcFromResOnly = 1 verhindern, es erfolgt dann kein Zugriff auf die Datenbank mehr.

INSERT  INTO edbBstn ( Name, Bezeichnung, Suffix, Präfix, Zielsystem, Baustein_Kategorie, Parent, EdbInt, Path, AltPath, Header_Record, Anzahl_Felder, Table_Mode, ListFor, Flags, Interface_Version, Version, Aufrufbar, ExtName, AltExtName )
 SELECT 'STBC', 'Schlüsseltabelleninhalt', 'CSV', 'T$F', 'CSV', 0, 'OUTP', 132, '$E\$V\$S;K:\SRC\$(*)V\EDB\$S/r', '$E\$V\$S;K:\SRC\$(*)V\EDB\$S/r', 0, 0, 0, '', 0, 0, 0, 0, '', '';

Dieser Eintrag wird durch nachfolgende MDB-Änderungen noch angepasst.

 insert into edbClas values ("REF", "Schlüsseltabelle")

 update edbbstn set flags = flags | 16 where edbint = 120

Folgende Änderungen sind in der MDB notwendig, um Schlüsseltabelleninhalte (STBC) in eine Ressourcen-DLL generieren zu können:

UPDATE edbBstn SET edbBstn.[ListBy] = 'LSTC' WHERE (((edbBstn.Name)='STBC'));

UPDATE edbBstn SET edbBstn.[Flags] =flags | 16 WHERE (((edbBstn.Name)='STBC'));

UPDATE edbBstn SET edbBstn.[Präfix] = 'T$F' WHERE (((edbBstn.Name)='STBC'));

INSERT INTO edbBstn ( Name, Bezeichnung, Suffix, Baustein_Kategorie, Parent, EdbInt, Path, Header_Record, Anzahl_Felder, Table_Mode, ListFor, Flags, Interface_Version, Version, Aufrufbar ) SELECT 'LSTC' , 'Schlüsseltabelleninhaltsliste' , 'CSV' , 2 , 'SLST' , 133 , '$E\$V\$S;K:\SRC\$(*)V\EDB\$S/r' , 1 , 5 , 2 , 'STBC', 0, 0, 0, 

INSERT  INTO edbBstn ( Name, Bezeichnung, Suffix, Baustein_Kategorie, Parent, EdbInt, Path, Header_Record, Anzahl_Felder, Table_Mode, ListFor, Flags, Interface_Version, Version, Aufrufbar )
 SELECT 'STBO', 'Schlüsseltabelleninhalt für simulierte Datenzugriffe', '', 0, 'STBC', 134, '', 0, 0, 0, '', 0, 0, 0, 0;

[HKEY_LOCAL_MACHINE\SOFTWARE\TAA\DbConfig\RefDB]
 "PhysicalName"=""
 "ConnectionStringExtra"="Driver={Microsoft Access Driver (*.mdb)};FIL=MS Access;MaxBufferSize=512;MaxScanRows=1;ReadOnly=1;DBQ=g:\\400\\dalref.mdb"
 "ExecuteInternal"=hex:01
 "Caching"=hex:01
 "LoadStbcFromRes"=hex:01
 "LoadStbcFromResOnly" = hex:00 

–> Weitere Informationen zur DbConfig.

(Arbeitsstand 08.09.2000) Fall A: Client mit Pentium II 450, 256MB RAM, sämtliche Schlüsseltabellen in MS-Access Datenbank (5,4MB) auf Fileserver mit 100MBit Netz. Benutzte Schlüsseltabelle TVOSGT (Gevo-Typ-Tabelle).

Durchschnittliche Zeit zum Laden zwei ausgewählter Einträge (auf Basis Schlüsselvorbelegung im Mengenobjekt): zwischen 50 und 60 Millisekunden.

Durchschnittliche Zeit zum Laden der gesamten Schlüsseltabelle (332 Sätze - tvosgt) in einem Mengenobjekt: zwischen 90 und 110 Millisekunden.

(Arbeitsstand 11.09.2000)

Zeiten bei Zugriff auf einem einzigen Element einer Schlüsseltabelle:

Zeiten bei Zugriff auf acht ausgewählte Elemente einer Schlüsseltabelle:

Zeiten bei unselektiertem Zugriff auf die gesamte Tabelle (332 Elemente), wobei die Ergebnisse nach dem ersten Zugriff aus dem lokalen Cache besorgt werden können, da kein Filter angewandt wurde: