While IMS is still the central repository for critical data at many large enterprises, it’s not your father’s IMS. Over the years, IMS has evolved from a few databases running on one IMS image to data sharing across multiple IMS images, to access from other systems such as DB2 and CICS/DBCTL, and even to access from the Internet.

Applications that were written in the ’70s and ’80s were simpler than today’s applications; the databases and systems were more finite and clearly defined. As IMS has expanded, the applications have become more complex—even simple applications span multiple IMS images and spawn business processes that run on several IMS systems. Other applications enter requests from the Web and “hop” between WebSphere Application Server, IMS Connect, WebSphere MQ, CICS, IMS, and DB2.

Opening IMS to the Web has breathed new life into legacy databases, but added complexity. When business processes and applications fail in these mixed environments, it can be difficult and time-consuming to determine what caused the problem. Moreover, the problems are more visible because many different systems and users are involved; an outage in a Web application may generate headlines as well as causing expense and possibly lost business.

So, when you encounter a problem in an IMS application, how do you determine what caused it? Finding the cause of a problem can be like trying to find a needle in a haystack. This article examines how you can use an IMS log analysis tool to help you find relevant information and quickly identify and resolve problems.

Performance: Just One Factor

Performance issues are one cause of application problems; other problems arise from communication failures, application errors, and data integrity issues. Monitoring tools are usually designed for real-time data capture and analysis, rather than historical analysis.

Monitoring tools provide a real-time view of the system and can tell you how long it took for a transaction to complete, but they don’t offer a historical, detailed view of the steps this transaction may have followed while IMS processed it. These business application flows may include message switches, multiple database updates, or a call to a DB2 subsystem. To see these flows over time and diagnose incorrect results or integrity problems, you need detailed historical information such as that stored in IMS logs.

IMS Logs Overview

The IMS logs, more commonly known as Online Log Data Sets (OLDS) and System Log Data Sets (SLDS), record and store a wealth of information, including:

• Receipt of an input message in the input queue and successful receipt of an output message by a terminal

5 Pages