The SUSPEND macro with the RB parameter provides an efficient way for an RB to wait for an event to complete. It is similar to the WAIT macro; the SUSPEND-RESUME sequence can be compared to the WAIT-POST sequence.
The SUSPEND macro does not have an immediate effect on the issuer as the WAIT macro does. Instead, the effect is delayed, depending on the type of suspension the macro user requests. If the previous RB is suspended, the effect takes place when the current RB returns to the system. If the current RB is suspended, the suspended state occurs when the RB passes control to the system.
RBs that issue the SUSPEND macro with the RB=CURRENT option should hold the suspended state time to a minimum. As soon as possible after SUSPEND completion, the RB that issues a SUSPEND RB=CURRENT should issue a CALLDISP macro with the BRANCH=YES option. Using the SUSPEND macro this way minimizes potential performance problems because the RB in this case must either be disabled or must hold the LOCAL lock or a CML lock. Minimizing suspension time also minimizes other potential problems the program might experience by limiting the time in which the RB is unable to cause any synchronous interrupts (such as SVCs and page faults) or provide interfaces to the WAIT, POST, or EVENTS macros.
RBs that issue SUSPEND RB=PREVIOUS, on the other hand, do not require the same synchronization because they are operating on behalf of another RB. The suspension of the previous RB does not require disabled execution or the holding of the LOCAL lock or a CML lock.
The following scenarios show typical SUSPEND macro sequences: