Log stream offload process
This chapter describes a z/OS V2R2 enhancement to the log stream offload process.
The z/OS system logger component allows data to be logged from one or more systems within a sysplex. Typical users of this enhancement are the operations log stream (OPERLOG), the IBM Service Management Facility (SMF) log stream, and the IBM CICS® log manager. You also can choose to write your own application to use write the use system logger.
This chapter includes the following topics:
5.1 Overview
The system logger writes user log data to a log stream. The data in the log stream can be stored in the following ways:
•Interim storage: Data can be accessed quickly and can be held in the following areas:
– A CF log stream: Where the interim storage for log data is in the CF list structures.
– DASD-only log stream: Where interim storage for log data is held in local storage buffers on the system. The local storage buffers in the logger data space are associated with the system logger address space IXGLOGR.
•Offloaded storage: Stored in DASD log data sets.
The users from each of the systems that are connected to the log stream write their data to it. At some point, the volume of data fills up the log stream interim storage. To help prevent this issue, thresholds are set to trigger the offload process to alleviate the threat of the log stream becoming full.
The effect of a log stream filling up interim storage can range from the user not being able to write more log data, to performance issues, or to a multi-system outage.
5.2 Offload processing
Offload processing is performed by a system logger for both the CF structure and the DASD-only log streams. This process is responsible for moving old data from the coupling facility (CF) structure or local buffers to offload data sets for more permanent storage.
When a log stream or interim storage reaches its high threshold, the offload process is triggered to delete and migrate data from the log stream interim storage to offload data sets. The offload process consists of the following steps:
1. Delete all log blocks that were logically deleted by IXGDELET.
2. If LOWOFFLOAD was not reached, calculate how much data must be offloaded to reach the low offload threshold.
3. Allocate the offload data set, if not currently allocated.
4. Offload data to offload data sets. All eligible data is moved, regardless of the system that created the data.
If the current offload data set is filled, and there is still data to be moved, a new offload data set is allocated, and offload continues.
For a CF structure log stream, the space is freed up as the offload proceeds. For DASD-only log streams, the space is freed only after the offload completes.
5.2.1 Offload data set allocation
You can have multiple log streams in use at the same time, or perform multiple offload processes that are running concurrently for different log streams. Earlier releases of system logger featured only one task per system to allocate and deleted offload data sets. Therefore, if you have an offload process running and it is allocating an offload data set, other offload processes might be delayed if they also require allocation to new data sets.
As of V2R1 and V1R13 (with appropriate maintenance) the constraint of using tasks is relieved.
5.3 z/OS V2R2 changes
There is a new keyword available when defining or updating log streams on z/OS V2R2 called LS_ALLOCAHEAD to proactively allocate up to three advance-current offload data sets.
Before you use LS_ALLOCAHEAD for defining log streams, you must make sure that this feature is enabled in your environment. The default is to have this feature enabled. You can enable or disable ALLOCAHEAD on SYS1.PARMLIB member IXGCNFxx. You can also enable or disable ALLOCAHEAD dynamically by using the ia command (see Example 5-1).
Example 5-1 Set ALLOCAHEAD ON/OFF
SETLOGR MANAGE,OFFLOAD,ALLOCAHEAD(YES|NO)
You can allocate up to three advance-current offload data sets when log streams are defined or updated. If a new log stream is defined, the offload data sets are opened when a data set switch is necessary from the actual offload data set that is being written to for the log stream.
When the first advance-current offload data set becomes the current data set, the logger automatically triggers another allocation to get a new advance-current offload data set to meet the target.
Example 5-2 shows a sample of commands to define a DASD-only log stream with three advance-current offload data sets. If the return code for the define command is zero, the system logger allocates three advance-current offload data sets and the current offload data set in advance.
Example 5-2 Define sample log stream
DEFINE LOGSTREAM
NAME(LOGGER.TEST1)
STRUCTNAME(LIST01)
DASD-ONLY(YES)
LS_ALLOCAHEAD(3)
The define command defines all offload data sets. The first advance-current offload data set is not opened until an IXGWRITE is issued and the log data must be offloaded. Example 5-3 shows the log messages that are related to offload data set allocation.
Example 5-3 Offload data sets allocation messages
IXG283I OFFLOAD DATASET IXGLOGR.LOGGER.TEST1.A0000000
ALLOCATED NEW FOR LOGSTREAM LOGGER.TEST1
CISIZE=4K, SIZE=147456
IXG283I OFFLOAD DATASET IXGLOGR.LOGGER.TEST1.A0000001
ALLOC ADV NEW FOR LOGSTREAM LOGGER.TEST1
CISIZE=4K, SIZE=147456
You can view the advance-current data sets allocated by displaying the log stream. Example 5-4 shows the log stream display output.
Example 5-4 Log stream display
IXG601I 19.03.17 LOGGER DISPLAY FRAME 1 F E SYS=SY1
CONNECTION INFORMATION BY LOGSTREAM FOR SYSTEM SY1
LOGSTREAM STRUCTURE #CONN STATUS
--------- --------- ------ ------
LOGGER.TEST1 LIST01 000001 IN USE
DUPLEXING: LOCAL BUFFERS
GROUP: PRODUCTION
OFFLOAD DSN FORMAT: IXGLOGR.LOGGER.TEST1.<SEQ#>
CURRENT DSN OPEN: YES SEQ#: A0000000
ADV-CURRENT DSN OPEN: YES SEQ#: A0000001
New advance-current offload data sets are automatically created when current offload data sets become full.
If you decide to update the number of advance-current offload data sets for a specific log stream, you can use the update option in the IXCMIAPU utility, as shown in Example 5-5.
Example 5-5 Update log stream to use two advance-current offload data sets
UPDATE LOGSTREAM
NAME(LOGGER.TEST1)
LS_ALLOCAHEAD(2)
The update is pending after the command is issued. It takes effect when one of the following scenarios are present:
•The next log stream offload data set is allocated (data set switch event).
•On the first connection to the log stream in the sysplex.
•During the next structure rebuild for a structure-based log stream.
Logger was also updated to deallocate current offload data sets. Also, all advanced current offload data sets might be opened in the system that are not currently in use. To deallocate these data sets, you can use the command that is shown in Example 5-6.
Example 5-6 Deallocate all LOGGER.TEST1 data sets
SETLOGR FORCE,DEALLC,LSN=LOGGER.TEST1
5.3.1 Migration and coexistence
There are coexistence program temporary fixes (PTFs) that are available so that the LS_ALLOCAHEAD keyword can be used for log streams on multi-level systems. It is also necessary to have the LOGR couple data set formatted at the HBB7705 Level. Consider formatting your couple data sets before this option is used.
Although the LS_ALLOCAHEAD keyword is not available in earlier releases (z/OS v1r13 and z/OS v2r1), it appears in the IXCMIAPU report and list output for log stream attributes. Advanced-current offload data sets are not newly created or proactively used on earlier systems, but are used as needed.
New z/OS v2r2 IXGCNFxx parmlib specifications are not recognized on earlier release levels. You must use a separate member for z/OS v2r2 systems. Errors during initial loading result in defaults for parmlib options being used.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.