Architecturally, ERi/LOGR can be broken down into several major components. A brief overview of each component is explained in this section. The components are:

• Administrative Interface (CICS Based)
• Product Initialization (z/OS)
• Application Instrumentation
• Logging Gates (z/OS)
• Housekeeping (z/OS)
• Defining Environments
• Graphical User Interface (Web based GUI Browser)

Product setup and configuration is supported by the ERi/LOGR Administration component, a CICS-based user interface. This feature is designed to simplify the setup process and eliminate the need for cumbersome configuration files with batch installation jobs. Changes are applied real-time providing a fast-path to product availability and ongoing administration.

The ERi/LOGR Administration component supports five primary functions, they are:

• Setup - Installation and Verification
• Client Environments - Setup and Administration (Prod, Dev, Test, etc.)
• Client Event Profiles - Setup and Administration
• Event Monitor - Real-time logging activity
• Event Browser - Log Stream

For high performance, ERi/LOGR utilizes two pieces of central storage (ECSA key-9). The first holds Client Environmental & Event Profile information loaded from the ERi/LOGR VSAM control file. The second storage area is where ERi/LOGR records logging statistics for each event type. This storage is initialized early in the z/OS IPL process and anchored to the MVS Name Token Table. Initialization takes place before CICS and Batch are available for business processing.

Instrumentation is the term we use to describe the process of upgrading a z/OS application to become ERi/LOGR enabled. Logging key business and processing events centrally will create many new possibilities for monitoring application behavior. Historical trend analysis as well as real-time monitors can be created with ease by using the ERi/LOGR Graphical User Interface. SOX compliance is simplified.

Instrumentation is implemented by the use of an ERI-/LOGR application programming interface (API). Behind the API are several logging gates that handle the technical interface with the z/OS System Logger. Sample code is provided that illustrates the API call to ERi/LOGR. Implementation is simple and can be completed in a matter of hours.

The current version of ERi/LOGR supports three application logging gates. They are:

• z/OS CICS Logging Gate
• z/OS Batch Logging Gate
• z/OS Websphere Logging Gate

The below illustration provides an overview of the three z/OS ERi/LOGR logging gates. With future ERi/LOGR releases support is planned for an MQ logging gate - for receiving data from non-z/OS servers such as Unix J2EE servers.

ERi/LOGR’s underlining logging technology is IBM’s MVS Logger. This sub-system allows for user logging but IBM provides no tools and only sample code for developing utilities for managing the logs. For example, each user log must have its log data off- loaded and optionally archived – IBM calls this LS Tail Processing. Basically, data is written to a MVS Log Stream (LS) non-stop 24x7. However, the log tail can be off- loaded to a more efficient file system such as VSAM or DB2. ERi/LOGR provides three options to manage the off-loaded log data. They are:

Option 1:	Delete all LS tail data from a given point in time.
Option 2:	Move all, or selected, LS tail data from a given point in time to VSAM or DB2 for extended access by the ERi/LOGR GUI browser.
Option 3:	Archive LS data using GDGs or ASM. Optionally, ERI can create a custom solution that interfaces with a client archive solution.

IT Environmental configurations (Prod, Test, Dev) can be simple to very complex and employ many LPARs in an IBM Parallel Sysplex. ERi/LOGR must know the scope in which it is operating and this requires some basic setup.

Clients define their environments, using a simple CICS based administration tool, by creating a profile for each environment (Prod, Test, Dev) that is in scope for ERi/LOGR. Each environment profile includes a set of address space filters that are used by ERi/LOGR to screen logging requests. The screening process is transparent to the calling application with no measurable overhead.