Release 2 (9.2.0.1.0) for OS/390
Part No. A97312-01
 Contents |
 Index |
|
Oracle9i Enterprise Edition User's Guide
Release 2 (9.2.0.1.0) for OS/390 Part No. A97312-01 |
|
Oracle Precompilers are used to process C, COBOL, or PL/I programs before passing them to their native compilers. Oracle Precompilers translate embedded SQL statements into calls necessary to access the Oracle9i database server.
Read this chapter for OS/390-specific information about using the Oracle Precompilers and Chapter 8, " Oracle Call Interface" for information about the Oracle Call Interface. Sections in this chapter include:
The product-specific documentation for the Oracle Precompilers is contained in the following Oracle documents:
Programmer's Guide to the Oracle Precompilers
Pro*C/C++ Precompiler Programmer's Guide
Pro*COBOL Precompiler Programmer's Guide
Pro*PL/I Supplement to the Oracle Precompilers Guide
The Oracle Precompilers are used to process C, COBOL, or PL/I programs before passing them to their native compilers. Oracle Precompilers translate embedded SQL statements in the programs into the appropriate native language statements and calls necessary to access the Oracle9i database server.
OS/390 supports several major operating environments, and the Oracle Precompilers can be used to target your programs 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, the Oracle Precompilers are the first step in building your programs.
Oracle also supports the OS/390 UNIX System Services (USS) environment. Refer to Chapter 4, " Accessing Oracle9i Under USS", for additional information about building and running Oracle Precompiler applications in the OS/390 UNIX System Services environment.
Regardless of the environment you choose, there are four steps involved:
Precompiling your program with one of the Oracle Precompilers and other precompilers that are required by the target environment.
Compiling the program with the language's compiler.
|
Note: A Language Environment conforming compiler is required for programs targeted to run in BATCH or TSO. |
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.
Running your program in the target environment.
This chapter discusses each of the steps needed to build and run an Oracle Precompiler application program, and contains some environment-specific program design considerations. For more information, refer to Oracle9i Application Developer's Guide - Fundamentals and the precompiler documentation specific to the programming language you plan to use.
The following information discusses application design considerations that apply to each of the target environments.
To use an Oracle Precompiler application under TSO (by the CALL command or as a command processor), ensure an EXEC SQL COMMIT WORK RELEASE or EXEC SQL ROLLBACK WORK RELEASE statement is run before the program ends
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.
Oracle Access Manager for CICS allows COBOL or C programming language programs running as CICS transactions to access an Oracle9i database server anywhere in your network. Programs can access and update DL/I, VSAM, and Oracle9i data within a single synchronized transaction.
From a CICS perspective, programs accessing Oracle9i databases have no special requirements. The normal CICS SEND and RECEIVE functions are used to communicate with the CICS terminal.
From an Oracle9i perspective, Oracle Precompiler applications running under CICS are no different from other Oracle Precompiler applications. They contain SQL statements that are translated by Oracle Precompilers and passed to the Oracle9i database server as the program runs. When using Pro*C or Pro*COBOL programs in a CICS transaction, however, there are some special considerations.
Oracle9i programs often use the AT clause of the CONNECT statement to specify which server to access.
Your CICS programs can, optionally, synchronize Oracle updates with updates to CICS resources such as VSAM files. When COMMIT(CICS) is specified as the recovery option during configuration of Oracle Access Manager for CICS, Oracle Access Manager for CICS participates in SYNCPOINT processing. You must also use CICS SYNCPOINT functions in your programs instead of Oracle9i COMMIT or ROLLBACK.
If there is more than one explicit connect (i.e., exec sql connect) within the same CICS transaction, a CICS syncpoint is required prior to a second, or subsequent connect statement. This applies whether multiple connect statements are within one program or the program containing a connect statement is given control by a CICS LINK or XCTL within the same CICS transaction.
Programs that use CICS LINK or XCTL commands must specify RELEASE_CURSOR=YES as an Oracle Precompiler option.
Programs that explicitly open cursors must explicitly close them before control is passed to another program with CICS LINK, CICS XCTL, or as a program linked to a CICS RETURN.
Each program targeted to CICS can only communicate with one Oracle Access Manager for CICS and only one server because it can only be linked with one ORACSTUB interface stub. Access to more than one Oracle9i database server from a single CICS region is accomplished 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 CICS program. Then you configure an Oracle Access Manager and a corresponding ORACSTUB interface stub for each distinct server to be accessed. Finally, you link each of the CICS programs with the appropriate ORACSTUB stub.
Programs used with Oracle Access Manager for CICS can only use Oracle data manipulation language (DML) SQL statements. Programs attempting to use data definition language (DDL) or data control language (DCL) statements, such as CREATE TABLE or GRANT, receive an Oracle error code indicating improper use of distributed transaction mechanics.
Oracle Access Manager for IMS TM allows COBOL or C programming language programs running in an IMS MPP, IFP, or BMP region to access an Oracle9i database server anywhere in your network.
From an IMS TM perspective, transaction programs accessing Oracle9i databases have no special requirements. The normal IMS calls for input and output message processing, data access, and synchronization behave as they would if Oracle9i were not in use.
From an Oracle9i perspective, Oracle Precompiler applications running under IMS TM are no different from other Oracle Precompiler applications. They contain SQL statements that are translated by the Oracle Precompilers and passed to the Oracle9i database server as the program runs. When using Pro*C or Pro*COBOL programs in an IMS TM transaction, however, there are some special considerations.
A typical Oracle9i application uses the CONNECT statement to specify which server is to be accessed and to send the server an Oracle user id and password for authentication. With Oracle Access Manager for IMS TM, this information is configured outside of the program in one of the following ways:
The language interface token (LIT) linked with your application designates which Oracle Access Manager for IMS TM instance and which database is to be accessed. The name of this module is determined by your IMS TM system administrator.
The Oracle user id and password, if any, are related to the IMS PSB name for the application.
Each program targeted to IMS TM can normally only communicate with one Oracle Access Manager for IMS TM and only one server because it can only be linked with one LIT. Access to more than one Oracle9i database server from a single IMS TM region can be accomplished 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 accomplish this, you first design your application so that the access logic for each database is contained in a separate IMS TM program. Then you 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.
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 improper use of distributed mechanics.
A typical Oracle9i application might use COMMIT or ROLLBACK statements to control whether database updates are committed or removed. With Oracle Access Manager for IMS TM, these SQL statements 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.
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.
The Oracle Precompiler MODE option lets you specify one of several alternatives to normal Oracle SQL processing behavior. This allows applications to adhere more closely to ANSI/ISO rules. These options work under Oracle Access Manager for IMS TM. For example, if MODE is set to ANSI, then the cursors are closed with each transaction.
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. Which REO to use is decided by the application developer and the IMS administrator. The REO is not specified by or in the application program. It is an Oracle Access Manager for IMS TM configuration parameter.
Oracle Precompilers are normally run in a batch environment but can be run under TSO if the required data sets have been allocated before the precompiler is run.
The following sample JCL illustrates the precompile, compile, and link steps necessary to build a precompiler application program.
|
Note: Unlike previous releases of OS/390 Precompilers, this release relies on and exploits native support for long, mixed-case function names. The object produced will cause the binder to create a PM3 type program object. If this is not appropriate, other methods are available. See Appendix A, "API Short Name Support". |
//PRECOMPL EXEC PGM=pcc_mod, *- Refer to Note 1 -*
// PARM='++/DD/SYSPARM' *- Refer to Note 2 -*
//STEPLIB DD DSN=oran.orav.CMDLOAD,DISP=SHR
//ORA$LIB DD DSN=oran.orav.MESG,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DSN=oran.orav.H,DISP=SHR
// DD DSN=SYS1.SCEEH.H
// DD DSN=SYS1.SCEEH.SYS.H
//PROCFG DD DUMMY *- Refer to Note 12 -*
//SYSIN DD DSN= *- Refer to Note 4 -*,DISP=SHR
//SYSPUNCH DD DSN=&&PCCOUT,DISP=(,PASS,DELETE),
// UNIT=VIO *- Refer to Note 5 -*
//SYSPARM DD *
INAME=/DD/SYSIN
ONAME=/DD/SYSPUNCH
LNAME=/DD/SYSPRINT
/*
//SYSOUT DD SYSOUT=*
//SYSERR DD SYSOUT=*
//SYSUT1 DD UNIT=VIO *- Refer to Note 6 -*
//SYSUT2 DD UNIT=VIO
//SYSUT3 DD UNIT=VIO *- Refer to Note 3 -*
//*
If CICS is the target environment, run the CICS translator compiler here. The input to the CICS translator should be data set "&&PCCOUT" from the precompiler step, and the output should be passed to the host language compiler (next).
//*
Run the Oracle Precompiler program's native language here. The input to the compiler should be data set "&&PCCOUT" from the precompile step (or the output from the CICS translator step if CICS is the target environment).
//*
//LKED EXEC PGM=IEWL,
// PARM='XREF,LET,LIST,DYNAM=DLL'
//SYSPRINT DD SYSOUT=*
//SYSLIB DD DSN=oran.orav.SQLLIB,DISP=SHR
// DD DSN=SYS1.SCEELKED
// DD *- Refer to Note 7 -*
//SYSLMOD DD *- Refer to Note 8 -*
//TEXT DD *- Refer to Note 9 -*
//SYSUT1 DD UNIT=VIO /
//SYSLIN DD *
INCLUDE SYSLIB(stub) *- Refer to Note 10 -*
INCLUDE TEXT
*- Refer to Note 11 -*
/*
The following usage notes apply to the previous JCL example:
This is the name of the Oracle Precompiler load module. There is a different Oracle Precompiler for each supported language. They are:
This PARM keyword shows an example of using parameter redirection. It points to the SYSPARM DD statement, which contains the INAME, ONAME, and LNAME parameters.
Only PROCOB and PROC require this DD statement.
This DD statement points to your Oracle Precompiler program source.
The output from the precompilation process is placed in this data set.
If the ORECLEN parameter is larger than 132, then the DCB attributes must be specified in the SYSUT1 or SYSUT2 DD statements to set the LRECL equal to the ORECLEN value. For example, the following statement sets the LRECL to 200:
//SYSUT1 DD UNIT=VIO,DCB=(LRECL=200)
Include additional libraries required by your program and any runtime libraries required by the native language.
This DD statement describes the library in which your linkedited Oracle load module is placed.
This DD statement points to the object output from your Oracle Precompiler program's native language compiler.
The specific contents of the SYSLIN DD statement depend on the target environment. Refer to "Linking Your Program" on page 7-13 for more information.
Include any additional linkage editor statements you might require.
Only PROCOB requires this DD statement.
The following sections discuss precompiling your program using Oracle Precompilers.
Because there are many possible options for the Oracle Precompilers, you might find it impossible to fit all the options you need in the 100 bytes OS/390 allows for parameters initially passed to user programs (for example, from JCL or under TSO). You can use the following methods to pass more than 100 bytes of precompiler options to an Oracle Precompiler interface:
Use the Oracle Precompiler EXEC ORACLE OPTION statement in your source program to specify some of the parameters. This is a good way to specify options that do not change for each compile. Refer to the appropriate Oracle Precompiler manual for information on the EXEC ORACLE OPTION statement.
Use a parameter redirection operator to direct the Oracle Precompiler to retrieve parameters from an OS/390 file in addition to the OS/390 parameter field. Refer to Chapter 3, " Oracle9i Utilities and OS/390 Files" for more information about parameter redirection.
When running under OS/390, some of the Oracle Precompiler options require special attention:
| INAME |
specifies the input data set containing the source code, in any supported language, for the precompiler. Refer to Chapter 3, " Oracle9i Utilities and OS/390 Files" for a description of how to specify OS/390 data set names to the Oracle9i database server. Typically, this operand is coded as shown in the following example with a SYSIN DD statement pointing to the input source code:
INAME=/DD/SYSIN |
| ONAME |
specifies the data set to contain the output from the Oracle Precompiler. Refer to Chapter 3, " Oracle9i Utilities and OS/390 Files" for rules on specifying OS/390 data set names to the Oracle9i database server. Typically, this operand is coded as shown in the following example with a SYSPUNCH DD statement pointing to a data set that is passed as input to the native language compiler:
ONAME=/DD/SYSPUNCH |
| LNAME |
specifies the data set to contain the listing from the Oracle Precompiler. Typically, this operand is coded as shown in the following example with a SYSPRINT DD statement pointing to a SYSOUT data set:
LNAME=/DD/SYSPRINT |
| CONFIG |
Pro*C and Pro*COBOL now support system configuration files, pointed to by PROCFG DD. Additionally, an overriding configuration file can be specified in SYPARM by /DD/CONFIG. The methods previously in place for specifying Oracle Precompilers option can also be used.
For example: PARM='++/DD/ddname option1 option1 ...' When specifying Oracle Precompiler options, separate each option with one or more blanks. Do not use a comma as a separator. If you use a data set to pass options to an Oracle Precompiler, then the data set must not have sequence numbers. If sequence numbers are found, then the Oracle Precompiler stops processing. To specify a fully-qualified data set name in an Oracle Precompiler option, use the /DSN/ or /DD/ specifications. Do not use a quoted data set name. |
The Oracle Precompiler utility sets a return code of 0 upon successful precompilation of source code. A return code of 8 is set if the precompiler detects an irrecoverable error condition. In this case, an error message is written to the data set specified in the LNAME parameter passed to the Oracle Precompiler.
The following sections discuss certain considerations that impact Oracle Precompiler programs written in a particular language, regardless of the target environment running the program.
Refer to Chapter 2 of the Oracle9i Enterprise Edition Installation Guide for OS/390 for specific compilers supported with each precompiler.
When using Pro*COBOL, each of the following have special considerations:
RETURN-CODE special register
INTEGER values
Compiler support
MAXLITERAL option
DYNAM compiler option
OS/390 COBOL programs use the RETURN-CODE special register to pass a return code from a main program back to OS/390. It is then used to form the job step completion code. The OS/390 standard subroutine linkage places unpredictable values into the RETURN-CODE special register as a subroutine is called. OS/390 subprograms can set the value of the RETURN-CODE special register as they exit. However, the RETURN-CODE special register is an IBM extension to the COBOL language and is not part of the SQL standard.
In compliance with the SQL standard, Oracle Pro*COBOL does not make use of the RETURN-CODE special register and does not explicitly set the value. This causes the value of the RETURN-CODE special register to be unpredictable after each SQL statement completes. If a SQL statement is issued immediately before the main program returns to OS/390, then the unpredictable value remains in the RETURN-CODE special register and is used to form the job step completion code. You are responsible for ensuring the correctness of the RETURN-CODE special register.
In the generic Oracle documentation, SQL library function parameters are often documented with a data type of INTEGER. In OS/390, integers are a fullword and must be defined in COBOL as S9(8) COMP fields. An S9(4) definition generates a halfword that is the default integer size on some operating systems. This can cause problems when migrating applications from other operating systems to OS/390. For example, a call to SQLIEM expects an integer MESSAGE_LENGTH as the second parameter. Define a MESSAGE_LENGTH field as PIC S9(8) COMP in your program. A call to SQLGLM expects the second and third parameters, BUFFER_SIZE and MESSAGE_LENGTH respectively, to be integers. As with SQLIEM, they must be defined as PIC S9(8) COMP fields.
The default value of the MAXLITERAL Oracle Precompiler option is 120. If you supply a MAXLITERAL value, then it is rounded down to the next full word boundary (for example, 50 to 48).
The Oracle Precompiler interface stub must be statically linked with your application. Therefore, the COBOL compiler DYNAM option must not be used with Pro*COBOL programs. You can dynamically call your own subroutines by using the CALL identifier form of the COBOL CALL statement. Refer to the appropriate compiler documentation for more information.
The native language output from the Pro*PL/1 Precompiler that is directed to the data set specified in the ONAME parameter cannot have a RECFM of V. This is because an OS/390 compiler restriction requires all PL/I programs contained on a variable length data set have a blank or a sequence number in columns 1 to 8. This restriction does not apply to the data set input to PROPLI, only to the intermediate data set passed to the PL/I compiler.
After your program has been precompiled, the resulting source file is passed to the host language compiler.
You must run the Oracle Precompiler program first and pass the output to the CICS translator to translate the CICS commands. Otherwise, the CICS translator issues warning messages for each EXEC SQL statement that is encountered. Refer to the machine-readable samples in the SRCLIB library for the JCL used to process COBOL or C programming language programs.
After your program has been compiled, the resulting object code is passed to the linkage editor where it is linked with the Oracle Precompiler interface stub. Each target environment has a unique stub and different linking considerations apply to each of the target environments. In all cases the interface stub must be linked directly to your load module. Dynamic loading techniques (for example, the COBOL dynamic call mechanism) cannot be used with the interface stub.
When linking a program to run in batch or TSO, add the following linkage editor control statement to the SYSLIN DD statement:
INCLUDE SYSLIB(ORASTBL)
If there are unresolved external references for symbols whose names begin with SQL, then ensure ORASTBL is included in the linkedit. This stub resolves any calls in the generated code. If ORASTBL is correctly included, then the problem is probably caused by a missing entry point to the stub routine. You can contact Oracle Support Services for additional assistance.
When linking a program to run under CICS, add the following linkage editor control statement to the SYSLIN DD statement:
INCLUDE SQLLIB(ORACSTUB)
Do not include references for ORASTBL or AMILS.
AMODE must be set to 31. There are no special requirements for RMODE.
If there are any unresolved external references for symbols whose names start with SQL, then ensure ORACSTUB is included in the linkedit. This stub resolves any calls in the generated code. If ORACSTUB is correctly included, then the problem is caused by a missing entry point in the stub routine. You can contact Oracle Support Services for additional assistance.
When linking a program to run under IMS TM, add the following linkage editor control statements to the SYSLIN DD statement:
INCLUDE SYSLIB(AMILS) INCLUDE SYSLIB(lit-module)
The lit-module statement is the customer-generated language interface module described later in this chapter. The IMS TM system administrator generates and names the lit-module according to installation standards.
Do not include references to ORASTBL or ORACSTUB.
If there are unresolved external references for symbols whose names begin with SQL, then ensure AMILS is included in the linkedit. This stub resolves any calls in the generated 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.
After your program has been linked, the resulting load module is run in the target environment. As your program runs, it passes SQL statements to the SQL interface stub that is linked with it. The interface stub contains logic to dynamically locate the full Oracle SQL interface for the target environment and 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. These are discussed in the following sections:
Pro*C, PRO*COB, and PROCOB18 are supported in the UNIX System Services environment. Refer to Chapter 4, " Accessing Oracle9i Under USS", for more information.
Pro*COB parses the input files, and must know the include pathname to find all the include files. The Pro*COB command line must have each nonstandard include pathname specified. For example:
$procob iname=xyz.pco include=/home/jones/copybooks oname=xyz.cbl $/usr/lpp/cobol/bin/cob2 -c xyz.cbl
You can build your own Pro*COB programs with demo_procob.mk. For example, to precompile, compile, and link the userprog.pco program, enter:
$ make -f $ORACLE_HOME/precomp/demo/proc/demo_proc.mk userprog
Users must change makefiles or scripts that call proc. The proc command line must have each nonstandard include pathname specified. For example:
Please note that the sample programs require that you run a SQL script to create the various tables and packages required by the precompiler. You must run the SQL scripts in the precomp/demo/sql directory for the following sample programs in precomp/demo/:
lobdemo1.pco
To build one of the sample PRO*COB programs, cd to the precomp/demo/proc directory and issue the following make command:
make -f demo_proc.mk sample1
To build all of the sample PRO*COB programs, cd to the precomp/demo/proc directory and issue the following make command:
make -f demo_proc.mk samples
|
Note: If your program depends on non-Oracle libraries, you may have to alterdemo_procob.mk to include them.
|
Pro*C is upwardly compatible for all Pro*C programs written in C. (Pro*C does not support C++ programs.) Pro*C parses the input files, and must know the include pathname to find all the include files.
Users must change makefiles or scripts that call proc. The proc command line must have each nonstandard include pathname specified. For example:
$proc iname=xyz.pc include=/home/jones/include $c89 -r/home/jones/include xyz.c
You can build your own Pro*C programs with demo_proc.mk. For example, to precompile, compile, and link the userprog.pc program, enter:
$ make -f $ORACLE_HOME/precomp/demo/proc/demo_proc.mk userprog
|
Note: If your program depends on non-Oracle libraries, you may have to alterdemo_proc.mk to include them.
|
Please note that the sample programs require that you run a SQL script to create the various tables and packages required by the precompiler. You must run the SQL scripts in the precomp/demo/sql directory for the following sample programs in precomp/demo/:
sample11 cv_demo ansidyn1 coldemo1 lobdemo1 objdemo1 navdemo1 cppdemo2
To build one of the sample PRO*C programs, cd to the precomp/demo/proc directory and issue the following make command:
make -f demo_proc.mk sample1
To build all of the sample PRO*C programs, cd to the precomp/demo/proc directory and issue the following make command:
make -f demo_proc.mk samples
To build one of the C++ sample PRO*C programs, cd to the precomp/demo/proc directory and issue the following make command:
make -f demo_proc.mk cppdemo1
To build all of the C++ sample PRO*C programs, cd to the precomp/demo/proc directory and issue the following make command:
make -f demo_proc.mk cppsamples
To build one of the Object sample PRO*C programs, cd to the precomp/demo/proc directory and issue the following make command:
make -f demo_proc.mk coldemo1
To build all of the Object sample PRO*C programs, cd to the precomp/demo/proc directory and issue the following make command:
make -f demo_proc.mk object_samples
As your batch or TSO program runs, it must have access to several load modules contained in the oran.orav.CMDLOAD library and all modules in the oran.orav.MESG library. This includes the following modules:
Your programs can access these modules in the following ways:
Add a JOBLIB or STEPLIB statement to your JCL and point to the oran.orav.CMDLOAD library.
Add an ORA$LIB statement to your JCL and point to the library, oran.orav.MESG. Message modules will be accessed from here.
Your Oracle system administrator might place an oran.orav.CMDLOAD library in the system LINKLIST or he might place various modules in the PLPA or EPLPA. If this is the case, then you might have other directions for writing your JCL.
|
Note: One common option you can use is to put CMDLOAD data set in STEPLIB and MESG data set in ORA$LIB. |
If your program receives OS/390 message IEA703I, then this is an indication that one of the required modules cannot be located. IEA703I is accompanied by error codes 106-n, 306-n, or 806-n. Refer to the IBM OS/390 System Codes manual to determine why LIBCLNTS cannot be located and correct the problem.
Normal CICS practices for defining your program to CICS are followed for Oracle Precompiler programs. CICS programs access a shared copy of the full SQL interface (called the CICS adapter) that must be configured and available before your program begins running. If the adapter is not available, then you receive error AEY9 from CICS. You need to contact your CICS system administrator to have this condition corrected.
Normal IMS TM practices for defining your program to IMS TM are followed for Oracle Precompiler programs. IMS TM programs access a shared copy of the full SQL interface that must be configured and available before your program begins running. If the interface is not available, then you receive error 3042 from IMS TM. You must contact your IMS TM system administrator to have this condition corrected.
|
 Copyright © 2002 Oracle Corporation All rights reserved |
|