Mit der Steueranweisung TAC werden Namen und Eigenschaften von Transaktionscodes und TAC-Queues der UTM-Anwendung festgelegt.
Transaktionscodes sind dabei „Rufnamen“ für Teilprogramme der Anwendung. Einem Transaktionscode müssen Sie immer einen Programmnamen (Operand PROGRAM=) zuweisen.
TAC-Queues sind anwendungsweite Message-Queues, die unabhängig von einem Teilprogramm existieren. Daher darf der Operand PROGRAM= nicht angegeben werden. TAC-Queues sind Service-gesteuert, d.h. für das Lesen von Nachrichten aus Queues sind die Teilprogramme der UTM-Anwendung verantwortlich, openUTM übernimmt - im Gegensatz zu Transaktionscodes - kein Scheduling.
Die Dead Letter Queue ist eine TAC-Queue mit dem festen Namen KDCDLETQ. Sie steht immer zur Verfügung, um Asynchron-Nachrichten an Transaktionscodes oder TAC-Queues zu sichern, die endgültig, d.h. nach evtl. erfolgter maximaler Anzahl erneuter Zustellungen, nicht verarbeitet werden konnten. Außerdem können Asynchron-Nachrichten an LPAP- oder OSI-LPAP-Partner gesichert werden, die wegen eines permanenten Fehlers nicht gesendet werden konnten und aus ihrer Message Queue gelöscht werden.
Die Nachrichten der Dead Letter Queue können mit DGET BF/BN gelesen und mit DADM MV/MA zur weiteren Verarbeitung in andere Message Queues verschoben werden. Beim Verschieben muss darauf geachtet werden, dass das neue Ziel vom gleichen Typ ist (Asynchron-TAC/TAC-Queue, LPAP-Partner oder OSI-LPAP-Partner). Details finden Sie im openUTM-Handbuch „Anwendungen programmieren mit KDCS“ beim KDCS-Aufruf DADM.
Für die Dead Letter Queue KDCDLETQ können Sie keine Nachrichten erzeugen oder verarbeiten.
Die Sicherung von Asynchron-Nachrichten in der Dead Letter Queue kann für jedes Nachrichtenziel einzeln durch den Parameter DEAD-LETTER-Q ein- und ausgeschaltet werden. Dieser Parameter steht in folgenden Anweisungen zur Verfügung:
in der TAC-Anweisung für Nachrichten an Asynchron-TACs oder TAC-Queues
in der LPAP-Anweisung für Asynchron-Nachrichten an LPAP-Partner
in der OSI-LPAP-Anweisung für Asynchron-Nachrichten an OSI-LPAP-Partner
Hauptaufträge zu Message-Komplexen mit negativen Quittungsaufträgen werden nie in der Dead Letter Queue gesichert.
Für die Dead Letter Queue wird bei der Generierung der Name KDCDLETQ erzeugt. Dabei werden folgende Eigenschaften gesetzt:
TYPE=Q, STATUS=ON, ADMIN=N, QMODE=STD, QLEV=32767
Die Eigenschaften dieser TAC-Queue können auch durch eine eigene TAC-Anweisung definiert werden.
Eine Nachricht einer TAC-Queue kann nicht verarbeitet werden, wenn die Transaktion zurückgesetzt wird, die den Aufruf DGET FT/NT oder PF/PN beinhaltet. Eine Nachricht an einen Asynchron-TAC kann nicht verarbeitet werden, wenn der gestartete Asynchron-Vorgang mit PEND ER/FR abnormal beendet wird, ohne vorher einen Sicherungspunkt erreicht zu haben.
Generieren von Transaktionscodes
Die Parameter QMODE, Q-READ-ACL und Q-WRITE-ACL sind für Transaktionscodes ohne Bedeutung.
Bei der Definition von Transaktionscodes für Teilprogramme, die Aufrufe der X/Open-Schnittstellen CPI-C oder XATMI enthalten, müssen Sie dem TAC mit dem Operanden API= das Kennzeichen für die verwendete Programmschnittstelle zuordnen.
Administrationskommandos, die Sie zur Administration der Anwendung nutzen wollen, müssen Sie ebenfalls als TAC definieren. Administrationskommandos können Sie als Dialog-TACs und als Asynchron-TACs generieren. Es muss mindestens ein Administrations-TAC (vorzugsweise das Administrationkommando KDCSHUT) generiert und in der Anwendung definiert sein. Außerdem muss mindestens ein Benutzer mit Administrationsberechtigung generiert werden.
Die Event-Services BADTACS, MSGTAC werden dadurch definiert, dass man TAC-Anweisungen mit den privilegierten TAC-Namen KDCBADTC und KDCMSGTC in die Generierung aufnimmt.
Ein Event-Service SIGNON (= Anmelde-Vorgang) kann auf mehrere Arten definiert werden:
durch den privilegierten TAC-Namen KDCSGNTC. Damit definieren Sie den Event-Service für den in MAX APPLINAME=appliname angegebenen Zugriffspunkt. Dieser Event-Service ist dann zugleich Standard für alle anderen Zugriffspunkte, die mit einer BCAMAPPL-Anweisung generiert werden.
durch BCAMAPPL appliname2,SIGNON-TAC=signon-tac zusammen mit TAC signon-tac. Damit definieren Sie einen eigenen Event-Service für den Zugriffspunkt appliname2. Auf diese Weise können Sie mehrere SIGNON-Services definieren.
Der mit KDCSGNTC generierte Event-Service ist Standard für alle anderen Zugriffspunkte, die mit einer BCAMAPPL-Anweisung generiert werden.
Für die Event-Services BADTACS, MSGTAC und SIGNON gelten für einige Operanden Voreinstellungen, die in unten stehender Tabelle aufgelistet sind. Diese Voreinstellungen können bei KDCBADTC, KDCMSGTC und KDCSGNTC nicht verändert werden. Bei TAC signon-tac heißt das, dass Sie die Werte so setzen müssen.
Operand in
TAC-AnweisungVoreinstellung bei
KDCBADTC KDCMSGTC KDCSGNTC bzw.
TAC signon-tacACCESS-LIST=
Leerzeichen
Leerzeichen
Leerzeichen
ADMIN=
NO
(frei wählbar)
NO
API=
KDCS
KDCS
KDCS
CALL=
FIRST
FIRST
BOTH
ENCRYPTION-LEVEL=
NONE
NONE
NONE
LOCK=
0
0
0
SATADM=
(BS2000-Systeme)NO
NO
NO
SATSEL=
(BS2000-Systeme)NONE
NONE
NONE
STATUS=
OFF
OFF
OFF
TACCLASS=
keine TAC-Klasse
16
keine TAC-Klasse
TYPE=
D
A
D
Diese Voreinstellungen bedeuten z.B., dass die Transaktionscodes KDCSGNTC, KDCBADTC und KDCMSGTC keinem Zugriffsschutz durch Keysets und Lockcodes unterliegen und weder vom Benutzer noch in einem FPUT- bzw. DPUT-Aufruf verwendet werden können.
Außerdem unterliegen die TACs KDCBADTC, KDCSGNTC und KDCMSGTC nicht der Bearbeitungssteuerung über die TAC-Klassen. Das gilt auch für KDCMSGTC, obwohl KDCMSGTC der TAC-Klasse 16 zugeordnet ist.
Weiterhin unterliegen alle TACs, die innerhalb eines Anmelde-Vorgangs laufen, nicht der Bearbeitungssteuerung über die TAC-Klassen.
Für KDCMSGTC ist DEAD-LETTER-Q=NO fest eingestellt und nicht änderbar.
Beachten Sie bei der Generierung der TACs Folgendes (nur BS2000-Systeme):
Die den TACs KDCBADTC, KDCMSGTC und KDCSGNTC und TAC signon-tac zugeordneten Programme dürfen keinem Lademodul zugeordnet werden, das erst beim ersten Aufruf eines seiner Teilprogramme nachgeladen werden soll (LOAD-MODULE-Anweisung mit LOAD-MODE=ONCALL).
Der Event-Exit VORGANG und die Teilprogramme des Vorgangs müssen im gleichen Lademodul liegen, wenn das Lademodul mit LOAD-MODE=ONCALL generiert wird.
Auf BS2000-Systemen können UTM-SAT-Administrationskommandos (Preselection-Kommandos) nur als Dialog-TACs generiert werden. Die Namen dieser TACs finden Sie im openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000-Systemen“.
Generieren von TAC-Queues
Für die Generierung einer TAC-Queue (TYPE=Q) sind nur die folgenden Operanden der TAC-Anweisung von Bedeutung:
tacname, ADMIN, DEAD-LETTER-Q, QLEV, QMODE, Q-READ-ACL, Q-WRITE-ACL, STATUS und TYPE.
Für die Dead Letter Queue KDCDLETQ können die Operanden ADMIN, QLEV, QMODE, Q-READ-ACL und STATUS frei verwendet werden.
Alle anderen Operanden werden für TAC-Queues nicht ausgewertet.
 | Näheres zu TAC-Queues und den damit möglichen Anwendungen finden Sie im openUTM-Handbuch „Konzepte und Funktionen“. |
