User-Added Signals

Summary of Routines for Adding Signals

To add a user signal to the library, you must write at least two routines. (Depending on your needs, more routines may be necessary.) Routines for Adding Signals lists the routines you may need to write to define and control a new signal. The table also indicates the preferred language for each routine. Most routines can be written in either C or assembler language.

Assembler routines called by the SAS/C Library rather than by the operating system can use the CENTRY and CEXIT macros for function linkage. (Refer to Chapter 11, "Communication with Assembler Programs," in SAS/C Compiler and Library User's Guide, for information on the CENTRY and CEXIT macros.)

Assembler routines that call C functions must use the CENTRY and CEXIT macros to run successfully when either the optimized or minimal form of function linkage is in use. Refer to Chapter 9, "Run-Time Argument Processing," of the SAS/C Compiler and Library User's Guide for more information on the =optimize and =minimal options.

Note: A routine that calls operating system macros is usually written in assembler language. [cautionend]

Routines for Adding Signals
Routine Required?/Frequency of use? Recommended Language* Description

initialization routine yes/always assembler calls sigdef to define the new signal and identify which of the following routines are coded.

signal generator yes/always assembler intercepts the hardware or software interrupt and informs the library that the signal occurred. The routine is usually an operating system exit.

default handler no/common C establishes default actions that occur when no handler is defined for the new signal

interrupt control no/seldom assembler communicates to the operating system when a signal is ignored, blocked, or handled in the default manner.

final routine no/very common assembler cancels signal handling at the end of the program. The routine is invoked after all files are closed.

executive routine no/seldom C supervises linkage to handlers. For example, the routine can prevent use of longjmp or normal returns.

jump intercept routine no/rare assembler notifies the operating system that the interrupt has been handled; that is, it clears the interrupt.

***Routines for Adding Signals***
Routine	Required?/Frequency of use?	Recommended Language*	Description
initialization routine	yes/always	assembler	calls `sigdef` to define the new signal and identify which of the following routines are coded.
signal generator	yes/always	assembler	intercepts the hardware or software interrupt and informs the library that the signal occurred. The routine is usually an operating system exit.
default handler	no/common	C	establishes default actions that occur when no handler is defined for the new signal
interrupt control	no/seldom	assembler	communicates to the operating system when a signal is ignored, blocked, or handled in the default manner.
final routine	no/very common	assembler	cancels signal handling at the end of the program. The routine is invoked after all files are closed.
executive routine	no/seldom	C	supervises linkage to handlers. For example, the routine can prevent use of `longjmp` or normal returns.
jump intercept routine	no/rare	assembler	notifies the operating system that the interrupt has been handled; that is, it clears the interrupt.

Note that all of the routines in Routines for Adding Signals except the jump intercept routine can be coded in either C or assembler. This table simply indicates which language is preferred.

Initialization Routine and sigdef Function

To add a signal to the library, you must code an initialization routine. This routine is usually coded in assembler language. The initialization routine calls the sigdef function to define the signal. The initialization routine also calls an operating system macro to establish the address of the operating system exit that should be invoked when the signal occurs. For example, to define a CMS I/O interrupt signal called SIGIOI , the initialization routine may issue calls similar to the ones here. The call to sigdef in assembler might look like the following:

         LA   R1,DEFPARMS
         L    R15,=V(SIGDEF)
         BALR R14,R15       sigdef(SIGASY1,0,0,0,0,"IOI");

DEFPARMS DC   A(SIGASY1)    symbol definition obtained by
*                           "COPY SIGNALS"
         DC   4A(0)
         DC   A(SIGNAME)

SIGNAME  DC   C'IOI',X'00'

The call to sigdef renames SIGASY1 to SIGIOI but does not define any special routines for processing the signal (indicated by the 0s for the second DC in the DEFPARMS area).

A sample call to the CMS HNDINT macro to handle the interrupt might look like the following:

HNDINT SET,(TAP1,EXIT,unit,ASAP)

The call to HNDINT identifies the I/O unit number that causes the interrupt ( unit ) and the address of the operating system exit routine ( EXIT ) that you code to generate the signal for the library.

You can also use the initialization routine to save the C Run-Time Anchor Block (CRAB) address so that it can be accessed by the signal generator routine. (One way to do this is to request that the operating system provide the address as a user parameter to an exit routine.) Saving the address of the CRAB is frequently necessary because register 12 is dedicated to the CRAB address only during C program execution; it is usually not preserved by the operating system when an exit routine is called.

Note: It is possible to raise, handle, or block a user signal before it has been defined by a call to sigdef . When sigdef is called, it has no effect on the signal's status; that is, the signal remains blocked or unblocked, and any user handler remains in effect. However, if the call to sigdef defines a default handler, this default replaces the previous default handler. [cautionend]

Chapter Contents
Previous
Next
Top of Page