WebSphere Application Server for z/OS uses Resource Recovery Services
(RRS) to support two-phase transaction commit. This article describes the
process of preparing RRS.
About this task
Note: RRS must be up and running before WebSphere Application Server
for z/OS servers are started. See z/OS MVS Programming: Resource Recovery (SA22-7616)
for more information.
Normally, all systems in a sysplex share a
common set of RRS logs for syncpoint processing. If you want to associate
specific systems in a sysplex for syncpoint processing, you can specify a
log group name when you start RRS. The default log group name is the sysplex
name. If you specify a different log group name when you start RRS, it will
coordinate syncpoint processing with all systems in the sysplex that use the
same RRS log group name.
Resource recovery services log streams
RRS
uses five log streams that are shared by the systems in the log group. Every
MVS image that runs RRS needs access to the coupling facility and the DASD
on which are defined the system logger log streams for its log group.
Note: You
can define RRS log streams as coupling facility log streams or as DASD-only
log streams.
If using coupling facility log streams, the RRS
images on different systems in a sysplex run independently but share log streams
to keep track of the work. If a system fails, an instance of RRS on a different
system in the sysplex can use the shared logs to take over the failed system's
work.
Use DASD-only log streams only in either single system sysplexes
with one RRS image or a sysplex in which information should not be shared
among RRS images.
The following list summarizes the RRS logs. In the
list,
lgname is the log group name. The default log group
name is the sysplex name.
- ATR.lgname.ARCHIVE
- Information about completed units of recovery (URs). This log stream is
recommended but optional.
- ATR.lgname.RM.DATA
- Information about the resource managers using RRS services.
- 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.
- ATR.lgname.DELAYED.UR
- The state of active URs when UR completion is delayed.
- 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.
In a multiple-system sysplex, RRS log streams should
normally reside in a coupling facility.
All RRS transaction logging
for WebSphere Application Server for z/OS will occur solely in the DELAYED.UR
log stream. You can still configure your MAIN.UR log stream so that it can
handle a production workload in case you deploy a new container or the WebSphere
Application Server for z/OS infrastructure changes. WebSphere Application
Server for z/OS has no significant impact on the RM.DATA or RESTART logs.
Use
the following steps to configure RRS.
- Copy the RRS cataloged procedure, ATRRRS, from SYS1.SAMPLIB to
SYS1.PROCLIB (or another proclib in the MSTJCLxx concatenation), and rename
it RRS.
If you want, you can set the log group name (GNAME)
in the RRS cataloged procedure to a specific value. If you will share the
ATRRRS proc among several systems, however, you might prefer to set the log
group name at RRS startup or use a system variable in IEASYMxx to set each
system's RRS log group name.
- Establish the dispatching priority of the RRS address space.
The best way to control RRS's dispatching priority is through the
workload manager (WLM). IBM recommends that you put RRS in the SYSSTC service
class. The service class you choose must give RRS a dispatching priority greater
than or equal to the dispatching priority of applications and resource managers
that use RRS. SYSSTC will usually accomplish this. For information about system-provided
service classes, see z/OS MVS Planning: Workload Management (SA22-7602).
- Define RRS as a subsystem.
Place the following statement
in an active IEFSSNxx parmlib member:
SUBSYS SUBNAME(RRS)
Place
this statement after the statement that defines the primary subsystem. The
subsystem name (RRS) must match the name of the RRS cataloged procedure.
For more information about IEFSSNxx, see
z/OS MVS Initialization and
Tuning Reference (SA22-7592).
Note: RRS does not support dynamic subsystem
definition, so you cannot use the SETSSI ADD,SUBNAME=RRS command to define
RRS as a subsystem. Even though this command will appear to succeed, subsequent
attempts to start RRS will fail.
- Set up the RRS log streams.
- For your convenience, the WebSphere Application
Server for z/OS product library SBBOJCL contains the following sample jobs
to allocate the RRS log streams:
- BBORRSLC
- Allocates RRS log streams in a coupling facility
- BBORRSLD
- Allocates RRS log streams as DASD-only log streams
- Start RRS.
- Define optional RACF Access
An
entry is created in the ATR.lgname.RM.DATA log for each WebSphere server connected
to RRS. These entries can be deleted automatically by WebSphere when a server
is shut down cleanly with no outstanding transactions to recover. This can
prevent the log from filling up with entries for old servers, which are no
longer part of the configuration. This feature is available when the WebSphere
server is running on z/OS 1.8 and higher, or z/OS 1.6 and higher with MVS
APAR OA12048 installed.
To enable this feature, the user ID that the
application server controller region runs under must have ALTER access to
the MVSADMIN.RRS.COMMANDS.gname.sysname resource in the FACILITY class, where
gname is the RRS logging group (usually the SYSPLEX name) and sysname is the
system name. To allow access to all logging groups and systems, the resource
name can be wildcarded. (For example, MVSADMIN.RRS.COMMANDS.** where the number
of asterisks depends on how the RACF administrator has set up the permissions).
WebSphere
Application Server for z/OS will automatically delete entries when appropriate
from the RM data log, when the appropriate RACF permissions are defined.
Note: Because
the controller region runs as an authorized address space, it will have access
to this resource class unless the RACF configuration explicitly restricts
it. IBM recommends that access to this resource be explicitly allowed, rather
than rely on the authorized state of the controller region.