T2XQT

Wenn das COBOL Laufzeitsystem eine neue COBOL-DLL lädt, wird ein Entrypoint _mFDllInfo erwartet. Das COBOL-Laufzeitsystem wertet die Angaben, die unter diesem Entrypoint abgelegt sind aus, und leitet daraus ab, welche Program-IDs in dieser DLL unter welchem Entrypoint resp. Adresse zu finden sind. Sollte es sich dabei herausstellen, dass hier eine Program-ID aufgeführt wird, die bereits in einer anderen geladenen COBOL-DLL zu finden ist, verweigert das Laufzeitsystem das Laden der DLL, da es nicht in der Lage ist, im Falle eines Calls auf die Program-ID zwischen den beiden Entrypoints zu entscheiden. In anderen Programmierumgebungen ist das normalerweise kein Problem, da entweder bereits zur Linkzeit bekannt ist, in welcher DLL ein bestimmter Entrypoint zu finden ist, oder bei dynamischen Aufrufen grundsätzlich die Kombination der DLL mit dem Entrypoint angegeben werden muss.

Das oben geschilderte Problem tritt dann auf, wenn innerhalb eines einzigen Prozesses DLLs mit sich überschneidenden Entrypoints geladen werden müssen. Das kann beispielsweise passieren, wenn in einem Prozess mit unterschiedlichen Versionen einer Anwendung gearbeitet wird (wie beim Wiederaufnahmeserver oder bei der ISAPI-Extension), aber auch, wenn gleiche Entrypoints (allgemeine Servicefunktionen) in mehreren Anwendungs-DLLs zu finden sind. In einem solchen Fall kann die COBOL-DLL nicht mehr im gleichen Prozess geladen werden.

Wenn die TAA Infrastruktur feststellt, dass eine COBOL-DLL (Implementierungstyp dllcob*) erstmalig geladen werden muss, wird diese DLL vor dem Laden analysiert und sämtliche Entrypoints gesammelt. Dann wird nachgeschaut, ob es bereits eine geladene COBOL-DLL gibt, in der einer der Entrypoints der zu ladenden DLL vorkommt. Ist das nicht der Fall, wird die DLL geladen und werden die Entrypoints dieser DLL für das Laden künftiger COBOL-DLLs gemerkt.

Wird allerdings festgestellt, dass die DLL wegen doppelter Entrypoints nicht geladen werden kann, wird ein Auftrag an den TAA-Dienst t2xqt weitergeleitet. Dieser Auftrag betrifft die Ausführung des Bausteins, wofür die DLL geladen werden musste. Der Dienst t2xqt wird aus dem Auftrag ableiten, welche DLL gefordert ist. In einer Sammlung bestehender Prozesse wird nachgeschaut, ob bereits ein Worker-Prozess (taaPwp) verfügbar ist, der spezifisch diese DLL geladen hat und bearbeitet. Wenn nicht, wird ein solcher Prozess gestartet. Diesem Prozess wird dann der Auftrag zur Ausführung weitergeleitet. Nach erfolgter Ausführung des Bausteins wird das Ergebnis dem Dienst t2xqt zurückgereicht, der dieses Ergebnis wiederum dem anfordernden Clientprozess zurückreicht. Im nachfolgenden Bild wird dies näher dargestellt.

Denkbar ist durchaus, dass bei der Ausführung in einem Worker-Prozess der gleiche Entrypoint-Konflikt auftritt. In diesem Fall ist auch der Worker-Prozess in der Lage, den Auftrag zur Ausführung weiterer Bausteine wiederum über den t2xqt-Dienst zur Ausführung an einem anderen Worker-Prozess weiterzuleiten. Auch die Kombination mit der sog. OutOfProc-Funktionalität ist unterstützt. Dies kann zu beliebig komplexen Zusammenhängen zwischen den einzelnen Prozessen führen.

CentralQueue Standardmäßig wird durch den Dienst t2xqt pro DLL nur ein einziger Prozess zu Verarbeitung von Anfragen zu dieser DLL gestartet. Mit der Einstellung CentralInst im Config-Abschnitt der TAA-Registry kann dieser Wert angepasst werden. Wenn mehrere Anfragen an die gleiche DLL eingestellt werden, werden diese in Reihenfolge des Eintreffens abgearbeitet. Dabei werden maximal 20 Anfragen gepuffert. Dieser Wert kann mit der Einstellung CentralQueue im Config-Abschnitt der TAA-Registry angepasst werden.

