KDCINF Syntax-Beschreibung

---

KDCINF      type

           [ ,LIST={ KDCNAMES | (name_1,...,name_10) | KDCALL | KDCCON } ]

           [ ,OUT={ KDCDISP | KDCPRINT | KDCBOTH | ltermname | tacname } ]

           [ ,CONT={ name | (name,proname) | (name,proname,bcamname) } ]

           [ ,PRONAM=proname]

           [ ,LPAP=lpapname ]                    (nur bei type = LSES)

           [ ,OSI-LPAP=osilpapname ]             (nur bei type = OSI-ASSOCIATIONS)

                       Nur auf BS2000-Systemen:

           [ ,OPTION=MONITORING ]                (nur bei type = MUX)

---

Für die Administration über Message Queuing müssen Sie KDCINFA angeben.

type		Typ der Objekte bzw. Anwendungsparameter, über die openUTM informieren soll. Für type können Sie einen der folgenden Werte angeben:

ALL KSET LTERM PAGEPOOL POOL	PROG PTERM STATISTICS SYSLOG SYSPARM	TAC TACCLASS TAC-PROG USER
Zur Abfrage von Informationen über die Objekte der verteilten Verarbeitung können Sie für type folgende Werte angeben:
CON LPAP LSES LTAC	OSI-ASSOCIATIONS OSI-CON OSI-LPAP
In UTM-Anwendungen auf BS2000-Systemen können Sie für type auch angeben:
LOAD-MODULE	MUX
In UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen können Sie für type auch angeben:
SHARED-OBJECT

	Die Angaben für type haben die folgende Bedeutung:
	ALL	fordert eine Gesamtinformation über alle Objekte, Statistikwerte und Anwendungsparameter an. Das Ergebnis von KDCINF ALL wird immer auf dem Standard-System-Drucker (im Betriebsystem voreingestellter Drucker) ausgegeben. Die Steuerung der Ausgabe über den Operanden OUT ist nicht möglich, Angaben für OUT werden ignoriert. Für den Operanden LIST werden nur die Operandenwerte KDCNAMES (Standard) und KDCALL berücksichtigt. Bei der Kombination ALL und LIST=KDCNAMES werden die Namen aller Objekte ausgegeben, jedoch keine Anwendungsparameter und keine Statistikinformationen. Bei der Kombination ALL und LIST=KDCALL werden alle Anwendungsparameter, Statistikwerte und die Eigenschaften aller Objekte ausgegeben. In UTM-Anwendungen auf BS2000-Systemen wird bei KDCINF ALL, LIST=KDCALL keine Information über Lademodule ausgegeben. Bei KDCINF ALL bleiben Angaben für die Operanden CONT, OUT, PRONAM ohne Wirkung.
	KSET	Informieren über die Keysets der Anwendung. Die Information über ein bestimmtes Keyset (Verwendung von LIST=kset_name) können Sie sich am Administrator-Terminal ausgeben lassen. Wollen Sie sich über mehrere oder alle Keysets informieren, dann erfolgt die Ausgabe immer am Standard-System-Drucker. Angaben für den Operanden OUT bleiben ohne Wirkung. Ausnahme Wurde bei der KDCDEF-Generierung in der MAX-Anweisung für den Operanden KEYVALUE ein Wert größer als 255 angegeben, dann können Sie mit KDCINF keine Informationen über Keysets (type = KSET) abfragen. Das KDCINF-Kommando wird in diesem Fall mit der Meldung „KEYVALUE > 255 NOT SUPPORTED“ abgewiesen. Sie können sich jedoch mit Hilfe der Programmschnittstelle zur Administration ein eigenes Administrationsprogramm zur Abfrage der Information erstellen (KC_GET_OBJECT-Aufruf mit Objekttyp KC_KSET).
LOAD-MODULE (nur auf BS2000-Systemen)
		Informieren über Lademodule. Der Umfang der Ausgabe kann mit den Operanden CONT und LIST gesteuert werden. Bei LIST ist nur die Angabe von KDCNAMES oder eines einzelnen Lademodul-Namens erlaubt. Bei LIST=KDCNAMES wird eine Liste aller Lademodul-Namen ausgegeben. Informationen über ein bestimmtes Lademodul erhalten Sie, wenn Sie für LIST den Namen des Lademoduls angeben. Geben Sie in LIST den Namen eines Lademoduls an, dann wird die Angabe in CONT als Programmname interpretiert. Die Angabe in CONT bestimmt dann, mit welchem Teilprogrammnamen die Liste der im Lademodul enthaltenen Teilprogramme beginnt.
