Chapter Contents

Previous

Next
All-Resident C Programs

The <resident.h> Header File

Given the large number of available library functions and the wide variety of functionality they provide, it is probable that few C programs make use of all the library support routines. Even though it is typically very difficult to determine the minimum number of required support routines, it is usually possible to specify some subset of the entire library. (For example, programs that do not use coprocesses do not need the coprocess support routines.) Therefore, an important part of the linking process must be some way for the programmer to specify the set of support routines required by the program. This tailoring ability is available via the <resident.h> header file.

Including the <resident.h> header file causes the compiler to generate external symbols for various groups of support routines. Each external symbol causes a corresponding group of support routines to be included when the program is linked. Which external symbols are generated and, therefore, which support routines are linked into the program, is controlled by defining specific macro names prior to the inclusion of <resident.h> in the C source file.

For example, defining the macro name RES_VSAM causes <resident.h> to generate an external symbol for the VSAM I/O support routines when the file including it is compiled. When the program is linked (including the object code from the <resident.h> file), the linker includes these routines as part of the program load module.

By confining the all-resident tailoring process to a single source file, it is possible to create both an all-resident version of the program and a transient version. The all-resident version is created by including the <resident.h> object code and linking with the all-resident library. For the transient version, neither of these steps are necessary.

Note:    An all-resident application should include <resident.h> in one and only one source module. Errors may occur if <resident.h> is included in several different modules of the same program.  [cautionend]


Identifying the Target Operating System

The <resident.h> header file generates external symbols that are specific to CMS, OS/390, or CICS. You can define the macro name SYS_CMS , SYS_OSVS , or SYS_CICS to target a specific system. If you do not define one of these macro names, <resident.h> tests the macro names OSVS and CMS , one of which is automatically generated by the compiler for each of those two operating systems to determine whether or not to generate symbols for OS/390 or CMS. If you are developing an all-resident application for CICS, you must define the macro name SYS_CICS before including the <resident.h> header file in your program.


Selecting the Routines to Be Included

Macro Names Used with <resident.h> for Inclusion shows the macro names that can be defined to cause inclusion of library support routines and describes the associated support routines. By default, these routines are not included in the program load module. The Operating System column indicates whether the support routines are used under OS/390, CMS, CICS, or all three. A number appearing in the Notes column indicates that the support routines are included automatically if certain functions are used in the program. An explanation of the numbers used in the Notes column follows Macro Names Used with <resident.h> for Inclusion. (Refer to Subordinate Load Modules for more information on when support routines are included automatically.)

Macro Names Used with <resident.h> for Inclusion
Macro Names Operating System Notes Includes Support for
RES_SIGNAL all 1 signal-handling functions
RES_COPROC all 2 coprocessing functions
RES_IOUTIL OS/390, CMS 3 remove, rename, access functions; cmsstat function (CMS only)
RES_UNIXIO OS/390, CMS 4 UNIX style I/O
RES_UNIXSTDF OS/390, CMS
UNIX style I/O to stdin, stdout, and stderr
RES_TMPFILE OS/390, CMS 5 VSAM I/O
RES_VSAM OS/390, CMS 6 VSAM I/O
RES_DSNAME OS/390
dsn and tso style filenames
RES_DIVIO OS/390
DIV I/O
RES_TSOENVVAR OS/390
TSO environment variable support
RES_VSAM_STDIO OS/390, CMS
VSAM I/O using text or binary access
RES_KEYED_IO OS/390, CMS
VSAM I/O using keyed access
RES_TCPIP all 7 socket library functions
RES_HFS_STDIO OS/390 8 UNIX System Services (USS) HFS I/O (plus remove, rename, or access )
RES_FDOPEN OS/390 9 the fdopen function
RES_OE_SYSTEM OS/390
system used to envoke a shell command
RES_SUBCOM OS/390 10 TSO or USS SUBCOM
RES_FILEDEF CMS
ddn style filenames
RES_OSSIM CMS
OS/390-simulated I/O
RES_LIBIO CMS
MACLIB and TXTLIB member I/O
RES_UNITREC CMS
unit record I/O (virtual reader, printer, and punch)
RES_SHARED_FILE CMS
CMS Shared File System I/O
RES_SPLFILE CMS
CICS spool file I/O
RES_CICSVSE CICS
VSE error handling
RES_FSSLSTD OS/390, CMS
FSSL using the direct 3270 interface
RES_FSSLISPF OS/390, CMS
FSSL using the ISPF interface

Note:    The support routines are included automatically if

  [cautionend]


Selecting the Routines to Be Excluded

In addition to specifying which support routines should be included, <resident.h> respects a number of macro names that indicate that certain support routines should be omitted. By default, these routines are included in the program load module, except for the subcom and socket routines. For an all-resident program that has specified _nio to be not equal to zero, the macro name NO_IO must be defined prior to including the <resident.h> header file in the program. Macro Names Used with <resident.h> for Exclusion shows these names and the associated support routines.

Macro Names Used with <resident.h> for Exclusion
Macro Names Operating System Excludes Support for
NO_IO all C I/O functions
NO_WARNING all warning messages
NO_ABEND all ABEND handling
MVS370_ONLY OS/390 MVS/XA ABEND handling
MVSXA_ONLY OS/390 MVS/370 ABEND handling
MODE370_ONLY CMS XA-mode ABEND handling
MODEXA_ONLY CMS 370-mode ABEND handling
NO_OE_SOCKETS OS/390 nonintegrated sockets
RES_SUBCOMM_TSO OS/390 USS SUBCOM support
RES_SUBCOM_OE OS/390 TSO SUBCOM support


Using Dynamic Loading

<resident.h> allows the programmer to decide whether dynamic loading will be available to the program. There are three possible choices as follows:


Using <resident.h>

Sample Use of <resident.h> is an example of using <resident.h> . In this particular use, signal-handling and UNIX style I/O support routines are linked with the program. Note that the header file and macro name definitions can be added to another program source file or confined to a source file by themselves.


Sample Use of <resident.h>
#define RES_SIGNAL /* Include signal handling support. */ #define RES_IOUTIL /* Include access, rename, remove support. */ #define RES_UNIXIO /* Include UNIX style I/O support. */ #define RES_TMPFILE /* Include temporary file I/O support. */ #if defined CMS #define RES_LIBIO /* If CMS, include support routines for */ #endif /* I/O to MACLIB/TXTLIB members. */ #if defined OSVS #define MVSXA_ONLY /* If OS, exclude MVS/370 ABEND handling. */ #endif #define ALLOW_LOADM /* Allow this program to load other load */ /* modules, but no library modules can be */ /* loaded. */ #include <resident.h>

Note:    The dollars compiler option must be used when compiling a C++ source file that contains <resident.h> .  [cautionend]


Chapter Contents

Previous

Next

Top of Page

Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved.