This chapter describes the openUTM administration commands which call up the basic administration functions. These administration commands are transaction codes in the administration program KDCADM which are supplied together with openUTM. Before you can make use of these administration commands you must add entries for both KDCADM and the administration commands to the configuration file during the KDCDEF generation phase. The table below lists all the administration commands.
There are two versions of each administration command:
a command to initiate processing interactively.
a command for administration by means of message queuing (asynchronous processing).
There follows a description of the dialog-based administration commands. This description is arranged in ascending alphabetical order of command names. The associated commands for administration via message queuing have the same operands and the same input format. Command input differs only in terms of the actual command name entered.
With dialog-based administration procedures, openUTM returns the result of command processing to the job submitter (a user at a terminal, UPIC client, TS application or a partner application).
In the case of asynchronous commands, all results are sent to a fixed receiver (DESTADM) in the form of asynchronous messages. The receiver can either be:
an LTERM partner (Exception: UPIC LTERM partner are not permitted)
an asynchronous TAC
a TAC queue (TYPE=Q)
The receiver is defined during KDCDEF generation in MAX DESTADM= and can be modified via the administration program interface, see chapter "obj_type=KC_MAX_PAR". If no receiver is defined, the result is lost. If a TAC is defined but unable to receive the result, e.g. in the case of a disabled asynchronous TAC, UTM does not execute the administration command and writes message K076 to the system log file SYSLOG and to SYSOUT (on BS2000 systems) or stderr (on Unix, Linux and Windows systems).
List of administration commands
Dialog commands | Asynchronous commands |
KDCAPPL - Change properties and limit values for an operation | KDCAPPLA |
KDCBNDLA | |
KDCDIAGA | |
KDCHELPA | |
KDCINF - Request information on objects and application parameters | KDCINFA |
KDCLOGA | |
KDCLPAPA | |
KDCLSES - Establish/shut down connections for LU6.1 sessions | KDCLSESA |
KDCLTACA | |
KDCLTRMA | |
KDCMUX - Change properties of multiplex connections (BS2000 systems) | KDCMUXA |
KDCPOOLA | |
KDCPROGA | |
KDCPTRMA | |
KDCSENDA | |
KDCSHUTA | |
KDCSLOGA | |
KDCSWTCH - Change the assignment of clients and printers to LTERM partners | KDCSWCHA |
KDCTACA | |
KDCTCLA | |
KDCUSERA |
KDCADM commands
Command format
command-name operand1,operand2,...
There are position operands and keyword operands.
Position operands are entries without a keyword and an “=” sign and must appear in the specified sequence.
You can write keyword operands, e.g. PTERM=ptermname in any sequence. The operands must be separated by commas.
If an optional operand is not set, the default value of this operand applies.
If an optional operand is not set for a command used for modifying the configuration then the value defined during generation or the value previously set by the administrator continues to apply.
After processing a command, openUTM returns an output which indicates the result. However, this does not mean in any case that the action was performed successfully.
You can use the information functions to establish whether or not openUTM was able to perform an action successfully, e.g. in the case of the command KDCINF.