3.3 Case study: Managing the CICS TP Monitor

The purpose of TP Monitors is to ensure the transaction properties (ACID) of applications. A widely used TP monitor is the IBM Customer Information Control System (CICS). Its high complexity yields a strong demand for powerful monitoring and administration concepts. Due to the heterogeneity of the underlying systems (from PCs to mainframes), having an integrated view is particularly important for managing the distributed application CICS. In this section, we will describe how the GAMOCs can be applied to CICS-management; the underlying scenario is the installation of new application software. As mentioned in section 2.2, information relevant for software distribution and installation is found in GAMOCs related to the computational viewpoint; they serve therefore as base MOCs for CICS-specific MOCs.

If new applications have to be installed, detailed program- and transaction-specific information is required, e.g. the location, the version and the parameters of the subsystems the application relies on. It is also necessary to determine the relationships of transactions, applications, and users to the systems on which they are defined and to the corresponding security and database systems. In order to cope with this huge amount of information, it has to be structured and filtered according to specific criteria. Given a transaction identifier it must be possible, for example, to determine the corresponding region and the systems from which the transaction can be issued remotely. Analogous requirements exist for all resources having multiple occurrences in the same domain and representing the same functionality. Starting from our software installation scenario, we are able to identify the required management information and the necessary management functionality (Fischer, 1996):

• Management information: Transactions, applications, files and users affected by the change; the already installed version; the region; the security system and its administrator; the database system and its administrator.
• Management functionality: Deactivate transactions, applications and files; determine the current version; determine the prerequisite software for the new version of an application; apply resource definitions in the regions subject to the change; activate transactions, applications and files; inform security and database system administrators.

After the relevant MOCs provided by RM-ODP have been identified (step 1 of our approach), it is now necessary to map the required information to the GAMOCs (step 2; top-down approach). As will be seen, some kind of information is already contained in the computational and enterprise languages. The remaining items have to be resolved by specifying additional CICS-specific MOCs together with their attributes and methods. These have to be checked against aspects of implementation, i.e. the question ``is the required information available from the system?'' must be answered (step 3; bottom-up approach). The direct mapping of the management information to the GAMOCs can be done as follows:

• A transaction can be regarded as a sequence of interactions, i.e. a flow, occuring at interfaces with the necessary management information therefore being available from the respective computational interface templates and interface signatures.
• The relationship between the CICS systems and databases or security systems can be looked at from the computational viewpoint as a permitted sequence of interactions at the corresponding interfaces or, from the engineering viewpoint, as a channel, i.e. a configuration of stubs, protocol objects etc. Again, management information is available from the respective interface templates or signatures or stem from channel rules.
• Files of the CICS system are examples of clusters, i.e. single units for checkpointing, recovery and migration.
• Certain aspects of CICS-regions have to be modelled as binding objects. This provides information about the resources of these regions (e.g. terminals, applications, files etc.)

These examples show that the MOCs derived from ODP viewpoint concepts support a broad range of tasks identified by management use cases. The information provided by them is the basis for execution of management functions from a console or for the application of ODP functions (e.g. deactivate, reactivate, recovery or checkpointing) for management purposes. Our experiences have shown that this is also true for entities and tasks identified in other scenarios dealing with different kinds of distributed applications. We were therefore able to implement our GAMOC-based management model in a very straightforward fashion by applying the transformation process described in section 3.2. The results are CORBA-compliant distributed objects for management purposes interacting via an ORB. Together, they form a ``CICS management agent''.