| < Day Day Up > |
|
This chapter provides information about what the System Logger component of z/OS is and why it was developed. It also introduces the components and products that exploit Logger and describes the topics in this book that are useful to MVS Systems Programmers and Subsystem Systems Programmers.
System Logger is an MVS component that provides a logging facility for applications running in a single-system or multi-system sysplex. The advantage of using System Logger is that the responsibility for tasks such as saving the log data (with the requested persistence), retrieving the data (potentially from any system in the sysplex), archiving the data, and expiring the data is removed from the creator of the log records. In addition, Logger provides the ability to have a single, merged, log, containing log data from multiple instances of an application within the sysplex.
Log data managed by the System Logger may reside in processor storage, in a Coupling Facility structure, on DASD, or potentially on tape. However, regardless of where System Logger is currently storing a given log record, from the point of view of the exploiter, all the log records are kept in a single file that is a limited size. The location of the data, and the migration of that data from one level to another, is transparent to the application and is managed completely by System Logger, with the objective of providing optimal performance while maintaining the integrity of the data. This is shown in Figure 1-1.
Figure 1-1: Logical and physical views of System Logger-maintained log data
The task of tracking where a specific piece of log data is at any given time is handled by System Logger. Additionally, System Logger will manage the utilization of its storage—as the space in one medium starts filling up (a Coupling Facility structure, for example), Logger will move old data to the next level in the hierarchy.
By providing these capabilities using a standard interface, many applications can obtain the benefits that System Logger provides without having to develop and maintain these features themselves. This results in faster development, more functionality, and better reliability. Enhancements to System Logger, such as support for System Managed CF Structure Duplexing, become available to all System Logger exploiters as soon as they are implemented in System Logger, rather than having to wait for each exploiter to design, write, and test their own support.
There are basically two types of users of System Logger. Some exploiters basically use System Logger as an archival facility for log data. These exploiters dump their log data into System Logger and rely on it to manage the archival and expiration of the data from there on. Of course, these exploiters have the ability to subsequently retrieve the data should they need to do so, but their normal mode of operation would be to just give data to System Logger and not look for it back again. And example of this type of exploiter would be the CICS Forward Recovery logs, where CICS stores data away in case a forward recovery is required some time in the future. In this book, we call these exploiters funnel-type exploiters.
The other type of exploiter typically uses the data more actively, and explicitly deletes it when it is no longer required. An example of this would be the CICS DFHLOG. CICS stores information in DFHLOG about running transactions, and deletes the records as the transactions complete. We call these types of exploiters active exploiters,
As you can imagine, the performance requirements of these exploiters will differ. The exploiters that use Logger primarily to archive data are not particularly concerned about retrieval speeds, whereas an active user of the data will ideally want all the active data to be kept in a high performance location, like a dataspace or a CF structure. One of the objectives of this part of the book is to help you identify and provide the appropriate levels of service for the various users of System Logger in your installation. Table 1-1 contains a list of the current System Logger exploiters, and shows for each one what type of exploiter it is (funnel-type or active).
Exploiter | Exploiter Type |
---|---|
APPC Protected Conversations | funnel-type |
CICS DFHLOG | active |
CICS DFHSHUNT | active |
CICS user journals | funnel-type |
CICS forward recovery logs | funnel-type |
CICS log of logs | funnel-type |
DFSMStvs IGWLOG | active |
DFSMStvs IGWSHUNT | active |
IMS Shared Queues | funnel-type |
Logrec | funnel-type |
OPERLOG | funnel-type |
RRS Active log | active |
RRS Archive | funnel-type |
RRS Resource Manager data | funnel-type |
RRS Delayed URs | funnel-type |
RRS Restart | funnel-type |
SA/390 Message Log | funnel-type |
SA/390 Workitem History Log | funnel-type |
SA/390 Health Checker History | funnel-type |
WebSphere Error Log | funnel-type |
When an application passes log data to System Logger, the data can initially be stored on DASD, in what is known as a DASD-only log stream, or it can be stored in a Coupling Facility (CF) in what is known as a CF-Structure log stream. The major differences between these two types of log stream configurations are the storage medium System Logger uses to hold interim log data, and how many systems can use the log stream concurrently:
In a CF log stream, interim storage for log data is in CF list structures. This type of log stream supports the ability for exploiters on more than one system to write log data to the same log stream concurrently.
In a DASD-only log stream, interim storage for log data is contained in a dataspace in the z/OS system. The dataspaces are associated with the System Logger address space, IXGLOGR. DASD-only log streams can only be used by exploiters on one system at a time.
| < Day Day Up > |
|