One of the major benefits of using Connect TPS to connect dissimilar systems is the degree to which different programming environments can be isolated. BEA TUXEDO programmers rarely need to know that services are handled by dissimilar systems or by systems in remote regions. Application programs do not need to be developed in any special way.
The key to this high degree of transparency is the Connect TPS configuration. It is through this mechanism that environmental differences, such as naming conventions and data formats, are concealed from programmers and programs.
There are three kinds of environmental differences that are isolated in the Connect TPS configuration file (TPSINIT):
The technique that is used to hide these differences is called mapping. Generally speaking, when you map things, you associate local values or entities with values or entities that are meaningful to programs on remote systems.
The procedure for mapping service names is self-explanatory; you create a configuration file record in which a local name for a service is paired with a remote name for that service. On the other hand, procedures for mapping input data, output data, and application errors are more complex. Conceptual information and other background information is required.
In addition to providing installation instructions, this chapter explains how Connect TPS performs the following tasks:
In addition, this chapter provides information about creating VIEW definitions. VIEW definitions are descriptions of data structures that are used for input and output in the BEA TUXEDO environment. Connect TPS uses VIEW definitions to determine how to convert input data and output data into formats that are acceptable to target systems.
For detailed information about updating the Connect TPS configuration file (TPSINIT), see Chapter 4, "Configuring BEA Connect TPS".
Note:
All Connect TPS configuration parameters are described in Chapter 4, "Configuring BEA Connect TPS". This chapter focuses on complex parameters that require a separate introduction.
The installation procedure for BEA Connect TPS is slightly different for each platform on which the software can be installed. Please follow the directions for the appropriate platform.
To install BEA Connect TPS on any UNIX platform use the "install.sh" script on the CD ROM. To run the script, complete the following steps:
How to Install BEA Connect TPS
Installing BEA Connect TPS on UNIX
To install BEA Connect TCP for IMS, please refer to the installation instructions in the BEA Connect TCP for IMS User Guide. To install BEA Connect TCP for CICS, please refer to the installation instructions in the BEA Connect TCP for CICS User Guide.
To install BEA Connect TPS on Windows NT, complete the following steps.
This subsection introduces procedures that Connect TPS follows to process and convert input and output data.
In this guide, the following terms are used to describe input and output data:
Buffer
Record
These terms make it easier to understand how Connect TPS handles input and output data.
When Connect TPS receives a buffer from a local program, it automatically determines the buffer's type.
If the configuration indicates that conversion is required, Connect TPS transforms the buffer into the record format that is specified in the configuration.
When Connect TPS receives a record from a remote system, it consults the configuration (TPSINIT) to determine the record's type.
After Connect TPS determines a record's type, it consults the configuration (TPSINIT) to determine whether or not the record needs to be converted to a different format.
Records Received from Remote Programs
If the configuration indicates that conversion is required, Connect TPS transforms the record into the buffer format that is specified in the configuration.
Connect TPS provides four configuration parameters you can use to map buffers and records. See subsection "Buffers and Records" on page 3-4 for a discussion of buffers and records. These include:
Configuration Parameters for Managing Conversion
Each of these four parameters has two possible meanings or interpretations-one for service requests that originate locally, and one for service requests that originate on remote systems.
The next two subsections ("Parameters for Locally Originated Calls" and "Parameters for Remotely Originated Calls") explore these different meanings in detail.
This subsection takes a closer look at how Connect TPS handles service calls that originate locally, within the immediate BEA TUXEDO region. Also, it explains how the INBUFTYPE, INRECTYPE, OUTRECTYPE, and OUTBUFTYPE parameters can be used to manage the conversion of buffers and records that flow between local client programs and remote services.
In Figure 3-1, a local BEA TUXEDO client program issues a service call that a local Connect TPS Requester (TPSR) routes to a remote server through Connect TPS.
In this situation, the four configuration parameters that are shown in the figure have the following meanings:
Parameters for Locally Originated Calls
Figure 3-1 How Parameters are Mapped during Locally Originated Calls
Here is some detailed information that will help you understand how to use the INBUFTYPE and INRECTYPE parameters for service calls that originate locally (where local client programs call remote services).
The INBUFTYPE parameter is used to specify the buffer type that is provided to a local Connect TPS Requester (TPSR) when a local client program issues a service request.
Because the Requester determines the type of incoming buffers automatically at run time, this parameter is described here for conceptual completeness only. In the Connect TPS configuration, it is used only by the Handlers (TPSH).
The INRECTYPE parameter is used to specify the type, and in some cases the format, of the input record that a particular remote service requires. Connect TPS uses this information to convert BEA TUXEDO input buffers into records that remote services can process.
You must specify the INRECTYPE parameter when one of the circumstances described in Table 3-1 is true:
The INRECTYPE parameter may be omitted if the input buffer is identical, in type and structure, to the record the remote service expects.
Here is some detailed information that will help you understand how to use the OUTRECTYPE and OUTBUFTYPE parameters for service calls that originate locally (where local client programs call remote services and receive output from those services).
The OUTRECTYPE parameter is used to specify the type, and in some cases the format, of the output record that a particular remote service returns to the local Connect TPS Requester (TPSR).
The OUTBUFTYPE parameter is used to specify the type, and in some cases the structure, of the output buffer that a local client program expects. Connect TPS uses this information to map output records from remote services to the appropriate kinds of output buffers.
You must specify the OUTBUFTYPE parameter when one of the circumstances described in Table 3-2 is true:
The OUTBUFTYPE parameter may be omitted if the remote service returns an output record that is identical, in type and structure, to the output buffer the local client program expects.
This subsection takes a closer look at how Connect TPS handles service calls that originate on remote computers, outside the local BEA TUXEDO region. Also, it explains how the INRECTYPE, INBUFTYPE, OUTBUFTYPE, and OUTRECTYPE parameters can be used to manage the conversion of buffers and records that flow between remote client programs and local services.
In subsection "Parameters for Locally Originated Calls," a remote client program issues a service request that a remote Connect TPS gateway (or equivalent software) routes to the local Connect TPS gateway. A Handler process (TPSH) that was previously started by the Connect TPS Liaison (TPSL) receives the request from the network and passes the request to a local BEA TUXEDO server.
In this situation, the four configuration parameters that are shown in the figure have the following meanings:
Guidelines for Mapping Input Buffers to Input Records
The INBUFTYPE Parameter
The INRECTYPE Parameter
Guidelines for Mapping Output Records to Output Buffers
The OUTRECTYPE Parameter
The OUTBUFTYPE Parameter
Parameters for Remotely Originated Calls
Figure 3-2 How Parameters are Mapped during Remotely Originated Calls
Here is some detailed information that will help you understand how to use the INRECTYPE and INBUFTYPE parameters for service calls that originate on remote systems (where remote client programs call local services).
The INRECTYPE parameter is used to specify the type, and in some cases the format, of the input record that a particular remote client program sends to a local Connect TPS Handler.
The INBUFTYPE parameter is used to specify the type, and in some cases the structure, of the input buffer that a local service expects. Connect TPS uses this information to map input records from remote client programs to the appropriate kinds of input buffers.
You must specify the INBUFTYPE parameter when one of the circumstances described in Table 3-3 is true:
You can omit the INBUFTYPE parameter if the remote client program sends an input record that is identical in type and structure to the input buffer the local service expects.
Here is some detailed information that will help you understand how to use the OUTBUFTYPE and OUTRECTYPE parameters for service calls that originate on remote computers (where remote client programs call local services and receive output from those services).
The OUTBUFTYPE parameter specifies the buffer type that is provided to the local Connect TPS Handler (TPSH) after the local server completes its work.
Because the Handler determines the type of incoming buffers automatically at run time, this parameter is described here for conceptual completeness only. In the Connect TPS configuration, it is used only by Requesters (TPSR).
The OUTRECTYPE parameter is used to specify the type, and in some cases the format, of the output record a particular remote client program requires. Connect TPS uses this information to convert output buffers from local services into records that remote client programs can process.
You must specify the OUTRECTYPE parameter when one of the circumstances described in Table 3-4 is true:
The OUTRECTYPE parameter may be omitted if the local service's output buffer is identical, in type and structure, to the record the remote client program expects.
This section provides guidelines for setting configuration parameters.
Figure 3-3 shows all the possibilities for mapping input buffers to input records:
As Figure 3-3 shows, Connect TPS Requester is responsible for mapping input buffers to input records, based on information it finds in the Connect TPS configuration.
Here are some comments about the mapping possibilities that are shown in Figure 3-3 and some suggestions for setting the INBUFTYPE and INRECTYPE parameters. Guidelines for Mapping Input Records to Input Buffers
The INRECTYPE Parameter
The INBUFTYPE Parameter
Guidelines for Mapping Output Buffers to Output Records
The OUTBUFTYPE Parameter
The OUTRECTYPE Parameter
Guidelines for Setting Parameters
Mapping Input Buffers to Input Records
Figure 3-3 Input Mappings
Setting the INBUFTYPE and INRECTYPE Parameters
Figure 3-4 shows all the possibilities for mapping output records to output buffers:
Figure 3-4 Output Mappings
As Figure 3-4 shows the Connect TPS Requester is responsible for mapping output records to output buffers, based on information it finds in the Connect TPS configuration.
Here are some comments about the mapping possibilities that are shown in Figure 3-4 and some suggestions for setting the OUTRECTYPE and OUTBUFTYPE parameters (for service calls that originate locally).
The following subsections
Read this information carefully before you create VIEW definitions (to facilitate buffer conversion) and configure Connect TPS.
When a local client program sends data to (or receives data from) a service routine on a different kind of computer, Connect TPS automatically translates data as required.
Translation involves changing the representation of intrinsic data types by changing attributes such as
Introduction
Connect TPS automatically translates input and output data as required, following rules that are described in this subsection.
Here are the data translation rules that Connect TPS follows:
Data Translation Rules
Warning:
dec_t cannot be used with VIEW translations.
Note:
BEA TUXEDO provides a field type named dec_t that supports decimal values within VIEWs. Connect TPS translates these fields into machine independent representations of packed decimals. For example, dec_t(m,n) becomes S9(2*m-(n+1))V9(n) COMP-3. Therefore, a decimal field with a size of 8,5 corresponds to S9(10)V9(5) COMP-3.
Table 3-5 summarizes the relationships.
This subsection
Strings and Numeric Data: A Closer Look
When you create VIEW definitions for input and output buffers that are used by C language applications, you must specify extra characters for terminating NULL characters that are used in string fields.
For example, when a local application program expects a 10-byte string in an output buffer, you would specify 11 for that field-10 for the string plus 1 for the terminating NULL character.
When you create VIEW definitions for input and output buffers that are used by COBOL language applications, do not specify extra characters for terminating NULL characters that are used in string fields.
For example, when a remote COBOL application program expects 10 characters in an input record, you would specify 10 for that field, not 10 plus 1 (for the terminating NULL character).
Note:
Although Connect TPS does not require strings to be NULL-terminated, it respects NULL termination. Therefore, when Connect TPS detects a NULL (zero) character within a string, it does not process any subsequent characters. To pass full 8-bit data that contains embedded NULL values, use a CARRAY type field or buffer.
The character set translations performed by BEA Connect TPS are fully localizable, in accordance with the X/Open XPG Portability Guides. ASCII and EBCDIC translations are loadable from message files based on the locale subdirectory and the LANG environment variable. Connect TPS contains default behaviors for translation, one for ASCII and one for EBCDIC. There are two message catalogs, TPS-ASC_CAT for ASCII and TPS-EBC_CAT for EBCDIC respectively. The text for each is in TPS-ASC.text and TPS-EBC.text. These mapping table files should meet the requirements of most English-language applications. However, you may find it necessary to customize tables. See Appendix B, "Customizing Character Set Mapping Tables," for complete instructions.
Numeric data can easily be converted into different data types, provided that you have enough range in the intermediate and destination types to handle the maximum value you need to represent.
For example, you can convert numeric values into strings (and the reverse). For example, while FML buffers do not directly support the dec_t type, you can place decimal values in string fields and map these to dec_t fields within VIEW definitions.
This subsection will provide information about error handling. It will:
NULL Characters in String Length Calculations (C Programs)
NULL Characters in String Length Calculations (COBOL Programs)
Converting Numeric Data
How the Connect TPS Configuration Helps with Error Handling
Read this information carefully before you configure Connect TPS.
There are several ways that local client programs can learn about application errors that occur on remote systems. For example:
Introduction
This makes it possible to centralize error detection and reporting and frees client programs from the burden of knowing too much about remote application programs.
Connect TPS provides several configuration parameters that help you manage application errors. These are introduced in Table 3-6:
See Chapter 4, "Configuring BEA Connect TPS," for more detailed information about these parameters.
By setting the Connect TPS configuration parameters (that were introduced in Table 3-6) to the following values, you can instruct the local gateway to look for error indications within records sent from the remote system. Connect TPS will examine the structure member "status_fld" and, if it contains a value of 256, log an error and convert it into a format that the client program finds acceptable.
The following subsections explain how to create VIEW definitions. Connect TPS uses VIEW definitions to determine how to convert input data and output data into formats that are acceptable to target systems.
You should create VIEW definitions before you configure Connect TPS.
For complete information about VIEW definitions and related topics, see the BEA TUXEDO Transaction Manager Programming Guide.
Connect TPS buffer and record conversion capabilities are extremely powerful and flexible. The key to maximizing these capabilities is to thoroughly understand the BEA TUXEDO VIEW definition mechanism.
VIEW definitions are used to describe input and output records that are sent to and received from remote systems. They describe data elements and indicate how data elements are typed and sequenced. Based on these descriptions, Connect TPS translates field data types as required to maintain transparency between dissimilar systems.
VIEW definitions make it possible to specify composite data structures that can be used
Configuration Parameters for Managing Application Errors
Example
OUTRECTYPE=VIEW:YOURSTRUCT
ERRORLOCATION=status_fld
ERRORMATCH=256
ERRBUFTYPE=VIEW:MYSTRUCT
ERRORLOG=Y Creating VIEW Definitions to Facilitate Buffer Conversion
Introduction
Once you have determined the input and output record layouts for the remote application programs you will be working with, you need to
Preparing VIEW Definitions
After these tasks are complete, you can specify VIEW definitions in the TPSINIT file (by associating names of VIEW definitions with the INRECTYPE, OUTRECTYPE, INBUFTYPE, and OUTBUFTYPE parameters, as required).
See Chapter 4, "Configuring BEA Connect TPS," for detailed information about configuring Connect TPS.
Note:
FML fields must be specified for all VIEWs that Connect TPS converts. In other words, any VIEW that you specify as an INRECTYPE, OUTRECTYPE, INBUFTYPE or OUTBUFTYPE must be defined with appropriate FML fields (no dashes in the FNAME column of the VIEW definition).