LTERM		Informieren über LTERM-Partner, d.h. über logische Namen und Eigenschaften von Clients und Druckern. Der Umfang der Ausgabe kann mit den Operanden CONT und LIST gesteuert werden. Ist einem LTERM-Partner ein Druckerbündel (mehrere Drucker, d.h. PTERMs) zugeordnet, dann können Sie sich mit folgendem Kommando die Liste der zum LTERM gehörenden Drucker (PTERMs) anzeigen lassen. KDCINF LTERM, LIST=ltermname Ist das angegebene LTERM das Primary-LTERM einer LTERM-Gruppe, so werden die Primary- und Gruppen-LTERMs der LTERM-Gruppe ausgegeben (siehe openUTM-Handbuch „Anwendungen generieren“). Die Reihenfolge ist wie folgt: Die erste Zeile enthält das Primary-LTERM. Die Folgezeilen enthalten die Gruppen-LTERMs. Ist das angebene LTERM sowohl MASTER-LTERM eines LTERM-Bündels als auch Primary-LTERM seiner LTERM-Gruppe, so werden alle Master-, Primary-, Slave-und Gruppen-LTERMs ausgegeben. Die Reihenfolge ist wie folgt: Die erste Zeile enthält das Master-/primary-LTERM Dann folgen alle Gruppen-LTERMs Die Folgezeilen enthalten alle Slave-LTERMS. Als erstes steht hier das Slave-LTERM, an das die Nachrichten zugestellt werden. Der Aufruf KDCINF LTERM, LIST=master-lterm gibt die Master- und Slave-LTERMs eines LTERM-Bündels aus. Die Ausgabe erfolgt genauso wie beim Aufruf KDCINF LTERM, LIST=KDCALL: Die erste Zeile enthält das Master-LTERM. Die Folgezeilen enthalten die Slave-LTERMs.
MUX (nur auf BS2000-Systemen)
		Informieren über die Eigenschaften und den aktuellen Zustand von Multiplex-Anschlüssen.  Wird MUX zusammen mit dem Operanden OPTION=MONITORING angegeben, dann liefert openUTM zusätzlich Messwerte für die Multiplex-Verbindungen.  OPTION=MONITORING ist jedoch ohne Wirkung, wenn Sie LIST=KDCNAMES angeben.
PAGEPOOL		Informieren über die aktuelle Belegung des Pagepools. Zusammen mit PAGEPOOL hat nur der Operand OUT eine Wirkung. Angaben für die Operanden LIST, CONT und PRONAM werden von openUTM ignoriert.
POOL		Informieren über LTERM-Pools. Der Umfang der Ausgabe kann mit den Operanden CONT und LIST gesteuert werden.
PROG		ist nur zulässig, wenn die Anwendung mit Lademodulen/SharedObjects generiert ist (LOAD-MODULE-Anweisung (BS2000-Systeme) und SHARED-OBJECT-Anweisung (Unix-, Linux- und Windows-Systeme)). openUTM informiert über die Teilprogramme der Anwendung. Zu jedem Teilprogramm wird der Name des zugehörigen Lademoduls/Shared Objects/DLLs, dessen Lademodus und eine Aussage zu dessen Austauschbarkeit angezeigt. Der Umfang der Ausgabe kann mit den Operanden CONT und LIST gesteuert werden.
PTERM		Informieren über physische Eigenschaften von Clients und Druckern. Der Umfang der Ausgabe kann mit den Operanden CONT, LIST und PRONAM gesteuert werden.
SHARED-OBJECT (nur auf Unix-, Linux- und Windows-Systemen)
		ist nur zulässig, wenn die Anwendung mit SHARED-OBJECT-Anweisungen generiert ist.  openUTM informiert über Shared Objects/DLLs.  Der Umfang der Ausgabe kann mit den Operanden CONT und LIST gesteuert werden. Bei LIST ist nur die Angabe von KDCNAMES oder eines einzelnen Shared Object/DLL-Namens erlaubt. Bei LIST=KDCNAMES wird eine Liste aller Shared Object/DLL-Namen ausgegeben.
