Delayed signal delivery

Asynchronous signals are generated from a process or task different from the task the signal is being delivered to. Delivery of asynchronous signals is not always possible and can have a delay. Signals that must be delayed are delivered later, when signals are permitted and the next z/OS UNIX service is invoked. The following describes some additional cases when signal delivery must be delayed:

During STORAGE obtains or releases that use a hardware linkage stack.
During execution of system services that are entered with PC or that use the hardware linkage stack (such as a BAKR instruction).
When applications use a BAKR instruction on entry to save registers in a hardware linkage stack and use a PR instruction to restore registers on exit. Therefore, asynchronous signals cannot be delivered after the BAKR instruction and before the PR instruction.
When a task that is set up for signals by a mvssigsetup service is followed by a system service call (for example, LINK) that creates another program request block (PRB).

z/OS UNIX System Services provides a signal deferral capability that allows an application to defer the receipt of signals until it is ready to accept them. You could use it, for instance, to shield an application from signal interruption during a time of critical processing. Once the section of critical code had finished, the application could receive any signals that had been deferred.

To use the signal deferral capability, the application sets the ThliDeferSignals bit on in the THLI data structure. When it is interested in receiving signals again, it sets this bit off. To see if any signals are pending, the application can check the OtcbSigPending or the ThliSigPending bit. If OtcbSigPending or ThliSigPending is set on, it can set ThliDeferSignals = OFF, and call BPX1GPI to drive signal delivery.

To access the THLI bit, traverse the data structures TCB, STCB, OTCB, and THLI. If the STCBOTCB (the field in the STCB that points to the OTCB) is 0, the process is not dubbed and the THLI has not been created. (However, since a process that has not been dubbed cannot receive signals, it is not necessary to set the THLI bit to defer their handling.) If there is an OTCB, the OTCBTHLI points to the THLI. Set the ThliDeferSignals bit accordingly.

For example:

If (stcbotcb ^= 0) then              /* Make sure the process is dubbed, the otcb pointer  */
                                     /* will not be zero.                                  */

   otcbthli->thlidefersignals = ON;  /* The otcbthli field points to the thli; set the thli*/
                                     /* to defer signals.                                  */

...start of important stuff                     
                                     /* Remember not to issue any syscalls during this     */
                                     /* segment of code. A syscall will force a delivery   */
                                     /* of any pending signal.                             */
...end of important stuff

otcbthli->thlidefersignals = off;    /* Reset the bit.                                     */
                                                                                                         
If otcbthli-thlisigpending = on      /* Check to see if any signals were made pending      */
                                     /* during the critical code interval. 
                
   then call bpx1gpi(...)            /* Make any syscall. It will have all pending signals */
                                     /* delivered.                                         */

This mechanism is not intended to be used by an application that is requesting z/OS UNIX system services. If a syscall is requested, any pending signals are delivered. The THLI bit is intended to shield the application from unwanted interruptions only when no syscalls are being performed.