All-Resident C Programs

Development Considerations

The following items should be considered when developing all-resident programs.

In a program that does not allow the library to dynamically load support routines, if a support routine is needed but has not been linked into the program load module, the library issues warning message LSCX119:

"Transient module name  could not be located."

Warning Messages

In a program that does not allow the library to dynamically load support routines, if a warning message is needed but has not been linked into the program load module, the library issues the generic message LSCX047:

"Unable to load runtime message texts, errno = EFORBID".

The errno value EFORBID indicates that the library cannot issue the correct message because ALLOW_TRANSIENT was not defined.

If the macro names NO_WARNING (see Macro Names Used with <resident.h> for Exclusion) and ALLOW_TRANSIENT are defined in the source file containing <resident.h> , the library diagnostic message texts are not linked with the program but are loaded by the library, if needed. This combination may be helpful during program development.

Subordinate Load Modules

As mentioned above, it is possible for an all-resident program to dynamically load subordinate load modules even though the library is prohibited from doing so itself. The subordinate load modules use the support routines that have been linked into the primary load module. The reverse is not true, however. The primary load module cannot use support routines that are linked in a subordinate load module, even if the load module has been loaded into storage.

CAUTION:: Link support routines with the primary load module. In an application that uses subordinate load modules, always link the support routines with the primary load module. The subordinate load modules should be linked in the normal manner.

If a function that usually causes the appropriate support routines to be included automatically (as indicated in Macro Names Used with <resident.h> for Inclusion) is called only from a subordinate load module, then those routines are not linked with the load module. The primary load module must be linked with an object deck that is generated from a source file containing <resident.h> and that has the required symbol defined.

For example, suppose a program contains two load modules, MAINPROG and its subordinate load module, IOFUNC. MAINPROG contains no I/O functions, but IOFUNC has a call to open . Because IOFUNC is linked normally, the UNIX style I/O support routines are not linked in this load module. Because MAINPROG has no calls to open , UNIX style I/O support routines are not linked with MAINPROG either. To include the UNIX style I/O support routines, define RES_UNIXIO in the source file containing <resident.h> and include the generated object code when MAINPROG is linked.

If the subordinate load modules do not require preprocessing by COOL due to reentrancy or extended names considerations, COOL is not required as it is for the primary load module. Under any extended architecture system, if the primary load module is linked with AMODE=31, the subordinate load modules can be linked RMODE=ANY, that is, they can reside above the 16-megabtye line.

UNIX System Services

The use of the all-resident library is recommended for setuid or setgid shell programs. For security reasons, setuid and setgid programs ignore the ddn_CTRANS environment variable when executed. If these programs are not linked as all-resident, the SAS/C Transient Library must be in the system link list or accessible via the STEPLIB environment variable. Note that if the SAS/C Library is specified by STEPLIB, it must be present on the site-maintained list of permitted STEPLIBs for setuid / setgid programs.

Chapter Contents
Previous
Next
Top of Page