1. Field of the Invention
This invention pertains in general to data processing utilizing mainframe computer systems and in particular to diagnostic logging in such computer systems.
2. Description of Background Art
An entity that performs large amounts of data processing, such as a corporation handling a large number of daily transactions, typically relies on mainframe computer systems to perform the data processing. Not long ago, an entity could rely on a single, or only a few mainframe computers to perform all of its data processing. Each mainframe computer typically executed two or three different processing subsystems, each of which executed one or more applications. Each subsystem maintained its own diagnostic log. When a particular application generated a diagnostic message, it was relatively easy for a technician to determine which application in which subsystem generated the message, find the log associated with that subsystem, and examine the messages in the log.
Now, however, data processing needs have increased to the point where an entity such as a corporation may require dozens of mainframe computers to meet its data processing needs. The number of subsystems and applications typically executed by each mainframe computer has also increased. When an application generates a diagnostic message, it is very difficult for a technician to locate the log for that subsystem. Moreover, it is difficult for the technician to determine if other applications in other subsystems have generated the same message. Therefore, there is a need for a way to quickly and conveniently review the diagnostic logs of multiple subsystems executing on multiple mainframe computers.
The above need is met by a logging service that logs diagnostic messages from applications executing on the various mainframe computer subsystems to a centralized log. In an embodiment of the present invention, a mainframe computing environment has a plurality of mainframes coupled to a coupling facility. The coupling facility has a data storage area called a xe2x80x9clogstream.xe2x80x9d A preferred embodiment of the present invention uses the logging service to store diagnostic messages in the logstream. Since the diagnostic messages are centrally stored, a person can easily review diagnostic messages from multiple applications by reviewing the data in the logstream.
Each mainframe preferably executes the OS/390 operating system, also referred to as xe2x80x9cMVSxe2x80x9d (for Multiple Virtual Storage). Under MVS, each computer can execute one or more subsystems. One subsystem is the online transaction processing (OLTP) subsystem. In general, the OLTP subsystem executes short transactions that need to be performed right away, such as stock trading transactions. Another subsystem is the batch subsystem, which performs transactions that take a relatively long time to complete and do not need to be performed right away. For example, accounting and backup processes that can execute over long periods of time late at night can be performed on the batch subsystem.
Zero or more applications execute within a subsystem. Each application preferably contains an application program interface (API ) block, which is a data structure populated by the application when the application generates a diagnostic message. The API block is associated with a logging service API in the subsystem. The application generates a diagnostic message by passing the populated API block to the logging service API.
The logging service API in the subsystem is configured to store diagnostic messages in the logstream 116. The logging service API in the OLTP subsystem is preferably connected to an alert facility. The alert facility signals an alert to an automated system and/or a human operator of the computing environment in response to certain diagnostic messages generated by the applications. In addition, the logging service API is preferably coupled to a message queue. The message queue is utilized because the version of the OS/390 operating system used by one embodiment of the present invention does not allow direct writes to the logstream from the OLTP subsystem. Therefore, the logging service API uses the message queue to pass the diagnostic messages to a subsystem that allows logstream access. Preferably, an application executing as a long-running started batch task drains the message queue and writes the diagnostic messages to the logstream in the coupling facility.
One embodiment of the present invention includes a report and extract utility for extracting data from the logstream based on user-defined criteria. One embodiment also includes an interactive browser utility that allows a user to browse real-time logstream data.
In one embodiment, the operation of the present invention is as follows. Upon receiving a diagnostic message in the form of a populated API block from an application, the logging service preferably validates the header information in the block. Preferably, only messages having valid header information are logged. Next, the logging service determines whether there are any missing fields in the API block that can be populated by the logging service. The logging service also determines whether the block was received from an application executing in either the OLTP or batch subsystem. If the block was received from an application in the batch subsystem, then the logging service preferably writes the diagnostic message directly to the logstream. If the logging service received the diagnostic message from an application in the OLTP subsystem, the logging service preferably writes the message into the message queue. The logging service also checks the message and notifies the alert service if necessary.