STATISTICS		Anzeigen allgemeiner Statistik-Informationen. Zusammen mit STATISTICS hat nur der Operand OUT eine Wirkung. Angaben für die Operanden LIST, CONT und PRONAM werden von openUTM ignoriert. Einige Statistikdaten werden über die K081-Meldung stündlich auf die System-Protokolldatei SYSLOG geschrieben und nach dem Schreiben wieder auf 0 gesetzt. Dazu muss die Anwendung mit MAX STATISTICS-MSG=FULL-HOUR generiert sein. Im Abschnitt "Ausgabe von KDCINF (Beispiele)" sind die Statistikwerte, die openUTM liefert, und deren Lebensdauer beschrieben.
SYSLOG		Informieren über die SYSLOG-Datei der UTM-Anwendung. Zusammen mit SYSLOG hat nur der Operand OUT eine Wirkung. Angaben für die Operanden LIST, CONT und PRONAM werden von openUTM ignoriert. KDCINF SYSLOG wirkt wie KDCSLOG INFO (siehe Abschnitt "KDCSLOG - SYSLOG-Datei administrieren" ).
SYSPARM		Informieren über Anwendungsparameter (Systemparameter) und Timereinstellungen, die bei der Generierung in der MAX-Anweisung festgelegt wurden und per Administration geändert werden können. Mit SYSPARM können Sie z.B. Parameterwerte kontrollieren, die mit KDCAPPL verändert wurden. Zusammen mit SYSPARM hat nur der Operand OUT eine Wirkung. Angaben für die Operanden LIST, CONT und PRONAM werden von openUTM ignoriert.
TAC		Informieren über Transaktionscodes bzw. TAC-Queues der Anwendung. Der Umfang der Ausgabe kann mit Hilfe der Operanden CONT und LIST gesteuert werden.
TAC-PROG		ist nur zulässig, wenn die Anwendung mit Lademodulen/Shared Objects generiert ist (LOAD-MODULE-Anweisung (BS2000-Systeme) bzw. SHARED-OBJECT-Anweisung (Unix-, Linux- und Windows-Systeme)). openUTM informiert darüber, welche Teilprogramme den Transaktionscodes zugeordnet sind und zu welchen Lademodulen/Shared Objects/DLLs die Teilprogramme gehören. Die Transaktionscodes werden im Operanden LIST angegeben.
TACCLASS		Informieren über TAC-Klassen der Anwendung. openUTM zeigt an, wieviele Nachrichten in jeder TAC-Klasse auf Bearbeitung warten, wie hoch die durchschnittliche Wartezeit pro TAC-Klasse ist und ob die Prioritätensteuerung für die TAC-Klassen generiert ist. Ist die Prioritätensteuerung nicht generiert, d.h. bei der KDCDEF-Generierung wurde die Anweisung TAC-PRIORITIES nicht angegeben, dann wird angezeigt, wieviele Prozesse jeder TAC-Klasse zugeordnet sind.
USER		Informieren über die Benutzerkennungen der Anwendung. openUTM informiert über Sicherheitsverletzungen für die Benutzerkennung, verbrauchte CPU-Zeit seit dem Anmelden und den LTERM-Partner, über den die Benutzerkennung angemeldet ist. Der Umfang der Ausgabe kann mit Hilfe der Operanden CONT und LIST gesteuert werden.

Die folgenden Werte sind nur für Anwendungen mit verteilter Verarbeitung sinnvoll:

