Using the SAS/C® Cross-Platform Compiler and C++ Development System

Introduction

The SAS/C C and C++ cross-platform compilers are invoked in a manner similar to other compilers commonly used on UNIX platforms. The syntax for the commands used to invoke the compilers consists of the filename of the driver, followed by a list of options, and then the filenames of the source code. This method of invoking the cross-platform compilers enables you to specify options using a syntax that is very comfortable to UNIX users, providing easy integration with UNIX build facilities. This method of compiling C and C++ programs is described in the section "Compiling C Programs" on page 10 and "Compiling C++ Programs" on page 11.

CICS Command Preprocessor

The SAS/C CICS Command Preprocessor enables you to develop application programs to run under CICS. This application-programming interface enables you to request CICS services by placing CICS commands anywhere within your C or C++ source code. The SAS/C CICS preprocessor translates these commands into appropriate function calls for communication with CICS.

Once the preprocessor has translated the CICS commands within your C or C++ program, you then compile and link-edit your program as you would any SAS/C program. When you run your SAS/C program, the function calls inserted by the preprocessor invoke the services requested by calling the appropriate CICS control program using the CICS EXEC Interface program.

Compiling C Programs

This section explains how to invoke the SAS/C Cross-Platform Compiler with the sascc370 command.

Using sascc370

The sascc370 compiler driver controls the compilation of your C object code. Invoke the compiler driver with the following command:

 sascc370 [options] [filename1 [filename2...]]
If specified, the options argument can be one or more of the compiler options described in Chapter 3, "Compiling C and C++ Programs" on page 23, or the cool options described in Chapter 6, "Pre-Linking C and C++ Programs" on page 53. You can also view a partial listing of these options online by issuing the sascc370 command without any arguments. Some of the compiler options are particular to the sascc370 driver, and others will alter the compilation in some manner. As mentioned in Chapter 1, "Overview of the SAS/C® Cross-Platform Compiler and C++ Development System" on page 1, the compiler driver processes these options during the phases of compilation, passing them to the appropriate executable file as necessary.

If you do not specify any compiler options, the cross-platform compiler will generate pre-linked, non-reentrant object code by default. Pre-linking is accomplished by cool, which is normally invoked by the compiler driver.

It should also be noted that the cross-platform compiler generates object code targeted for an MVS environment by default. If you are compiling programs that you intend to run under CMS, you should specify either the -Tcms370 or the -Tpcms370 compiler option. See Chapter 3 on page 23 for more information about these options.

The filename arguments specify a list of input files that are to be compiled or pre-linked. Files with a .c, .C, or .cxx extension will be compiled (filenames that end with .C or .cxx are assumed to be C++ input files); files with a .o extension will be pre-linked. See "Files" on page 15 for more information about the files used by the cross-platform compiler.

Note that the -Kextname option, which enables the use of extended names, is on automatically when you use sascc370. To disable the use of extended names, you must specify -Knoextname.

Examples

The following examples are command line invocations of the cross-platform compiler using sascc370:

 sascc370 alpha.c
Compiles the file alpha.c, generating the pre-linked output file a.out. Notice that a.out is the default filename for pre-linked output.

Normally, the pre-linked output is copied to the mainframe for final linking. However, you can also copy the object files to the mainframe and use COOL to generate a load module. See "Linking C and C++ Programs" on page 13 for additional information.

 sascc370 -c alpha.c
Compiles the file alpha.c, generating the object file alpha.o. The -c compiler option specifies that the object should not be pre-linked.

 sascc370 -o beta alpha.c
Compiles the file alpha.c, generating the pre-linked output file beta. The -o option is used to specify the name of the pre-linked output file. Notice that beta is generated instead of the default a.out.

 sascc370 -o beta alpha.c gamma.cxx
Compiles the files alpha.c , as a C source file, and gamma.cxx, as a C++ source file, generating the pre-linked output file beta and the object file alpha.o and gamma.o. The -o option is used to specify the name of the pre-linked output file. Notice that beta is generated instead of the default a.out.

 sascc370 -Kextname alpha.c
Compiles alpha.c, which may contain external C identifiers of lengths greater than 8 characters. The -Kextname compiler option specifies extended names.

 sascc370 -o gamma alpha.c beta.c
Compiles the files alpha.c and beta.c. The object files are then pre-linked by cool, combining the output into the gamma file. The gamma file would then need to be copied to the mainframe for final linking.

 sascc370 alpha.o beta.c
