Characteristics and restrictions of SRB routines
SRB routines run enabled and can be interrupted by an asynchronous interruption. They can be scheduled as preemptable SRBs, allowing higher priority work access to the processor. SRB routines might lose control because of synchronous events that cause suspension of the program in control, such as page faults and unconditional requests for suspend-type locks. In this case, full status of the process is saved and other work is dispatched; the SRB routine is redispatched when the situation is resolved.
An enabled SRB routine can take page faults.
- If the routine does not hold any locks when the page fault occurs, the system suspends the SRB routine, which allows the system to dispatch other work on the active processor. The system redispatches the SRB routine after it resolves the page fault.
- If the routine holds a suspend type lock (such as a local, CML, or CMS lock) when a page fault occurs, the suspended SRB routine continues to hold those locks. The system suspends other work units that require the lock held by the suspended SRB routine until the system redispatches the SRB and the SRB routine explicitly releases those locks.
You can use the SUSPEND macro to suspend the execution of an SRB routine until an event occurs. The RESUME macro then causes the SRB routine to resume execution. Serializing SRB processing describes how you use the SUSPEND and RESUME macros.
If an SRB routine requires an Integrated Cryptographic Feature
(ICRF) to encrypt or decrypt data, use the following guidelines:
- Use the FEATURE=CRYPTO parameter if the routine's only purpose is to encrypt or decrypt data.
- Do not use the FEATURE=CRYPTO parameter if the routine has many purposes. In this case, let the system schedule the routine to run on the appropriate processors as the routine's requirements change.