All standard include files are shipped in the LMS library, $ORACINST.PRO.INCLUDE.LIB. You must specify this LMS library or a user-defined include library for the EXEC SQL INCLUDE statements. Use the INCLUDE precompiler option, as follows:

* INCLUDE=$ORACINST.PRO.INCLUDE.LIB \
* INCLUDE=mylibrary

where mylibrary is the BS2000 file name of the user-defined library, such as PROC.INCLIB.

You can also specify a user-specific configuration file as an LMS-element using the following syntax:

* CONFIG=my_config_lib[config_element]

where my_config_lib is the BS2000 file name of the configuration library and config_element is the full name of the element.

You must use brackets when specifying the configuration element, as shown in the following example.

* CONFIG=CONFIG.LIB[PROCOB.CFG]

Besides using BS2000 files, you can also use the LMS library elements for precompiler I/O using the INAME, ONAME, and LNAME options.

If you do not specify a library file name and an element, then the Oracle Database precompilers generate BS2000 ISAM files by default. The only option that you must enter is the INAME option. This can be either a BS2000 file name, or a library file name and the name of an element from the LMS library.

For example:

* INAME=my_input_lib[my_element] \
* ONAME=my_output_lib[my_element] \
* LNAME=my_list_lib[my_element] \

where my_input_lib is the BS2000 file name of the particular library and my_element is the name of the element including the specific suffix.

In the following example, Pro*C generates an output file with the name SAMPLE.C as the ONAME option has been omitted:

* INAME=INPUT.LIB[SAMPLE.PC] \ 
* LNAME=LIST.LIB[SAMPLE.LST]

The following are the additional remarks on this release of Oracle Database 12c Release 2 (12.2) for Fujitsu BS2000:

• Only compilers and compiler versions supporting the ILCS Standard Linkage are supported. If the Oracle Database detects a call from a user program not using the Standard Linkage conventions, then it terminates the task and displays the message number 5002 or 5003.

• If ONAME is not specified when starting a precompiler, then the precompiler generates a default name, which consists of the last part of INAME with the relevant suffix. For example, if the name of the C program you want to compile is MYPROG.PERS.TEST.PC, and if ONAME is omitted, then Pro*C generates an output file with the name TEST.C.

• If you work with float variables, then you may encounter rounding problems. The workaround is to declare the float variables as double variables instead.

The Pro*C include files, demo files, and system configuration files are shipped under:

$ORACINST.PRO.INCLUDE.LIB
$ORACINST.C.DEMO.*.PC
$ORACINST.UTM.DEMO.*.PC
$ORACINST.CONFIG.PCSCFG.CFG

An example of a BS2000 procedure for precompilation and compilation is included in the Oracle Database software under the name $ORACINST.P.PROC.

If you want to program explicit C calls to SQLLIB functions, then you must call sq2xxx instead of sqlxxx. For example, call sq2cex instead of sqlcex.

If you are making calls to Pro*C functions, such as sq2cls() or sq2glm(), then you can include the SQLCPR.H file into the C programs to verify that the functions calls are correct.

In the Pro*C programs, add the following line:

EXEC SQL INCLUDE SQLCPR

as you would for SQLCA or SQLDA.

You can use Pro*C to write UTM program units.

The Pro*COBOL include files, demo files, and system configuration files are shipped under:

$ORACINST.PRO.INCLUDE.LIB
$ORACINST.COBOL.DEMO.*.PCO 
$ORACINST.UTM.DEMO.*.PCO 
$ORACINST.CONFIG.PCBCFG.CFG

An example of a BS2000 procedure for precompilation and compilation is included in your Oracle Database software under the name $ORACINST.P.PROCOB2000.

If you want to program explicit COBOL calls to SQLLIB functions, then call SQ0XXX instead of SQLXXX. For example, call SQ0ADR instead of SQLADR.

You can use Pro*COBOL to write openUTM (Universal Transaction Monitor) program units. Pro*C and Pro*COBOL program units can be combined in an openUTM application.

This section describes how to construct an open string and includes the following topics:

• Required Fields

• Optional Fields

• Examples

The transaction monitor uses this string to connect to the database. The maximum number of characters in an open string is 256. Construct the string as follows:

Oracle_XA{+required_fields...}[+optional_fields...]

where the required_fields are:

• Acc=P/user/access_info

• SesTm=session_time_limit

and the optional_fields are:

• DB=db_name

• MaxCur=maximum_no_of_open_cursors

• SqlNet=connect_string

• DbgFl=value_from_1_to_15

You can choose from the following options when interfacing with precompilers:

• Using Pro*C with the Default Database

• Using Pro*C with a Named Database

Run all the precompiler programs with the option release_cursor set to no. Precompiler programs may be written in C or COBOL. The precompiler Pro*C is used in the examples.

UTM application program units must use embedded SQL. Calls to the Oracle Call Interface (OCI) are not allowed.

The following SQL operations are discussed:

• CONNECT

• COMMIT

• ROLLBACK

• SAVEPOINT

• Cursor Operations

• Dynamic SQL

• PL/SQL

• Autocommit

This section describes the Oracle Database-specific points that you must consider when using UTM operations. It describes the effect of the PEND (Program Unit End), and RSET (Reset) operations of openUTM. These operations represent the common synchronization points between openUTM and the Oracle Database.

The following openUTM operations are discussed:

• RSET and PEND RS

• PEND ER and PEND FR

• PEND KP, PEND PR, and PEND PA

• PEND RE, PEND FI, PEND SP, and PEND FC

When you issue a PEND call, UTM calls the Oracle Database internally through the XA interface for synchronization. When the PEND takes place:

• The user dialog/transaction is detached from the executing task.

• Any resource that is still attached to the user is released.

You can specify the DbgFl (debug flag) in the open string.

Depending on the debugging level (low:DbgFl=1, high:DbgFl=15), you can get more or less debug entries in the trace file ORAXALOG.pid-db_name-date.TRC.

In-doubt or pending transactions are transactions that have been prepared but not yet committed in the database. Generally, openUTM resolves any in-doubt or pending transaction. However, the Database Administrator may have to override an in-doubt transaction when working with UTM-F, that is, APPLIMODE=FAST. For example, when the in-doubt transaction is:

• Locking data that is required by other transactions.

• Not resolved in a reasonable amount of time.