Compiles beta.c, which is then pre-linked with alpha.o and the C libraries to produce the pre-linked output file a.out.

 sascc370 -Krent -Tcms370 alpha.c beta.c
Compiles the files alpha.c and beta.c, generating reentrant code targeted for a CMS system running under VM/ESA or VM/XA. The -Krent option specifies that reentrant modification of external variables is allowed, and the -Tcms370 option specifies that the cross-platform compiler preprocessor should use predefined CMS symbols and link with the CMS libraries.

 sascc370 -Tpcms370 -Tallres notrans.c
Compiles notrans.c, using the all-resident library to generate an all-resident program targeted for a CMS system running in System/370 mode (pre-bimodal).

 sascc370 -Tspe sysprog.c 
Compiles sysprog.c, using the SPE library to generate a program targeted for the C Systems Programming Environment under MVS

Compiling C++ Programs

This section explains how to invoke the SAS/C Cross-Platform C++ Compiler directly with the sasCC370 command.

Using sasCC370

The sasCC370 compiler driver controls the compilation of your C++ object code. Invoke the compiler driver with the following command:

 sasCC370 [options] [filename1 [filename2...]]

If specified, the options argument can be one or more of the compiler options described in Chapter 3, "Compiling C and C++ Programs" on page 23, or the cool options described in Chapter 6, "Pre-Linking C and C++ Programs" on page 53. (You can also view a partial listing of these options online by issuing the sasCC370 command without any arguments.) Some of the compiler options are particular to the sasCC370 driver, and others will alter the compilation in some manner. As mentioned in Chapter 1, "Overview of the SAS/C® Cross-Platform Compiler and C++ Development System" on page 1, the compiler driver processes these options during the phases of compilation, passing them to the appropriate executable file as necessary.

If you do not specify any compiler options, the C++ development system will generate pre-linked, non-reentrant object code by default. Pre-linking is accomplished by cool, which is normally invoked by the compiler driver.

Note that the C++ development system generates object code targeted for an MVS environment by default. If you are compiling programs that you intend to run under CMS, you should specify either the -Tcms370 or the -Tpcms370 compiler option. See Chapter 3 on page 23 for more information about these options.

The filename arguments specify a list of input files that are to be compiled or pre-linked. Files with a .cxx, .C, or .c extension will be considered to be C++ input and be compiled. Files with a .o extension will be pre-linked. See "Files" on page 15 for more information about the files used by the cross-platform compiler.

It should also be noted that the -Kextname option, which enables the use of extended names, is on automatically when you use sasCC370; extended names processing cannot be disabled for C++ compilations.

The sasCC370 command is functionally equivalent to the sascc370 command with the -cxx option.

Examples

The following examples are command line invocations of the cross-platform compiler using sasCC370:

 sasCC370 alpha.cxx
Translates and compiles the file alpha.cxx, generating the pre-linked output file a.out. Notice that a.out is the default filename for pre-linked output.

Normally, the pre-linked output is copied to the mainframe for final linking. However, you can also copy the object files to the mainframe and use COOL to generate a load module. See "Linking C and C++ Programs" on page 13 for more information about pre-linking and linking.

 sasCC370 -c alpha.cxx
Translates and compiles the file alpha.cxx. The -c compiler option specifies that the object should not be pre-linked; therefore, the output file a.out is not generated.

 sasCC370 -o beta alpha.cxx
Translates and compiles the file alpha.cxx, generating the pre-linked output file beta. The -o option is used to specify the name of the pre-linked output file. Notice that beta is generated instead of the default a.out.

 sasCC370 -o gamma alpha.cxx beta.cxx
Translates and compiles the files alpha.cxx and beta.cxx. The object files are then pre-linked by cool, combining the output into the gamma file. The gamma file would then need to be copied to the mainframe for final linking.

 sasCC370 alpha.o beta.cxx
Translates and compiles beta.cxx, which is then pre-linked with alpha.o and the C++ and C libraries to produce the pre-linked output file a.out.

 sasCC370 -Krent -Tcms370 alpha.cxx beta.cxx
Translates and compiles the files alpha.cxx and beta.cxx, generating reentrant code targeted for a CMS system running under VM/ESA or VM/XA. The -Krent option specifies that reentrant modification of external variables is allowed, and the -Tcms370 option specifies that the cross-platform compiler preprocessor should use predefined CMS symbols and link with the CMS libraries.

Linking C and C++ Programs

Linking in the cross-platform environment usually involves pre-linking on the host system and then copying the pre-linked file to the target system, either MVS or CMS, where the final linking occurs. Pre-linking is performed by cool, which is normally called when you compile your source code. Final linking of the pre-linked output on the mainframe can be accomplished with the IBM linkage editor or CMS LOAD and GENMOD commands.

Although pre-linking is performed by default when you call the cross-platform compiler, you can suppress pre-linking by specifying the -c compiler option. Note, however, that pre-linking is required, either on the UNIX workstation or on the mainframe, if any of the following conditions are true:

  1. The variable is external and the compiler option -Krent or -Krentext is used.
  2. The variable is static and the compiler option -Krent is used.
  3. The variable is external and the name begins with an underscore
  4. The variable is declared _ _rent.
If you do not call the pre-linker during compilation, you can perform the pre-linking in one of the following ways:

This section discusses each of these methods of pre-linking.

Using cool

The pre-linker, cool, is an executable file that can be called directly. The following is the syntax for invoking cool:

 cool [options] [filename1 [filename2 ...]]
The options argument specifies any of the pre-linker options described in Chapter 6 on page 53. You must use the -o option to specify an output file when you invoke cool. If you enter the cool command without specifying the -o option, an error message is displayed along with a partial listing of the options accepted by cool.

The filename arguments specify a list of input files that are to be pre-linked. You must specify the complete name of the file; cool does not assume a .o extension.

The SAS/C C library objects are located in the ar370 archive /libdir/libc.a. The libdir depends on where the product was installed and which target you are compiling for. The SAS/C C++ objects are located in the ar370 archive /libdir/libcxx.a. In order to resolve references to SAS/C C and C++ library functions, these ar370 archives must be included in the cool command. If you are pre-linking a C++ program, you must specify /libdir/libcxx.a before specifying /libdir/libc.a.

Examples

The following examples are command line invocations of cool:

 cool -o prog alpha.o beta.o /libdir/libc.a
Pre-link the object files alpha.o and beta.o to produce the pre-linked output file prog.

Notice that libc.a, must be included in order to resolve references to SAS/C C library functions. The directory specification, libdir, for this library is target and site-specific. If you are not sure where it is located at your site, compile a program with the -v (verbose) option to see the default command line used by the sascc370 or sasCC370 compiler driver to invoke cool.

 cool -o prog myojb.o /libdir/libcxx.a /libdir/libc.a
In this example, a C++ object file, myojb.o, is being pre-linked, generating the pre-linked output file prog.

Note: If you are using cool to pre-link a C++ program, you must specify /libdir/libcxx.a before specifying /libdir/libc.a. The SAS/C C++ library functions must be resolved before SAS/C C library functions. The directory specification, libdir, for this library is site-specific. If you are not sure where it is located at your site, compile a program with the -v (verbose) option to see the default command line used by the sascc370 or sasCC370 compiler driver to invoke cool.

 cool -o prog interface.o io_handler.o /libdir/libares.a
In this example, the all-resident library, libares.a, is specified. Specialized applications, such as all-resident or SPE applications, must be linked with special library routines. See "Library Files" on page 15 and the SAS/C Compiler and Library User's Guide, Fourth Edition for more information.

 cool -o prog -w binary_tree.o /libdir/libc.a
Pre-link the object file binary_tree.o, generating the pre-linked output file prog. The -w option specifies that warning messages should be suppressed

Using COOL on the Mainframe

The other method of pre-linking your object files is to copy them to the mainframe where they can be linked with the COOL object code utility. The SAS/C Compiler and Library User's Guide, Fourth Edition describes the COOL CLIST and the COOL EXEC, which can be used to invoke COOL on the mainframe.

Note that you can use the UNIX cat command to combine multiple object files into a single file on the workstation, copy that file to the mainframe, and then run COOL on the mainframe on the copied file. This is often easier than copying each file individually.

Also note that if you use extended names or the -Aprem option, you should not pre-link both on the workstation and on the mainframe.

Files

As described in "Executable Files" on page 4, the cross-platform compiler actually consists of executable files. The sascc370 and sasCC370 compiler drivers are responsible for processing the options you specify on the command line and controlling the compilation of C and C++ programs. The other executable files are the translator, parser, global optimizer, code generator, pre-linker, and the object module disassembler. The location of these files is site-specific.

