Transaction tracking

Transaction tracking identifies the significant events in the lifecycle of a single transaction across subsystems and logs.

Identifying the log records that are related to an individual transaction can be difficult:

  • The log records for a transaction are typically interspersed among records for other transactions.
  • The log records for a transaction are correlated by a variety of tokens.
  • The log records for heterogeneous transactions, such as CICS-DB2 transactions (CICS® transactions that call DB2®), are dispersed across different logs written by multiple subsystems.

The Transaction Analysis Workbench log browser makes transaction tracking easy: you simply enter TX next to any log record, and the log browser displays the records that are related to the same transaction, hiding all other log records. The log browser tracks the transaction across all available logs.

For example:

  • CICS with DBCTL: from a CICS transaction record, view the related IMS log records
  • CICS or IMS with DB2: from a CICS or an IMS transaction record, view the related DB2 accounting and trace (IFCID) records, and DB2 log events
  • CICS or IMS with IBM® MQ: from a CICS or an IMS transaction record, view the related MQ accounting records (SMF) and MQ log (extract) events
  • DB2: track the lifecycle of an individual thread across DB2 log records and IFCID records
  • IMS Connect: view IMS transaction and DRDA ODBM database activity

The term transaction is used here loosely. For DB2, in situations where there is no driving transaction from another system such as CICS or IMS, Transaction Analysis Workbench tracks DB2 threads.

For IMS, you can track a unit of recovery (UOR) within a transaction by entering TU next to a log record.

Figure 1. Transaction tracking example: a CICS-DBCTL transaction that causes a deadlock in IMS
Figure that shows a sequence of two screen captures: starting from a summarized view of several log records, and then entering a TX line action next to a log record to view records from the same transaction.

Tracking simplifies and accelerates problem analysis by condensing all of the available log records for a transaction (or thread, or unit of recovery) in a single view.

Tracking can help both expert and non-expert users to analyze problems.

For example, suppose you have applied a filter in the log browser to display log records that report a long response time, or excessive CPU time, or some other metric with an abnormally high value. Tracking (entering TX next to one of those records) can help to analyze the problem in the following ways:

  • Tracking can uncover a related log record that reports the specific exception condition that is responsible for the abnormal value. Non-expert users can then refer to the documentation for that exception condition.
  • Tracking displays log records that correspond to events in the transaction lifecycle. Elapsed times between those log records typically correspond to elapsed times between events. Often, you don't need an expert understanding of the events in a transaction to pinpoint which event caused the problem: just look for the log record with the longest elapsed time.

Tracking is not just useful for analyzing problems. Tracking can help to educate developers and other technical staff about the behavior of their own systems by showing a time line of events in a transaction.