Resource Recovery Services attachment facility

An attachment facility enables programs to communicate with Db2. The Resource Recovery Services attachment facility (RRSAF) provides such a connection for programs that run in z/OS® batch, TSO foreground, and TSO background. The RRSAF is an alternative to CAF and has more functionality.

An application program using RRSAF can perform the following actions:
  • Use Db2 to process SQL statements, commands, or instrumentation facility interface (IFI) calls.
  • Coordinate Db2 updates with updates made by all other resource managers that also use z/OS RRS in an z/OS system.
  • Use the z/OS System Authorization Facility and an external security product, such as RACF®, to sign on to Db2 with the authorization ID of a user.
  • Sign on to Db2 using a new authorization ID and an existing connection and plan.
  • Access Db2 from multiple z/OS tasks in an address space.
  • Switch a Db2 thread among z/OS tasks within a single address space.
  • Access the Db2 IFI.
  • Run with or without the TSO terminal monitor program (TMP).
  • Run without being a subtask of the DSN command processor (or of any Db2 code).
  • Run above or below the 16-MB line.
  • Establish an explicit connection to Db2, through a call interface, with control over the exact state of the connection.
  • Establish an implicit connection to Db2 (with a default subsystem identifier and a default plan name) by using SQL statements or IFI calls without first calling RRSAF.
  • Supply event control blocks (ECBs), for Db2 to post, that signal start-up or termination.
  • Intercept return codes, reason codes, and abend codes from Db2 and translate them into messages as required.

RRSAF uses z/OS Transaction Management and Recoverable Resource Manager Services (z/OS RRS).

Any task in an address space can establish a connection to Db2 through RRSAF. Each task control block (TCB) can have only one connection to Db2. A Db2 service request that is issued by a program that runs under a given task is associated with that task's connection to Db2. The service request operates independently of any Db2 activity under any other task.

Each connected task can run a plan. Tasks within a single address space can specify the same plan, but each instance of a plan runs independently from the others. A task can terminate its plan and run a different plan without completely breaking its connection to Db2.

RRSAF does not generate task structures.

When you design your application, consider that using multiple simultaneous connections can increase the possibility of deadlocks and Db2 resource contention.

Restriction: RRSAF does not provide attention processing exits or functional recovery routines. You can provide whatever attention handling and functional recovery your application needs, but you must use ESTAE/ESTAI type recovery routines only.

A tracing facility provides diagnostic messages that help you debug programs and diagnose errors in the RRSAF code. The trace information is available only in a SYSABEND or SYSUDUMP dump.

To commit work in RRSAF applications, use the CPIC SRRCMIT function or the Db2 COMMIT statement. To roll back work, use the CPIC SRRBACK function or the Db2 ROLLBACK statement.

Use the following guidelines to decide whether to use the Db2 statements or the CPIC functions for commit and rollback operations:
  • Use Db2 COMMIT and ROLLBACK statements when all of the following conditions are true:
    • The only recoverable resource that is accessed by your application is Db2 data that is managed by a single Db2 instance.

      Db2 COMMIT and ROLLBACK statements fail if your RRSAF application accesses recoverable resources other than Db2 data that is managed by a single Db2 instance.

    • The address space from which syncpoint processing is initiated is the same as the address space that is connected to Db2.
  • If your application accesses other recoverable resources, or syncpoint processing and Db2 access are initiated from different address spaces, use SRRCMIT and SRRBACK.