CICS / WebSphere

The CICS Log Manager: Background, Hints, & Tips

3 Pages

CICS has undergone many changes since its inception more than 30 years ago. During that time, IBM has continually enhanced the product and enabled it to exploit new features in the underlying operating system and in other subsystems running alongside CICS. IBM has also restructured various components within CICS during its lifetime. Since the days of CICS/ESA Version 3, the internal structure of CICS has been managed by a series of domains. A domain is similar to the concept of a class in object-oriented programming languages, as it has clearly defined interfaces and executable code, and is responsible for managing any data that relates to that particular component. This encapsulation of data and function helps improve the reliability, extendibility, and serviceability of the product as a whole. Since CICS/ESA Version 3, different components of CICS have been restructured into their own domains. The CICS Log Manager is one such component. It was introduced in the first release of CICS Transaction Server Version 1 and replaced the older journal control management programs.


Before the advent of the Log Manager domain, CICS managed journaling operations using its journal control program, DFHJCP, and other associated modules. CICS journal control was responsible for coordinating the writing of log data records, generated both explicitly from application programs and implicitly by CICS itself. This process was referred to as either logging or journaling, and the terms were used interchangeably over the years. However, there is a subtle difference in the semantics of these words: Logging pertained to the recording of information relevant for CICS recovery processing, needed when backing out any recoverable changes made by a failing transaction or when recovering a CICS system to a committed state during an emergency restart. Journaling related to the writing of data for other purposes, such as maintaining audit trails, recording terminal input and output messages, or writing explicit user data to journals for processing offline. Nonetheless, both terms have become synonymous over the years, and this distinction is somewhat academic now.

CICS journal data was written to BSAM-managed data sets. Typically, a pair of BSAM data sets on DASD represented each journal, although single-extent journaling was also available. CICS supported journaling to tape data sets, too. CICS managed the log data for each journal, buffering log records into variable-size blocks of data and using BSAM as the access method to harden them to disk or tape as the buffers became full, or when a CICS task required synchronization with a particular journaling operation and had to wait for I/O to complete before it could continue. Being BSAM, the journal buffers had to reside below the 16MB line within each CICS address space.

CICS maintained a journal for its own recovery purposes. On a typical system, this was represented by dual data sets with suffixes DFHJ01A and DFHJ01B. CICS would switch back and forth between the two data set extents when the currently used one had filled up. This recovery journal was referred to as the CICS system log. It was used to record the data required for system emergency restart purposes. This data consisted of before images of recoverable resources that were changed by in-flight transactions in the system, together with synchronization records written by CICS during syncpoint processing. In addition, CICS kept copies of this recovery data within memory for use in dynamic transaction back out of individual failing transactions. This copy was referred to as the dynamic log. Being held in memory, it contributed toward the total storage requirements for a CICS system.

In addition to the system log, CICS also supported user journals in the range DFHJ02 through DFHJ99. Each journal required a definition in the CICS journal control table (JCT). These definitions defined the attributes of each journal, such as its destination (disk or tape) or its associated access method (in addition to BSAM, CICS also supported journaling to SMF).  


CICS Transaction Server (TS) was developed in part to exploit the parallel sysplex environment. As such, its journaling mechanism utilizes this environment, too, as journal data may be shared between different CICS address spaces across separate MVS images. The new Log Manager domain replaced the journal control programs of earlier releases of CICS. In turn, the Log Manager domain utilized the services of the MVS System Logger subsystem. This is a component of MVS that runs as a separate system address space (IXGLOGR). The MVS Logger provides a programming interface for other subsystems to exploit. This application programming interface (API) allows address spaces such as CICS to connect and disconnect (via IXGCONN calls) to various logs, and to write (IXGWRITE), browse (IXGBRWSE), and delete (IXGDELET) log data held there.

The MVS Logger maintains log data in log streams. These are managed as a series of blocks of log data. Log streams are supported on several forms of storage, including coupling facility (CF) structures and DASD storage. There are discrete layers of storage for each log stream. The primary storage is the initial destination for log data written to a log stream. This is in a CF list structure, or a log stream staging data set (for DASD only log streams). Log data kept in primary storage is intended for quick reference if needed. If the MVS Logger needs to move log data from this location (assuming no further space is available there), then it performs offloading I/O activity to move log blocks to secondary storage, which is comprised of log stream offload data sets.

Each log stream is identified by its own unique log stream name. One example of such a log stream name is the sequence userid.applid.journalname, such as TESTCICS.CICS20.DFHJ05. To ease access to log streams, CICS provides the concept of journal names (up to eight characters in length). In the previous example, the journal name is DFHJ05. The relationship between journal names and log stream names is similar to that of file and data set names in CICS.

3 Pages