The content of a PGAU-generated TIP reflects the calls available to the remote host transaction and the data that has been exchanged. Understanding this content helps when designing and debugging client applications that call the TIP.

A TIP is a PL/SQL package, and accordingly has two sections:

• A Package Specification containing:

  • Public function prototypes and parameters

• A Package Body containing:

  • Private functions and internal control variables

  • Public functions

  • Package initialization following the last public function

The purpose of the TIP is to provide a PL/SQL callable public function for every allowed remote transaction program interaction. A remote transaction program interaction is a logically related group of data exchanges through one or more PGAXFER RPC calls. This is conceptually similar to a screen or menu interaction in which several fields are filled in, the enter key is pressed, and several fields are returned to the user. Carrying the analogy further:

• the user might be likened to the TIP or client application

• fields to be filled in are IN parameters on the TIP function call

• fields returned are OUT parameters on the TIP function call

• screen or menu is the group of IN and OUT parameters combined

• a pressed enter key is likened to the PGAXFER remote procedural call (RPC)

The actual grouping of parameters that constitute a transaction call is defined by the user. The gateway places no restrictions on how a remote transaction program might correspond to a collection of TIP function calls, each call having many IN and OUT parameters.

PGA users typically have one TIP per remote transaction program. How the TIP function calls are grouped and what data parameters are exchanged on each call depends on the size, complexity and behavior of the remote transaction program.

Refer to Oracle's Oracle Database PL/SQL Language Reference for a discussion of how PL/SQL packages work. The following discussion covers the logic that must be performed within a TIP. Refer to the sample TIP and driver supplied in the %ORACLE_HOME%\dg4appc\demo\IMS directory on Microsoft Windows and in $ORACLE_HOME/dg4appc/demo/IMS directory on UNIX based systems, in files pgtflip.pkh, pgtflip.pkb, and pgtflipd.sql.

From a database gateway application perspective, there are three main types of remote host transactions:

• transaction socket

• persistent socket

• non-persistent socket

You should be familiar with the remote host transaction types. Refer to the IBM IMS Connect Guide and Reference for a full description of these transaction types.

Using data definitions programmed in the language of the remote host transaction, the PGAU DEFINE DATA command stores in the PG DD the information needed for PGAU GENERATE to create the TIP function logic to perform:

• all data conversion from PL/SQL IN parameters supplied by the receiving remote host transaction

• all buffering into the format expected by the receiving remote host transaction

• all data unbuffering from the format supplied by the sending remote host transaction

• all data conversion to PL/SQL OUT parameters supplied by the sending remote host transaction

PGAU determines the information needed to generate the conversion and buffering logic from the data definitions included in the remote host transaction program. PGAU DEFINE DATA reads this information from files, such as COBOL copy books, or in-stream from scripts and saves it in the PG DD for repeated use. The Gateway Administrator needs to transfer these definition files from the remote host to the Oracle host where PGAU runs.

From the data definitions stored in the PG DD, PGAU GENERATE determines the remote host datatype and matches it to an appropriate PL/SQL datatype. It also determines data lengths and offsets within records and buffers and generates the needed PL/SQL logic into the TIP. Refer to the PGAU "DEFINE DATA" statement in Procedural Gateway Administration Utility and "Sample PGAU DEFINE DATA Statements" in Administration Utility Samples for more information.

All data that are referenced as parameters by subsequent calls must first be defined using PGAU DEFINE DATA. Simple data items, such as single numbers or character strings, and complex multi-field data aggregates, such as records or structures, can be defined. PGAU automatically generates equivalent PL/SQL variables and records of fields or tables for the client application to reference in its calls to the generated TIP.

As discussed, a parameter might be a simple data item, such as an employee number, or a complex item, such as an employee record. PGAU DEFINE DATA automatically extracts the datatype information it needs from the input program data definition files.

In this example, FLIPIN and FLIPOUT are the arguments to be exchanged.

PGTFLIP_MAIN(trannum,FLIPIN,FLIPOUT)

A PGAU DEFINE DATA statement must therefore be issued for each of these parameters:

DEFINE DATA FLIPIN
       PLSDNAME (FLIPIN)
       USAGE (PASS)
       LANGUAGE (IBMVSCOBOLII)
       (
       01 MSGIN PIC X(20).
       ); 

DEFINE DATA FLIPOUT
       PLSDNAME (flipout)
       USAGE (PASS)
       LANGUAGE (IBMVSCOBOLII)
       (
       01 MSGOUT PIC X(20).
       );

