TAAWithCEL/TAAWithBOL

ECI mit CEListener (OM-Neu) kann nur COBOL, andere Implementierungstypen werden nicht unterstützt. Das gleiche Problem existiert auch für das Batch-Framework, auch hier kann nur COBOL verwendet werden. Daher wurde nach einer Möglichkeit gesucht, die TAA LAN Infrastruktur (TAA) mit dem CEListener und dem Batch-Framework zum Laufen zu bringen. Damit könnten dann auch andere Implementierungstypen als COBOL verwendet werden.

Es folgt eine Auflistung/Beschreibung darüber, was geändert wurde, und was noch zu tun ist, um dieses Ziel zu erreichen.

Wenn ein Modulaufruf angefordert wird, wird diese durch ein sog. Proxy, bestimmt durch den Implementierungstyp (Ityp), ausgeführt:

Der ECI-Proxy kontaktiert den CEListener(-Server), und bekommt einen Prozess für die weitere Kommunikation zugewiesen. Die Verbindung mit diesem Prozess bleibt für die Dauer einer Transakation bestehen. Dieser Prozess hält die Datenbankverbindung bis zur Transaktionsende und führt alle von dem ECI-Proxy innerhalb der Transaktion angeforderten Modulaufrufe durch.

Der ECI-Proxy besteht aus 2 Komponenten (Plug-Ins):

• Communicator: Zuständig für Initialverbindung und Übertragung von Befehlen (Commit/Rollback/CALL Programm)
• Dataflow: (nur für CALL Programm) Zuständig für Datenaustausch mit OM-Neu

Welche Plug-Ins verwendet werden, wird aus der Implementierungspezifikation (Ispc) abgeleitet.

Das Plug-In für Dataflow wird ersetzt durch ein TAA-eigenes (TWECIPLG), welches den Datenstrom erstellt und die Daten aus der Response auswertet. Hierfür wird der gleiche Code verwendet, der auch bei dem Ityp HTTP zum Einsatz kommt. Außerdem wird für ein ECI-Modul anstatt des COBOL-Programms aus der Ispc ein TAA-Entrypoint (TWCELPLG) aufgerufen. Dieser extrahiert die Daten, ruft das TAA Modul auf, und erstellt anschließend den Response.

Das Batch Framework besteht aus einer Reihe von Scripts, die schlussendlich einen Prozess mit dem Namen tloc1drv.exe starten. Dieser bekommt eine gewisse Menge an Daten, die benötigt werden, um den Batch-Job durchzuführen. Einer dieser Angaben ist der Name des Programms, welches für die Batchsteuerung zuständig ist. Standardmäßig handelt es sich hierbei um Z0MWBP000, das generierte COBOL Programm für die TAA Steuerung MW-BATCH-PROZESS-GEVO.

Hierbei handelt es sich um eines von einer Anzahl TAA Module (MW-BATCH-PROZESS-…), welche ein Framework bilden, um in einem Standard-Batchverfahren die vom Anwendungsentwickler definierten Batchabläufe durchzuführen. Dazu werden von diesem Batch-Framework eine Anzahl DB2-Tabellen mit Hilfe eines Checkpoint/Restart-Verfahrens verarbeitet. Diese Tabellen enthalten die zu verarbeitenden Daten und den Namen des TAA Moduls, das für die Datenverarbeitung aufgerufen werden soll. Über bestimmte Einstellungen in den Tabellen kann zudem festgelegt werden, wie das Batch-Framework sich zu verhalten hat (Art der Verarbeitung, Transaktionierungsverhalten, etc…).

Konzeptionell gesehen muss in diesem Batchframework unterschieden werden zwischen dem BC-Kontext des Frameworks selbst (Steuerungskontext), und dem BC-Kontext für das TAA Modul, welches einen Datensatz verarbeiten soll (Verarbeitungskontext). Der Steuerungskontext greift auf bestimmte Tabellen zu, um das TAA Modul zu ermitteln, welches ausgeführt werden soll, und stellt die notwendigen Daten für den Aufruf bereit. Im folgenden Bild ist diese Steuerung (vereinfacht) dargestellt:In der Unterroutine Gevo-Verarbeitung findet dann der Aufruf des TAA Moduls und die Nachverarbeitung statt:Dazu wird die Funktion MW-BATCH-PROZESS-STR-GEVO aufgerufen, welche den Verarbeitungskontext für das TAA Modul aufbaut und den Aufruf durchführt. Die Daten, die der Verarbeitungskontext benötigt und ggf. an den Steuerungskontext zurück liefert, werden über globale TAA Objekte und TAA Workfloweigenschaften ausgetauscht. Außerdem werden in der Funktion MW-BATCH-PROZESS-STR-GEVO eventuell aufgetretene Conditions und der (Workflow)-Zustand ausgewertet, und ggf. ein Eintrag ins Geschichtsbuch vorgenommen.

Es ist aber auch möglich, ein anderes Programm anzugeben, und es ist vorgesehen, hier auch Argumente übergeben zu können, indem diese durch ein Komma von den Programmnamen getrennt werden (i.e. Z0MWBP00,<Zeichenfolge>). Dies wird verwendet, um statt des COBOL-Programms einen eigenen Entrypoint aufzurufen, der den Namen des TAA Moduls übergeben bekommt (z.B. TWBATPLG,MIDWAR;GEVO;MW-BATCH-PROZESS-GEVO). Dieser Entrypoint kann dann das TAA-Modul für die LAN-Infrastruktur aufrufen.

Um TAA mit dem CEListener bzw. das Batch-Framework zu verwenden, braucht es eine eigene Installation des CEListeners bzw. Batch-Frameworks, da einige Komponenten ersetzt werden müssen, insbesondere die TAAIM.DLL. Diese verwendet OM-Neu, und muss daher durch die TAAIM.DLL von TAA ersetzt werden. Da der Pfad, wo die TAA-Komponenten liegen, in der jeweiligen Umgebung.ini-Konfigurationsdatei eingetragen ist, reicht es, bestimmte DLLs aus dem Installationsverzeichnis zu entfernen:

• TAAIM.DLL
• Z0MWSAPS.DLL

Auf dem Client muss in der der Config-Section der TAA-Registry ein Eintrag TAAWithCEL angelegt und mit den Binärwert 01 versehen werden, damit in der ECI-Proxy das Dataflow-PlugIn von TAA (TWECIPLG) verwendet wird. Wenn dieser Eintrag nicht vorhanden ist, oder den Wert 00 enthält, wird das Standardverhalten des ECI Proxy aktiviert.

Die COBOL-DLLs, welche die Implementierungen für die ECI Module enthalten, sind normalerweise nicht über den ComponentPath zu finden. Damit TAA in der Lage ist, die COBOL-DLLs zu finden, muss entweder der ComponentPath um diese Verzeichnisse erweitert werden, oder diese Verzeichnisse in dem Eintrag MVSComponentPath eingetragen werden. Dieser Eintrag wird nur für die Suche nach diesen COBOL DLLs verwendet. Dieser muss sowohl auf dem Client als auch auf dem Server angepasst werden.

Um einen Batch-Job mit TAA laufen zu lassen, muss anstatt des Namens des generierten COBOL Programms für die Batchsteuerung ein TAA Entrypoint (TWBATPLG) angegeben werden. Als Argument wird der Name des TAA Moduls übergeben: TWBATPLG,<appl>;<bstn>;<modl>[;<oper>[;<opts>]]. Die Angaben für die auszulösende Operation (<oper>) und Optionen (<opts>) sind optional.

Hier folgt eine Auflistung aller Probleme, welche festgestellt wurden, und eine Beschreibung der Lösung/Umgehung, bzw. Verweise auf die Tickets, wo das Problem erkannt wurde, bzw. weiter verfolgt wird.

OM-Neu ignoriert Ityp/Ispc, und ruft immer das COBOL-Programm für ein Modul. Der Name des COBOL Programms wird vom COBOL-Präprozessor (abgeleitet aus dem Kurznamen des Moduls) im Generat erzeugt. Alle COBOL-Programme liegen als DLLs mit diesem Namen/Entrypoint vor. TAA verwendet Ityp/Ispc, um die Namen der DLL und des Entrypoint zu ermitteln. Allerdings sind nicht alle Module mit einem Ityp/Ispc versehen.

TAA erkennt, dass die Ausführung unter Kontrolle des CEListener bzw. Batch erfolgt, und ersetzt zur Laufzeit bei allen Module mit Ityp ECI oder ohne Ityp die Ityp/Ispc Angabe. Als Ityp wird DLLCOB32 verwendet, und mangels weiterer Angaben wird die Ispc gebildet aus Z0<agk><kurzname>. Bei <agk> handelt es sich um das Projekt Kürzel der Anwendung, zu der das Modul gehört, und bei <kurzname> um den Kurznamen des Moduls. Sollte aber für das Module eine ISpc für ITyp ECI vorhanden sein, wird diese verwendet (TFS225366).

Für einen produktiven Einsatz sollten aber alle Module mit einer ordentlichen Ityp/Ispc-Angabe versehen werden. Ticket?

Ein Datenzugriffsmodul soll sich nur um den Zugriff auf eine bestimmte Tabelle/View kümmern, und nichts über die Datenbank und Transaktion wissen. Die Infrastruktur kümmert sich um die Datenbankverbindung und die Transkationen. Dafür ist vorgesehen, dass in der Konfigurationsbeschreibung des Moduls die Eigenschaft DBNAME bestückt werden kann:

Der Wert bezeichnet einen logischen Namen für eine Datenbankverbindung. Um welche physische Datenbank es sich handelt, wird unter einem Key mit diesem Namen in der DbConfig-Section der TAA Registry beschrieben. Neben den Angaben zu Benutzerkennung und verschlüsseltem Kennwort können hier noch weitere Angaben gemacht werden, wie diese Datenbankverbindung sich zu verhalten hat. Diese Angaben können auch umgebungsspezifisch angelegt und für Änderungen geschützt werden.

TAA verwendet einem Datenbankmanager (DBMGR), der dieser DBNAME Eigenschaft auswertet, um beim Register/Unregister des Moduls sicherzustellen, dass die Datenbankverbindung (de)aktiviert wird. Dazu verwaltet der DBMGR einen Stack mit Datenbankverbindungen. Da der DBMGR alle verwendeten Datenbankverbindungen kennt, könnte er sich auch um die Transaktionierung kümmern. Dies ist aber nicht umgesetzt, siehe auch nächstes Thema Transaktionen.

OM-Neu ignoriert diese DBNAME Eigenschaft, und nutzt dafür eine Umgebung.ini-Datei mit einem ConnectionString. Der CEListener-Prozess wertet diesen aus, und kümmert sich um die Datenbankverbindung.

Bei der Ausführung unterhalb des CEListeners wird die DBNAME Eigenschaft ignoriert, und die TAA verlässt sich auf die Datenbankverbindung, die vom CEListener-Prozess verwaltet wird. Ob beim Register/Unregister des Modules die Datenbankverbindung (de)aktiviert wird, wird über die Einstellung AutoConnect in der DbConfig-Section gesteuert. Bei Ausführung unterhalb von CEListener/Batch wird diese Einstellung ignoriert. Die DBNAME-Eigenschaft wir nämlich auch für das Umlenken der Schlüssentabellenzugriffe auf der Ressourcenzugriff verwendet. (TFS222814)

Dieses beiden abweichenden Verfahren zu der Datenbankverbindung müssen abgestimmt und zusammengeführt werden. Solche Angaben zu der notwendigen Datenbankverbindung für ein Modul sollten generell in Rochade (als Single Point of Control) abgelegt werden. Ticket?

Transaktionen werden auf Steuerungsebene durch sog. Transaktionskonstrukte, bzw. entsprechende Transaktionsanweisungen in anderen Implementierungstypen, initiiert und beendet:

Bei der Ausführung können Bausteine auch in ausgelagerten Prozessen ausgeführt werden. Um die Datenbankänderungen, welche in diesen ausgelagerten Prozessen ausgeführt werden, als Bestandteil der in der Steuerung modellierten Transaktion behandeln zu können, müsste ein multi-phase commit verwendet werden. Dies ist allerdings nie umgesetzt worden. Eine modellierte Transaktion bezieht sich daher nur auf dem Prozess, in dem sie modelliert ist.

In der TAA wird für jede Transaktion beim BC ein sog. Taskunit angelegt, welche beim einem Commit bzw. Rollback wieder aufgeräumt wird. Außerdem werden alle Proxies über eine neue Taskunit und Commit/Rollback unterrichtet. Beim Unregister werden alle noch existierenden Taskunits, die in dem Modul angelegt wurden, durch einen Rollback aufgeräumt.

Da bis dato alle Datenbankänderungen auf DB2/MVS stattfinden, ist der ECI-Proxy bislang der einzige, der Transaktionsanweisungen umsetzt. Dazu speichert er die Informationen, die er für die Transaktion braucht, an der jeweiligen Taskunit. Außerdem erkennt er, ob ein ECI-Modul innerhalb einer Transaktion in einem ausgelagerten Prozess aufgerufen wird, und verwendet dann den richtigen CEListener-Prozess. Hierdurch vermeidet er die Komplexität, die eine verteilte Transaktion mit sich bringt. Wie hier beschrieben, hält der CEListener-Prozess nämlich die Datenbankverbindung.

Weitere Transaktionsanweisungen werden von OM-Neu (für Online) ignoriert. Beim Unregister des Moduls auf oberster Ebene (d.h. das Modul, dessen Aufruf von dem ECI-Proxy angefordert wurde) wird nur eine Info (Vote für Commit/Rollback) an den CEListener Prozess zurückgereicht. In Batch liegt die Transaktionskontrolle beim Batchframework (i.e. Steuerungskontext). Deswegen müssen die Transkationanweisungen hierfür an OM-Neu weitergeleitet werden.

Bei der Ausführung unterhalb des CEListeners/Batchframework werden alle Transaktionsanweisungen von der ECI Proxy ignoriert. Nur der Vote für Commit/Rollback wird am Ende beim Erstellen des Response an den CEListener Prozess zurückgereicht. Damit für Batch die Transaktionierung weiterhin funktioniert, werden alle Transaktionsanweisungen an OM-Neu weitergeleitet. Siehe auch TFS224349

Da der DBMGR Kenntnisse über alle Datenbankverbindungen hat, könnte er sich auch um die Transaktionierung kümmern, und ggf. eine verteilte Transaktion (z.B. MSDTC¹⁾) nutzen. Die MSDTC Transaktion kann auch verwendet werden, um die Aufrufe in ausgelagerten Prozessen zu koordinieren²⁾. Der Nachteil ist aber der Performanceverlust, wenn MSDTC verwendet wird. Solange aber nur eine transaktionsrelevante Datenbankverbindung verwendet wird, und alle Datenbankzugriffe innerhalb einer Transaktionsklammer in dem selben Prozess ausgeführt werden, wird die MSDTC Transaktion nicht gebraucht. Die Infrastruktur kann erkennen, dass ein Datenzugriff unterhalb einer Transaktion in einem 2. Prozess ausgeführt wird, und entsprechend reagieren. Bei dieser Reaktion kann es sich ggf. auch um eine Fehlermeldung handeln müssen, da nicht garantiert ist, dass eine ODBC Connection, die sich bereits in einer lokalen Transaktion befindet, nachrichtlich in eine MSDTC Transaktion aufgenommen werden kann.

Interessant in diesem Zusammenhang ist, was seit .NET 2.0 von Microsoft mit System.Transactions³⁾ zur Verfügung gestellt wird. Hier stehen Klassen zur Verfügung, um mehrere Ressourcen (neben Datenbanken z.B. auch Message-Queues) in einer Transaktion zu verwenden. Der Trick hierbei ist, dass intern von .NET ein sog. Lightweight Transaction Manager verwendet wird, der (anfangs lokale) Transaktionen bei Bedarf in MSDTC Transaktionen umwandelt. Dieses Verfahren (Transaction Escalating⁴⁾) findet z.B. dann statt, wenn ein Transaktions-Objekt in eine andere AppDomain bzw. Prozess transferiert wird, aber auch wenn die verwendeten Ressourcen (z.B. eine 2. Connection) innerhalb der Transaktion es verlangen. Implementiert wird dieses Verfahren durch die .NET Klasse System.Transactions.TransactionInterop⁵⁾. Diese stellt Methoden zur Verfügung, um für Transaktionsobjekte sog. Propagation Tokens zu erzeugen. Diese können dann in andere Prozesse bzw. auf andere Rechner übertragen werden, um daraus wieder Transaktionsobjekte zu erzeugen, welche dann in dem Prozess für eine verteilte Transaktion verwendet werden können.

WF-INTERFACE ist ein ECI-Modul (aus Midwar), das von der Workflow Engine verwendet wird, um Aufrufe für die Kontextsicherung, Geschichtsbuch, Druckaufträge und Requestdatenbank zu bündeln. Die Implementierung macht aber einen Register als UNIVERSAL-PROXY. Dies wird von OM-Neu akzeptiert, von TAA nicht.

