Skip Headers

Oracle9i Enterprise Edition User's Guide
Release 2 (9.2.0.1.0) for OS/390
Part No. A97312-01
Go To Table Of Contents
Contents
Go To Index
Index

Previous Next

8
Oracle Call Interface

Oracle9i for OS/390 supports two types of programmatic interfaces:  Oracle Precompilers and the Oracle Call Interface (OCI).  Together, they allow precise control over SQL statement operations in a high-level source program.

Read this chapter for OS/390-specific information about using the Oracle Call Interface under OS/390 and Chapter 7, " Oracle Precompilers" for information about Oracle Precompilers.  Sections in this chapter include:

The product-specific documentation for OCI is contained in the OCI Programmer's Guide.

Oracle Call Interface Overview

The Oracle Call Interface (OCI) provides precise control over all aspects of Oracle9i database access to your C programming language application programs.  Unlike Oracle Precompiler applications that use Pro*C to convert embedded SQL statements into C programming language statements and function calls, OCI applications are written to specify the C programming language function calls directly.  Oracle9i OCI only supports programs written in C programming language.  Although use of Oracle V7 OCI is still supported for existing applications and existing applications can be run without relinking, it is no longer documented.

OS/390 supports several major operating environments and OCI programs can be targeted to run in any of them.  Whether your application requires traditional batch processing, interactive processing under TSO, or transaction processing under CICS or IMS TM, OCI can be a part of your application architecture.

OCI is also supported in the OS/390 UNIX System Services environment.  Refer to Chapter 4, " Accessing Oracle9i Under USS", for additional information about building and running OCI programs in the OS/390 UNIX System Services environment.

Regardless of which environment you choose, the same steps are done.  These steps are:

  1. Compiling the program with the language's compiler.

  2. Linking the program with an Oracle interface stub designed especially for the target environment.  Batch, TSO, CICS, and IMS TM each require linking with a different stub.

  3. Running your program in the target environment.

This chapter discusses each of the steps needed to build and run an application program that uses Oracle9i OCI.  It contains environment-specific program design considerations.  For more information, refer to the OCI Programmer's Guide.

Target Environment Design Considerations

This section discusses application design considerations that apply specifically to a target environment.

TSO Programs

To use an OCI application under TSO (by the CALL command or as a command processor), ensure you call OCISessionEnd or OCIServerDetach before the program ends.  Otherwise, an abend with completion code A03 occurs when the program attempts to end.  The OCISessionEnd or OCIServerDetach call ensures Oracle cleanup actions are taken, in particular the removal of an OS/390 subtask that is used to handle TSO session attention signals.

The IBM TSO TEST processor does not support cross memory mode operations. Because Oracle applications perform all database operations in cross memory mode, you cannot escape to TSO TEST when an Oracle application is performing operations within the database.

CICS Programs

Oracle OCI calls are not supported by Oracle Access Manager for CICS.

IMS TM Programs

Oracle Access Manager for IMS TM allows OCI programs written in C programming language and running in an IMS MPP, IFP, or BMP region to access an Oracle9i database server anywhere in your network.  Programs can access and update IMS, DB2, and Oracle9i data within a single synchronized transaction.

From an IMS TM perspective, transaction programs accessing Oracle9i databases have no special requirements.  The normal IMS calls for input and output messages processing, data access, and synchronization perform as if the Oracle9i system is not being used.

From an Oracle9i perspective, OCI applications running under IMS TM are no different from other OCI applications.  They contain OCI function calls that are passed to the Oracle9i database server as the program runs.  When using OCI programs in an IMS TM transaction, there are some special considerations.

Accessing Multiple Oracle9i Databases

Each program target to IMS TM can only communicate with one Oracle Access Manager for IMS TM and one server because it can only link with one LIT.  Access to more than one Oracle9i database server from a single IMS TM region can be done as follows:

  • You can use Oracle database links.  With this method, all updates to any of the accessed databases can be part of a single program.

  • You can use multiple Oracle Access Managers.  To do this, you first design your application so that the access logic for each database is contained in a separate IMS TM program.  You then configure an Oracle Access Manager and a corresponding LIT for each distinct server to be accessed.  Finally, you link each of the IMS TM programs with the appropriate LIT.

Additional Restricted OCI Functions

Programs used with Oracle Access Manager for IMS TM can only use Oracle DML SQL statements.  Programs attempting to use DDL or DCL statements, such as CREATE TABLE or GRANT, receive an Oracle error code indicating incorrect use of distributed transaction mechanics.

A typical Oracle9i application might use OCI functions for commit or rollback statements to control whether database updates are committed or removed.  With Oracle Access Manager for IMS TM, these OCI functions are not available.  Instead, programs must use native IMS functions (such as GU, SYNC, ROLL, or ROLB) to synchronize both Oracle and non-Oracle updates.

Unavailable Calls

When using Oracle Access Manager for IMS TM, the following OCI function calls are not available:

  • All OCI security calls

  • All OCI thread calls

  • All OCI direct path load operations

  • The following function calls:

    • OCIBreak
    • OCIServerDetach
    • OCIDefineDynamic
    • OCISessionBegin
    • OCIEnvCreate
    • OCISessionEnd
    • OCIEnvInit
    • OCISvcCtxToLda
    • OCIInitialize
    • OCITerminate
    • OCILdaToSvcCtx
    • OCITransCommit
    • OCILogoff
    • OCITransDetach
    • OCILogon
    • OCITransForget
    • OCIPasswordChange
    • OCITransPrepare
    • OCIReset
    • OCITransRollback
    • OCIServerAttach
    • OCITransStart

Oracle Access Manager for IMS TM supports both version 7 and version 9 OCI functions.  OCON and OCOF are only supported for version 7.  For version 9, use OCIStmtExecute with mode parameter OCI_COMMIT_ON_SUCCESS.  If you specify OCI_COMMIT_ON_SUCCESS with version 7, then the mode parameter is changed to OCI_DEFAULT.

Accessing Oracle9i and DB2 Databases in a Single Transaction

When accessing Oracle and DB2 data in a single transaction, the DB2 and Oracle access logic must be separated into distinct source programs that are precompiled and compiled separately.  They are then linked to act as a single transaction program.

Processing of Oracle9i Errors by Your IMS TM Program

Oracle errors that are considered application-oriented are always returned to the transaction program to be handled by the application logic.  These include message ORA-0001, all errors in the range of messages ORA-1400 to ORA-1489, and user-defined error messages in the range of ORA-20xxx.  It is the responsibility of the application developer to include suitable error handling logic for these types of errors.

All other errors are considered system-oriented.  These include errors associated with loss of the connection to the target Oracle9i database server and simpler errors, such as ORA-0942.  How Oracle Access Manager for IMS TM handles these errors is determined by an IMS option called the region error option (REO).

The REO can specify that system errors are to be passed to the transaction for handling that is identical to application-oriented errors.  Alternatively, the REO can specify that system errors abend and requeue, or abend and discard the transaction. The application developer and IMS administrator decide which REO to use.  The REO is not specified by or in the application program.  It is an Oracle Access Manager for IMS TM configuration parameter.

Compiling Your Program

When compiling your program there are considerations for long name support and callback restrictions.

Long Name Support

Unlike previous releases of the OS/390 implementation of OCI, this release relies on and exploits native support for long, mixed-case function names.  So, when compiling an OCI application, the LONGNAME compiler option must be specified. The object produced will cause the binder to create a PM3 type program object.  If this is not appropriate, another method is available.  See Appendix A, "API Short Name Support".

Callback Restriction

Applications using OCI functions that make use of callbacks must be compiled with the DLL option.

UNIX System Services

The Oracle Call Interface may be used in C programs developed for the USS environment.  Refer to Chapter 4, " Accessing Oracle9i Under USS" for more information.

To build one of the sample OCI programs, cd to the rdbms/demo directory and issue the following make command:

make -f demo_rdbms.mk build EXE=demo OBJS="demo.o ..."

For example:

make -f demo_rdbms.mk build EXE=oci02 OBJS=oci02.o 

To build all of the sample OCI programs, cd to the rdbms/demo directory and issue the following make command:

make -f demo_rdbms.mk demos

Note:

The sample OCI C++ programs are not supported in the USS environment due to a current limitation with the IBM C++ compiler on OS/390.  The current versions of the C++ compiler (version 2.6 through version 2.9) do not support the "long long" datatype.

Linking Your Program

After your program has been compiled, the resulting object code file is passed to the linkage editor where it is linked with the Oracle interface stub.  Each target environment has a unique stub and different linking considerations apply to each target environment.  In all cases the interface stub must be linked directly to your load module.  Dynamic loading cannot be used with the interface stub.

Sample Link JCL

Following is an example of JCL that might be used for linking:

//LKED     EXEC PGM=IEWL,

//         PARM='XREF,LET,LIST,DYNAM=DLL'

//SYSPRINT DD  SYSOUT=* 