Note that a definition is not required for the trannum argument. This is the APPC conversation identifier and does not require a definition in PGAU.

The requirement to synchronize TCP/IP send() and receive() means that when the remote transaction program expects data parameters to be input, it issues TCP/IP receive() to read the data parameters. Accordingly, the TIP must cause the gateway to issue TCP/IP send() to write the data parameters to the remote transaction program. The TIP must also cause the gateway to issue TCP/IP receive() when the remote transaction program issues TCP/IP send().

The PGAU DEFINE CALL statement specifies how the generated TIP is to be called by the client application and which data parameters are to be exchanged with the remote host transaction for that call. Each PGAU DEFINE CALL statement might specify the name of the TIP function, one or more data parameters, and the IN/OUT mode of each data parameter. Data parameters must have been previously defined with PGAU DEFINE DATA statements. Refer to "DEFINE CALL" in Procedural Gateway Administration Utility and "Sample PGAU DEFINE CALL Statements" in Administration Utility Samples for more information.

PGAU DEFINE CALL processing stores the specified information in the PG DD for later use by PGAU GENERATE. PGAU GENERATE then creates the following in the TIP package specification:

• declarations of public PL/SQL functions for each CALL defined with PL/SQL parameters for each DATA definition specified on the CALL

• declarations of the public PL/SQL data parameters

The client application calls the TIP public function as a PL/SQL function call, using the function name and parameter list specified in the PGAU DEFINE CALL statement. The client application might also declare, by reference, private variables of the same datatype as the TIP public data parameters to facilitate data passing and handling within the client application, thus sharing the declarations created by PGAU GENERATE.

In this example, the following PGAU DEFINE CALL statement must be issued to define the TIP public function:

DEFINE CALL FLIPMAIN
       PKGCALL (pgtflip_main)
       PARMS ((FLIPIN IN),(FLIPOUT OUT));

The remote host transaction is defined with the PGAU DEFINE TRANSACTION statement with additional references to prior definitions of CALLs that the transaction supports.

You specify the remote host transaction attributes, such as:

• transaction ID or name

• network address or location

• system type (such as IBM370)

• Oracle National Language of the remote host

  Note:

  The PL/SQL package name is specified when the transaction is defined; this is the name by which the TIP is referenced and which the public function calls to be included within the TIP. Each public function must have been previously defined with a PGAU DEFINE CALL statement, which has been stored in the PG DD. If you do not specify a package name (TIP name) in the GENERATE statement, the transaction name you specified will become the package name by default. In that case, the transaction name (tname) must be unique and must be in valid PL/SQL syntax within the database containing the PL/SQL packages.

  For more information, refer to "DEFINE TRANSACTION" in Procedural Gateway Administration Utility and "Sample PGAU DEFINE TRANSACTION Statement" in Administration Utility Samples.

In this example, the following DEFINE TRANSACTION statement is used to match this information with the inserted row in the PGA_TCP_IMSC table.

DEFINE TRANSACTION IMSFLIP
   CALL (FLIPMAIN)
   SIDEPROFILE(PGATCP)
   TPNAME(FLIP)
   NLS_LANGUAGE("american_america.us7ascii");

The user declarations section of the tipname.doc file documents the required declarations.

When passing PL/SQL parameters on calls to TIP functions, the client application must use the exact same PL/SQL data types for TIP function arguments as are defined by the TIP in its specification section. Assume, for example, the following is in the TIP specification, or tipname.doc:

FUNCTION tip_call1    tranuse,   IN      BINARY_INTEGER, 
                      tip_var1   io_mode pls_type1, 
                      tip_record io_mode tran_rectype) 
RETURN INTEGER;

TYPE  tran_rectype is RECORD
      (rec_field1 pls_type1,
      ...
      rec_fieldN pls_typeN);

Where Table 7-2 provides a description of each of the parameters:

In the client application PL/SQL atomic data types should be defined as the exact same data type of their corresponding arguments in the TIP function definition. The following should be coded in the client application before the BEGIN command:

appl_var  pls_type1;    /* declare appl variable for ....  */

You do not need to redefine TIP data types. They must be declared locally within the client application, appearing in the client application before the BEGIN:

appl_record tipname.tran_rectype;  /* declare appl record */

Table 7-3 describes the meaning of each procedure declaration:

Refer to the tipname.doc content file for a complete description of the user declarations you can reference.

The client application calls the TIP public function as if it were any local PL/SQL function:

