GTDA Lesen aus einem TLS

Mit dem Aufruf GTDA (get data) können Sie einen Block eines TLS (Terminal-spezifischer Langzeitspeicher) in den angegebenen Nachrichtenbereich einlesen. Der Blockname wird bei der Generierung vergeben (TLS-Anweisung bei KDCDEF).

Ein Teilprogramm eines Dialog-Vorgangs darf nur Blöcke des "eigenen" TLS lesen, also nur den TLS des LTERM-/LPAP-/OSI-LPAP-Partners, über den der Vorgang gestartet wurde.

Ein Teilprogrammlauf eines Asynchron-Vorgangs kann die Blöcke jedes  LTERM/LPAP/OSI-LPAP/Master-LPAP-Partners der UTM-Anwendung lesen.

Versorgen des KDCS-Parameterbereichs (1. Parameter)

Die folgende Tabelle zeigt die notwendigen Angaben im KDCS-Parameterbereich.

Funktion des Aufrufs	Einträge im KDCS-Parameterbereich
	KCOP	KCLA	KCRN	KCLT
Lesen aus einem TLS (im Dialog-Programm)	"GTDA"	Länge	Blockname	——
Lesen aus einem TLS (im Asynchron-Programm)	"GTDA"	Länge	Blockname	LTERM / LPAP / OSI-LPAP / Master-LPAP Name

Versorgen des 2. Parameters

Hier stellen Sie die Adresse des Nachrichtenbereichs bereit, in den openUTM die Nachricht einlesen soll.

Versorgen der Parameter
Feldname im KDCS-Parameterbereich	Inhalt
KCOP	"GTDA"
KCLA	Länge in Byte
KCRN	Blockname
KCLT	LTERM / LPAP / OSI-LPAP / Master-LPAP-Name / -

KDCS-Aufruf
1. Parameter	2. Parameter
KDCS-Parameterbereich	Nachrichtenbereich

C/C++-Makroaufruf
Makronamen	Parameter
KDCS_GDTA	(nb,la,rn,lt)

Rückgaben von openUTM
Nachrichtenbereich	Inhalt
	Daten
Feldname im KB-Rückgabebereich
KCRLM	tatsächliche Blocklänge
KCRCCC	Returncode
KCRCDC	interner Returncode

In den KDCS-Parameterbereich tragen Sie für den GTDA-Aufruf ein:

KCOP

im Feld KCOP den Operationscode GTDA.

KCLA

im Feld KCLA die Länge, in der die Daten aus dem TLS übertragen werden sollen.

KCRN

im Feld KCRN den Namen des Blocks des TLS, aus dem openUTM übertragen soll.

KCLT

nur bei Asynchron-Programmen:
im Feld KCLT der Name des LTERM/LPAP/OSI-LPAP/Master-LPAP-Partners, aus dessen TLS gelesen werden soll (von Dialog-Programmen wird dieses Feld nicht ausgewertet).

Beim KDCS-Aufruf geben Sie an:

1. Parameter

Die Adresse des KDCS-Parameterbereichs.

2. Parameter

Die Adresse des Nachrichtenbereichs, in den openUTM die Nachricht einlesen soll. Die Adresse des Nachrichtenbereichs geben Sie auch an, wenn Sie in KCLA die Länge 0 eintragen.

Makronamen

Wie Sie Makroaufrufe für C/C++ nutzen, ist in Abschnitt „C/C++-Makroschnittstelle" ausführlich beschrieben.

openUTM gibt zurück:

Nachrichtenbereich

im angegebenen Nachrichtenbereich die gewünschten Daten.

KCRLM

im Feld KCRLM die tatsächliche Länge der Daten im TLS, damit das Programm Abweichungen von der Angabe in KCLA feststellen kann (wichtig, wenn KCLA kleiner angegeben wurde). Ausnahme: Bei KCLA = 0 wird in KCRLM immer 0 zurückgegeben.

KCRCCC

im Feld KCRCCC den KDCS-Returncode, siehe nächste Seite.

KCRCDC

im Feld KCRCDC den internen Returncode von openUTM (siehe openUTM-Handbuch „Meldungen, Test und Diagnose“).

KDCS-Returncodes im Feld KCRCCC beim GTDA-Aufruf

Im Programm sind auswertbar:

000	Die Operation wurde ausgeführt.
40Z	Das System kann die Operation nicht ausführen (Generierungs- bzw. Systemfehler, Deadlock, Timeout), siehe KCRCDC.
41Z	Der Aufruf wurde im ersten Teil des Anmelde-Vorgangs gegeben, obwohl dies in der Generierung nicht erlaubt wurde (SIGNON= in der MAX Anweisung).
43Z	Die Längenangabe in KCLA ist ungültig (z.B. negativ).
44Z	Der Name des Blocks in KCRN ist unbekannt oder ungültig.
46Z	Der  LTERM/LPAP/OSI-LPAP/Master-LPAP-Name in KCLT ist ungültig (nur bei Asynchron-Programmen).
47Z	Der Nachrichtenbereich fehlt oder ist in der angegebenen Länge nicht zugreifbar.

Ein weiterer Returncode ist dem DUMP zu entnehmen:

71Z	In diesem Programm wurde kein INIT gegeben.

Eigenschaften des GTDA-Aufrufs

• Ein GTDA-Aufruf sperrt den Zugriff auf den angesprochenen TLS-Block für alle konkurrierenden Teilprogramme. Alle anderen TLS-Blöcke des angesprochenen LTERM-, LPAP- oder OSI-LPAP-Partners-Partners sind frei.
  Mit dem Aufruf UNLK kann der TLS-Block explizit entsperrt werden.
  Bei den Aufrufen PEND RE/FI/SP/FC/RS/ER/FR und RSET wird der TLS-Block entsperrt.
  Bei PEND PA/PR/KP und PGWT KP/PR bleibt die Sperre erhalten.

  Wie openUTM reagiert, wenn der gewünschte TLS-Block gesperrt ist, ist in Abschnitt „Verhalten bei gesperrten Speicherbereichen (TLS, ULS und GSSB)" beschrieben.

• Der TLS-Block wird in der tatsächlichen Länge übertragen, höchstens jedoch in der bei KCLA angegebenen Länge. War der Inhalt von KCLA beim GTDA-Aufruf > 0, so wird die tatsächliche Länge der Daten im TLS im Feld KCRLM zurückgegeben.