CON	Nur bei verteilter Verarbeitung über das LU6.1-Protokoll. openUTM informiert über Verbindungen, die mit KC_CREATE_OBJECT Objekttyp KC_CON erzeugt oder mit der KDCDEF-Steueranweisung CON generiert wurden. openUTM zeigt Namen, generierte Eigenschaften, aktuellen Zustand und Statistikwerte über die Auslastung der Verbindung an. Der Umfang der Ausgabe kann mit Hilfe der Operanden CONT, LIST und PRONAM gesteuert werden.
LPAP	Nur bei verteilter Verarbeitung über das LU6.1-Protokoll. openUTM informiert über Namen und Eigenschaften der LPAP-Partner. Abhängig von den Angaben in LIST gibt openUTM entweder nur die Namen oder die Namen zusammen mit den Eigenschaften der LPAP-Partner aus. Der Umfang der Ausgabe kann mit Hilfe der Operanden CONT und LIST gesteuert werden. Mit dem Aufruf KDCINF LPAP, LIST=master-lpap können Sie sich die Master- und Slave-LPAPs eines LU6.1-LPAP-Bündels ausgeben lassen (siehe openUTM-Handbuch „Anwendungen generieren“). Die Ausgabe erfolgt genauso wie beim Aufruf KDCINF LPAP, LIST=KDCALL: Die erste Zeile enthält das Master-LPAP. Die Folgezeilen enthalten die Slave-LPAPs.
LSES	Nur bei verteilter Verarbeitung über das LU6.1-Protokoll. openUTM informiert über lokale Sessions, die mit KC_CREATE_OBJECT Objekttyp KC_LSES erzeugt oder mit der KDCDEF-Steueranweisung LSES generiert wurden. Geben Sie LSES zusammen mit dem Operanden LPAP=lpapname an (KDCINF LSES, LPAP=lpapname), dann schränkt openUTM die Ausgabe auf Informationen über Sessions ein, die für den in lpapname angegebenen LPAP-Partner generiert sind. Der Umfang der Ausgabe kann auch mit Hilfe der Operanden CONT und LIST gesteuert werden.
LTAC	Informieren über Namen und Eigenschaften, die fernen Service-Programmen innerhalb der lokalen Anwendung zugeordnet sind (LTAC-Eigenschaften). Der Umfang der Ausgabe kann mit Hilfe der Operanden CONT und LIST gesteuert werden.
OSI-CON	Nur bei verteilter Verarbeitung über das OSI TP-Protokoll. openUTM informiert über die mit der KDCDEF-Steueranweisung OSI-CON generierten Namen für logische Verbindungen zu Partner-Anwendungen. Abhängig von den Angaben in LIST werden die in der Anweisung OSI-CON generierten Eigenschaften der zugehörigen Verbindung angezeigt. Der Umfang der Ausgabe kann mit Hilfe der Operanden CONT und LIST gesteuert werden.
OSI-LPAP	Nur bei verteilter Verarbeitung über das OSI TP-Protokoll. openUTM informiert über OSI-LPAP-Partner, die für die OSI TP-Partner-Anwendungen der lokalen Anwendung generiert wurden. Abhängig von den Angaben für den Operanden LIST gibt openUTM entweder nur die Namen oder die Namen zusammen mit den logischen Eigenschaften der Partner-Anwendung aus.  Der Umfang der Ausgabe kann mit Hilfe der Operanden CONT und LIST gesteuert werden. Der Aufruf KDCINF OSI-LPAP, LIST=master-lpap-name gibt die Master- und Slave-LPAPs eines OSI-LPAP-Bündels aus (siehe openUTM-Handbuch „Anwendungen generieren“). Die Ausgabe erfolgt genauso wie beim Aufruf KDCINF OSI-LPAP, LIST=KDCALL: Die erste Zeile enthält das Master-OSI-LPAP. Die Folgezeilen enthalten die Slave-OSI-LPAPs.
OSI-ASSOCIATIONS
	Nur bei verteilter Verarbeitung über das OSI TP-Protokoll. openUTM informiert über OSI TP-Associations. Es werden Informationen zum Auftraggeber, der eine Association belegt, und Statistikinformationen angezeigt. KDCINF...,L=KDCNAMES gibt die Namen der generierten OSI-Associations aus. KDCINF...,L=KDCALL,OSI-LPAP=osilpapname gibt nur die aktuell verbundenen OSI-Associations aus, sortiert nach der von XAPTP vergebenen Association-Id.  Der Operand OSI-LPAP=osilpapname ist Pflicht! KDCINF...,L=(name_1...name_10),OSI-LPAP=osilpapname In diesem Fall muss bei name_n die von XAPTP vergebene Association-Id angegeben werden, nicht der generierte OSI-Association Name. Der Operand OSI-LPAP=osilpapname ist Pflicht! Der Umfang der Ausgabe kann mit Hilfe der Operanden CONT und LIST gesteuert werden. openUTM schränkt die Ausgabe von Informationen auf die OSI-Associations ein, die zu dem angegebenen OSI-LPAP-Partner aufgebaut sind.

