The Group User Routine

A member's group user routine receives control under a variety of circumstances. In this example, the group user routines have two basic functions:

To create and maintain a table with entries for each member of the group. The group user routine serializes the use of this resource by obtaining the local lock.
To initiate a takeover when the PRIMARY member fails.

To accomplish these functions, the group user routines are concerned about the following events:

Member state changes (GEPLTYPE=GEMSTATE)
Member status updating missing (GEPLMISR flag is on if the member's status user routine reported the status update missing; GEPLMISD flag is on if XCF assumed a status update missing for the member.)

When a member state change occurs (GEPLTYPE=GEMSTATE), the group user routine loops through its table and does one of the following:

Adds the member to the table if no entry for that member exists
Updates the member's entry.

When a status update missing event occurs, the group user routine's actions depend on the following:

The member whose status update is missing (PRIMARY, BACKUP, or NO-BACKUP)
The member whose group user routine is being scheduled (PRIMARY, BACKUP, or NO-BACKUP)
Whether the member's status user routine reported the status update missing condition, or whether XCF assumed that condition for the member.

Table 1 summarizes the possible combinations of the member whose group user routine is scheduled and the member whose status update is missing (either reported to or assumed by XCF):

Table 1. Group User Routine Scheduled vs. Status Update Missing
Combination Number	Whose group user routine is scheduled?	Whose status update is missing?
1	BACKUP	PRIMARY
2	BACKUP	NO-BACKUP
3	NO-BACKUP	PRIMARY
4	NO-BACKUP	BACKUP
5	PRIMARY	BACKUP
6	PRIMARY	NO-BACKUP

Note: Remember the following:

When a member misses its status update, its own status user routine runs.
When a member's status user reports the member's status update missing (or XCF assumes a missing status update for the member), the group user routines of the other active members of the group run.

The following explains the actions of the group user routine for each of the combinations specified above. For all combinations except combination 1, the group user routine takes the same action whether the member's status user routine reported the status update missing condition or XCF assumed that condition for the member.

Combination 1

When the BACKUP member's group user routine gets control because the PRIMARY member's status update is missing, the routine:

Posts a task (the CLEANUP task) that:
- Waits for both TASKECB1 (to be posted by the message user routine) and TASKECB2 (to be posted by the group user routine).
- Terminates the PRIMARY member by issuing IXCTERM. (The PRIMARY member's recovery routine then gets control and can disassociate the member from XCF through the IXCLEAVE macro.)
```
 IXCTERM   MEMTOKEN=MEM2TKN,TARGET=MEM1TKN,RETCODE=RETURN,  X
     RSNCODE=REASON,MF=S
 IXCLEAVE  MEMTOKEN=MEM1TKN,RETCODE=RETURN,                 X
     RSNCODE=REASON,MF=S
```
- Change the BACKUP member's user state value from BACKUP to PRIMARY through the IXCSETUS macro.
```
 IXCSETUS  MEMTOKEN=MEM2TKN,NEWUS=PRIMARY,TARGET=MEM2TKN,   X
     RETCODE=RETURN,RSNCODE=REASON,MF=S
```
Turns on the XPRIMBU switch in MDATASTR.

When XCF assumes a status update missing for the PRIMARY member, the primary member's status user routine might never have sent the DBMGR's work queue. The group user routine still posts the CLEANUP task to terminate the PRIMARY member and change the user state values. However, the CLEANUP task does not wait for TASKECB1 to be posted by the message user routine. Additionally, the group user routine issues IXCMSGOX to the NO-BACKUP member, with the message control information containing WORKREQ. This signals the NO-BACKUP member to send its work queue to the BACKUP member for processing.

Combination 2

When the BACKUP member's group user routine gets control because the NO-BACKUP member's status update is missing, the routine checks NO-BACKUP's member state in the table. If NO-BACKUP is still active, the routine takes no action, assuming that the member missed its status update for a valid reason. If NO-BACKUP is not-defined, the routine posts the CLEANUP task to delete the member from the table.

Combination 3

When the NO-BACKUP member's group user routine gets control because the PRIMARY member's status update is missing, the routine takes no action because the BACKUP member will do the work.

Combination 4

When the NO-BACKUP member's group user routine gets control because the BACKUP member's status update is missing, the routine takes no action because the PRIMARY member will do the work.

Combination 5

When the PRIMARY member's group user routine gets control because the BACKUP member's status update is missing, the routine checks BACKUP's member state in the table. If BACKUP is still active, the routine takes no action, assuming that the member missed its status update for a valid reason. If BACKUP is not-defined, the routine posts the CLEANUP task to delete the member from the table.

Combination 6

When the PRIMARY member's group user routine gets control because the NO-BACKUP member's status update is missing, the routine takes no action because the BACKUP member will do the work.