Self-Contained Callable Shared Objects

A self-contained callable shared object is similar to an executable, but is designed to be loaded by non-COBOL executables. Only use this type of object when you are not able to use the cob command to relink the object to a main executable, for example, when used with third-party executables such as DB2.

You create a self-contained callable shared object using the -y cob flag:

cob -y obj1.o obj2.o obj3.o

By default, the base-name of the resulting file takes the name of the first file being linked, and has the filename extension .so; the example above results in the file obj1.so. The base-name forms the main entry point, but this can be overridden using the -e flag.

Input files can be any file type except .gnt files. If you use object module files (.o), they are linked in using the system linker (ld). You can also use the CC option to also link C++ objects into the library file. If C++ source files are specified, the C++ compiler is invoked to compile them to object code first.

To load a self-contained callable shared object, you must use the dlopen() function, as follows:

handle=dlopen("obj1.so", RTLD_GLOBAL|RTLD_NOW);

If you are building a self-contained callable shared object on a Linux platform, and will be calling COBOL modules built to .int or .gnt files, you must specify the following additional options when you link the main (non-COBOL) executable: -Wl,-zexecstack

For example:

gcc -m32 -o mymainexe mymain.o -g -ldl -Wl,-zexecstack
Restriction: You can only load one self-contained callable shared object into a process at any one time; the current self-contained callable shared object must be unloaded before you can load another one in the same process.