MVS BOOT CAMP: Leveraging Your Coupling Facility to Enhance LOGREC
by John E. Johnston
October 1, 2004
** Read this article online at http://www.mainframezone.com/operating-systems/mvs-boot-camp-leveraging-your-coupling-facility-to-enhance-logrec
There are many new and valuable functions and features in today’s mainframe environment. This article addresses one of these, the use of a coupling facility structure and the system logger to manage LOGREC data collection.
LOGREC data is comprised of records created when hardware or software errors are encountered. The data can be printed and analyzed using the Environmental Record Editing and Printing (EREP) program. Collecting LOGREC data has always been a bit cumbersome (not as onerous as collecting SMF data, but still a pain).
Old-Style LOGREC Data Collection
With the traditional LOGREC data collection method, the LOGREC data is stored on a disk data set. When the disk data set fills up, a console message is issued. When this “full” message is generated, either the computer operator or the mainframe automation software submits a batch process that copies the data to another storage area (usually a disk or tape Generation Data Group [GDG]), and then clears out the LOGREC data set. When multiple MVS images are deployed in a Parallel Sysplex environment, each MVS image must implement its own LOGREC data collection system.
The challenge is greater when you need to access this LOGREC data using the EREP program. Usually, where you need to run EREP, you’ll need to access the LOGREC data from multiple systems. With the traditional method, this means you must concatenate the appropriate LOGREC history data in your EREP JCL. While this is not an insurmountable ordeal, it’s just plain clumsy.
New-Style LOGREC Data Collection
In a Parallel Sysplex environment, you can leverage your coupling facility and the MVS logger component to automate LOGREC data collection. With this method, all the MVS images in your Sysplex write their LOGREC data to a structure in your coupling facility. When the structure fills up, the MVS logger function offloads the data into a disk data set. The MVS logger also prunes old records automatically based on parameters the systems programmer sets. Note: In a single system Sysplex, you can use a DASD-only log stream instead of a coupling facility structure.
Implementing LOGREC Data Collection
Implementing the new-style LOGREC data collection method requires that you:
• Determine the size needed for the LOGREC structure
• Create a new CFRM policy to add the LOGREC structure
• Activate the new CFRM policy
• Allocate the LOGREC log stream by updating the LOGR policy
• Change the LOGREC recording medium to the log stream.
You can use two methods to determine the size needed for the LOGREC structure. IBM recommends that you determine how many records are written per second to the LOGREC data set on each of your systems, then use the CFSizer utility (www.ibm.com/servers/ eserver/zseries/pso) to determine the size.
Another method is to guess. You might select a size of 3,096 and an INITSIZE of 2,048. At my site, this structure allocation supports five Logical Partitions (LPARs) and works well.
Next, you must run the IXCMIAPU utility to define the new LOCREC structure in a new CFRM policy. The partial job stream in Figure 1 shows the JCL and control cards for adding the LOGREC structure. A new CFRM policy (named ZOSCFRM8) is created that includes the definition for the LOGREC structure. The SIZE parameter tells the CFRM policy that the largest the LOGREC structure can be is 3,096KB. The INITSIZE parameter caused the initial allocation of the LOGREC structure to be 2,048KB.
Once you’ve successfully created the new CFRM policy, you’re ready to activate this new policy. Enter this command from one of your systems:
SETXCF
START,POLICY,POLNAME=ZOSCFRM8,TYPE=CFRM
Replace ZOSCFRM8 with the name you assigned to your new CFRM policy. After entering the command, you may see “policy pending” messages as shown in Figure 2. This usually means you must manually rebuild one or more structures to activate the new policy. To view the structures causing the pending state, enter this command:
D XCF,STR
If the output of the command (see Figure 3) shows that a structure is in a pending state, you must manually rebuild that structure. In this example, the size of an existing LOGREC structure was increased, creating the need to rebuild that structure. To rebuild it, issue this command:
SETXCF START,REBUILD,STRNM=LOGREC,LOC=NORMAL
After the structure is rebuilt, the new CFRM policy activation is complete and this message is issued:
IXC513I COMPLETED POLICY CHANGE FOR CFRM.
ZOSCFRM8 POLICY IS ACTIVE.
Be careful when rebuilding structures. Some structures shouldn’t be rebuilt, such as the JES2 checkpoint structures. These should be rebuilt using the JES2 checkpoint definition dialog.
The next step is to update the LOGR policy to add the LOCREG log stream. You can define the LOGREC log stream using the IXCMIAPU utility (see Figure 4). The LOGR policy differs from the CFRM policy. With the CFRM policy, we created a new policy that contained the definition for the LOGREC structure and then activated the new policy. With the LOGR policy, the IXCMIAPU utility adds the new entries to the existing policy (see the log stream definition parameters in Figure 5).
The DEFINE STRUCTURE statement defines the structure the CFRM policy allocated. The name specified must match the name in the CFRM policy. The AVGBUFSIZE and MAXBUFSIZE values match the recommendation in the Systems Programmers Guide to z/OS System Logger manual.
The DEFINE LOGSTREAM statement defines the LOGREC log stream:
• The name must be SYSPLEX.LOGREC.ALLRECS.
• STRUCTNAME must match the name specified in the CFRM policy.
• AUTODELETE(YES) and RETPD(90) parameters work together to automatically delete records more than 90 days old.
• LS_SIZE specifies the number of 4KB blocks of the DASD data set used to offload the structure when it reaches the HIGHOFFLOAD full percentage.
• HLQ specifies the High-Level Qualifier of DASD offload data set. This HLQ is placed at the beginning of the log stream name. For example, the offload data sets in this example would be named SAPZPLEX.SYSPLEX. LOGREC.ALLRECS.xxx (where xxx is a counter the MVS logger function adds).
After you run the IXCMIAPU utility, you can check the status of the MVS logger by issuing these commands:
D LOGGER, STATUS
(displays the status of the MVS Logger)
D LOGGER,CONNECTION
(displays active Logger log streams)
Now it’s time to tell LOGREC to change its recording medium from the LOGREC disk data set to our newly defined log stream. To do this, issue this command:
SETLOGRC LOGSTREAM
You should see responses to the command as shown in Figure 6. You can also check the status of the LOGREC recording medium by issuing the “D LOGREC” command.
You can change your IEASYS parmlib member to direct LOGREC to record its data directly to the log stream instead of the disk data set. However, this isn’t recommended. Rather, the recommended method is to let LOGREC come up after an IPL with the standard method of using the disk data set. Then, after the IPL, issue the SETLOGRC command to switch the recording medium to the log stream. The reason for this is that if the LOGREC log stream isn’t available during the IPL, the IPL won’t complete.
Final Thoughts
The JCL you use to generate the EREP report will need to change to read the log stream rather than the DASD LOGREC data set. There’s a sample job for this (and more) in SYS1.SAMPLIB(IFBEREPS).
Using a coupling facility structure and the MVS logger for collecting LOGREC data is a much simpler method to maintain LOGREC data. While you’re revamping LOGREC and EREP, you should also check out the online LOGREC viewer. This handy utility lets you view LOGREC data online via an ISPF application. You can download this free utility from IBM at www-ibm.com/servers/s390/os390/downloads/ logrec_viewer.html.
References
Systems Programmers Guide to z/OS System Logger (SG24-6898-00)
Parallel Sysplex Operational Scenarios (SG24-2079-00)
