The term “administration” covers all activities involved in the control and administration of the current application. “Administering” means adapting the application to changing circumstances and requirements without interrupting the application run.
To help you administer your UTM application, openUTM provides you with the interfaces and tools in the following list.
The command interface on which the basic administration functions are available. This is implemented in the KDCADM administration program.
The KDCADMI program interface for administration which you can use to generate administration programs specifically tailored to your application. The UTM administration functions are provided at this program interface.
The PADM and DADM calls at the KDCS program interface with which you administer local message queues and printers, enabling you to control the output of print jobs. The UTM program units KDCDADM and KDCPADM provide you with all the functions of the KDCS calls DADM and PADM.
The openUTM component WinAdmin with which you can administer several UTM applications in a network from the graphical user interface on your PC.
The openUTM WebAdmin component that provides a Web application for the administration of UTM applications.
Only on BS2000 systems
WebAdmin can be integrated into the SE Manager as an add-on.
The administration tool CALLUTM with which you can start also administration services in UTM applications while in a BS2000 task, and which enables you to call up administration commands.
The KDCISAT and KDCMSAT commands (dialog transaction codes) with which you can control the SAT logging function for your application. These commands are described in the openUTM manual “Using UTM Applications on BS2000 Systems”.
openUTM provides you with a comprehensive range of administration functions via the command interface and the program interfaces KDCADMI and KDCS, enabling you to obtain optimum performance and flexibility from your application, and ensuring that the application can operate without interruption (7*24-hour operation). You can, for example, perform the following actions:
Check the performance of the application by querying information about the current utilization level of the application, diagnosing performance bottlenecks and errors and, where necessary, taking measures to improve performance.
Replace parts of the application program or the entire application program at runtime. This enables you to modify program units during the application run or to add new program units.
Assign the restart information and/or print queues on terminals and printers where hardware faults arise to other terminals or printers. This enables the user to continue work from a different terminal, or to redirect print jobs to an intact printer.
Disable/enable clients, printers, LTERM pools, user IDs, services and the connection points for communication partners (LTERM, LPAP and OSI-LPAP partners) where necessary.
Establish and shut down connections to clients, printers and partner applications or switch to replacement connections.
Request information about the configuration of an application and the current settings for application and operating parameters.
Modify the configuration of an application at runtime by adding to the configuration services, user IDs, clients, printers, connections and session names for distributed processing by means of LU6.1, key sets and transaction codes for partner applications or by deleting them from it.
Administer TAC, USER and temporary queues as well as the local message queues of LTERM partners and transaction codes.
Terminate an application.
You can call up the administration functions of openUTM (with the exception of the SAT administration command) in dialog mode or by means of message queuing. The message queuing form of administration for a UTM application involves the use of “programmed administrators”, i.e. you can generate programs which execute administration functions at a given time (DPUT call) or in response to specific events. The program interface calls and administration commands can, in particular, be called by the MSGTAC event service.
You can also take advantage of the opportunities offered by the user-specific message destinations. These message destinations allow you to read messages in a TAC or USER queue, for example, by means of the KDCS program interface and the DGET function. With this function and corresponding follow-up processing, you can design MSGTAC-like programs that respond specifically to a message.
For information on automatic administration refer to chapter "Automatic administration". |
UTM administration privileges are required for all administration functions which involve write access to configuration data of the application. There is also a slightly lower level of authorization which entitles users to use administration functions which have read-only access to the application data.
For details of the authorizations concept, see chapter "Access rights and data access control". |
The following section provides a summary of the range of functions for individual interfaces and tools and also describes the differences between them and their respective areas of application.