6.4 Resource Recovery Services

Previous page
Table of content
Next page

  < Day Day Up > 


6.4 Resource Recovery Services

RRS uses five log streams that can be shared by multiple z/OS instances in a sysplex. It keeps track of the resource managers registered with RRS, the Units of Recovery and their state.

6.4.1 Functional description

RRS log streams can be defined either coupling facility based or as DASDONLY log streams, mainly dependent on the workload configurations and on where the RRS resource managers are running. This is only true if those RMs want to participate in the same set of transactions. If RRS resource managers running on different systems in a sysplex participate in the same transactions, then coupling facility log streams are required in order to share information across multiple RRS instances. Each system that wants to connect to the set of log streams needs access to the coupling facility and to the DASD on which the offload data set will reside.

On the other hand, if the RMs never participate in the same transactions, they could be placed in DASDONLY log streams on each system. This configuration can occur either in a single system sysplex with one RRS image, or in a sysplex where each image runs independent workloads from each other (not very common).

RRS images on different systems in the sysplex run independently. However, RRS images that are in the same logging group share the same log stream to keep track of the work. If a system in the same logging group fails, RRS on a different system in the same logging group within the sysplex can use the shared log streams to take over the failed system's work. This means that the CF log streams allow the failed Resource Managers to restart on a different RRS image and that RRS then uses the shared logs to takeover the work. The takeover happens as a result of the failed Resource Managers restart. The Resource Managers must restart before the transactions are taken over and assigned to another RRS image. The shared logs provide the installation with the choice of where the Resource Managers can restart.

If there is only one system connected to the structure where the log streams reside or the log streams are DASD-only, then no other system can take over the failed system's work. In this situation, any outstanding syncpoints are resolved when RRS restarts using the logging group and the resource managers are active within the logging group.

You can have multiple RRS logging groups in a sysplex with different workloads. Each RRS group has a different set of log streams. At start time, RRS knows which group it belongs to from its procedure, and it then connects to the log streams for the specific group. The groupname identifier is part of the log stream name so they can differentiate from each other. The default log groupname is the sysplex name.

Example where your installation might want an RRS log group being a subset of the systems in a sysplex:

  • You can restart RRS with a different log group name to cause a cold start and keep the data in the old logs.

  • More frequently, you can use different log group names to subdivide the syncpoint work in a sysplex. For example, use a different log group for a test system.

Table 6-1 lists the RRS log streams and the related contents:

Table 6-1: RRS Log streams and their content

Log stream type

Log stream name

Content

RRS archive log

ATR.lgname.ARCHIVE

Information about completed URs.This log is optional. See Note for further details.

RRS main UR state log

ATR.lgname.MAIN.UR

The state of active URs. RRS periodically moves this information into the RRS delayed UR state log when UR completion is delayed.

RRS resource manager data log

ATR.lgname.RM.DATA

Information about the resource managers using RRS services.

RRS delayed UR state log

ATR.lgname.DELAYED.UR

The state of active URs, when UR completion is delayed.

RRS restart log

ATR.lgname.RESTART

Information about incomplete URs needed during restart. This information enables a functioning RRS instance to take over incomplete work left over from an RRS instance that failed.
Note 

The ARCHIVE log stream is an optional log stream and your installation can decide to use this log stream based on the following needs:

  • If you need information to manually resolve units of recovery in catastrophic situations where RRS loses information about 'non completed' unit of recovery, for example situation where RRS loses its own log data and it cannot recover UR. You can access the ARCHIVE log stream to see which URs have completed so you can avoid processing completed transactions again.

  • If your installation needs to maintain a history of completed transactions, that is, for accounting.

If you choose not to use the ARCHIVE log stream, a warning message is issued at RRS start up time about not being able to connect to the log stream, but RRS continues its initialization process.

Criticality/persistence of data

RRS keeps information about units of recovery and their process in the log stream for the registered resource managers. This allows the coordination of the two phase commit protocol across multiple resource managers. For this reason, RRS data are very critical to the installation and it is not easy to deal with loss of data related to RRS log streams.

The critical piece of data for RRS is contained in the RM.DATA log stream. It is strongly recommended that you consider unconditionally duplexing the resource manager data log (ATR.lgname.RM.DATA). This log is small and infrequently updated, so its impact on performance is minimal, but any loss of data, unresolved gap, or any permanent error will force an RRS cold start

Since duplexing the logs can impact performance, it is suggested to conditional duplex all the other log streams as RRS is capable to tolerate unresolved gap in case the log stream suffers damage, although RRS will not be able to recover the lost data. (For a description of the meaning and consequence of cold start in an RRS environment, refer to the redbook Systems Programmer's Guide to: RRS, which is planned for publication in the first quarter of 2004.)

Log stream sizing

Table 6-2 on page 221 provides initial consideration on the amount of storage required for the RRS log streams. These recommendations should result in reasonably efficient usage of coupling facility storage while minimizing the likelihood that you will have to redefine the structures due to the variations in your workload. However, the exact amount of storage you need for each log stream depends on the installation RRS workload. SMF88 data can be used to understand if the structure sizes require any adjustments. If your RRS log streams are DASD ONLY log streams, determine the size of the Coupling Facility structure that would be needed for each log stream and make the staging data set as big as the structure would be.

Table 6-2: RRS log streams and allocation considerations

Log stream

Log Stream Name

Interim storage Requirement

Maximum Size in K

Initial Size in K

Archive log

ARCHIVE

High

24576

6144

Resource Manager data log

RM.DATA

Low, if few resource managers; Medium, if many resource managers

4096

1024

Main UR state log

MAIN.UR

Medium

4096

1024

Restart log

RESTART

Medium

28672

9216

Delayed UR state log

DELAYED.UR

High

24576

8192

After your initial set up, you can use the values from the SMF88 report as input to the web-based tool to determine the exact amount of coupling facility space that you should allocate for a coupling facility structure. This tool can be accessed via the IBM web site:

http://www.ibm.com/servers/eserver/zseries/pso

Because of the differences in activity rate among the multiple RRS log streams and also the possibility to easily manage their coupling facility storage sizing, it is suggested to map each coupling facility log stream to a unique coupling facility structure.

In case your installation has a constraint in the available number of coupling facility structures in your CFRM policy, you can think about grouping multiple RRS log stream in a single coupling facility structure. In this configuration:

  • Re-evaluate the need for the ARCHIVE log stream in your installation and if your installation doesn't not make any use of the log stream data, delete the log stream. Before deleting the log stream, verify this action with all the resource managers to make sure they do not take advantage of this data in normal operations.

  • Combine the RM.DATA and RESTART log streams in the same structure.

  • Combine the MAIN.UR and DELAYED.UR log stream in the same structure.

RRS log streams belong to the active log stream with the exception of the ARCHIVE. RRS has a trimming mechanism, so it keeps the content of the log streams up the date with the current workload running on the system. As for the ARCHIVE, this is a funnel-type log stream, where RRS writes a record to the log stream for each completed transaction. RRS just writes and never reads the ARCHIVE log and therefore never deletes archive log records. You should use a combination of AUTODELETE and RETPD to manage this log stream.

6.4.2 Definition

Subsystem definition

There are no actual definitions in the RRS subsystem to map the log stream. Each member of a RRS group connects to the group's own set of log streams at start up time and the log stream are structured with a fixed name, that is, ATR.groupname.DELAYED.UR where the plexname is the sysplex name by default or the logging group name if multiple RRS logging group are present within the same sysplex. Either the plexname or the logging group is the connection between the RRS group and the set of log streams to be used.

If there is only one RRS logging group, then it is common to use the sysplex name as qualifier and nothing has to be done on the subsystem side to identify the log streams to connect to. If multiple RRS log groups exist within the sysplex, then the RRS procedure GNAME parameter need to be updated with the value of the specific qualifier of this RRS log group so this particular instance of RRS connects to this set of log streams peculiar to this logging group.

Logger definition

RRS can use either Coupling Facility log streams or DASDONLY log streams. In an RRS environment, it is rare to see a mixing of Coupling Facility log streams and DASDONLY log streams. Usually the choice toward one media or another is mainly dictated by the capability of sharing the log streams across multiple instance of RRS.

Coupling Facility log streams

The following samples show definitions for the RRS log stream and their logger view of the structures. To define a log stream, a combination of a structure and log stream definition are needed. The parameters and values that can affect performance and functionality are marked and discussed in the following sections.

Structure definitions in the CFRM Policy for the RRS log streams

This task is only required if you are planning to use Coupling Facility log streams. Before running any LOGR policy, you have to make sure that the correspondent Coupling Facility structure has already been defined in the CFRM policy and that the CFRM policy has been activated in the sysplex through the SETXCF command.

Here is a set of initial samples to define the Coupling Facility structures for the RRS log streams. Usually these sizing values are good for most of the installation, at least as starting point. We suggest that you use both RMF Coupling Facility report and the SMF88 output to validate your log stream configuration.

Example 6-17: Structure Definition for MAIN.UR sample

start example 
 //MAINSTR JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(CFRM)    STRUCTURE NAME(RRS_MAINUR_1)       SIZE(4096)       INITSIZE(1024)       PREFLIST(FACIL01, FACIL02)
end example

Example 6-18: Structure Definition for DELAYED.UR sample

start example 
 //DELSTR JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(CFRM)    STRUCTURE NAME(RRS_DELAYED_1)       SIZE(24576)       INITSIZE(8192)       PREFLIST(FACIL01, FACIL02)
end example

Example 6-19: Structure Definition for ARCHIVE sample

start example 
 //ARCSTR JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(CFRM) REPORT(YES)    STRUCTURE NAME(RRS_ARCHIVE_1)       SIZE(24576)       INITSIZE(6144)       PREFLIST(FACIL01, FACIL02)
end example

Example 6-20: Structure Definition for RM.DATA sample

start example 
 //RMSTR JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(CFRM) REPORT(YES)    STRUCTURE NAME(RRS_RMDATA_1)       SIZE(4096)       INITSIZE(1024)       PREFLIST(FACIL01, FACIL02)
end example

Example 6-21: Structure Definition for RESTART sample

start example 
 //RSTSTR JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(CFRM)    STRUCTURE NAME(RRS_RESTART_1)       SIZE(28672)       INITSIZE(9216)       PREFLIST(FACIL01, FACIL02)
end example

Logger structure definitions

The structure used for the log stream affects performance. Key factors include the number and characteristics of the log streams which shares the structure. Best practise has shown that the best performance is achieved when in the RRS environment there is one log stream per structure.

Following are the example for the definition of the structure in the LOGR policy.

Example 6-22: MAIN.UR structure definition sample

start example 
 //MAINSTR JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR)    DEFINE STRUCTURE NAME(RRS_MAINUR_1)       LOGSNUM(1)       AVGBUFSIZE(158)       MAXBUFSIZE(65276)
end example

Example 6-23: DELAYED.UR structure definition sample

start example 
 //DELAYSTR JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR) REPORT(YES)    DEFINE STRUCTURE NAME(RRS_DELAYED_1)       LOGSNUM(1)       AVGBUFSIZE(158)       MAXBUFSIZE(65276)
end example

Example 6-24: ARCHIVE structure definition sample

start example 
 //ARCHSTR JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR) REPORT(YES)    DEFINE STRUCTURE NAME(RRS_ARCHIVE_1)       LOGSNUM(1)       AVGBUFSIZE(262)       MAXBUFSIZE(65276)
end example

Example 6-25: RM.DATA structure definition sample

start example 
 //RMSTR JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR) REPORT(YES)    DEFINE STRUCTURE NAME(RRS_RMDATA_1)       LOGSNUM(1)       AVGBUFSIZE(252)       MAXBUFSIZE(1024)
end example

Example 6-26: RESTART structure definition sample

start example 
 //RSTSTR JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR) REPORT(YES)    DEFINE STRUCTURE NAME(RRS_RESTART_1)       LOGSNUM(1)       AVGBUFSIZE(158)       MAXBUFSIZE(65276)
end example

MAXBUFSIZE: MAXBUFSIZE in conjunction with AVGBUFSIZE is used to determine the CF structure ENTRY/ELEMENT ratio. When data is written to the CF, it's written in increments equal to ELEMENT size. A MAXBUFSIZE greater than 65276 gives an element size of 512; a MAXBUFSIZE equal to or less than 65276 results in an element size of 256.

With OS/390 R1.3, System Logger dynamically adjusts the Entry/Element ratio avoiding potential problem, specially if you are not planning to share the same structure between multiple log stream with in theory different characteristics.

Log stream definitions

Example 6-27: MAIN.UR log stream

start example 
 //MAINLOG JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR)    DEFINE LOGSTREAM NAME(ATR.groupname.MAIN.UR)       STRUCTNAME(RRS_MAINUR_1)       LS_DATACLAS(LOGR4K)       HLQ(IXGLOGR)       LS_SIZE(1024)       STG_SIZE()       LOWOFFLOAD(60)       HIGHOFFLOAD(80)       STG_DUPLEX(YES)       DUPLEXMODE(COND)       RETPD(0)       AUTODELETE(NO)
end example

Example 6-28: DELAYED.UR log stream

start example 
 //DELLOG JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR)    DEFINE LOGSTREAM NAME(ATR.groupname.DELAYED.UR)       STRUCTNAME(RRS_DELAYEDUR_1)       LS_DATACLAS(LOGR4K)       HLQ(IXGLOGR)       LS_SIZE(1024)       STG_DATACLAS()       STG_SIZE(9000)       LOWOFFLOAD(60)       HIGHOFFLOAD(80)       STG_DUPLEX(YES)       DUPLEXMODE(COND)       RETPD(0)       AUTODELETE(NO)
end example

Example 6-29: ARCHIVE log stream

start example 
 //ARCHLOG JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR)    DEFINE LOGSTREAM NAME(ATR.groupname.ARCHIVE.UR)       STRUCTNAME(RRS_ARCHIVE_1)       LS_DATACLAS(LOGR4K)       HLQ(IXGLOGR)       LS_SIZE(1024)       STG_SIZE(9000)       LOWOFFLOAD(0)       HIGHOFFLOAD(80)       STG_DUPLEX(NO)       RETPD(2)       AUTODELETE(YES)
end example

Example 6-30: RM.DATA log stream

start example 
 //RMLOG JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR)    DEFINE LOGSTREAM NAME(ATR.groupname.RM.DATA)       STRUCTNAME(RRS_DATA_1)       LS_DATACLAS(LOGR4K)       HLQ(IXGLOGR)       LS_SIZE(1024)       STG_DATACLAS()       STG_SIZE(9000)       LOWOFFLOAD(60)       HIGHOFFLOAD(80)       STG_DUPLEX(YES)       DUPLEXMODE(UNCOND)       RETPD(0)       AUTODELETE(NO)
end example

Example 6-31: RESTART log stream

start example 
 //RESTLOG JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR)    DEFINE LOGSTREAM NAME(ATR.groupname.RESTART)       STRUCTNAME(RRS_RESTART_1)       LS_DATACLAS(LOGR4K)       HLQ(IXGLOGR)       LS_SIZE(1024)       STG_DATACLAS()       STG_SIZE(9000)       LOWOFFLOAD(60)       HIGHOFFLOAD(80)       STG_DUPLEX(YES)       DUPLEXMODE(COND)       RETPD(0)       AUTODELETE(NO)
end example

AUTODELETE and RETPD: AUTODELETE and RETPD can have a disastrous effect on all the RRS log stream except the ARCHIVE if specified other than AUTODELETE(NO) and RETPD(0). With AUTODELETE(YES) and RETPD>0, even though RRS will attempt to delete un-necessary log entries, all data will be off-loaded to the offload data sets and held for the number of days specified for RETPD. AUTODELETE(YES) allows the System Logger (rather than RRS) to decide when to delete the data. When a new offload data set is allocated and AUTODELETE(YES) is specified, the System Logger will delete the data on the old offload data set. Since data on the MAIn.UR are managed by RRS, you must let RRS managed the life of the records on this log streams so there will not be the risk that RRS will need records that have been deleted by logger because of the AUTODELETE option.

For the ARCHIVE log stream, RRS never uses information written on the Archive log; the information is intended for the installation to use if a catastrophic problem occurs. You must use retention period and autodelete support to delete old entries - specify these value big enough to manage this log stream on a reasonable size and to provide enough coverage in time to recover any potential situation.

HIGHOFFLOAD: The HIGHOFFLOAD parameter is used to determine when the space dedicated to the log stream in the Coupling Facility is filling up and an offload need to be initiated to re-gain available space. HIGHOFFLOAD should be set at 80% for all the RRS log streams at least initially and then use the SMF88 report to evaluate if this value need same tuning.

LOWOFFLOAD: The LOWOFFLOAD value defines the amount of data which may be retained in the log stream interim storage following an offload process. In the RRS environment, the LOWOFFLOAD value should be high enough to retain the data required for backout of the UR but low enough to keep the number of offloads to a minimum.

LOWOFFLOAD should be set between 40 and 60% for all the RRS log stream as described in the examples and 0% for the ARCHIVE.

LS_SIZE: LS_SIZE defines the allocation size for the offload data sets. It should be specified large enough to contain several offloads, possibly a day's worth. All RRS log streams except ARCHIVE should only offload a minimal amount of data.

Caution 

If LS_SIZE is not specified in the log stream definition, and an extent size is not specified in the data class pointed to by LS_DATACLAS, the value is taken from the ALLOCxx Parmlib member. The default value in ALLOCxx is 2 tracks. Refer to the z/OS MVS Initialization and Tuning Reference, SA22-7592.

It is very important to remember log stream staging and offload (log) data sets are single extent VSAM linear data sets, and the shareoptions MUST be specified as '3,3'. If the shareoptions are anything other than '3,3' there is a risk the System Logger will be unable to read offloaded data and provide RRS with return code 8, reason code 804 (IxgRsnCodeNoBlock).

STG_SIZE: For a Coupling Facility log stream, STG_SIZE defines the size of the staging data set to be allocated if STG_DUPLEX(YES). If DUPLEXMODE(UNCOND) is specified the data in the Coupling Facility log stream will always be duplexed to the staging data set. If DUPLEXMODE(COND) is specified the data in the Coupling Facility log stream is duplexed to the staging data set only if the CF becomes volatile or failure dependent.

The size of the staging data set (STG_SIZE) must be large enough to hold as much data as the log stream storage in the Coupling Facility. IF STG_SIZE is (), logger allocates a staging data set large enough to hold the coupling facility structure size.

Data is written to the staging data set in 4096 byte increments, regardless of the buffer size.

STG_DUPLEX: STG_DUPLEX(YES) with DUPLEXMODE(COND) means that if the CF becomes volatile, or resides in the same failure domain as the System Logger system, the log stream data will be duplexed to the staging data set; otherwise it is duplexed to buffers in the System Logger dataspace. A CF is in the same failure domain when the Coupling Facility LPAR and the LPAR running this OS/390 or z/OS reside in the same physical hardware box, central processing complex (CPC). Duplexing to the staging data set means the cost of an I/O will be incurred for each write.

LS_DATACLAS: With this keyword, you can specify the SMS Dataclass that is used for the allocation of offload data sets. The Automatic Class Selection (ACS) routines can override this value so you should ensure the desired dataclass is used. In addition to the size of the data set, the dataclass defines the CI Size for the data set along with the share options. Offload data sets may use a CI size up to 24K; in general, the larger CI size provides better performance, however, if the log stream consists mostly of log blocks of a much smaller size, the 24K CI size may be wasteful.

Attention: 

For a shared Coupling Facility log stream which has connections to multiple z/OS images when the offload process is triggered, the offload may be performed by the logger address space on a different z/OS image. If the offload requires the movement of data to the log (offload) data sets, and the current data set fills, a new data set will be allocated. Unless the shareoptions are specified 3,3 the logger address space on the z/OS image where RRS is running may not be able to access the data set.

STG_DATACLAS: With this keyword, you can specify the SMS Dataclass that is used for the allocation of staging data sets. The Automatic Class Selection (ACS) routines can override this value so you should ensure that desired dataclass is used. In addition to the size of the data set, the dataclass defines the CI Size for the data set along with the share options. Staging data sets must use a CI size of 4K.

Important: 

the data class is the only way to specify the share options for a data set. You MUST ensure that all System Logger data sets, including staging data sets, are allocated with a dataclass that defines share options (3,3).

DASD-only log stream definitions

The following samples show definitions for the RRS log stream when defined as DASD-only log streams. The parameters and values that can affect performance and functionality are marked and discussed in the following sections.

Example 6-32: MAIN.UR DASD-only log stream sample

start example 
 //MAINLOG JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR)    DEFINE LOGSTREAM NAME(ATR.groupname.MAIN.UR)       DASDONLY(YES)       LS_DATACLAS(LOGR4K)       HLQ(IXGLOGR)       LS_SIZE(1024)       STG_DATACLAS()       STG_SIZE(9000)       LOWOFFLOAD(60)       HIGHOFFLOAD(80)       RETPD(0)       AUTODELETE(NO)       DASDONLY(YES)       MAXBUFSIZE(65532)
end example

Example 6-33: DELAYED.UR DASD-only log stream sample

start example 
 //DELLOG JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR) REPORT(YES)    DEFINE LOGSTREAM NAME(ATR.groupname.DELAYED.UR)       DASDONLY(YES)       LS_DATACLAS(LOGR4K)       HLQ(IXGLOGR)       LS_SIZE(1024)       STG_DATACLAS()       STG_SIZE(9000)       LOWOFFLOAD(60)       HIGHOFFLOAD(80)       RETPD(0)       AUTODELETE(NO)       DASDONLY(YES)       MAXBUFSIZE(65532)
end example

Example 6-34: ARCHIVE DASD-only log stream sample

start example 
 //ARCHLOG JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR)    DEFINE LOGSTREAM NAME(ATR.groupname.ARCHIVE.UR)       DASDONLY(YES)       LS_DATACLAS(LOGR4K)       HLQ(IXGLOGR)       LS_SIZE(1024)       STG_DATACLAS()       STG_SIZE(9000)       LOWOFFLOAD(0)       HIGHOFFLOAD(80)       RETPD(15)       AUTODELETE(YES)       DASDONLY(YES)       MAXBUFSIZE(65532)
end example

Example 6-35: RM.DATA DASD-only log stream sample

start example 
 //RMLOG JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR)    DEFINE LOGSTREAM NAME(ATR.groupname.RM.DATA)       DASDONLY(YES)       LS_DATACLAS(LOGR4K)       HLQ(IXGLOGR)       LS_SIZE(1024)       STG_DATACLAS()       STG_SIZE(9000)       LOWOFFLOAD(60)       HIGHOFFLOAD(80)       RETPD(0)       AUTODELETE(NO)       DASDONLY(YES)       MAXBUFSIZE(65532)
end example

Example 6-36: RESTART DASD-only log stream sample

start example 
 //RESTLOG JOB CLASS=A,MSGCLASS=A //POLICY EXEC PGM=IXCMIAPU //SYSPRINT DD SYSOUT=A //SYSIN DD *    DATA TYPE(LOGR)    DEFINE LOGSTREAM NAME(ATR.groupname.RESTART)       DASDONLY(YES)       LS_DATACLAS(LOGR4K)       HLQ(IXGLOGR)       LS_SIZE(1024)       STG_DATACLAS()       STG_SIZE(9000)       LOWOFFLOAD(60)       HIGHOFFLOAD(80)       RETPD(0)       AUTODELETE(NO)       DASDONLY(YES)       MAXBUFSIZE(65532)
end example

MAXBUFSIZE: MAXBUFSIZE may be specified for a DASDONLY log stream, it defines the largest block that can be written to the log stream. The default value is 65532 and should be used in a RRS environment.

STG_DUPLEX: STG_DUPLEX(YES) with DUPLEXMODE(UNCOND) are implicitly defaulted in DASDONLY log streams.

Security definitions

The RRS log streams can be protected in the Security Access Facility (SAF) LOGSTRM class. To enable the protection, you need to give READ access to the TSO userids or groups that will need to retrieve log data through the RRS panels and the UPDATE access level to the RRS address space userid.

If your installation doesn't not require this level of security, you can define the log stream with READ as universal access. This will allow all the userid in your installation to browse the RRS log streams data.

Example 6-37: Sample log stream security definitions

start example 
 RDEFINE LOGSTRM ATR.plexname.RESTART UACC(NONE) RDEFINE LOGSTRM ATR.plexname.MAIN.UR UACC(NONE) RDEFINE LOGSTRM ATR.plexname.ARCHIVE UACC(NONE) RDEFINE LOGSTRM ATR.plexname.DELAYED.UR UACC(NONE) RDEFINE LOGSTRM ATR.plexname.RM.DATA UACC(NONE) PERMIT ATR.plexname.RESTART CLASS(LOGSTRM) ID(CBASR2) ACCESS(UPDATE) PERMIT ATR.plexname.MAIN.UR CLASS(LOGSTRM) ID(CBASR2) ACCESS(UPDATE) PERMIT ATR.plexname.ARCHIVE CLASS(LOGSTRM) ID(CBASR2) ACCESS(UPDATE) PERMIT ATR.plexname.DELAYED.UR CLASS(LOGSTRM) ID(CBASR2) ACCESS(UPDATE) PERMIT ATR.plexname.RM.DATA CLASS(LOGSTRM) ID(CBASR2) ACCESS(UPDATE) PERMIT ATR.plexname.RESTART CLASS(LOGSTRM) ID(tso_userid) ACCESS(READ) PERMIT ATR.plexname.MAIN.UR CLASS(LOGSTRM) ID(tso_userid) ACCESS(READ) PERMIT ATR.plexname.ARCHIVE CLASS(LOGSTRM) ID(tso_userid) ACCESS(READ) PERMIT ATR.plexname.DELAYED.UR CLASS(LOGSTRM) ID(tso_userid) ACCESS(READ) PERMIT ATR.plexname.RM.DATA CLASS(LOGSTRM) ID(tso_userid) ACCESS(READ) SETROPTS CLASSACT(LOGSTRM)
end example

The log stream name defined to RACF is the name specified on the NAME parameter of the DEFINE LOGSTREAM statement in the LOGR policy

6.4.3 Operational considerations

Application start up

Every time an application that uses RRS starts, RRS needs to go through the log stream reading and updating the RM.DATA and reading the other log streams. This process needs to be performed sequentially, so forth, RRS enqueues on SYSZATR.plexname/logrp.RESTART resource. Bear in mind that the application start process can take some time and if you start multiple applications using RRS at the same time, there might be some delay.

RRS shutdown

Before shutting RRS down, you should shut down all the RRS applications. Once the RRS application are down, issue the following commands:

  • SETRRS CANCEL command to shutdown RRS

  • D LOGGER,L,LSN=ATR.* and verify that the connections number is 0.

If the connection number is not 0, issue the D LOGGER,C,LSN=ATR.* to verify the outstanding connection in every system in the sysplex. If the number of connections is zero, then RRS needs to go through log streams recovery.

Power-on-Reset

Make sure that RRS disconnects from its log streams before shutting down the z/OS images and performing a power-on-reset of the coupling facility and z/OS CECs. This action will prevent loss of data or message ATR212I RRS DETECTED LOG DATA LOSS at IPL time.

When you are shutting down your system, after all the resource managers are down, you can issue the SETRRS CANCEL command to close RRS and force it to disconnect from its log stream. This will allow logger to offload the data and harden them on the offload data set.

Starting RRS with no log stream defined

RRS is not able to complete is initialization if it cannot connect to the log stream. You will receive the following messages on the console and RRS will shutdown.

Example 6-38: RRS start up messages

start example 
 S RRS ATR221I RRS IS JOINING RRS GROUP A ON SYSTEM #@$1  IXG231I IXGCONN REQUEST=CONNECT TO LOG STREAM ATR.A.RM.DATA DID NOT  SUCCEED FOR JOB RRS.  RETURN CODE: 00000008  REASON CODE: 0000080B  DIAG1: 00000008  DIAG2: 0000F801  DIAG3: 05030004  DIAG4: 05020010  ATR130I RRS LOGSTREAM CONNECT HAS FAILED FOR  MANDATORY LOGSTREAM ATR.A.RM.DATA.  RC=00000008, RSN=00000000  IEA989I SLIP TRAP ID=X13E MATCHED.  JOBNAME=RRS     , ASID=0082.  ASA2013I RRS INITIALIZATION FAILED. COMPONENT ID=SCRRS
end example

6.4.4 Recovery

Log streams recovery

To perform RRS log stream recovery, restart and then shutdown all the RRS instances to force RRS to connect and then disconnect to the log streams.This will try to clear and solve any potential problem.

Cold start

The most critical log stream is the RM.DATA. If, for any reason, data is lost, RRS cannot recover and the only way to resume is to perform a cold start. In case of a cold start, all the in-fight UOW for the Resource Managers that were registered with RRS will abend.

Although to perform a cold start you only need to redefine the RM.DATA log stream, it is suggested to delete all the current log streams, define new ones and restart RRS. This will clean all the previous information and perform a clean restart.

In case you want to keep the old logs for problem determination, then you only need to redefine the RM.DATA and use the other old log streams.

Performance

After your initial log streams allocation, performance data is produced in a number of forms that can be useful to determine if any adjustments are necessary to your installation:

  • SMF 88 data produced by the MVS System Logger

  • SMF 70–78 data produced by various MVS components

There are several tools which aide in the analysis of log stream performance problems.

  • IXGRPT1 formats and reports the SMF 88 data produced by the MVS System Logger

  • ERBRMFPP reports on the data captured in the SMF 70 -78 records

All the RRS log streams with the exception of the ARCHIVE are active log stream: this means that RRS takes care of maintaining currency of data within the log stream. For this reason, after an accurate tuning, while we should expect offloads for the ARCHIVE log stream, we should see that offload are eliminated or minimized for all the other log streams.

In addition, generally speaking, RRS log streams usually are not very critical from a performance perspective. There are some fields in the SMF88 that you might want to check against the active log streams to determine if they are tuned properly: DASD SHIFT, STRUCTURE FULL, ENTRY FULL and OFFLOAD.

As regards to the ARCHIVE log stream, being a funnel type log stream, offload are expected - for this reason you should check the fields DASD SHIFT, STRUCTURE FULL, ENTRY FULL and SC1/2/3 in the SMF88 for this particular log stream.

Refer to "SMF Type 88 records and IXGRPT1 program" on page 281 for a description of these fields and what to do in case of one of this condition happens in your installation


  < Day Day Up > 


Previous page
Table of content
Next page
Systems Programmer's Guide to--Z. OS System Logger
ASP.NET for Web Designers
ISBN: 738489433
EAN: 2147483647
Year: 2002
Pages: 99
Authors: Peter Ladka
BUY ON AMAZON
SQL Hacks
The Java Tutorial: A Short Course on the Basics, 4th Edition
What is Lean Six Sigma
Visual Studio Tools for Office(c) Using C# with Excel, Word, Outlook, and InfoPath
.NET System Management Services
VBScript in a Nutshell, 2nd Edition
flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net
Privacy policy