Sample RRSAF scenarios

One or more tasks can use Resource Recovery Services attachment facility (RRSAF) to connect to Db2. This connection can be made either implicitly or explicitly. For explicit connections, a task calls one or more of the RRSAF connection functions.

A single task

The following example pseudocode illustrates a single task running in an address space that explicitly connects to Db2 through RRSAF. z/OS® RRS controls commit processing when the task terminates normally.

IDENTIFY
SIGNON
CREATE THREAD
SQL or IFI
⋮
TERMINATE IDENTIFY

Multiple tasks

In the following scenario, multiple tasks in an address space explicitly connect to Db2 through RRSAF. Task 1 executes no SQL statements and makes no IFI calls. Its purpose is to monitor Db2 termination and startup ECBs and to check the Db2 release level.

TASK 1             TASK 2          TASK 3          TASK n
 
IDENTIFY           IDENTIFY        IDENTIFY        IDENTIFY
                   SIGNON          SIGNON          SIGNON
                   CREATE THREAD   CREATE THREAD   CREATE THREAD
                     SQL             SQL             SQL
                     ...             ...             ...
                     SRRCMIT         SRRCMIT         SRRCMIT
                     SQL             SQL             SQL
                     ...             ...             ...
                     SRRCMIT         SRRCMIT         SRRCMIT
                     ...             ...             ...
TERMINATE IDENTIFY

Reusing a Db2 thread

The following example pseudocode shows a Db2 thread that is reused by another user at a point of consistency. When the application calls the SIGNON function for user B, Db2 reuses the plan that is allocated by the CREATE THREAD function for user A.

IDENTIFY
SIGNON user A
CREATE THREAD
  SQL
  ...
  SRRCMIT
SIGNON user B
  SQL
  ...
  SRRCMIT

Switching Db2 threads between tasks

The following scenario shows how you can switch the threads for four users (A, B, C, and D) among two tasks (1 and 2).

Task 1                              Task 2
 
CTXBEGC (create context a)          CTXBEGC (create context b)
  CTXSWCH(a,0)                        CTXSWCH(b,0)
  IDENTIFY                            IDENTIFY
  SIGNON user A                       SIGNON user B
  CREATE THREAD (Plan A)              CREATE THREAD (plan B)
    SQL                                 SQL
    ...                                 ...
CTXSWCH(0,a)                        CTXSWCH(0,b)
 
 
CTXBEGC (create context c)          CTXBEGC (create context d)
  CTXSWCH(c,0)                        CTXSWCH(d,0)
  IDENTIFY                            IDENTIFY
  SIGNON user C                       SIGNON user D
  CREATE THREAD (plan C)              CREATE THREAD (plan D)
    SQL                                 SQL
    ...                                 ...
CTXSWCH(b,c)                        CTXSWCH(0,d)
    SQL (plan B)                        ...
    ...                             CTXSWCH(a,0)
                                        SQL (plan A)

The applications perform the following steps:

Task 1 creates context a, switches contexts so that context a is active for task 1, and calls the IDENTIFY function to initialize a connection to a subsystem. A task must always call the IDENTIFY function before a context switch can occur. After the IDENTIFY operation is complete, task 1 allocates a thread for user A, and performs SQL operations.
At the same time, task 2 creates context b, switches contexts so that context b is active for task 2, calls the IDENTIFY function to initialize a connection to the subsystem, allocates a thread for user B, and performs SQL operations.

When the SQL operations complete, both tasks perform RRS context switch operations. Those operations disconnect each Db2 thread from the task under which it was running.
Task 1 then creates context c, calls the IDENTIFY function to initialize a connection to the subsystem, switches contexts so that context c is active for task 1, allocates a thread for user C, and performs SQL operations for user C.
Task 2 does the same operations for user D.
When the SQL operations for user C complete, task 1 performs a context switch operation to perform the following actions:
- Switch the thread for user C away from task 1.
- Switch the thread for user B to task 1.
For a context switch operation to associate a task with a Db2 thread, the Db2 thread must have previously performed an IDENTIFY operation. Therefore, before the thread for user B can be associated with task 1, task 1 must have performed an IDENTIFY operation.
Task 2 performs two context switch operations to perform the following actions:
- Disassociate the thread for user D from task 2.
- Associate the thread for user A with task 2.