The cross-platform compiler also supplies and uses additional files that are located in other directories. These files are:

TABLE 3. Additional Files Required

----------------------------------------------------------------------------------------
| Files    | Location                                                                  |
========================================================================================
| Library  | The resident portion of the SAS/C C and C++ libraries is located in the   |
|          | ar370 archives found in the lib directory. Since the transient            |
|          | portion of the SAS/C C and C++ libraries contains routines that must      |
|          | be loaded during program execution, the transient portion must be         |
|          | located on the mainframe with your executable load module. Different      |
|          | ar370 archives are provided for different mainframe target                |
|          | environments.                                                             |
----------------------------------------------------------------------------------------
| Header   | The standard SAS/C C and C++ header files are located in an               |
|          | include directory. Additional directory locations for include files       |
|          | can be specified.                                                         |
----------------------------------------------------------------------------------------
| Input    | Your source code, compiled objects, or ar370 archive input files can      |
|          | be located in any directory you choose                                    |
----------------------------------------------------------------------------------------
| Output   | Your compiled or pre-linked output can be directed to files in any        |
|          | directory you choose.                                                     |
----------------------------------------------------------------------------------------

The next four sections of this chapter provide additional information about the library, include, input, and output files used by the cross-platform compiler.

Library Files

The SAS/C C and C++ libraries contain both resident and transient routines. (They also provide all-resident and SPE routines that can be used in specialized applications.) Resident routines are incorporated into your program before it is executed. Transient routines are dynamically loaded during program execution.

Resident Library Routines

The resident libraries, libc.a for C and libcxx.a for C++, contain routines that are pre-linked with your application. Because these routines are added to your program during linking, resident library routines are not dynamically loaded during program execution. The resident library is specific to your target: MVS, CMS (VM/ESA Mode), or CMS (System/370 mode).

Transient Library Routines

The transient library is a collection of system-dependent routines that are loaded as needed by a program during execution. For example, before the program's main function is entered, the command line must be parsed and the argv vector created. Because the command line parsing routine is only needed once, during program start-up, the program initialization routine dynamically loads it from the transient library and unloads it (freeing the memory it required as well) when it is no longer needed.

All-resident Library Routines

In most programming situations, the dynamic loading and unloading of routines from the transient library makes the best use of available resources. User storage is not occupied by unused code, and when the support routines are installed in shared memory, many users can access a single copy of the routine. Also, the load module is much smaller because it contains only a small percentage of the required code.

However, in certain specialized applications and environments, it may be desirable to force the program load module to contain a private copy of all the required support routines. These programs can be characterized as all-resident programs because no transient library routines are used. In order to create an all-resident program, your program must include routines from the all-resident library.

The -Tallres compiler option is used to specify an all-resident program. You can also invoke cool directly, specifying the location of the all-resident library, libdir/libares.a, as an argument to cool.

SPE Library Routines

The SAS/C SPE library, libspe.a, provides resident routines that support the C Systems Programming Environment (SPE). The -Tspe compiler option can be used to specify an SPE program. You can invoke cool directly, specifying the location of the SPE library as an argument to cool.

Header Files

C and C++ source files take advantage of preprocessor support for including auxiliary source in a compilation by using the #include mechanism. The cross-platform compiler C and C++ preprocessors interpret #include statements that cause auxiliary files to be included as part of the source being compiled.

Auxiliary source files that are not provided as part of the SAS/C C and C++ libraries are considered to be user header files, and are typically enclosed in double quotes. For example

 #include "error_messages.h"
Auxiliary files that are provided with the SAS/C C and C++ libraries are called library header files or system header files, and are typically enclosed in angle brackets. For example

 #include <stdio.h>
The library header files are installed with the product, into the include subdirectory. This location is called the system directory.

When the SAS/C C and C++ preprocessors encounter a #include statement, the auxiliary file to be included must be located. The compilers search for the named file in a way that is typical of UNIX compilers. To modify the search order use the -Knousearch option. The following describes the search performed by the preprocessor.

  1. The directory of the source file containing the #include statement.
  2. Any directories specified by -I compiler option. This search is done in the order that the -I options appear on the command line.
  3. The system directory.
  1. Any directories specified by -I compiler option. This search is done in the order that the -I options appear on the command line.
  2. The system directory.
  1. The current working directory.
  2. Any directories specified by -I compiler option. This search is done in the order that the -I options appear on the command line.
  3. The directory of the source file containing the #include statement.
  4. The system directory.
  1. The current working directory.
  2. The system directory.
The search order described in this section is traditional with UNIX C compilers, and therefore meshes well with many of the programming tools commonly used under the UNIX operating system, such as make.

Adding Directories to the Search Path

The -I compiler option in the SAS/C Cross-Platform Complier enables you to specify additional directories that are searched before the standard include-file search list. For example, the following command causes the cross-platform compiler to search the /u/userid/branch_bank/headers directory for header files:

 sascc370 -I/u/userid/branch_bank/headers debits.c credits.c
In this example, debits.c, or credits.c could contain the statement,

 #include "transactions.h"
which would be located in the /u/userid/branch_bank/headers directory. The -I option works the same for sasCC370.

Input Files

The sascc370 compiler driver accepts C source, C++ source, and previously compiled objects. The sasCC370 compiler driver accepts C++ source and previously compiled objects.

sascc370 Input Files

The sascc370 compiler driver accepts the following input files.

TABLE 4. sascc370 Input Files

------------------------------------------------------------------------
| Input Files            | Description                                 |
========================================================================
| C Source Files         | uncompiled C source code, identified by a   |
|                        | .c filename extension.                      |
------------------------------------------------------------------------
| C++ Source Files       | uncompiled C++ source code, identified by   |
|                        | .cxx or .C.                                 |
------------------------------------------------------------------------
| Compiled Object Files  | contain previously compiled object code.    |
|                        | Identified by a .o filename extension.      |
------------------------------------------------------------------------
| Archive Libraries      | ar370 archive files. Identified by a .a     |
|                        | filename extension.                         |
------------------------------------------------------------------------

The sascc370 compiler driver examines the filename extension to determine whether the file contains source code (.c) or compiled objects (.o or .a). The driver then takes action based on the compiler options and the types of input files specified on the command line. For a .c file, the following actions are taken:

  1. Invoke the cross-platform compiler to produce a .o object file.
  2. Invoke cool with the system ar370 archive, libc.a and the .o object file to produce a pre-linked object file.
Note: If you specify -cxx on the sascc370 command line, sascc370 will perform identically to sasCC370.

The output files produced by this sequence are described in "Output Files" on page 19.

sasCC370 Input Files

The sasCC370 compiler driver accepts the following input files.

TABLE 5. sasCC370 Input Files

------------------------------------------------------------------------
| Input Files            | Description                                 |
========================================================================
| C++ Source Files       | uncompiled C++ source code, identified by   |
|                        | a .cxx, .C, or .c filename extension.       |
------------------------------------------------------------------------
| Compiled Object Files  | contain previously compiled object code.    |
|                        | Identified by a .o filename extension.      |
------------------------------------------------------------------------
| Archive Libraries      | ar370 archive files. Identified by a .a     |
|                        | filename extension.                         |
------------------------------------------------------------------------

The sasCC370 compiler driver examines the filename extension to determine whether the file contains source code (.cxx, .C, or .c) or compiled objects (.o or .a). The driver then takes action based on the compiler options and the types of input files specified on the command line. For a .c file, the following actions are taken:

  1. Invoke the cross-platform compiler to produce a .o object file.
  2. Invoke cool with the system ar370 archive, libc.a and the .o object file to produce a pre-linked object file.
The output files produced by this sequence are described in "Output Files" on page 19.

Output Files

Depending upon how it is invoked, the sascc370 and sasCC370 compiler drivers produce any of the following output file types:

TABLE 6. sascc370 Output Files

----------------------------------------------------------------------------------------
| Output Files               | Contents                                                |
========================================================================================
| Object Files               | unlinked object code and are identified by a .o         |
|                            | filename extension.                                     |
----------------------------------------------------------------------------------------
| Pre-linked Output Files    | object code that has been pre-linked by cool. By        |
|                            | default, the pre-linked output is written to a.out.     |
|                            | The -o compiler option is used to direct the output     |
|                            | to another file.                                        |
----------------------------------------------------------------------------------------
| Preprocessed Source Files  | source code that has been preprocessed and are          |
|                            | identified by a .i extension. Preprocessed source       |
|                            | code has all the macros and #include files              |
|                            | expanded. These files are generated by invoking the     |
|                            | sascc370 compiler driver with the -P option.            |
----------------------------------------------------------------------------------------
| Debugger Files             | information used by the SAS/C Debugger and are          |
|                            | identified by a .dbg370 filename extension. These       |
|                            | files are produced if the -g compiler option is         |
|                            | specified.                                              |
----------------------------------------------------------------------------------------
| OMD Output Files           | output from the Object Module Disassembler. These       |
|                            | files are identified by a .omd filename extension.      |
|                            | See Chapter 5, "Using the Global Optimizer and the      |
|                            | Object Module Disassembler" on page 49 for more         |
|                            | information.                                            |
----------------------------------------------------------------------------------------
| Listing Files              | output listings and are identified by a .lst filename   |
|                            | extension. The -Klisting compiler option is             |
|                            | used to specify a particular listing file.              |
----------------------------------------------------------------------------------------

