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.
sascc370
command.
sascc370
compiler driver controls the compilation of your C object code. Invoke the
compiler driver with the following command:
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 thesascc370 [
options
] [
filename1
[
filename2...
]]
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
.
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
sasCC370
command.
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.
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.
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:
_
_rent
variable. There are four ways a variable is
assigned the _
_rent
attribute:
-Krent
or -Krentext
is used.
-Krent
is used.
_
_rent
.
-Kextname
option is specified for more than one compilation.
-Tcms370
or -Tpcms370
options are specified and the cumulative length of the
pseudoregisters exceeds the maximum size allowed by the CMS loader.
ar370
archive.
cool
directly
COOL
to perform the pre-linking.
cool
, is an executable file that can be called directly. The following is the syntax
for invoking cool
:
The options argument specifies any of the pre-linker options described in Chapter 6 on page 53. You must use thecool [
options
] [
filename1
[
filename2 ...
]]
-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
.
cool
:
Pre-link the object filescool -o prog alpha.o beta.o /
libdir/libc.a
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
.
In this example, a C++ object file,cool -o prog myojb.o /
libdir/libcxx.a
/
libdir/libc.a
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
.
In this example, the all-resident library,cool -o prog interface.o io_handler.o /
libdir/libares.a
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.
Pre-link the object filecool -o prog -w binary_tree.o /
libdir/libc.a
binary_tree.o
, generating the pre-linked output file prog
. The
-w
option specifies that warning messages should be suppressed
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.
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.
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).
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.
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
.
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
.
#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.
#include
statement is a complete pathname, beginning from the root
directory (/
), then no other searching is performed. If the C or C++ system is unable to read the
named file, an error is produced.
-Knousearch
option was not specified, the
search proceeds as follows. Look in:
#include
statement.
-I
compiler option. This search is done in the order that the -I
options appear on the command line.
-Knousearch
option was not specified, the
search proceeds as follows. Look in:
-I
compiler option. This search is done in the order that the -I
options appear on the command line.
-Knousearch
option was specified, the
SAS/C C preprocessors take the following steps to locate the named file. Look in:
-I
compiler option. This search is done in the order that the -I
options appear on the command line.
#include
statement.
-Knousearch
option was specified, the
SAS/C C preprocessors take the following steps to locate the named file. Look in:
make
.
-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
.
sascc370
compiler driver accepts C source, C++ source, and previously compiled objects.
The sasCC370
compiler driver accepts C++ source and previously compiled objects.
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:
.o
object file.
cool
with the system ar370
archive, libc.a
and the .o
object file to produce a
pre-linked object file.
-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
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:
.o
object file.
cool
with the system ar370
archive, libc.a
and the .o
object file to produce a
pre-linked object file.
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.
-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. | ------------------------------------------------------------------------------------------
-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
.
.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
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.