Bei der Ausführung unterhalb des CEListeners wird eine TW-interne Funktion verwendet, die zum Testen der Workflowfunktionalität implementiert wurde.

Die Lösung wird auch für den Aufruf von CT-INTERFACE verwendet (TFS261553).

OM-Neu kennt einige zusätzliche Operationen für TAAIM:

• BC-RESET, BPC, CRI, DRI, EEOGETDATA, EEOPUTDATA, GET-BS2CON, GET-DSN, GET-ENVIRE, GET-ENVVAR, GET-LUW, GET-PREFIX, GET-SAPENV, GET-TSOFF, GRI, GRUINF, HTPAAUTH, HTPAHEAD, HTPAPOST, HTPGRH, HTPINIT, HTPPERF, HTPREL, ITYP-HTTP, LUW-MODE, MARKTIME, OM.ALI, OM.ALS, OM.DEI, OM.DSY, OM.GBL, OM.GEI, OM.GIP, OM.LAG, PUT-EGTS, PUT-LUW, SCPULIMIT, SRUINF, TIMEDELTA, TIMEOFFSET, TRX.AUTO, TRX.DTC, TRX.END, TRX.STC, URI, ZARE

Kursiv markierte Funktionen werden nicht mehr benötigt, und ignoriert. Fett markierte Funktionen werden erkannt, und entsprechend implementiert, bzw. an OM-Neu weitergeleitet. Eine Beschreibung zu der jeweiligen Funktion findet sich unter dem Link. Für alle anderen (noch nicht verlinkten) Operationen ist noch nichts unternommen.

Hier folgt eine Liste mit Punkten, die den Objektmanager betreffen.

OM-Neu lässt ein PUT ohne NEW zu. TAA auch, gibt aber eine Warnung aus (Details).

OM-Neu lässt ein PUT(Index) mit Index größer als Anzahl Einträge zu, und macht dafür implizit ein ADD LAST.

Bei der Ausführung unterhalb des CEListeners verhält sich TAA wie OM-Neu. (TFS76195)

OM.GIP ist eine Variante von EXEC TAA GET WHERE (Details), und wurde zusätzlich im Objektmanager implementiert (TFS84264).

Die Anwendung verwendet nach einem OM.GIP ein INSERT CURRENT, um einen Eintrag an der richtigen Position hinzufügen. Allerdings ist laut Doku das Verhalten undefiniert, wenn bei INSERT CURRENT nicht auf einem Eintrag positioniert ist. OM-Neu macht implizit ADD LAST, TAA macht ADD FIRST.

Bei der Ausführung unterhalb des CEListeners verhält sich TAA wie OM-Neu (TFS76456), produziert allerdings auch eine Warnung. Der neue Befehl GET INSERTPOINT berücksichtigt dieses Problem.

Diese Funktion wird von dem Batch Framework verwendet, um Zugriff auf alle globalen Objekte zu bekommen, damit diese zurückgesetzt werden können. Wenn wie hier beschrieben das Batch-Framework angepasst wird, kann auf diese Funktion verzichtet werden.

Bei der Ausführung innerhalb des Batch-Frameworks wird diese Funktion erkannt, und Zugriff auf alle globalen Objekt (mit der Rolle MOD) gewährt.

Es gibt eine Reihe von Funktionen, welche nicht über TAAIM, sondern über COBOL Call aufgerufen werden, und in OM-Neu implementiert sind bzw. Daten brauchen, welche von OM-Neu verwaltet werden:

• Z2MWRNG0 → Zufallsgenerator
• Z2MWCENQ → Emulation von CICS Enqueues in der Datenbank
• Z2CS0054 → Erkennung der Umgebung
• Z0MWVRS0 → Irgendwas mit ITTM (Roland fragen)
• Z0MWSHA1 → SHA1
• Z0MWSAPS → SAP Ansteuerung über http/Webservice
• Z0MWMIF0 → Mailversand für die Infrastruktur (Roland fragen)
• Z0MWKUPP → Allokation von Speicher im Scope des aktuellen Moduls. Verwaltung von Speicher in unterschiedlichen Pools. Diese Pools hängen von ihrer Lebenszeit an der aktuellen Transaktion. Durchführen von Commits/Rollbacks für BS2 Kompatibilität
• Z0MWHTTP → http Requests
• Z0MWENV0 → Infos über das Jobenvironment
• Z0MWBCPT → BCrypt Implementierung
• Z0MWACEB → Konvertierungsroutinen Ascii↔Ebcdic
• UMAILCS → Unimail Interface
• UPOSTCS → Unipost Interface
• STCKCONV → Systemzeit in Datenstruktur
• STCKASM → Beschaffen Systemzeit
• IEANT → Simulation des Name/Token Services unter zOS
• CBLSNIJV → Emulation BS2 Jobvariablen

Fett markierte Funktionen werden erkannt, und sind entsprechend implementiert, bzw. werden an OM-Neu weitergeleitet. Eine Beschreibung zu der jeweiligen Funktion findet sich unter dem Link. Alle anderen (noch nicht verlinkten) Funktionen werden zwar erkannt, aber produzieren eine Severe Condition der die Verarbeitung unterbricht. (TFS23875)

Das Programm Z0MWSAPS (SAP Ansteuerung über HTTP/Webservice) wird zusammen mit der TAAIM-Funktion GET-SAPENV verwendet. Diese brauchen bestimmte von OM-Neu verwaltete Daten. Die TAAIM-Funktion GET-SAPENV wird an OM-Neu weitergeleitet. Das Programm Z0MWSAPS wird durch einen eigenen Entrypoint ersetzt. Dieser initialisiert einen Kontext für OM-Neu, ruft dessen Entrypoint auf, und prüft auf anschließend auf Conditions. (TFS71070)