//SYSLIB   DD  DSN=SYS1.SCEELKED,DISP=SHR

//         DD  *- Refer to Note 1 -*

//         DD  SYS.SCEELKED

//SQLLIB   DD  DSN=oran.orav.SQLLIB,DISP=SHR 

//SYSLMOD  DD  *- Refer to Note 2 -*

//TEXT DD  *- Refer to Note 3 -*

//SYSUT1   DD  UNIT=VIO

//SYSLIN   DD  *

INCLUDE SQLLIB(stub) *- Refer to Note 4 -*

INCLUDE TEXT

*- Refer to Note 5 -*

/*

Usage Notes

The following usage notes apply to the previous JCL example:

  1. Include additional libraries required by your program and any runtime libraries required by the C programming language compiler.

  2. This DD statement describes the library in which your linkedited Oracle load module is placed.

  3. This DD statement points to the object output from the C programming language compiler's program native language compiler.

  4. The specific contents of the SYSLIN DD statement depend on the target environment.  These contents are discussed later in this chapter.

  5. Include any additional linkage editor statements you require.

Batch and TSO Programs

When linking an OCI program to run in batch or TSO, you must add the following linkage editor control statement to the SYSLIN DD statement:

INCLUDE SYSLIB(ORASTBL)

The ORASTBL stub provides long name support for OCI functions and support for SQL functions.

If there are external references for symbols whose names begin with the letter O, then the linkage editor cannot find one or more of the function calls in your application.  Ensure ORASTBL is included in your linkedit.  The ORASTBL stub resolves any calls in your code.  If ORASTBL is correctly included, then the problem might be caused by a missing entry point to the stub routine.  You can contact Oracle Support Services for additional assistance.

IMS TM Programs

When linking a program to run under IMS TM, add the following linkage editor control statements to the SYSLIN DD statement:

INCLUDE SQLLIB(AMILS)

INCLUDE SQLLIB(lit-module)

The AMILS module must be the version that is compatible with this release if Oracle9i OCI is used.

The lit-module statement refers to a customer-generated language interface module.  The IMS TM system administrator generates and names the statement according to the installation's standards.

Do not include references to ORASTBL, ORASTUBS, or ORACSTUB.

If there are external references for symbols whose names begin with the letter O, then the linkage editor cannot find one or more of the function calls in your application.  Ensure AMILS is included in your linkedit.  The AMILS stub resolves any calls in your code.  If AMILS is correctly included, then the problem might be caused by a missing entry point to the stub routine.  You can contact Oracle Support Services for additional assistance.

Running Your Program

After your program has been linked, the resulting load module is run in the target environment.  As your program runs, it passes OCI function calls to the OCI interface stub linked with it. The interface stub contains logic to dynamically locate the full Oracle OCI interface for the target environment and to pass control to it.  The full interface must be available in a load library as your program runs.  Depending on the target environment, other runtime considerations might apply.

Batch and TSO Programs

The requirement for OCI programs in batch and TSO environments is the same as Precompiler programs.  Refer to the "Running Your Program".

IMS TM Programs

Normal IMS TM practices for defining your program to IMS TM are followed for OCI programs.  IMS TM programs access a shared copy of the full OCI interface that must be configured and available before your program begins running.  If the interface is not available, then you receive error message 3042 from IMS TM.  You must contact your IMS TM system administrator to have this condition corrected.

OCI Interface to Publish/Subscribe

The OCI interface to Oracle's publish/subscribe features allows an application to register a callback function that is driven when there are queue data or trigger events to process.  This feature is supported with Oracle for OS/390 server as long as the client executes in a multi-threaded environment and there is TCP connectivity between the server and the client.  This includes local OS/390 clients running under USS as well as remote clients on any multi-threaded platform.  It excludes native TSO/batch and IMS clients at this time

The TCP connectivity requirement does not mean that the client must be connected to the server via Oracle Net PROTOCOL=TCP.  The client can be connected via any protocol (including Oracle Net PROTOCOL=XM for a local USS client) and in fact the client can disconnect its session from the database after setting up the callback without affecting the callback.  A special background process in the server (EMON) opens a TCP connection to the client thread that gets created when OCISubscriptionRegister is called. TCP communication from the server to the client thread ultimately drives the callback functions.

See the OCI Programmer's Guide for further details on the OCI interface to Oracle's publish/subscribe facility.


Previous Next
Oracle Logo
Copyright © 2002 Oracle Corporation

All rights reserved
Go To Table Of Contents
Contents
Go To Index
Index