IBM Support

Configuring COBOL Stored Procedures to use the COBOL CALL Statement

Technote (FAQ)


Configuring COBOL Stored Procedures to use the COBOL CALL Statement Successfully.


DB2 V7 supports COBOL stored procedures, and can successfully use the COBOL CALL statement in a Main COBOL stored procedure to CALL a COBOL subprogram. Please note, the separate sub module can be called by the COBOL CALL statement, not the SQL Call statement used to call a separate stored procedure. Calling sub type stored procedures is only supported in db2 V7 when the stored procedure is an SQL or C language stored procedure, COBOL is not a supported language for sub type stored procedures. With COBOL there are two ways to call a sub: directly (with a literal) or by using a variable. By directly I mean using the following syntax.


By using a variable I mean using the following syntax.



Please note, all COBOL statements in this document are for IBM's Visual Age COBOL for Windows, or COBOL Set for AIX.

When using the direct call the Sub program must be available to the COBOL Linker so a .exp file must first be created. Below is an example of a .exp file and a compile command .


Compile Command

cob2 -o main-program-name main-program-name.cbl sub-program-name.cbl -L/usr/lpp/db2_07_01/lib -I/usr/lpp/db2_07_01/include/cobol_a -ldb2 -bE:main-program-name.exp -bM:SRE -bnoentry

This compile statement creates a single library, main_program_name, which can then be registered as a stored procedure.

Quoting from the AIX Command Reference, the Linker options (-b) in the above statement do the following

Exports the external symbols listed in the file main-program-name.exp. Exported symbols are listed in the loader section of the output file. There is no default export file.

Indicates that the output file has no entry point. To retain any needed symbols, specify them with the -u flag or with an export file.

Sets the two-character module-type field to RE (reusable) and the shared object flag to S (shared) in the object file.

When using the variable to call the subprogram two .exp files will be needed, one for the main and one for the subprogram. Using the following form.


In this case the two source files are compiled separately and
linked dynamically by the COBOL runtime.
The following command is used to compile the main program.

cob2 -o main-program-name main-program-name.cbl -I/home/instance/sqllib/include/cobol_a -L/home/instance/sqllib/lib/ -ldb2 -bE:main-program-name.exp -bM:SRE -bnoentry

The following command is used to compile the sub program.

cob2 -o sub-program-name sub-program-name.cbl -I/home/instance/sqllib/include/cobol_a -L/home/instance/sqllib/lib/ -ldb2 -bE:sub-program-name.exp -bM:SRE -esub-program-name(as called in main program)

Please Note: the key to calling the sub program correctly in COBOL is the -esub-program-name, again quoting the AIX Command Reference, the option does the following.

Sets the entry point of the executable output file to sub-program-name. The default entry point is __start.

When calling COBOL stored procedures with a variable in the call statement, the COBOL runtime requires the COBPATH environment variable to be able to locate the object
modules correctly.

The COBOL COBPATH environment variable is set using the same syntax as a path variable. The COBPATH should include the path used to register the stored procedure at the time the create statement was issued. Please note, that the default library location for stored procedures is sqllib/function/, DB2 will look in this directory for the library to load, if nothing is specified in the EXTERNAL parameter of the Stored Procedure Create statement.
<provide AIX example of setting COBPATH... i.e. export COBPATH= sqllib/function/ etc.>

The default DB2 V7 environment does not include the COBPATH variable. To set DB2 up so that COBPATH variable is passed to the COBOL runtine during SP execution use the DB2 registry variable DB2ENVLIST. The following command will tell DB2 to include the COBPATH environment variable when it sets up the SP runtime environment.


Please note you can use the DB2ENVLIST registry variable to pass other environment variables into DB2 by simply using the following command to set the DB2ENVLIST registry variable to more than one environment variable.


Document information

More support for: DB2 for Linux, UNIX and Windows
DB2 Programming Interfaces - Non SQL Stored Procedure

Software version: 5, 6, 7, 8

Operating system(s): Platform Independent

Software edition: All Editions

Reference #: 1158411

Modified date: 2004-07-13