Open System Services Shell and Utilities Reference Manual (G06.27+, H06.04+)

cobol(1) OSS Shell and Utilities Reference Manual
• If a valid filename cannot be generated using the rule above, a filename returned from
tmpnam is used, and a message informs the user of the new filename.
Libraries residing in Guardian directories cannot be specified as -l operands because of the nam-
ing convention. They can be specified in the desired order with -Wbind flags.
The default executable file in a Guardian file system is aout in the directory from which cobol is
invoked.
Differences Between Static and Dynamic Binding
In static binding, the Binder resolves references to library functions by binding into the program
the functions from a user library, such as libc.a. In dynamic binding, the Binder resolves refer-
ences to library functions by using information found in a shared runtime library, such as libc.so.
Final resolution of references are not done until run time. Dynamic binding produces smaller
program files and uses fewer system resources than static binding. By default, cobol performs
dynamic binding.
A shared library must have a file extension of .so. Such a file can either be an actual shared
library file created by the Binder or an OSS text file containing only one line of text in the form
"SRL=srlpath" where srlpath is the OSS pathname of the actual shared library file.
In dynamic binding, if a library is specified by an operand of the form llibrary, cobol searches for
a file liblibrary.so in a directory in the library search paths. If the file is found in the directory,
cobol issues the Binder command SET IMPORT LIBRARY srlpath, where srlpath is the path-
name of the actual shared library file. If the file is not found in the directory, cobol searches for a
file liblibrary.a in the same directory. If a file is found, cobol issues the Binder command
SELECT SEARCH libpath to perform a static binding of the library. If neither file is found, cobol
repeats the search for the library in the next directory in the library search paths.
In static binding, cobol only searches for liblibrary.a from directories in the library search paths.
Static libraries can be used for dynamic binding. The Binder resolves external references using
all the specified static libraries before using the shared runtime library. A program can only have
one shared runtime library. cobol issues warnings if more than one shared runtime library is
specified.
The standard C runtime library, libc.a or libc.so is used in dynamic binding only if no other
shared runtime libraries are used.
By default, the shared runtime library used during binding (the model library) is the shared run-
time library used during execution (the runtime library), unless a different library is specified by
the -Wrunlib flag.
The shared runtime library must be in the Guardian file system name space. If a shared runtime
library is in the OSS file system name space, you must supply a library in the Guardian name
space either using the -Wrunlib flag during program generation or through the LIB option of the
TACL RUN command during program execution.
Refer to the Binder Manual for more details on using shared runtime libraries.
Using the c89 and cobol Utilities
OSS COBOL85 programs can contain COBOL85 modules and C modules. Compile COBOL85
modules using the cobol utility and C modules using the c89 utility. To produce a program con-
taining COBOL85 and C modules, first compile all the modules written in either COBOL85 or C.
You can also bind these modules together or with other libraries at this time, but do not
accelerate or SQL-compile the modules. After you have compiled all the modules of one
language, compile the modules written in the other language, specifying any necessary binding,
accelerating, or SQL-compiling options.
For example, to produce an executable object file made up of COBOL85 modules cobol1.cbl
and cobol2.cbl and C modules c1.c and c2.c, you can first run the C compiler using the c89
2−56 Hewlett-Packard Company 527188-004