The pre-linked object file can be copied to the mainframe, where it is then submitted to the linkage editor, which accomplishes the final linking and generates an executable module. Note that your output files will be targeted for an MVS environment by default. Use either the -Tcms370 or the -Tpcms370 compiler options to generate output files that are compatible with the CMS environment.

The .dbg370 debugger files are required to debug your program with the SAS/C Debugger. See Chapter 9, "Cross-Debugging" on page 71 for more information about using the SAS/C Debugger in the cross-development environment.

Output Filename Generation

Unless you use the -o compiler option to specify an output filename, the base filename of the source file will be used to generate the base filenames of the output object and listing files. For example, suppose you invoked the cross-platform compiler with the following command:

 sascc370 -Kilist students.c
In this example, the -Kilist option specifies that a header file listing should be generated. The students.c file contains uncompiled source code that includes a header file that will be printed to the output listing. The following output files are produced:

TABLE 7. Example Output Files

------------------------------------------------------------------------------------------
| File          | Description                                                            |
==========================================================================================
| a.out         | pre-linked output file                                                 |
------------------------------------------------------------------------------------------
| students.lst  | listing file containing the source code for the included header file.  |
------------------------------------------------------------------------------------------

Using -o with a Single Source File
If this same file is compiled with the -o option, the output object and listing filenames are formed with the specified base name. For example, suppose the cross-platform compiler is invoked as follows:

 sascc370 -o roster -Kilist students.c
In this case, the following output files are generated:

TABLE 8. Example Output Files

------------------------------------------------------------------------------------------
| File          | Description                                                            |
==========================================================================================
| roster        | pre-linked output file                                                 |
------------------------------------------------------------------------------------------
| students.lst  | listing file containing the source code for the included header file.  |
------------------------------------------------------------------------------------------

Notice that the a.out file is not generated in this case; instead, the prelinked object is written to the file specified with -o.

Using -o with Multiple Source Files
With multiple input files, the base name of each source file is used to generate the base of the .o and .lst filenames associated with the source file. For example,

 sascc370 -o acct_bal -Kilist debit.c credit.c
In this case, the following output files are generated:

TABLE 9. Example Output Files

-------------------------------------------------------------------------------------------
| File        | Description                                                               |
===========================================================================================
| acct_bal    | pre-linked output file                                                    |
-------------------------------------------------------------------------------------------
| debit.lst   | listing file containing the source code for the header file included by   |
|             | debit.c                                                                   |
-------------------------------------------------------------------------------------------
| credit.lst  | listing file containing the source code for the header file included by   |
|             | credit.c.                                                                 |
-------------------------------------------------------------------------------------------

ar370 Archives

An ar370 archive library is a collection of object files, similar to a partitioned data set under MVS or a TXTLIB under CMS. The advantage of ar370 archives is that they combine several files into one file, and they maintain a list of definitions of variables and functions. The items in the list are not limited in length, which allows references to long symbols to be resolved during linking. Furthermore, collecting many objects together in one ar370 archive can provide a single file for managing these objects.

Note: External references to variables are resolved by extracting files that define the reference from the ar370 archive. This is similar to the autocall process under MVS or CMS; however, there is an important distinction. On MVS and CMS, a reference is resolved by examining the names of the members of the partitioned data set or TXTLIB. Under UNIX, cool determines which file contains a defining instance of a reference by examining the ar370 generated symbol table, which is part of the ar370 archive. Thus, references are resolved following a mechanism that is more common to UNIX implementations.

The ar370 utility used to create and manage ar370 archives is described in Chapter 7, "ar370 Archive Utility" on page 61.