This section contains the following topics:
DB2 does not support the link386 linker that comes with the Micro Focus COBOL compiler. To link DB2 Micro Focus COBOL programs, you must use the ilink linker that is available from IBM compiler products. The cbllink command, used in the script files in this section, calls the ilink linker.
When building applications with the Micro Focus COBOL compiler that contain embedded SQL and DB2 API calls, keep the following points in mind:
set LIB=%DB2PATH%\lib;%LIB%
set COBCPY=%DB2PATH%\include\cobol_mf;%COBCPY%
Calls to all DB2 application programming interfaces must be made using calling convention 8. The DB2 COBOL precompiler automatically inserts a CALL-CONVENTION clause in a SPECIAL-NAMES paragraph. If the SPECIAL-NAMES paragraph does not exist, the DB2 COBOL precompiler creates it, as follows:
Identification Division
Program-ID. "static".
special-names.
call-convention 8 is DB2API.
Also, the precompiler automatically places the symbol DB2API, which is used to identify the calling convention, after the "call" keyword whenever a DB2 API is called. This occurs, for instance, whenever the precompiler generates a DB2 API run-time call from an embedded SQL statement.
If calls to DB2 APIs are made in an application which is not precompiled, you should manually create a SPECIAL-NAMES paragraph in the application, similar to that given above. If you are calling a DB2 API directly, then you will need to manually add the DB2API symbol after the "call" keyword.
The command file bldapp, in %DB2PATH%\samples\cobol_mf, contains the commands to build a DB2 application program.
The first parameter, %1, specifies the name of your source file. This is the only required parameter for programs that do not contain embedded SQL. Building embedded SQL programs requires a connection to the database so three optional parameters are also provided: the second parameter, %2, specifies the name of the database to which you want to connect; the third parameter, %3, specifies the user ID for the database, and %4 specifies the password.
For an embedded SQL program, bldapp passes the parameters to the precompile and bind command file, embprep. If no database name is supplied, the default sample database is used. The user ID and password parameters are only needed if the instance where the program is built is different from the instance where the database is located.
@echo off rem bldapp command file -- OS/2 rem Builds a Micro Focus COBOL application program rem Usage: bldapp <prog_name> [ <db_name> [ <userid> <password> ]] rem If an embedded SQL program, precompile and bind it. if exist "%1.sqb" goto prepbind goto compile_step :prepbind call embprep %1 %2 %3 %4 :compile_step rem Compile the error-checking utility. cobol checkerr.cbl; rem Compile the program. cobol %1.cbl; rem Link the program. cbllink %1.obj checkerr.obj db2api.lib db2gmf32.lib @echo on
| Compile and Link Options for bldapp |
|---|
|
Compile Option:
|
|
Link Options:
Refer to your compiler documentation for additional compiler
options.
|
To build the non-embedded SQL sample program, client, from the source file client.cbl , enter:
bldapp client
The result is an executable file client.exe. You can run the executable file against the sample database by entering the executable name (without the file extension):
client
There are three ways to build the embedded SQL application, updat, from the source file updat.sqb :
bldapp updat
bldapp updat database
bldapp updat database userid password
The result is an executable file, updat.exe.
There are three ways to run this embedded SQL application:
updat
updat database
updat database userid password
The command file bldsrv, in %DB2PATH%\samples\cobol_mf, contains the commands to build an embedded SQL stored procedure. The command file compiles the stored procedure into a DLL on the server.
The first parameter, %1, specifies the name of your source file. The second parameter, %2, specifies the name of the database to which you want to connect. Since the stored procedure must be built on the same instance where the database resides, there are no parameters for user ID and password.
Only the first parameter, source file name, is required. Database name is optional. If no database name is supplied, the program uses the default sample database. The command file uses the source file name, %1, for the DLL name.
@echo off rem bldsrv command file -- OS/2 rem Builds a Micro Focus COBOL stored procedure rem Usage: bldsrv <prog_name> [ <db_name> ] rem Precompile and bind the program. call embprep %1 %2 rem Compile the stored procedure. cobol %1.cbl; rem Link the stored procedure and create a shared library. cbllink /d %1.obj db2api.lib db2gmf32.lib rem Copy the stored procedure to the %DB2PATH%\function directory. copy %1.dll %DB2PATH%\function @echo on
| Compile and Link Options for bldsrv |
|---|
|
Compile Option:
|
|
Link Options:
Refer to your compiler documentation for additional compiler
options.
|
To build the sample program outsrv from the source file outsrv.sqb , if connecting to the sample database, enter:
bldsrv outsrv
If connecting to another database, also enter the database name:
bldsrv outsrv database
The linker uses a default entry point unspecified by the user. The /d option is used to create the .dll file in order to build the stored procedure. The command file copies the stored procedure DLL, outsrv.dll, on the server in the path %DB2PATH%\function.
If necessary, set the file mode for the DLL so the client application can access it.
Once you build the DLL, outsrv, you can build the client application outcli that accesses it. You can build outcli using the command file, bldapp. Refer to "DB2 API and Embedded SQL Applications" for details.
To call the stored procedure, run the sample client application by entering:
outcli database userid password
where
The client application accesses the DLL, outsrv, and executes the stored procedure function of the same name on the server database. The output is then returned to the client application.