Z0MWENV0 (Infos über das Jobenvironment) braucht ebenfalls bestimmte von OM-Neu verwaltete Daten. Das Programm Z0MWENV0 wird durch einen eigenen Entrypoint ersetzt. Dieser initialisiert einen Kontext für OM-Neu, ruft dessen Entrypoint auf, und prüft auf anschließend auf Conditions. (TFS228776)

Bei Z0MWHTTP (HTTP Requests) handelt es sich um eine Funktion der ein HTTP GET Request durchführt, und den Response als Byte Array zurück liefert. Diesen Speicher für den Response wird über ein 2. Aufruf ggf. wieder freigeben. Das Programm Z0MWHTTP wird durch einen eigenen Entrypoint ersetzt, der den HTTP GET Request über eine interne API durchführt, und auch den Speicher wieder freigegeben kann. (TFS23875)

Für Z0MWACEB (Konvertierungsroutinen Ascii↔Ebcdic) wird die OM-Neu Implemntierung weiterverwendet. (TFS242000)

Z0MWKUPP braucht ebenfalls Zugriff bestimmte von OM-Neu verwaltete Daten. Das Programm Z0MWKUPP wird durch einen eigenen Entrypoint ersetzt. Dieser initialisiert einen Kontext für OM-Neu, ruft dessen Entrypoint auf, und prüft auf anschließend auf Conditions. (TFS237657)

UMAILCS und UPOSTCS braucht (wie Z0MWKUPP) Zugriff auf bestimmte von OM-Neu verwaltete Daten. Die beiden Programme wird durch einen eigenen Entrypoint ersetzt. Dieser initialisiert einen Kontext für OM-Neu, ruft dessen Entrypoint auf, und prüft auf anschließend auf Conditions. (TFS245576)

Für die Funktion Z2CS0054 wird die OM-Neu Implementierung weiterverwendet (TFS246051)

Z0MWBCPT braucht Zugriff bestimmte von OM-Neu verwaltete Daten. Das Programm Z0MWBCPT wird durch einen eigenen Entrypoint ersetzt. Dieser initialisiert einen Kontext für OM-Neu, ruft dessen Entrypoint auf, und prüft auf anschließend auf Conditions. (TFS247055)

Die Funktion Z2MWRNG0 (Zufallsgenerator) ist durch eine eigene Implementierung ersetzt. (TFS257811)

Z2MWCENQ braucht ebenfalls Zugriff auf bestimmte von OM-Neu verwalteten Daten. Das Programm Z2MWCENQ wird durch einen eigenen Entrypoint ersetzt. Dieser initialisiert einen Kontext für OM-Neu, ruft dessen Entrypoint auf, und prüft anschließend auf Conditions. (TFS262599)

TAA verlässt sich normalerweise auf Windows (bzw. eine externe Authentifizierung auf einem Webserver), um den Benutzer zu ermitteln. Wenn dann ein Prozess- oder Platformmwechsel stattfindet, wird ein sog. Impersonationstoken verwendet, damit auf der anderen Seite der gleiche Benutzer verwendet wird. Dies hat den Riesenvorteil, dass obwohl der Serverprozess mit höhere Rechten ausgestattet sein kann, Code mit den (eingeschränkten) Rechten des Clients ausgeführt wird.

Dies funktioniert bei dem CEListener nicht. Hier muss die Benutzerid überträgen werden.

TAA Überträgt die Benutzerid, und verwendet diese unterhalb vom CEListener (TFS78290 und TFS178873)

Mit OM-Neu können nur generierte Steuerungen ausgeführt werden. Die TAA verwendet standardmässig den Steuerungsinterpreter. Es ist aufgefallen, dass es bei einigen Steuerungen ein unterschiedliches Verhalten gibt, je nachdem ob sie als generiertes COBOL Programm ausgeführt werden oder interpretiert werden. (TFS83896)

Ursache für das unterschiedliche Verhalten war die Verwendung von Parallelverarbeitungskonstrukten in der Steuerung, die anscheinend noch nie getestet worden sind (Details)

Bei der Ausführung unterhalb des CEListeners wird für Steuerungenn erzwungen, das generierte COBOL Programm zu verwenden. Es gibt einen Eintrag in der Config-Section der TAA Registry TAAWithCEL_ForceStrgInterpreter, mit der die Verwendung des Steuerungsinterpreters erzungen werden kann (Details).

Dieser kann auch dazu verwendet werden damit die Workflow-Engine für die Gevosteuerungen in dem Verarbeitungskontext verwendet wird, anstatt die generierte COBOL-Steuerungen.

Wie hier bereits erwähnt werden die Daten, die der Verarbeitungskontext benötigt und ggf. an den Steuerungskontext zurück liefert, über globale TAA Objekte und TAA Workfloweigenschaften ausgetauscht. Dies funktioniert in OM-Neu dadurch, dass der gesamte Ablauf in einem BC-Kontext stattfindet. Die globalen TAA Objekte und TAA Workfloweigenschaften werden in der Funktion MW-BATCH-PROZESS-STR-GEVO mit den notwendigen Daten für den Verarbeitungskontext gefüllt, bevor der Aufruf des TAA Moduls für den Verarbeitungskontext aufgerufen wird. Dazu werden in der Funktion MW-BATCH-PROZESS-DZ-NEXT die globalen TAA Objekte und TAA Workfloweigenschaften bei jedem Aufruf zurückgesetzt. Damit wird z.B. auch das von dem Steuerungskontext verwendete globale TAA Objekt MWPRSTR zurückgesetzt, was möglicherweise nicht die Absicht ist! Außerdem könnte dieses globale TAA Objekt bei der Verarbeitung des Datensatzes durch die Anwendung verändert werden, was nicht möglich sein dürfte. Des Weiteren gibt es ein Problem mit dem Zurücksetzen und Bestücken der TAA Workfloweigenschaften: es wird z.B. auch die Workfloweigenschaft STAGE (SysID 51), die die Stufe (i.e. EnvSpec) enthält, bestückt!

