Identifying the SRB to be purged

The program must tell PURGEDQ which SRBs are to be purged. Input to PURGEDQ is as follows:

The address of the RMTR (RMTR parameter, required).
The address space identifier (corresponding to SRBASCB) of the address space in which the SRB is scheduled to be dispatched (ASID parameter, optional).
The address space and the TCB associated with the SRB that the system is to purge (ASIDTCB parameter, optional).

The RMTR parameter specifies the address of the RMTR. The RMTR cleans up an SRB that has been scheduled, but not yet dispatched. The system purges only those SRBs whose SRBRMTR field contains the address of the RMTR, as specified on the PURGEDQ macro. When comparing the RMTR parameter to the SRBRMTR field, SRBRMTLL is treated as zero.

The ASID parameter specifies the address of a halfword containing an address space identifier. PURGEDQ searches for SRBs scheduled to be dispatched into the address space specified by this parameter. If you specify the primary address space by coding its address or by omitting the ASID parameter, you need to know what PURGEDQ does with the three kinds of SRBs: active, nondispatched, or suspended:

It waits for active SRB routines to complete processing.
It dequeues all nondispatched SRBs. After all of the SRBs have been dequeued or completed, the RMTR specified in the SRB is given control to perform the required cleanup for each dequeued SRB.
It does not pass control to an RMTR of a suspended SRB. Instead, the system abnormally terminates those SRB routines and waits for the termination to complete.

If you specify an address space other than the primary address space, PURGEDQ will try to purge SRBs that have not been dispatched. PURGEDQ does not guarantee that all SRBs matching the purge parameters will be purged. For example, PURGEDQ will not purge suspended SRBs, nor will PURGEDQ wait for active or suspended SRB routines to complete processing.

When you specify an address space other than the primary, you should use an RMTR to inform the issuer of PURGEDQ whether a particular SRB has been purged; otherwise, problems might result. For example, consider the following sequence of events:

Program-A running in ASID-Current schedules SRB-A to run in ASID-Target.
Program-A running in ASID-Current issues the PURGEDQ macro with the ASID parameter to purge SRBs in ASID-Target.
Program-A running in ASID-Current issues a FREEMAIN for SRB-A.

The preceding sequence of events could result in SRB-A's storage being freed while it is still waiting to be dispatched, because the PURGEDQ function, when the address space specified is other than the primary address space, does not guarantee that all SRBs in ASID-target will be found and purged. This processing might cause spin loops, ABENDs in lock manager, and other problems. Before issuing a FREEMAIN for an SRB, PURGEDQ users who specify an address space other than primary must construct their own communication mechanism to be sure that an SRB has indeed been purged. One way to be sure than an SRB has been purged is to use an RMTR. When the PURGEDQ successfully finds and purges an SRB, the RMTR associated with that SRB is called. The RMTR can free the SRB, or the RMTR can use the SRB parameter area to indicate to another program that the SRB can be safely freed. This prevents SRBs that are missed by PURGEDQ from being freed while they are still waiting to be dispatched.

The ASIDTCB parameter specifies the address of a doubleword that describes the TCB for which SRBs are to be purged. Through this parameter, you can purge the SRBs associated with a specific task. If you omit the parameter, the system purges SRBs associated with the current task in the primary address space.