Registrierung als Dienst Der Dienst t2xqt ist Bestandteil der zentralen TAA Dienste, die alle durch den Prozess t2srvc.exe erfüllt werden. Der Dienst wird registriert durch den Aufruf t2srvc/install. Wenn die TAA Dienste als selbständiger Prozess und nicht als TAA-Dienst laufen, entfällt die Registrierung. In diesem Fall läuft der Dienst t2xqt als Bestandteil des Prozesses taaSrvc.exe.

Auszuschließende Entrypoints Bestimmte Entrypoints werden vom COBOL-Compiler als Bestandteil des Laufzeitsystems in COBOL-DLLs erzeugt und sind ggf. in mehreren DLLs vorhanden. Solche Entrypoints müssen bei der Überprüfung auf Duplikatkonflikte ausgeschlossen werden.

Wie sich gezeigt hat, stammen die auszuschließenden Entrypoints aus immer denselben Cobol-Dlls, i.d.R. die mffh.dll. Deshalb kann²⁾ eine Liste von Dlls angegeben werden, deren Entrypoints ausgeschlossen werden sollen. Dadurch werden Entrypoints, die in neuen Cobol-Versionen hinzukommen oder entfallen, automatisch mit berücksichtigt.

In der Registry kann unter dem Schlüssel Config/CentralExcludeDll eine Liste von Dlls angegeben werden, mit Semikolon getrennt. Wenn der Eintrag nicht vorhanden ist, wird als Default „mffh.dll“ angenommen.

Wenn nach Auswertung der angegebenen Dlls die Liste der auszuschließenden Entrypoints leer ist, wird die Liste wie bis V8.12 üblich erstellt.

Zusätzlich kann unter dem Schlüssel Config/CentralExcludeAddEntry eine Liste von Entrypoints angegeben werden, die zusätzlich zu den in den Dlls gefundenen oder als Default (V8.12) angenommen Entrypoints ausgeschlossen werden sollen (Default=leer). Doppelte Einträge werden ignoriert.

Die Dlls werden zunächst im System-Suchpfad gesucht, dann - falls vorhanden - in dem in der Cobol-Installation angegebenen Root-Verzeichnis. Falls Dlls durchsucht werden sollen, die dort nicht gefunden werden können, kann dafür der vollständige Pfadname angegeben werden (bei Verwendung von Langnamen ggf. in Anführungszeichen).

Wenn der InfoLevel > 4 eingestellt und die Ausgabe für LoadLibrary eingeschaltet ist, wird im Monitor ausgegeben, welche Dlls gesucht, welche Dlls ausgewertet und welche Entrypoints gefunden wurden.

Bis V8.12 konnten Entrypoints nur in der Registry inter dem Schlüssel Config/CentralExclude als Liste eingetragen werden. Die Groß/Kleinschreibung spielt bei den Einträgen keine Rolle. Ist nichts angegeben, werden folgende Entrypoints ignoriert: _mFdllinfo
BSIO
ESDSFH
EXTFHSUB
FHR_CLOSE
FHREDIR
MAPPER
MFFH
MFINI
STRIPE_CLOSE_FILE
STRIPE_CONFIG_INFO
STRIPE_COPY_FILE
STRIPE_CREATE_FILE
STRIPE_DELETE_FILE
STRIPE_FLUSH_FILE
STRIPE_FREE_RECORD_LOCK
STRIPE_GET_RECORD_LOCK
STRIPE_INITIALIZE
STRIPE_LOCKFILE
STRIPE_OPEN_FILE
STRIPE_READ_FILE
STRIPE_RELSEMA
STRIPE_RENAME_FILE
STRIPE_SEEK_END
STRIPE_SETSEMA
STRIPE_TEST_RECORD_LOCK
STRIPE_UNLFILE
STRIPE_UNLOCK
STRIPE_WRITE_FILE
XFH_CLOSE_MAPPER
XFH_CLOSE_MVS
XFH_FUNC