Was eigentlich gebraucht wird, ist eine Möglichkeit, um Abhängigkeiten zwischen 2 BC-Kontexten (Main/Fragment) zu definieren, und Daten von einem BC-Kontext in einem anderen BC-Kontext zu überführen (Main ⇒ Fragment), bzw. aus einem anderen BC-Kontext abzurufen (Main ⇐ Fragment). Auf das Batch Framework bezogen würde das bedeuten, dass der Steuerungskontext (Main) zu einem bestimmten Zeitpunkt für jeden Verarbeitungskontext einen neuen BC-Kontext (Fragment) anlegt, und diesen mit den benötigten Daten (globale Objekte, Workfloweigenschaften, …) bestückt. Danach wird der Modulaufruf in dem BC-Kontext des Verarbeitungskontextes durchgeführt. Wenn dieser fertig ist, kann der Steuerungskontext die Daten, welche er aus dem BC-Kontext des Verarbeitungskontextes braucht (globale Objekte, Conditions, Workflow- und Modulzustand, …) abrufen, und diesen BC-Kontext anschließend aufräumen. Damit gibt es (vergleichbar mit .NET AppDomains) eine Trennung zwischen Steuerungskontext und Verarbeitungskontext, und kann der Verarbeitungskontext keine beliebigen Daten in dem Steuerungskontext mehr ändern. Außerdem besteht in dem Steuerungskontext keine Notwendigkeit mehr, globale Objekte bzw. Workfloweigenschaften zurückzusetzen, weil sie sonst von dem Verarbeitungskontext verwendet werden könnten, da der Steuerungskontext selbst festlegt, welche Daten ausgetauscht werden.

Die Frage stellt sich natürlich, wie das in den unterschiedlichen Programmiermodellen veröffentlicht werden soll. Für COBOL könnte diese Logik mit Modulaufruf und Datenaustausch in einem eigenen BC-Kontextes (Fragment) in eine TAAIM-Funktion verpackt werden. Diese Befehle könnten sich syntaktisch an dem EXEC TAA START Befehl orientieren, der für das Modul, was ausgeführt werden soll, Parameterobjekte und Workfloweigenschaften bestücken kann. Die neue TAA-Funktion würde aber anstelle von Parameterobjekten die globalen TAA Objekte bestücken, ggf. auch mit lokalen Objekten, und den Aufruf in einem eigenen BC-Kontext (Fragment) durchführen. Nachdem das Modul fertig ist, würden die Daten aus den globalen TAA Objekten dann auch wieder (von Fragment in Main) zurück überführt. Auch die Conditions bzw. die Highest Severity der Conditions, die in dem Verarbeitungskontext aufgetreten sind, könnten zurück überführt werden. Der BC-Kontext (Fragment) wird am Ende dieser TAAIM-Funktion aufgeräumt.

Das Zurücksetzen der globalen TAA Objekte und TAA Workfloweigenschaften könnte damit entfallen, und wenn der Steuerungskontext selbst nicht mehr mit den globalen TAA Objekten arbeitet, sondern nur mit Parameter- und lokalen Objekten, könnte OM-Neu für diese neue TAAIM-Funktion intern sogar die bestehende Funktionalität mit dem Zurücksetzen und Bestücken der globale Objekte und Workfloweigenschaften für den Verarbeitungskontext verwenden, um den Aufruf durchzuführen.

Da nicht ein 2. Batch-Framework implementiert werden soll, sondern nur die Möglichkeit, TAA auch für Batchjobs zu verwenden, braucht es einige Änderungen sowohl in TAA als auch in dem bestehenden Batch-Framework und OM-Neu. Außerdem muss sichergestellt sein, dass keine Änderungen an den Anwendungskomponenten notwendig sind. Konkret braucht es dafür folgende Änderungen:

TAA:

• Definition und Implementierung der neue TAAIM-Funktion, die die oben beschriebene Funktionalität umsetzt.
• Da es sich bei dem Batchframework um Infrastruktur-Komponenten handelt, kann für diese neue Funktion erstmal auf eine Anpassung des TAA Präprozessors verzichtet werden, und (wie auch bereits gemacht wird) direkt der TAAIM-Funktionsaufruf verwendet werden. Wenn der Umfang feststeht, kann diese Funktion ggfs. auch als EXEC TAA Befehl veröffentlicht werden.

Batch Framework:

• Die Verwendung der globalen Objekte MWPSTR, BATINP, BATIMPB, BATOUT, BATOUTB und SYSTVAR (gibt es noch mehr?) wird durch Parameterobjekte mit passenden Datenstrukturen ersetzt. Diese werden bestückt mit lokalen Objekten, welche in MW-BATCH-PROZESS-ASTR angelegt werden.
• In dem COBOL Programm Z0MWBP02.CBL für das Modul MW-BATCH-PROZESS-DZ-NXT-GEVO wird die Section BP02-GLOBAL-RESET und deren Aufruf entfernt.
• In dem COBOL Programm Z0MWPB03.CBL für das Modul MW-BATCH-PROZESS-STR-GEVO wird in der Section BP03-CONTAINER-FUELLEN der Aufruf der TAAIM-Funktion BPC entfernt. Anstatt die Workfloweigenschaften über die TAAIM-Funktion BPS zu bestücken, werden diese in TX-STARTPROPS geschrieben. Anstelle der globalen Objekte SYSTVAR und BATINP werden die entsprechenden Parameterobjekte bestückt. Außerdem muss hier die TX-IM-ASSIGNMENTS für die Bestückung der benötigten globalen Objekte mit dem entsprechenden Parameterobjekt für Eingabe und Ausgabe gefüllt werden. In der Section BP03-BATCH-GEVO-DURCHFUEHREN wird dann die TAAIM-Funktion CALL durch die neue ersetzt. Ggf. müssen noch weitere Felder in TX-TAA bestückt werden.

