PreviousInterface to Informix DBMS Interface to Sybase DBMSNext"

Chapter 28: Interface to Oracle DBMS

This chapter describes how to use Oracle in this COBOL system and how to compile and link COBOL programs containing their code. It also describes the COBOL to Oracle integration package, explaining how to use it, as well as giving solutions to some common problems.

28.1 Overview

You can access the SQL functions offered by the database system from your COBOL program by embedding SQL statements in your COBOL programs using the following format:


A preprocess step then replaces statements of the above form with the relevant calls to database services. Other additions are made to the source code to bind host COBOL variables to the SQL variable names known to the database system.

The advantage of embedding SQL in this way is that the programmer need not know the format of individual database routines. The disadvantage is that the resulting source code must be linked to the database routines, and therefore Animator using .int and .gnt code variants are unavailable. The COBOL to Oracle integration package described later in this chapter overcomes this limitation, but the source code used by Animator is the output from the precompiler rather than the original Embedded SQL written by the programmer. This disadvantage can be overcome by using the COBSQL integrated preprocessor (see the chapter Using COBSQL).

28.1.1 Software Requirements

Please consult on disk documentation for information about the compatibility of this COBOL System with the various database management systems and their precompilers.

There is a special version of Pro*COBOL available from Oracle which is XM aware for running on DOS. It is V1.3.1.08.

28.1.2 Working with .int/.gnt Files and Oracle

You can run your COBOL program containing Oracle code in .int or .gnt code format. To make Oracle calls accessible to COBOL programs in .int or .gnt code format, you must use the oralib interface module to resolve the calls from COBOL to Oracle.

The COBOL to Oracle integration package consists of:

oralib.gnt main integration library
oralib.cbl source code for oralib
cbl2orad.obj object file for linking with DOS
dos.lnk sample link file for DOS

Windows and OS/2:
For Windows and OS/2 oralib simply loads the appropriate Oracle DLL. Depending on the version of Oracle in use, you may have to edit and recompile oralib to make it load the correct DLL:

You also need the following COBOL system files to use the Oracle database support:


* applic.cfg, applic.exe and applic.lbr are user-defined names for the user
application configuration, executable and library files.

You also need the PRO*Cobol support files and SQL*Net or local database. See the documentation supplied with your Oracle product for details on the support files required.

On UNIX, you may animate and run .int and .gnt code by using a COBOL Run-time System that has been linked with the SQL run-time routines supplied by Oracle.

The Oracle installer builds a suitable RTS, called rtsora. The RTS may also be rebuilt by the command:

make -f $ORACLE_HOME/procob/lib/ rtsora

28.2 Linking Oracle Programs

Linking COBOL programs containing Oracle code is described in the manuals supplied with Pro*COBOL by Oracle.

28.2.1 Loading a COBOL to Oracle Interface Module

You can load a COBOL to Oracle Interface Module in any of the following ways:

Note: If you use either of the first two methods, ensure that only the top-level program calls the oralib interface module. Do not compile a subprogram with the INITCALL directive. Using COBOL Configuration Files

If you are using the Build utility, you can load your oralib file from your application configuration file. To do so, you must add the following information to your .cfg file:


Note: applic.lbr is a user-defined name for the user application library file.

28.3 COBOL-to-Oracle Interfacing Considerations

To avoid potential problems when interfacing between COBOL and Oracle, you must take the following areas into consideration:

16-bit Windows:
The first version of Pro*COBOL supported on 16-bit Windows is 1.6. This is actually a 32-bit application and so WIN32S must be installed on the machine where it is running. However, Pro*COBOL 1.6 thunks to 16-bit and will only run with the 16-bit version of COBOL.

16-bit OS/2:
The last version of Pro*COBOL supported on 16-bit OS/2 is 1.3. Later versions of Pro*COBOL only support 32-bit COBOL.

32-bit Windows:
Pro*COBOL Version 1.7 for Windows NT is a 32-bit application and will only work with 32-bit COBOL.

32-bit OS/2:
Versions of Pro*COBOL later than 1.5 for OS/2 are 32-bit applications. These versions will only work with 32-bit COBOL.

On UNIX, all versions of Pro*COBOL and COBOL are 32-bit. Please refer to your Oracle documentation for the recommended version of COBOL to use with your version of Pro*COBOL.

28.3.1 DOS Considerations

This section describes issues you must consider when interfacing between COBOL and Oracle on DOS.

If you want to run your COBOL/Oracle application against a remote database, you should ensure that at least 300Kb of base memory is free. If you want to run the application against a local database, the amount of memory required to run correctly is likely to be more than that available in base memory.

COBOL programs on DOS need to be run under the memory manager XM. Similarly, when running under DOS, Oracle uses its own memory manager, SQLPME.

In older versions of this COBOL system, there was no way for Oracle to route a call out of XM. Current versions of Micro Focus COBOL and Oracle provide this support. You must use the versions of COBOL and Oracle, including a special version of Pro*COBOL, given in the section Software Requirements earlier in this chapter to obtain this support.

The special version of Pro*COBOL enables a user program running under XM to talk to SQLPME. By default both XM and SQLPME try to use all available memory. Therefore, to enable this facility, you must restrict the memory for both memory managers.

To allocate the amount of extended memory to be used by XM, you set the /Z XM switch. We recommend you set /Z to a value of 4096Kb. You can set this switch in your autoexec.bat file as follows:

set xm=/Z4096

To allocate the amount of extended memory to be used by SQLPME, you set the DYNAMIC_MEMORY environment variable We recommend you set this environment variable to a value of 6020Kb. You set this in the Oracle configuration file, config.ora, as follows:

DYNAMIC_MEMORY=6020 Restrictions

The following restrictions apply when interfacing between COBOL and Oracle on DOS:

28.3.2 Windows Considerations

This section describes issues you must consider when interfacing between COBOL and Oracle on Windows.

You must install the Oracle Required Support Files for Windows on your machine. You must also ensure that these files are made available on the PATH.

It is important to ensure that the COBOL stack has been set up, or the call to allocate memory (usually the last C call of the expanded connect statement) will fail. This takes the form of a Protection Violation caused by Initapp in coblib.dlw.

There must sufficient system resources for Oracle to make its connection; otherwise, you could receive a 9241 error when trying to connect to the database. Specifically, you must take the following two areas into consideration:

28.3.3 OS/2 Considerations

This section describes issues you must consider when interfacing between COBOL and Oracle on OS/2.

The Oracle Required Support Files must be installed

You must ensure that the Oracle .dll files are made available on the LIBPATH.

If you are running with a local database, you need to be aware of the following issues:

28.4 Filename Extensions

Oracle uses .pco and .cob filename extensions. For the Micro Focus Copybook Preprocessor (CP) to resolve copybooks and include statements correctly, use the following COBOL Compiler directives:

osext (pco) copyext (cob,cpy,cbl)

28.5 Project Definition

You can use Workbench Organizer to create an Oracle project (see the chapter Configuring Your Organizer Desktop in your Workbench User Guide). Typical values are:

Project name: Oracle Demos
Environment Variables: cobcpy=e:\ora7win\pro16\cob;
Working directory: c:\tests\run\oracle\build
Directives: osext(eco) copyext(cob,cpy,cbl) p(cobsql) p(cp)
Icon: project

28.6 COBSQL Directives

If you are using COBSQL you can use the cobsql.dir file to specify COBSQL directives. Typical values are shown below:


28.7 COBSQL and Oracle Considerations

If you are using COBSQL in conjunction with the Oracle precompiler, you should bear in mind the following points.

Note: The oraprot module has a ROLLBACK WORK RELEASE statement in it. This would have to be changed to a ROLLBACK WORK statement.

Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.

PreviousInterface to Informix DBMS Interface to Sybase DBMSNext"