Monitoring procedures in a DBCTL environment

This topic explains how to establish monitoring procedures for your DBCTL environment. First, consider that monitoring in a DB/DC environment generally refers to the monitoring of transactions.

The transaction is entered by an end user on a terminal, is processed by the DB/DC environment, and returns a result to the user. Transaction characteristics that are measured include total response time and the number and duration of resource contentions,

A DBCTL environment has no transactions and no terminal end users. It does, however, do work on behalf of CCTL transactions that are entered by CCTL terminal users. DBCTL monitoring provides data about the DBCTL processing that occurs when a CCTL transaction accesses databases in a DBCTL environment. This access is provided by the CCTL making the database resource adapter (DRA) request.

The most typical sequence of DRA requests that represents a CCTL transaction would be:

• A SCHED request to schedule a PSB in the DBCTL environment
• A DL/I request to make database calls
• A sync point request, COMMTERM, to commit the database updates and release the PSB

The DBCTL process that encompasses this request is called a unit of recovery (UOR).

DBCTL provides UOR monitoring data, such as:

• Total time the UOR exists
• Wait time to schedule a PSB
• I/O activity during database calls

This information is similar to, and is often the same as, DB/DC monitoring data. However, in a DBCTL environment, the UOR data represents only a part of the total processing of a CCTL transaction. You must also include CCTL monitoring data to get an overall view of the CCTL transaction performance.

In this topic, the term transaction refers to a CCTL transaction. When it applies, UOR is specifically named.

The CCTL administrator must decide what strategy to use to monitor transaction performance. This topic describes some possible strategies and how IMS functions can help.

Several types of monitoring strategies are available. You can:

• Summarize actual workload for the whole of the online execution. This can be continuous or at an agreed-to frequency. Total workload or selected representative transactions can be tracked.
• Take sample snapshots at peak loads and under normal conditions. It is always useful to monitor the peak periods for two reasons:
  • Bottlenecks and response time problems are more pronounced at peak volumes.
  • The current peak load is a good indicator of what the future average will be like.
• Monitor critical transactions or programs that have documented performance criteria.

Plan your monitoring procedures in advance. A procedure should explain the tools to be used, the analysis techniques to be used, the operational extent of those activities, and how often they are to be performed.

You need to:

• Develop performance criteria
• Develop a master plan for monitoring, data gathering, and analysis