OM-Neu:

• Die TAAIM-Funktionen OM.LAG, und BPC müssen entfernt werden, bzw. dürfen nur noch für interne Verwendung zugänglich sein.
• Implementierung der neuen Funktion, ggf. unter Verwendung bestehender Funktionalitäten.

Damit die Kompatibilität zum Bestehenden gewährleistet ist, sollten die Änderungen in mehrere Schritte aufgeteilt werden, die nacheinander getestet und abgenommen werden können:

1. Ersetzen der globalen Objekte im Batchframework durch Parameterobjekte, und Entfernung von BP02-GLOBAL-RESET in MW-BATCH-PROZESS-DZ-NXT-GEVO. In MW-BATCH-PROZESS-STR-GEVO die globalen Objekte mit dem Inhalt der Parameterobjekte bestücken, und nach dem Aufruf zurück transferieren.
2. Definition und Implementierung der neuen TAAIM-Funktion in OM-Neu, und Anpassung von MW-BATCH-PROZESS-STR-GEVO, damit diese Funktion verwendet wird.
3. Implementierung der neuen TAAIM-Funktion in TAA, und Test mit TAAWithCEL.

Sowohl nach Schritt 1 als auch nach Schritt 2 sollte die Batchverarbeitung weiterhin so funktionieren wie bisher.

Da für eine Umsetzung dieser Änderungen auch mit einem nicht zu vernachlässigenden Aufwand gerechnet werden muss, wird erstmal auf eine Umsetzung verzichtet, und diese auf später vertagt. Stattdessen werden neben den hier beschriebenen TAAIM-Funktionen auch die momentan noch verwendeten TAAIM-Funktionen OM.LAG, und BPC umgesetzt. Lediglich die TAAIM-Funktion CALL, welche verwendet wird, um das TAA Modul für die Verarbeitung aufzurufen, wird durch einen neuen Befehl CALL-FRAG ersetzt. In OM-Neu wird dieser auf die Implementierung von CALL verzweigen. In TAA wird dieser einen getrennten BC-Kontext verwenden (Details)

Da für den Steuerungskontext und den Verarbeitungskontext getrennte BC-Kontexte verwendet werden, entstehen auch mehrere Tracedateien zu einem Batch Job. Hier ist das Feature mit der Zeitleise in TestEdge wiederum sehr nützlich:Hier werden z.B. die Aufzeichnungen zu einem Batch Job angezeigt, in dem 3 Datensätze von der GEVO-Steuerung GS-FV-MITARBEITER-AUFTRAG verarbeitet würden.

In der Steuertabelle CRS ist in machen Fällen das falsche Projekt eingetragen. Dies muss korrigiert werden, da die Infrastruktur diese Angabe braucht um die Ressource für das jeweilige Modul zu finden.

Durch die Verwendung von CALL-FRAG kann die Infrastruktur dies erkennen, und an Hand Arbeitsgebietkurzel aus den Kurznamen des Moduls, (der ebenfalls eingetragen ist), das richtige Projekt ermitteln (TFS119092).

Für die Batchverarbeitung werden in dem Verarbeitungskontext auch Gevosteuerungen aufgerufen, damit Geschichtsbuchprotokollierung und Schweben auch für Batches verwendet werden können. Hierzu würde in 1997 (als das Batchframework auf dem MVS Host implementiert würde) der der COBOL Präprozessor erweitert, damit diese für Module von Typ GSTR entsprechender Code in den generierte COBOL-Programme erzeugt. Die Infrastruktur (TAAIM) bekommt hiervon kaum etwas mit. Sie wird lediglich aufgerufen, um die Schwebekennzeichen an den beteiligte TAA Objekte zu speichern, bzw. zu entfernen. Hierzu wurden damals 3 OM-Funktionen definiert:

• SKG: Schwebekennzeichen lesen (wird nicht verwendet)
• SKS: Schwebekennzeichen speichern
• SKD: Schwebekennzeichen löschen

Diese 3 Funktionen sind in der LAN-INfrastrukur nicht implementiert, was zu Laufzeitfehlern führt, da die Schwebekennzeichen nicht ermittlet werden können (TFS210779). Die LAN-Infrastruktur ist darauf ausgerichtet, dass das Schwebehandling von der Steuerungsinterpreter/Workflow-Engine initiert wird. Die Verwendung des Steuerungeinterpreter ist hier auch nicht ohne weitereres möglich, da dann auch die Kontextsicherung aktiviert wird, was wir in Batch ja gerade nicht wollen.

Die OM-Funktionen SKS und SKG werden jetzt von der LAN-Inf4rastrutkur auch implementiert, und die Schwebekennzeinzeichen werden jetzt auch an den Objekten gespeichert. Allerdings werden wir und mit dem Thema nochmal beschäftigen müssen, da es keine sehr performate Lösung ist. Dafür brauchen wir sehr wahrscheinlich auch Anpssungen an den COBOL Präprozessor.

Das Batchframework prüft das Ergebnis des des aufgerufene TAA Modul, und schreibt eventuelle aufgetretene Consitions in eine dafür vorgesehene Tabelle (BFL). Dazu werden die in dem Verarbeitungskontext aufgetretene Conditions an der Steuerungskontext zurückgereicht. Allerdings werden diese Conditions bei Verwendung von TAAWithCeL gelöscht, bevor sie in der BFL-Tabelle gespeichert werden können (TFS214116). Die Ursache dafür ist eine Diskrepanz zwischen OM-Neu und die LAN-Infrastrzutkur bzg. den [i]Default Condition Handler[/i] (Details)

