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.