This topic applies only on the z/OS operating system.

Preparing Resource Recovery Services

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.

Procedure

  1. 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.

  2. 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).

  3. 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.
  4. Set up the RRS log streams.
    • The "Configure stand-alone application server" task in the Customization Dialog creates sample job BBORRSLS to allocate 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
  5. Start RRS.
    • To start RRS with a specific log group name "lgname", enter the following MVS console command:
      START RRS,GNAME=lgname
    • To stop RRS, enter the following MVS console command:
      SETRRS CANCEL
      Note: Do not stop RRS while WebSphere Application Server for z/OS servers are running.

What to do next

For more information on setting up and running RRS, see z/OS MVS Programming: Resource Recovery (SA22-7616).
Task topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 10:43:27 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v602web&product=was-nd-mp&topic=tins_preprrs
File name: tins_preprrs.html