The openUTM administration commands you want to use when running the application must be specified during KDCDEF generation or they must be entered dynamically into the configuration using WinAdmin, WebAdmin or an administration program you have written yourself.
To do this you will need to define the administration program KDCADM with a PROGRAM statement and generate the necessary commands as KDCADM transaction codes.
An exhaustive generation of KDCADM and of all administration commands is given below. Your KDCDEF generation must only include the TAC statements for those administration commands that you want to use when running the program. The administration command KDCSHUT must be generated in all cases.
REMARK Generate KDCADM for openUTM on BS2000 systems PROGRAM KDCADM,COMP=ILCS REMARK Generate KDCADM for openUTM on Unix, Linux and Windows systems: PROGRAM KDCADM,COMP=C REMARK Generate dialog TACs (commands) from KDCADM: TAC KDCAPPL ,PROGRAM=KDCADM,ADMIN=Y TAC KDCBNDL ,PROGRAM=KDCADM,ADMIN=Y TAC KDCDIAG ,PROGRAM=KDCADM,ADMIN=Y TAC KDCHELP ,PROGRAM=KDCADM,ADMIN=READ "ADMIN=Y is also permitted" TAC KDCINF ,PROGRAM=KDCADM,ADMIN=READ "ADMIN=Y is also permitted" TAC KDCLOG ,PROGRAM=KDCADM,ADMIN=Y TAC KDCLPAP ,PROGRAM=KDCADM,ADMIN=Y TAC KDCLSES ,PROGRAM=KDCADM,ADMIN=Y TAC KDCLTAC ,PROGRAM=KDCADM,ADMIN=Y TAC KDCLTERM,PROGRAM=KDCADM,ADMIN=Y TAC KDCPOOL ,PROGRAM=KDCADM,ADMIN=Y TAC KDCPROG ,PROGRAM=KDCADM,ADMIN=Y TAC KDCPTERM,PROGRAM=KDCADM,ADMIN=Y TAC KDCSHUT ,PROGRAM=KDCADM,ADMIN=Y TAC KDCSLOG ,PROGRAM=KDCADM,ADMIN=Y TAC KDCSWTCH,PROGRAM=KDCADM,ADMIN=Y TAC KDCTAC ,PROGRAM=KDCADM,ADMIN=Y TAC KDCTCL ,PROGRAM=KDCADM,ADMIN=Y TAC KDCUSER ,PROGRAM=KDCADM,ADMIN=Y TAC KDCMUX ,PROGRAM=KDCADM,ADMIN=Y "only on BS2000 systems" TAC KDCSEND ,PROGRAM=KDCADM,ADMIN=Y "only on BS2000 systems" REMARK Generate asynchronous TACs (commands) from KDCADM: TAC KDCAPPLA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCBNDLA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCDIAGA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCHELPA,PROGRAM=KDCADM,ADMIN=READ,TYPE=A "ADMIN=Y is also permitted" TAC KDCINFA ,PROGRAM=KDCADM,ADMIN=READ,TYPE=A "ADMIN=Y is also permitted" TAC KDCLOGA ,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCLPAPA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCLSESA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCLTACA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCLTRMA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCPOOLA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCPROGA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCPTRMA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCSHUTA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCSLOGA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCSWCHA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCTACA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCTCLA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCUSERA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A TAC KDCMUXA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A "only on BS2000 systems" TAC KDCSENDA,PROGRAM=KDCADM,ADMIN=Y,TYPE=A "only on BS2000 systems"
As with the ADMIN=READ generation above, the commands KDCINF[A] and KDCHELP[A] can be called from any user ID and from any partner application. However, you can assign a lock code to these commands (with the operand LOCK; e.g. LOCK=1). These commands can then only be called from user IDs and partner applications to which a keyset with the associated keycode (keycode 1) is assigned.
The access list concept provides another way of controlling access to these commands. An access list is assigned a key set containing a number of key/access codes, which can be for a specific group of commands, for example. If an access list like this is assigned to a command, only one user can access this command when the key set of the user’s user ID and the key set of the LTERM partner via which the user is logged in each contain at least one key/access code that is also contained in the access list of the command.
You can generate the administration commands dynamically by generating the commands required using KC_CREATE_OBJECT and obj_type KC_TAC.