Die folgenden Operanden steuern die Ausgabe

LPAP=lpapname
		ist nur bei type=LSES zulässig. Der Operand schränkt die Ausgabe der Session-Eigenschaften auf die Sessions ein, die für die in lpapname angegebene Partner-Anwendung generiert wurden.
OPTION=MONITORING (nur auf BS2000-Systemen)
		ist nur bei type=MUX zulässig und wirkt nur bei LIST != KDCNAMES. openUTM informiert über Messwerte von Multiplex-Verbindungen. Bei KDCINF ALL werden diese Messwerte nicht mit ausgegeben.
CONT=		Fortsetzen/Beginnen der Ausgabeliste an einer bestimmten Stelle. Die Ausgabe der Listen ist alphabetisch nach Objektnamen geordnet, CONT=name bewirkt, dass die ausgegebene Liste erst mit dem Objekt name beginnt und nur die Objekte enthält, deren Name in der alphabetischen Reihenfolge hinter name liegen. Bei UTM-Anwendungen auf BS2000-Systemen hat der Operand CONT zusammen mit LIST=name nur dann eine Wirkung, wenn für type LOAD-MODULE und für name der Name eines Teilprogramms angegeben wird. In UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen hat der Operand CONT, wenn er zusammen mit LIST=(name_1,..., name_10) angegeben wird, keine Wirkung.
	name	Die Liste beginnt mit dem Objekt name. Für name ist der Name eines Objektes der Anwendung anzugeben. Folgende Namen können Sie angeben: bei type=KSET: KSET-Name eines Keysets bei type=LTERM: Logischer Name eines Client /Druckers (Name eines LTERM-Partners) bei type=PTERM: (PTERM-)Name eines Client oder Druckers bei type=POOL: das für einen LTERM-Pool definierte LTERM-Präfix bei type=PROG: Name eines Teilprogramms bei type=TAC: TAC-Name eines lokalen Transaktionscodes/Queue bei type=USER: Benutzerkennung (USER-Name) bei type=CON/OSI-CON: ein in einer CON- bzw. OSI-CON-Anweisung generierter Name einer logischen Verbindung bei type=LPAP/OSI-LPAP: Name eines LPAP- oder OSI-LPAP-Partners bei type=LTAC: lokaler TAC-Name eines fernen Service-Programms bei type=OSI-ASSOCIATION: Association-Id, die der Association beim Aufbau einer OSI TP-Verbindung zugeordnet wurde In UTM-Anwendungen auf BS2000-Systemen können Sie zusätzlich die folgenden Namen angeben: bei type=LOAD-MODULE: Name eines Lademoduls oder eines Teilprogramms bei type=MUX: Name eines Multiplexanschlusses
	(name,proname)
		Die Liste soll mit dem Objekt (name,proname) beginnen. proname ist der Name des Prozessors, an dem sich das Objekt name befindet. Die Angabe von proname ist nur sinnvoll, wenn Objekte mit type=PTERM / CON / MUX mit demselben Namen existieren und deshalb eine eindeutige Identifizierung nur über den unterschiedlichen Prozessornamen möglich ist.
	(name,proname,bcamappl)
		Die Liste soll mit dem Objekt (name,proname,bcamappl) beginnen. bcamappl ist der Name des Transportzugriffspunkts, über den sich das Objekt (name,proname) an die Anwendung anschließt. Die Angabe von bcamappl ist nur sinnvoll, wenn Objekte mit type=PTERM / CON / MUX mit demselben Namen und Prozessor existieren und deshalb eine eindeutige Identifizierung nur über den unterschiedlichen Namen des Transportzugriffspunkts möglich ist. Die Ausgabe beginnt bei dem Objekt (name,proname), dem der in bcamappl angegebene Name des lokalen Transportzugriffspunkts zugeordnet ist.