|
|
2 nur auf Unix-, Linux- und Windows-Systemen
tacname | Max. 8 Zeichen langer Name des Transaktionscodes bzw. der TAC-Queue. tacname muss eindeutig sein und darf keinem weiteren Objekt der Namensklasse 1 zugeordnet sein. Siehe dazu auch Abschnitt "Eindeutigkeit der Namen und Adressen". | ||||
ACCESS-LIST= | keysetname Hiermit definieren Sie die Zugriffsrechte von Benutzern für diesen Transaktionscode. ACCESS-LIST= darf nicht zusammen mit dem Operanden LOCK=lockcode angegeben werden. Für keysetname müssen Sie den Namen eines Keysets angeben. Das Keyset muss mit einer KSET-Anweisung definiert werden. Ein Benutzer kann nur dann auf den Transaktionscode zugreifen, wenn das Keyset des Benutzers (USER ...,KSET=), das Keyset des LTERM-Partners, über den der Benutzer angemeldet ist, und das in keysetname angegebene Keyset mindestens einen gemeinsamen Keycode enthalten. Geben Sie weder ACCESS-LIST=keysetname noch LOCK=lockcode an, dann ist der Transaktionscode nicht geschützt und jeder Benutzer kann den Transaktionscode aufrufen. Standard: kein Keyset | ||||
ADMIN= | gibt an, welche Berechtigung der Benutzer benötigt, um diesen Transakionscode oder diese TAC-Queue aufrufen zu können, bzw. einen Vorgang, der diesen Transaktionscode als Folge-TAC enthält. | ||||
YES | Bedeutung für einen TAC (TYPE=A oder D): Bedeutung für eine TAC-Queue (TYPE=Q): | ||||
NO | Für diesen TAC bzw. diese TAC-Queue ist keine Administrationsberechtigung nötig. | ||||
READ | Für diesen TAC bzw. diese TAC-Queue ist keine Administrationsberechtigung nötig. In dem zugehörigen Administrationsprogramm können ausschließlich die Funktionen der Programmschnittstelle für die Administration genutzt werden, die lesend auf die Anwendungsdaten zugreifen (nur KDCADMI mit Operationscode KC_GET_OBJECT). | ||||
API= | Programmschnittstelle, die das zum Transaktionscode gehörende Teilprogramm verwendet. Pflichtoperand, wenn eine der X/Open-Schnittstellen CPI-C oder XATMI verwendet wird. | ||||
KDCS | Das Teilprogramm ist ein KDCS-Programm. Standard: KDCS | ||||
(XOPEN,CPIC) | Das Teilprogramm ist ein CPI-C-Programm. | ||||
(XOPEN,XATMI) | Das Teilprogramm ist ein XATMI-Programm. | ||||
CALL= | gibt an, ob mit dem Transaktionscode ein Service gestartet wird, d.h. erster TAC eines Vorgangs, oder ob er Folge-TAC in einem Vorgang ist. | ||||
BOTH | Der TAC kann erster TAC oder Folge-TAC in einem Vorgang sein. Standard: BOTH | ||||
FIRST | Der TAC kann nur erster TAC in einem Vorgang sein. | ||||
NEXT | Der TAC kann nur Folge-TAC in einem Vorgang sein. Er kann nur mit STATUS=HALT gesperrt werden. Es können keine Asynchron-Aufträge an diesen TAC erzeugt werden. CPI-C-Programme müssen mit CALL=FIRST oder BOTH generiert werden.XATMI-Programme müssen mit CALL=FIRST generiert werden. | ||||
DBKEY= | dbkey Dieser Operand gilt nur für BS2000-Systeme. Er ist nur relevant, wenn das Teilprogramm Datenbankaufrufe absetzt. dbkey ist ein maximal 8 Zeichen langer Name, unter dem die Aktivitäten dieses Transaktionscodes beim Datenbanksystem registriert werden. Das Format des Schlüssels ist abhängig vom verwendeten Datenbanksystem. Der DBKEY wird nur bei UDS-Datenbanken verwendet und dient dort als gesonderte Kennzeichnung der Aktivität im UDS-Monitor ("Programmname"). Bei Vorgängerversionen von openUTM wurde dieser Name auch im Rahmen der Rechteprüfung genutzt (daher auch die Bezeichnung DBKEY). Siehe dazu das Kapitel „BPRIVACY“ im UDS/SQL-Handbuch „Aufbauen und Umstrukturieren“. Standard: UTM Der Standardwert DBKEY=UTM bewirkt, dass der Wert des Startparameters DBKEY an der Schnittstelle zur Datenbank übergeben wird (siehe openUTM-Handbuch „Einsatz von UTM-Anwendungen“, Startparameter). | ||||
DEAD-LETTER-Q= | gibt an, ob Asynchron-Nachrichten dieser Message Queue nach einer nicht ordnungsgemäßen Verarbeitung und nicht erfolgter Redelivery in der Dead Letter Queue gesichert werden sollen. Die Überwachung der Anzahl Nachrichten in der Dead Letter Queue wird mit der Anweisung MAX ...,DEAD-LETTER-Q-ALARM ein- bzw. ausgeschaltet. | ||||
YES | Nachrichten an diesen Asynchron-TAC oder diese TAC-Queue, die nicht verarbeitet werden konnten, werden in der Dead Letter Queue gesichert, sofern sie nicht erneut zugestellt werden (Redelivery) und (bei Message-Komplexen) kein negativer Quittungsauftrag definiert wurde. | ||||
NO | Nachrichten an diesen Asynchron-TAC oder diese TAC-Queue, die nicht verarbeitet werden konnten, werden nicht in der Dead Letter Queue gespeichert. Standard: NO Hauptaufträge zu Message-Komplexen (MCOM) mit negativen Quittungsaufträgen werden nie in der Dead Letter Queue gesichert, da im Fehlerfall die negativen Quittungsaufträge aktiviert werden. Wird die Anzahl der Nachrichten der Dead Letter Queue mit QLEV beschränkt, können im Fehlerfall Nachrichten von Asynchron-TACs oder TAC-Queues verloren gehen. Wird auf die Beschränkung der Anzahl verzichtet, muss der Pagepool von openUTM ausreichend groß generiert werden. Droht ein Pagepool-Engpass, kann die Dead Letter Queue im laufenden Betrieb mit STATUS=OFF gesperrt werden. | ||||
ENCRYPTION-LEVEL= | |||||
legt die minimale Verschlüsselungsebene fest, die für einen Vorgang eingehalten werden muss, der über diesen Transaktionscode gestartet wird. Die hier festgelegte Verschlüsselungsebene gilt für alle Nachrichten, die in dem Vorgang gesendet und empfangen werden. und für Socket-Clients, die sich über einen als sicher generierten Anwendungsnamen anmelden (BCAMAPPL T‑PROT=(SOCKET,...,SECURE)), sowie auf BS2000-Systemen zusätzlich für Terminalemulationen, die Verschlüsselung unterstützen. | |||||
NONE | Eine Nachrichtenverschlüsselung ist nicht erforderlich. Standard: NONE | ||||
2 | 5 | Mit diesem Transaktionscode kann nur dann ein Vorgang gestartet werden, wenn die Eingabe-Nachricht vom Client verschlüsselt übertragen wird. Dialog-Ausgabe-Nachrichten des Vorgangs werden verschlüsselt an den Client übertragen. Der Wert bestimmt den Algorithmus, der zur Verschlüsselung verwendet werden sol.
Bezogen auf den Encryption-Level der Verbindung (PTERM, TPOOL) bedeutet das:
Verschlüsselt ein Client die erste Eingabe-Nachricht nicht mindestens mit der geforderten Verschlüsselungsebene oder unterstützt er keine Verschlüsselung, so wird der Vorgang nicht gestartet. Dabei gelten folgende Ausnahmen:
Wird der Transaktionscode ohne Benutzerdaten aufgerufen oder durch Vorgangskettung gestartet, dann muss der Client die Fähigkeit zur Verschlüsselung haben, da openUTM alle Dialog-Ausgabe-Nachrichten verschlüsselt überträgt, und, bei Mehrschritt-Vorgängen, alle weiteren Eingabe-Nachrichten vom „not-trusted“ Client verschlüsselt erwartet. ENCRYPTION-LEVEL=2 | 5 dürfen Sie nur für Transaktionscodes angeben, mit denen ein Vorgang gestartet wird (CALL=FIRST oder CALL=BOTH). In Anwendungen, in denen die Verschlüsselungsfunktionen nicht verfügbar sind , können Transaktionscodes mit ENCRYPTION-LEVEL= 2 | 5 nur von Clients gestartet werden, die als vertrauenswürdig (trusted) generiert sind. | ||||
EXIT= | conversation_exit Name des Event-Exits VORGANG, der diesem TAC zugeordnet werden soll. EXIT= darf nur zusammen mit CALL=FIRST oder CALL=BOTH angegeben werden. Der Event-Exit VORGANG muss mit einer eigenen PROGRAM-Anweisung definiert werden. Standard: Kein Event-Exit VORGANG | ||||
LOCK= | lockcode Lockcode, der dem Transaktionscode eines Services als logisches Zahlenschloss zugeordnet ist. lockcode ist eine Zahl zwischen 1 und dem in der Anwendung erlaubten Maximalwert (MAX ...,KEYVALUE=number). Darf nicht zusammen mit dem Operanden ACCESS-LIST= angegeben werden. Zur Zugriffskontrolle können Keysets sowohl für (UTM-)Benutzerkennungen (USER) als auch für die LTERM-/(OSI-)LPAP-Partner definiert werden. Ein mit Lockcode gesicherter Service kann dann nur gestartet werden, wenn im Keyset Benutzerkennung und im Keyset des LTERM- /(OSI-)LPAP-Partners ein mit dem Lockcode übereinstimmender Keycode enthalten ist. Services, deren TACs nicht durch einen Lockcode oder eine ACCESS-LIST gesichert sind, können unter jeder Benutzerkennung und von jedem LTERM-/(OSI-)LPAP-Partner aus ohne Einschränkung aufrufen. Ausführliche Informationen zum Lock-/Keycode- sowie zum Access-List-Konzept finden Sie im openUTM-Handbuch „Konzepte und Funktionen“. ACHTUNG! Standard: 0 (der TAC ist nicht mit Lockcode gesichert) | ||||
PGWT | dürfen Sie nur angeben, wenn in Ihrer Anwendung die Aufträge an TAC-Klassen prioritätengesteuert bearbeitet werden, d.h. die KDCDEF-Generierung enthält die Anweisung TAC-PRIORITIES. Mit PGWT legen Sie fest, ob in einem Teilprogrammlauf, der für diesen Transaktionscode gestartet wird, blockierende Aufrufe (z.B. PGWT) durchgeführt werden dürfen. | ||||
YES | Blockierende Aufrufe dürfen durchgeführt werden. Geben Sie PGWT=YES an, dann müssen Sie den Transaktionscode einer TAC-Klasse zuordnen, d.h. Sie müssen TACCLASS= setzen. Folgende Fälle sind zu beachten:
| ||||
NO | Blockierende Aufrufe dürfen nicht durchgeführt werden. Standard: NO | ||||
PROGRAM= | objectname Name des Teilprogramms, dem dieser TAC zugeordnet werden soll. Für Asynchron- und Dialog-TACs muss ein Programmname generiert werden; für TAC-Queues ist der Parameter PROGRAM verboten. Standard: Leerzeichen, d.h. kein Programmname Falls das Programm im Betrieb der Anwendung nicht geladen ist oder die Zugriffsrechte den Aufruf nicht erlauben, dann ruft openUTM den Dialog-Vorgang BADTACS auf. Ist BADTACS in der Anwendung nicht generiert, dann gibt openUTM stattdessen die Meldung K009 aus. | ||||
QLEV= | queue_level_number (queue level) Soll nach dem Erreichen des QLEV eine weitere Nachricht erzeugt werden, so ist das Verhalten von openUTM abhängig von der Einstellung bei QMODE= (siehe dort). Standard: 32767 | ||||
QMODE = | (Queue Mode) | ||||
STD | Ist zum Zeitpunkt des FPUT- oder DPUT-Aufrufs die Anzahl der in dieser Queue gespeicherten Nachrichten größer oder gleich der in QLEV= generierten Maximalzahl, so wird der FPUT- oder DPUT-Aufruf mit 40Z abgewiesen bzw. mit einer Meldung abgelehnt, wenn dieser TAC von einer Datensichtstation aus eingegeben wird. | ||||
WRAP-AROUND | |||||
nur für TACs mit TYPE=Q (TAC-Queues): Standard: STD | |||||
Q-READ-ACL= | read-keysetname Dieser Parameter wird nur für TACs mit TYPE=Q (TAC-Queues) ausgewertet. Mit diesem Parameter werden die Rechte festgelegt, die ein Benutzer benötigt, um Nachrichten aus dieser Queue lesen und löschen zu können. Bei diesem Parameter kann der Name eines KSETs angegeben werden, der mit einer KSET-Anweisung definiert ist. In diesem Fall kann ein Benutzer nur dann lesend auf diese TAC-Queue zugreifen, wenn der Schlüsselbund (KSET) des Benutzers und der Schlüsselbund des logischen Terminals, über das der Benutzer angemeldet ist, jeweils mindestens einen Schlüssel enthalten, der auch in dem hier angegebenen Schlüsselbund enthalten ist. Wird bei Q-READ-ACL kein Schlüsselbund angegeben, dann können alle Benutzer Nachrichten aus dieser Queue lesen und dabei löschen. Standard: kein Schlüsselbund | ||||
Q-WRITE-ACL= | write-keysetname Dieser Parameter wird nur für TACs mit TYPE=Q (TAC-Queues) ausgewertet. Er darf für die Dead Letter Queue nicht angegeben werden. Mit diesem Parameter werden die Rechte festgelegt, die ein Benutzer benötigt, um Nachrichten in diese Queue schreiben zu können. Bei diesem Parameter kann der Name eines KSETs angegeben werden, der mit einer KSET-Anweisung definiert ist. In diesem Fall kann ein Benutzer nur dann schreibend auf diese TAC-Queue zugreifen, wenn der Schlüsselbund (KSET) des Benutzers und der Schlüsselbund des logischen Terminals, über das der Benutzer angemeldet ist, jeweils mindestens einen Schlüssel enthalten, der auch in dem hier angegebenen Schlüsselbund enthalten ist. Wird bei Q-WRITE-ACL kein Schüsselbund angegeben, dann können alle Benutzer Nachrichten in diese Queue schreiben. Standard: kein Schlüsselbund | ||||
RTIME= | rtime Dieser Operand gilt nur für Unix-, Linux- und Windows-Systeme. Realzeit in Sekunden, die ein Teilprogramm maximal verbrauchen darf, wenn es über diesen TAC gestartet wird. Läuft das Teilprogramm länger, bricht openUTM den Vorgang ab und gibt eine Fehlermeldung aus (K017 mit Ursache 70Z/XTnn, siehe openUTM-Handbuch „Meldungen, Test und Diagnose auf Unix-, Linux- und Windows-Systemen“). Die Überwachung des Teilprogrammlaufs umfasst auch den PEND/PGWT-Aufruf inklusive etwaigen Datenbank-Aufrufen. Bei PGWT-Aufrufen ist auch die PGWT-Wartezeit mit eingeschlossen, d.h. Sie müssen bei RTIME die maximale Wartezeit in PGWT (MAX PGWTTIME) mit berücksichtigen. rtime = 0 bedeutet, dass der Realzeit-Verbrauch des Teilprogramms nicht überwacht wird. Standard: 0 | ||||
RUNPRIO= | priority Dieser Operand gilt nur für BS2000-Systeme. Er ordnet dem TAC eine Run-Priorität des BS2000-Systems zu. Diese Run-Priorität wird dem UTM-Prozess zugeordnet, in dem das Teilprogramm (Operand PROGRAM) abläuft. So können Sie die Scheduling Mechanismen des BS2000-Systems zur Ablaufsteuerung von UTM-Teilprogrammen einsetzen. Der Operand RUNPRIO hat jedoch keinen Einfluss auf den Zeitpunkt, zu dem openUTM ein Teilprogramm startet. Beim Start eines Teilprogramms versucht openUTM, die Run-Priorität des aktuellen Prozesses auf den Wert zu setzen, der mit RUNPRIO für den aktuellen TAC generiert wurde. Ist die generierte Run-Priorität nicht mit den JOIN-Einträgen der entsprechenden Benutzerkennung verträglich, dann wird die Run-Priorität des aktuellen Prozesses nicht geändert. openUTM gibt eine entsprechende K-Meldung aus. Sind die maximal erlaubten RUNPRIO-Werte für die Benutzerkennung und die Jobklasse unterschiedlich, so wird der für den Benutzer günstigere Wert erlaubt. Sind keine JOIN-Einträge vorhanden, wird die in RUNPRIO angegebene Run-Priorität gesetzt. Nach Beendigung eines Teilprogramms setzt openUTM die Run-Priorität wieder auf den ursprünglich eingestellten Wert zurück, es sei denn, die Run-Priorität wurde während des Teilprogrammlaufs mit dem CHANGE- TASK-PRIORITY-Kommando nochmals geändert. In diesem Fall wird die von außen eingestellte Run-Priorität nach Teilprogrammende beibehalten. Wird RUNPRIO=0 angegeben, dann ist für diesen TAC keine TAC-spezifische Run-Priorität generiert. Standard: 0 | ||||
SATADM= | Dieser Operand gilt nur für BS2000-Systeme. Er legt fest, ob zum Aufruf des TACs die UTM-SAT-Administrationsberechtigung nötig ist. | ||||
YES | Der TAC kann nur von Benutzern/Clients bzw. von Partner-Anwendungen aufgerufen werden, für die in der USER-, LPAP bzw. OSI-LPAP-Anweisung die Administrationsberechtigung für die SAT-Protokollierung (PERMIT=SATADM) generiert wurde. | ||||
NO | Zur Nutzung des TACs muss der Benutzer/Client oder die Partner-Anwendung keine UTM-SAT-Administrationsberechtigung haben. | ||||
SATSEL= | Dieser Operand gilt nur für BS2000-Systeme. Er legt die Art der SAT-Protokollierung der Ereignisse beim Ablauf des Teilprogramms fest, das mit diesem TAC aufgerufen wird. Bei eingeschalteter SAT-Protokollierung (MAX ...,SAT=ON) werden dann während eines Programmlaufs unter diesem TAC die TAC-spezifischen Ereignisse entsprechend der Angaben für SATSEL protokolliert. Die Art der SAT-Protokollierung kann allgemein für alle TACs und Benutzer in der SATSEL-Anweisung festgelegt werden. Der Operand SATSEL in der TAC-Anweisung legt zusätzlich zu den Angaben in der SATSEL-Anweisung eine TAC-spezifische Protokollierung fest. Wird die Protokollierung einer Ereignisklasse in der SATSEL-Anweisung ausgeschlossen, so werden Ereignisse dieser Klasse nicht protokolliert. (Zur Verknüpfung der EVENT-, TAC- und USER-spezifischen Einstellung der Protokollierung siehe openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000-Systemen“.) | ||||
BOTH | Es werden erfolgreiche und nicht erfolgreiche Ereignisse protokolliert. | ||||
SUCC | Es werden nur erfolgreiche Ereignisse protokolliert. | ||||
FAIL | Es werden nur nicht erfolgreiche Ereignisse protokolliert. | ||||
NONE | Es wird keine TAC-spezifische Art der SAT-Protokollierung definiert. Standard: NONE | ||||
STATUS= | legt fest, ob der TAC oder die TAC-Queue beim Anwendungsstart gesperrt oder freigegeben ist. | ||||
ON | Bedeutung für TACs: Der TAC ist nicht gesperrt und nach dem Start der Anwendung solange verfügbar, bis der Administrator ihn sperrt. Bedeutung für TAC-Queues: Für diese Queue ist Schreiben und Lesen erlaubt. Standard: ON | ||||
OFF | Für TACs: Der TAC ist nach dem Start der Anwendung gesperrt. Aufträge für diesen TAC werden erst angenommen, wenn ihn der Administrator freigibt. Handelt es sich um den TAC eines KDCS-Teilprogramms und ist er mit CALL=BOTH oder CALL=NEXT generiert, dann ist der TAC als Vorgangs-TAC (1. TAC eines Vorgangs) gesperrt, aber nicht als Folge-TAC eines Vorgangs. Bedeutung für TAC-Queues: Die Queue ist für Schreibzugriffe gesperrt; Lesezugriffe sind erlaubt. | ||||
HALT | Der TAC ist nach dem Start der Anwendung vollständig gesperrt, d.h. auch als Folge-TAC in einem Asynchron- oder Dialog-Vorgang. Wenn dieser TAC als Folge-TAC aufgerufen wird, dann wird der Vorgang mit PEND ER (74Z) beendet. Der TAC muss vom Administrator freigegeben werden. Asynchron-Aufträge, die bereits in der Message Queue des TACs zwischengespeichert sind, werden nicht gestartet. Sie bleiben in der Message Queue, bis der Status des TACs vom Administrator wieder auf ON oder OFF gesetzt wird. Bedeutung für TAC-Queues: Die Queue ist für Lese- und Schreibzugriffe gesperrt. | ||||
KEEP | darf nur für TAC-Queues sowie für Asynchron-Transaktionscodes angegeben werden, die auch Vorgangs-TACs (CALL=BOTH oder CALL=FIRST) sind. STATUS=KEEP können Sie benutzen, um Aufträge zu sammeln, die erst zu einem Zeitpunkt ausgeführt werden sollen, an dem die Anwendung weniger belastet ist (z.B. nachts). Um eine Überlastung des Pagepools durch zuviele zwischengespeicherte Aufträge zu vermeiden, sollten Sie die Auftragswarteschlange des Transaktionscodes durch den Parameter QLEV begrenzen. Bedeutung für TAC-Queues: Die Queue ist gegen Lesen gesperrt; Schreiben ist erlaubt. Für die Administrationskommandos KDCSHUT und KDCTAC wird der Status immer auf ON gesetzt, auch wenn Sie einen anderen Wert für STATUS angeben. Auf diese Weise bleibt Ihre Anwendung administrierbar. | ||||
TACCLASS= | tacclass Ordnet den Transaktionscode einer TAC-Klasse zu. Die TAC-Klassen werden für die Steuerung der Bearbeitung von Dialog- und Asynchron-Aufträgen benötigt. Aufträge, die unterschiedlichen TAC-Klassen zugeordnet sind, werden von openUTM nach unterschiedlichen Kriterien gestartet. Über die TAC-Klasse, der ein Transaktionscode zugeordnet ist, wird gesteuert, ob ein Auftrag sofort bearbeitet oder zunächst in der Message Queue des Transaktionscodes zwischengespeichert wird, und wann er aus der Message Queue gelesen und bearbeitet wird. Für die Steuerung der Auftragsbearbeitung stehen zwei verschiedene Verfahren zur Verfügung (siehe Abschnitt "Auftragsbearbeitung über Prioritäten steuern"). Die folgenden Zahlenwerte sind zulässig:
Werden Asynchron-TAC-Klassen generiert, so muss der Wert MAX ...,ASYNTASKS einen Wert größer 0 haben. Ist Ihre Anwendung ohne TAC-PRIORITIES-Anweisung generiert und durchläuft das zu diesem TAC gehörende Teilprogramm blockierende Aufrufe (z.B. den KDCS-Aufruf PGWT), dann müssen Sie für tacclass die Dialog- bzw. Asynchron-TAC-Klasse angeben, für die TACCLASS PGWT=YES gesetzt ist. Ist Ihre Anwendung mit TAC-PRIORITIES-Anweisung generiert, dann können Sie diese TACs jeder beliebigen Dialog- bzw. Asynchron-TAC-Klasse zuordnen. Sie müssen dann lediglich TAC ...,PGWT=YES setzen. Standard für Dialog-TACs: Standard für Asynchron-TACs: Ist der Transaktionscode mit PGWT=YES generiert, dann müssen Sie den Transaktionscode einer TAC-Klasse zuordnen. | ||||
TACUNIT= | tacunit legt die Anzahl der Verrechnungseinheiten fest, die in der Abrechnungsphase des UTM-Accounting für jeden Aufruf dieses Transaktionscodes berechnet wird. Die Verrechnungseinheiten werden auf den Verrechnungseinheitenzähler der Benutzerkennung aufaddiert, die den Transaktionscode aufgerufen hat. Standardwert: 1 | ||||
TCBENTRY= | name_of_tcbentry_statement Dieser Operand gilt nur für BS2000-Systeme. Nur relevant bei Transaktionscodes von Teilprogrammen, die mit PROGRAM ...,COMP=COB1 generiert sind. name_of_tcbentry_statement bezeichnet den Namen einer TCBENTRY-Anweisung, in der die TCB-Entries zusammengefasst wurden, die diesem TAC zugeordnet werden. Standard: Kein Name | ||||
TIME= | Dieser Operand gilt nur für BS2000-Systeme. CPU-Verbrauch und reale Laufzeit für Teilprogramm kontrollieren. | ||||
time1 | CPU-Zeit in Millisekunden, die das Teilprogramm mit diesem TAC während einer Verarbeitung maximal verbrauchen darf. Läuft das Teilprogramm länger, bricht openUTM den Vorgang mit einer Meldung ab: K017 bei Dialog-Programmen, K055 bei Asynchron-Programmen, KCRCCC ist 70Z, KCRCDC ist XT20 (siehe openUTM-Handbuch „Meldungen, Test und Diagnose auf BS2000-Systemen“). Der Wert 0 bedeutet, dass für das Teilprogramm, das über diesen TAC gestartet wurde, keine Zeitüberwachung erfolgen soll. Die Werte 1 bis 999 sind unzulässig und werden durch den Wert 1000 ersetzt. Standard: 30.000 ms ACHTUNG! Bei KDCSHUT WARN kann in Anwendungen mit vielen generierten Terminals mehr CPU-Zeit benötigt werden, als der Standardwert zulässt. Siehe dazu openUTM-Handbuch „Anwendungen administrieren“. Analoges gilt, wenn Sie bei großen Anwendungen mit KDCDIAG DUMP=YES einen Diagnose-Dump anfordern. | ||||
time2 | Realzeit in Sekunden, die das Teilprogramm mit diesem TAC während einer Verarbeitung maximal verbrauchen darf. Läuft das Teilprogramm länger, bricht openUTM den Vorgang mit einer Meldung ab: K017 bei Dialog-Programmen, K055 bei Asynchron-Programmen, KCRCCC ist 70Z, KCRCDC ist XTA0 (siehe openUTM-Handbuch „Meldungen, Test und Diagnose auf BS2000-Systemen“). Der Wert 0 bedeutet, dass für das Teilprogramm, das über diesen TAC gestartet wurde, keine Überwachung des realen Zeitverbrauchs erfolgen soll. Die Überwachung des Teilprogrammlaufs umfasst auch den PEND/PGWT-Aufruf inklusive etwaigen Datenbank-Aufrufen. Bei PGWT-Aufrufen ist auch die PGWT-Wartezeit mit eingeschlossen, d.h. Sie müssen bei TIME=(...,time2) die maximale Wartezeit in PGWT (MAX PGWTTIME) mit berücksichtigen. Standard: 0 s | ||||
TYPE= | gibt an, ob Aufträge an diesen Transaktionscode im Dialog oder asynchron bearbeitet werden oder ob eine TAC-Queue generiert wird. | ||||
D | Dieser TAC ist ein Dialog-Transaktionscode, d.h. ein Auftrag mit diesem TAC wird im Dialog mit dem Auftraggeber bearbeitet. Standard: D | ||||
A | Dieser TAC ist ein Asynchron-Transaktionscode, d.h. ein Auftrag mit diesem TAC erzeugt einen Asynchron-Auftrag in der Message Queue des Transaktionscodes. Die Bearbeitung erfolgt entkoppelt vom Auftraggeber. | ||||
Q | Mit dieser TAC-Anweisung wird eine TAC-Queue generiert. In eine solche Queue kann mit einem FPUT- oder DPUT-Aufruf eine Nachricht geschrieben und aus der Queue kann mit einem DGET-Aufruf gelesen werden. | ||||