rc = tip_call1( tranuse,
                appl_var,
                appl_record);

In the TCP/IP IMS Connect example, the PL/SQL driver pgtflipd.sql, which is located in %ORACLE_HOME%\dg4appc\demo\IMS directory on Microsoft Windows and in $ORACLE_HOME/dg4appc/demo/IMS directory on UNIX based systems, is the client application and includes the following declaration:

...
...
CREATE or REPLACE PROCEDURE pgtflipd(mesgin IN CHAR) IS
trannum INTEGER :=0               /* transaction usage number     */
mesgout VARCHAR2(254);            /* the output parameter       */
rc INTEGER :=0                    /* PGA RPC return codes         */
term INTEGER :=0;                 /* 1 if pgtflip_term called     */
...
...

The call to initialize the conversation serves several purposes:

• To cause the PL/SQL package, the TIP, to be loaded and to perform the initialization logic programmed in the TIP initialization section.

• To cause the TIP init function to call the PGAINIT remote procedural call (RPC), which in turn establishes communication with the remote transaction program (RTP), and returns a transaction instance number to the application.

Optionally, calls to initialize the conversation can be used to:

• Override default RHT/OLTP identification, network address attributes, and conversation security user ID and password.

• Specify what diagnostic traces the TIP is to produce. Refer to Troubleshooting for more information about diagnostic traces.

PGAU-generated TIPs provide four different initialization functions that client applications can call. These are overloaded functions which all have the same name, but vary in the types of parameters passed.

Three initialization parameters are passed:

• The transaction instance number for RHT socket file descriptor. The tranuse parameter is required on all TIP initializations.

• TIP diagnostic flags for TIP runtime diagnostic controls. The tipdiag parameter is optional. Refer to Troubleshooting for a discussion of TIP diagnostics.

• TIP default overrides for overriding OLTP and network attributes. The override parameter is optional.

The following four functions are shown as they might appear in the TIP Content documentation file. Examples of client application use are provided later.

TYPE override_Typ IS RECORD (
        tranname  VARCHAR2(2000),  /* Transaction Program     */
        transync  BINARY_INTEGER, /* RESERVED                */
        trannls   VARCHAR2(50),   /* RESERVED                */
        oltpname  VARCHAR2(2000),  /* Logical Unit            */
        oltpmode  VARCHAR2(2000),  /* LOG Mode Entry          */
        netaddr   VARCHAR2(2000),  /* Side Profile            */
        tracetag  VARCHAR2(2000),    /* gateway trace idtag  */
        
FUNCTION pgtflip_init(                /* init standard */
           tranuse IN OUT BINARY_INTEGER)
           RETURN INTEGER;

FUNCTION pgtflip_init(                /* init override */
           tranuse IN OUT BINARY_INTEGER,
           override IN override_Typ)
           RETURN INTEGER;

FUNCTION pgtflip_init(               /* init diagnostic */
           tranuse IN OUT BNARY_INTEGER,
           tipdiag IN CHAR)
           RETURN INTEGER;

FUNCTION pgtflip_init(                /* init over-diag */
           tranuse IN OUT BINARY_INTEGER,
           override IN override_Typ,
           tipdiag IN CHAR)
           RETURN INTEGER;

The client application calls the TIP termination function as if it were any local PL/SQL function. For example:

...
...
term := 1;    /* indicate term called */
 rc := pgtflip.pgtflip_term(trannum,0); /* terminate normally  */
...
...

After a transaction instance number has been passed on a TIP terminate call to terminate the transaction, or after the remote transaction program has abended, that particular transaction instance number might be forgotten.

The client application should include an exception handler that can clean up any active TCP/IP conversations before the client application terminates. The sample client application provided in pgtflipd.sql contains an example of exception handling.

Gateway exceptions are reported in the range PGA-20900 to PGA-20999 and PGA-22000 to PGA 22099. When an exception occurs, the TIP termination function should be called for any active conversations that have been started by prior calls to the TIP initialization function.

For example:

EXCEPTION
 WHEN OTHERS THEN
  IF term = 0 THEN         /* terminate function not called yet */
   rc := pgtflip.pgtflip_term(trannum,1); /*terminate abnormally*/
  END IF;
 RAISE;

The remote transaction should also include provisions for error handling and debugging, such as writing debugging information to the IMS temporary storage queue area. Refer to the Oracle Database PL/SQL Language Reference for a discussion of how to intercept and handle Oracle exceptions.