LIST=		steuert Art und Umfang der Informationen.
	KDCNAMES
		Es wird eine Namensliste aller Objekte des in type angegebenen Objektyps ausgegeben.  LIST=KDCNAMES ist ohne Wirkung bei type=PAGEPOOL, STATISTICS, SYSLOG, SYSPARM, TACCLASS.
	(name_1,..., name_10)
		Es werden die Eigenschaften der Objekte mit den Namen name_1,..., name_10 angezeigt. Sie können maximal 10 Namen angeben, bei einem Namen können die Klammern entfallen.
	KDCCON	Nur sinnvoll bei type=PTERM, USER, LSES und CON. Für UTM-Anwendungen auf BS2000-Systemen auch bei type=MUX. Es werden nur die Eigenschaften der Objekte angezeigt, die zur Zeit mit der Anwendung verbunden sind. Ausnahmen bei type=USER: Ist die Anwendung mit SIGNON MULTI-SIGNON=NO generiert, dann werden Benutzerkennungen, über die nur OSI TP-Partner zum Starten von Asynchron-Vorgängen angemeldet sind, nicht angezeigt. Ist die Anwendung mit SIGNON MULTI-SIGNON=YES generiert, dann werden folgende Benutzerkennungen nicht angezeigt: Benutzerkennungen mit RESTART=NO, die nicht über ein Terminal angemeldet sind Benutzerkennungen, über die nur OSI TP-Partner angemeldet sind, die entweder die Functional Unit „COMMIT“ ausgewählt haben, oder die einen Asynchron-Vorgang starten.
	KDCALL	Die Eigenschaften aller Objekte des in type angegebenen Typs werden angezeigt. Standard: KDCNAMES
OSI-LPAP=osilpapname
		ist nur bei type=OSI-ASSOCIATIONS zulässig. Der Operand schränkt die Ausgabe von Informationen auf die OSI-Associations ein, die zu dem angegebenen OSI-LPAP-Partner aufgebaut sind. Die Angabe des Operanden ist Pflicht bei: KDCINF OSI-ASSOCIATION...,L=(name_1...name_10) KDCINF OSI-ASSOCIATION...,L=KDCALL
OUT=		gibt an, wohin openUTM die angeforderten Informationen ausgeben soll.
	KDCDISP	Ausgabe am Administrator-Terminal, d.h. an dem Terminal, an dem KDCINF eingegeben wurde.
	KDCPRINT	Auf Unix- und Linux-Systemen wird für die Ausgabe das Shell-Script admlp verwendet. admlp ist in $UTMPATH/shsc enthalten und ruft das Kommando lp auf. Der Anwender kann admlp modifizieren oder ein eigenes Script namens admlp erstellen und unter einem eigenen Verzeichnis ablegen. Dieses Verzeichnis muss dann in der Pfadvariablen $PATH (vor $UTMPATH/shsc) enthalten sein. Auf Windows-Systemen wird die Ausgabe auf Drucker aus der UTM-Anwendung heraus derzeit noch nicht unterstützt, d. h. es wird keine Datei erzeugt und auch nicht gedruckt.
	KDCBOTH	Ausgabe am Administrator-Terminal und (auf Unix- und Linux-Systemen) auf Standard-System-Drucker. Auf Unix- und Linux-Systemen wird für die Ausgabe das Shell-Script admlp (s.o.) verwendet.
	ltermname	Die Ausgabe erfolgt auf dem Drucker mit dem logischen Namen ltermname.
	tacname	Name des Transaktionscodes, an den openUTM das Ergebnis der Informationsabfrage übergeben soll. Der Transaktionscode muss einem Teilprogramm zugeordnet sein, das in einem Asynchron-Vorgang abläuft. Standard: KDCDISP
PRONAM=proname
		wirkt nur bei type=PTERM, CON und MUX. openUTM liefert nur Informationen über die Clients und Partner-Anwendungen, die auf dem Rechner proname ablaufen bzw. am Rechner proname angeschlossen sind. Standardwert für openUTM auf Unix- und Linux-Systemen: Leerzeichen für lokale Geräte