Resource managers for unprotected resources do not log data changes or provide actions for commit and backout. This information deals with the actions resource managers take to work with RRS to control protected resources.

While each resource manager that works with RRS to control protected resources will be different, all must consider a common set of decisions and actions, including the following:

1. Your resource manager must register (make itself known to the operating system) before it can work with exit managers, such as RRS, to protect resources. To register, the resource manager issues a call to the Register_Resource_Manager service. When registering, the resource manager can specify global data, which is passed to all of the resource manager's exit routines when they are invoked.

   More information appears in Using registration services, and you can find descriptions of each service in Callable registration services.

2. Decide whether or not to set the notification exit routine with registration services. This exit routine, though optional, is important because it keeps your resource manager informed of events related to registration. It is driven when an exit manager becomes available or unavailable, and it is also driven when your resource manager exit routines have become unset. For information on the exit routine, see Using registration services.
3. After registering, your resource manager must establish connections to each exit manager it needs. To connect to an exit manager, the resource manager issues one or more calls to the Set_Exit_Information service. Each call specifies one exit manager and identifies the exit routines that the specified exit manager is to invoke, or drive. Setting an exit routine means that the exit manager will drive the exit routine when the event occurs.

   The exit manager drives the exit routines in response to predefined events. For RRS, these predefined events are events that occur during resource recovery. For example, when an application commits the changes for a UR, RRS invokes the COMMIT exit routine for each affected resource manager. The exit routine sets a return code that determines how the exit manager continues to process the event.

   A resource manager must set its exit routines before an exit manager can invoke any of the routines.

   For information about each exit manager and the exit routines it can drive, see:

   • Using registration services
   • Using context services
   • Using resource recovery services
4. Decide whether or not your resource manager needs to express interest in a work context. A context represents a business unit of work: one or more units of recovery with the associated application programs, resource managers, and protected resources. The context should be the anchor for the resource manager's control structures related to the work request.

   When an application program requests access to a resource, the resource manager might express an interest in the context associated with the application program and its work request. A resource manager might need to express interest in a work context because a context can persist over multiple URs.

   A work context can be either a native context, which is associated with a single application task, or a privately managed context, which can be switched from one task to another. A privately managed context is usually used by a work manager, such as IMS™.

   More information appears in Using context services.

5. Decide how to use resource recovery services to implement the two-phase commit protocol in your resource manager, described in Using resource recovery services.
6. You need to plan the actions your resource manager will take if a failure occurs.
   The effect of a resource manager failure depends on the scope of the failure, which can be either:

   • Exit manager scope
   • System scope

   If a resource manager has registered, the state of the resource manager is registered. It is known to the system, and it can then set exits with one or more exit managers. For example, one resource manager might set exits with RRS while another might set exits with both RRS and context services. Once a resource manager sets exits with an exit manager, its state with that exit manager is set.

   Exit Manager Scope: A failure that has exit manager scope occurs when the failure causes the resource manager's exits to be unset with a specific exit manager. The exit manager changes the resource manager state from set to unset and drives the resource manager's NOTIFICATION exit routine to inform the resource manager of the failure.

   For example, assume that a resource manager has set its exits with RRS. During processing, RRS drives the resource manager's EXIT_FAILED exit routine, but the routine returns an unexpected return code. This unexpected return code causes RRS to unset the resource manager's exits and drive its NOTIFICATION exit routine. The resource manager state with the system is still registered, but its state with RRS is unset (though it continues to run and might remain set with another exit manager).

   System Scope: In contrast, a failure that has system scope changes the resource manager state from registered to unregistered, either because the resource manager task or address space has failed, or because the resource manager has itself requested the state change. As a result, the resource manager state with all interested exit managers changes from set to unset. Before it can again participate in resource recovery, the resource manager must restart.