Das Batchframework wird angepasst, damit es für die interne Info-Conditions kein RAISE mehr verwendet. Allerdings würde auch festgestellt das OM-Neu bzg. Conditions nicht alles aufzeichnet. Dies sollte nachgehollt werden (Ticket?). Da

Hier folgt eine Liste von TAAIM Funktionen (mit eine kurze Erklärung), welche vom Batch Framework verwendet werden. Diese werden bei der Ausführung innerhalb des Batch Framework erkannt, und an OM-Neu weitergeleitet:

• GET-ENVIRE ⇒ liefert einige Informationen über den Batch Job (Name, Benutzer, etc…)
• GRUINF ⇒ liefert eine Information, ob der Batch Job beendet werden soll (kann von RZ ausgelöst werden)
• GET-ENVVAR ⇒ liefert den Wert für eine Job Variable

Diese 3 Funktionen können auch von Anwendungskomponenten verwendet werden, wobei GRUINF nur in Batch verwendet wird.

Diese Funktionen werden verwendet, um die Laufzeitdauer für den Verarbeitungskontext zu überwachen⁶⁾:

• SCPULIMIT ⇒ Setzen der Maximum Laufzeit
• MARKTIME ⇒ Zeitpunkt des Start markieren
• TIMEDELTA ⇒ Laufzeitdauer ermitteln

Wenn die Anwendung selbst Transaktionen verwendet (AT), werden diese Funktionen verwendet:

• CRI ⇒ Restart Information anlegen
• URI ⇒ Restart Information ändern
• GRI ⇒ Restart Information abrufen
• DRI ⇒ Restart Information löschen
• PUT-EGTS ⇒ GevoID mit Restart Information verknüpfen
• TRX.STC ⇒ Setzen eines Programms, welches beim Commit/Rollback aufgerufen wird, um Ergebnisdaten zu sicheren
• TRX.DTC ⇒ Löschen des Programms, welches beim Commit/Rollback aufgerufen wird, um Ergebnisdaten zu sicheren

Das Batch Framework löst für das TAA Modul, welches einen Datensatz verarbeiten soll, immer die Operation DURCHFUEHREN aus (Details). Dies führt zu Problemen, wenn in dem TAA Modul (z.B. bei GEVO) die Operation nicht bekannt ist. Dies sollte gerade gezogen werden.

Entweder muss in der CRS Tabelle neben der Name und Anwendung des Moduls auch die auszulösende Operation eingetragen werden, oder für die fachliche Module wird grundsätzlich nur die Operation UDEF verwendet.

Da an dieser Stelle bereits die neue TAAIM Funktion CALL-FRAG verwendet wird, prüft die TAA bei der Ausführung in dem Batchframework, ob das aufzurufende Modul die Operation DURCHFUEHREN kennt. Wenn nicht, wird auf die Operation UDEF geprüft, und diese ggf. verwendet. In allen anderen Fällen wird eine Oopsmeldung ausgegeben, und die Verarbeitung abgebrochen.

Das Batch Framework verwendet nach dem Aufruf die TAAIM Funktion GET-STATE um den Zustand abzufragen. Diese wird aber von der CALL Funktion allerdings bereits gesetzt. In OM-Neu ist dieser Funktion sogar ein No-Op, der keine Funktionalität hat. Außerdem wird hier der falsche Name (MW-BATCH-PROZESS-STR-GEVO) verwendet, was in TAA zu einem Fehler führt.

Bei der Ausführung innerhalb des Batch Framework wird diese Situation erkannt, und ignoriert.

Für Gevo-Steuerungen (i.e. GEVO, GVTL, BSTR) werden sog. EXEC GEVES Anweisungen generiert, die vom COBOL Preprozessor in Aufrufe von VO-D-GEVES-API umgesetzt werden, ggfs. wird auch die SYSTVAR angepasst. Deswegen sollte die SYSTVAR in der Schnittstellenbeschreibung vorhanden sein. Dies ist aber nicht immer der Fall, wodurch deas SYSTVAR Objekt machmal nicht verfügbar ist, und die Verarbeitung nicht durchgeführt werden kann. (TFS119605)

Bei generierte Gevo-Steuerungen die unterhalb von TAAWithCEL ausgeführt werden, wird die Schnittstelle des Moduls ggfs. impliziet erweitert un die SYSTVAR zur Verfügung gestellt bekommen.

Hier folgt eine Liste mit Punkten, die Workfloweigenschaften betreffen.

Hierbei handelt es sich um eine TAAIM Funktion, welche vom Batch Framework verwendet wird, um alle Workfloweigenschaften zurück zu setzten. Wenn wie hier beschrieben das Batch Framework angepasst wird, kann auf diese Funktion verzichtet werden.

Bei der Ausführung innerhalb des Batch Framework wird diese Funktion erkannt, und das Zurücksetzen aller Workfloweigenschaften gewährt.

Beim Bestücken der Workfloweigenschaften für den Verarbeitungskontext werden auch einige Workfloweigenschaften gesetzt, welche nicht in der WFLP-Tabelle definiert sind. Diese sind alle mit einem $-Zeichen präfixiert. (Details) Basierend auf den Namen und mit welchem Wert sie bestückt werden, sind es vermutlich Eigenschaften, wofür in der TAA eine Systemeigenschaft definiert ist, und mit einem Eintrag in der WFLP verknüpft werden kann.

Bei der Ausführung innerhalb des Batch Framework werden alle Eigenschaften, deren Namen mit einem $-Zeichen anfangen, ignoriert.