|  | BEA eLink TCP for TUXEDO 3.0 Information Center
HOME | SEARCH | CONTACT | PDF FILES | WHAT'S NEW
| TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC | INDEX

# Understanding How BEA eLink TCP for TUXEDO Works

To understand how eLink for Mainframe TCP for TUXEDO (hereafter referenced as eLink TCP for TUXEDO) works, you need to understand how it performs the following functions:

- Initializing eLink TCP for TUXEDO

- Processing Local Service Requests

- Processing Remote Service Requests

- Processing Shut Down Requests

- Programming Considerations

  Each of these operations is described in the following subsections.

  ## Initializing eLink TCP for TUXEDO

  When you boot BEA TUXEDO software using the `tmboot` command, eLink TCP for TUXEDO initializes in the following manner:

  1. BEA eLink TCP for TUXEDO parses the GWICONFIG configuration file and initializes all parameters. If syntax errors are encountered during parsing, eLink TCP for TUXEDO writes a message to the ULOG file and initialization fails.

  2. After reading the GWICONFIG file, eLink TCP for TUXEDO advertises remote services that are named in the file dynamically. This includes services for all remote gateways.

  ## Processing Local Service Requests

  When eLink TCP for TUXEDO receives a BEA TUXEDO service request from a local client program, it processes the request in the following manner.

  ### Step 1: Receiving a Service Request from BEA TUXEDO Software

  When a client program sends a request for a remote service that is accessible through eLink TCP for TUXEDO, BEA TUXEDO forwards the request to the gateway pending the requested service.

  ### Step 2: Connecting to a Remote System

  If no connection to the target remote system exists or an existing connection has been broken, the eLink TCP for TUXEDO gateway opens a new connection at this time.

  If the remote system returns a connection failure indication, the BEA TUXEDO service request fails and an error is returned to the caller. The actual error value returned depends on the timing of the connection failure. Information about failures is logged to the ULOG file.

  ### Step 3: Converting Input Buffer Types

  In some circumstances, typed buffers associated with service requests must be converted before service requests can be sent to remote systems. Type conversion involves changing the layout of a buffer to a format that is acceptable to a remote service.

  For example, if a local client program places user input in an FML buffer that a remote service cannot process, the buffer must be converted into the structure the remote service expects.

  In situations where input type conversion is required, programmers or administrators must perform the following tasks:

  - Determine the format of the input data the remote service expects.

  - If necessary, create a VIEW definition that describes the format of the input data. VIEW definitions are descriptions of data structures that are used for input and output in the BEA TUXEDO environment.

  - Specify this information in the eLink TCP for TUXEDO configuration files (GWICONFIG and DMCONFIG).

  Once these tasks have been completed, eLink TCP for TUXEDO performs all necessary type conversions automatically.

  For information about creating VIEW definitions to facilitate type conversion, see "Getting Ready to Configure BEA eLink TCP for TUXEDO." For information about the eLink TCP for TUXEDO configuration file, see "Configuring BEA eLink TCP for TUXEDO."

  ### Step 4: Translating Input Data

  BEA eLink TCP for TUXEDO automatically translates data as required. Translation refers to a change in how intrinsic data types are represented with respect to word length, byte ordering, and character encoding.

  To facilitate data translation, administrators must specify certain parameters in the GWICONFIG configuration file. For detailed information about how BEA eLink TCP for TUXEDO translates data, refer to "Getting Ready to Configure BEA eLink TCP for TUXEDO."

  ### Step 5: Transmitting the Service Request

  BEA eLink TCP for TUXEDO constructs a request message. This message includes the following items and is sent to the remote system:

  - The remote service name

  - The input data record that eLink TCP for TUXEDO has converted and translated, as required

  - An indication of whether the remote service should return a reply to the caller

  ### Step 6: Receiving a Reply

  After sending a request message, eLink TCP for TUXEDO performs a receive operation. If the eLink TCP for TUXEDO receive timeout expires before a message arrives from the remote system, a TPETIME error is returned to the caller.

  ### Step 7: Translating the Reply

  After eLink TCP for TUXEDO receives a reply, data representations are translated as needed, in the reverse of the input translation. For details, see the "Step 4: Translating Input Data" section in this document.

  ### Step 8: Converting Output Data

  If the format of the reply is not suitable for the local client program, eLink TCP for TUXEDO converts the reply into an appropriate buffer format.

  In situations where output conversion is required, programmers or administrators must do the following:

  - Determine the type and the format of the output buffer the local client program expects

  - If necessary, create a VIEW definition that describes the format of the output buffer

  - Specify this information in the eLink TCP for TUXEDO configuration files (GWICONFIG and DMCONFIG)

  Once these tasks have been completed, eLink TCP for TUXEDO performs all necessary conversions automatically.

  For information about creating VIEW definitions to facilitate type conversion, see "Getting Ready to Configure BEA eLink TCP for TUXEDO." For information about the BEA eLink TCP for TUXEDO configuration file, see "Configuring BEA eLink TCP for TUXEDO."

  ### Step 9: Sending the Reply to the Caller

  The BEA TUXEDO buffer resulting from output type conversion and output data translation is returned to the caller with a TPSUCCESS or TPFAIL indication.

  ## Processing Remote Service Requests

  BEA eLink TCP for TUXEDO processes remote service requests (those which originate on remote systems) in much the same way that it processes local requests. Here is a brief summary:

  1. The eLink TCP for TUXEDO gateway receives the service request and, if necessary, the input record associated with the request is translated and converted into the specified input buffer format.

  2. Acting as a client program, the gateway passes the service request to BEA TUXEDO software.

  3. When the service routine terminates, the output buffer is converted into the specified output record format and/or translated (when required).

  4. Finally, the output is sent to the requester on the remote system.

  For more detailed information about record and buffer conversion, and data translation, see "Processing Local Service Requests."

  ## Processing Shut Down Requests

  When you send a shutdown request to eLink TCP for TUXEDO using the `tmshutdown` command, eLink TCP for TUXEDO performs the following tasks:

  1. Completes outstanding requests

  2. Drops all open connections

  3. Terminates

  ## Programming Considerations

  In general, BEA TUXEDO application programs that send requests through eLink TCP for TUXEDO are developed just like other BEA TUXEDO application programs.

  BEA eLink TCP for TUXEDO supports all request/reply communications functions that are included in the ATMI and XATMI interfaces. In addition, all supported functions can be used in the standard manner. In particular:

  - All XATMI and ATMI buffer types are supported.

  - All system errors are reported in the standard manner.

  ### Input and Output Issues

  This subsection explores several input and output issues that programmers need to consider when developing application programs that use eLink TCP for TUXEDO.

  #### Preparing Input and Output Data with eLink TCP for TUXEDO

  As described in "Processing Local Service Requests," there are many circumstances in which it is necessary to convert input and output parameters into formats that are acceptable to remote systems or regions and the local system.

  BEA eLink TCP for TUXEDO provides powerful configuration capabilities that make it possible for you to convert or map parameters easily rather than requiring you to program in a different way.

  The eLink TCP for TUXEDO configuration files (GWICONFIG and DMCONFIG) are a centralized mechanism that you can use to define and maintain relationships between the local system and remote systems or regions. In addition to input and output parameter mappings, these relationships include service name mappings (where remote service names are mapped to local service names) and error record mappings.

  For more information about the GWICONFIG configuration file, see "Getting Ready to Configure BEA eLink TCP for TUXEDO," and "Configuring BEA eLink TCP for TUXEDO."

  #### Service Request Parameters

  BEA TUXEDO application programs can request the following two categories of remote services through eLink TCP for TUXEDO:

  - Existing application programs that were originally developed for traditional OLTP environments and have been adapted for use with BEA TUXEDO

  - Services that were developed specifically for the XATMI or ATMI (BEA TUXEDO) environments. Included in this category are services that reside in remote BEA TUXEDO regions.

  If a remote service was developed specifically for the BEA TUXEDO environment, the input it requires is shaped by three factors:

  - Application-specific requirements

  - Normal ATMI or XATMI requirements for defining and sending input

  - Machine-specific requirements for how input is formatted (such as those described in "Processing Local Service Requests")

  On the other hand, if a remote service is an existing OLTP application program, there are often additional requirements for input. For example, many systems require input that includes terminal data.

  Often, by creative use of the eLink TCP for TUXEDO configuration capabilities previously introduced, you can eliminate the need to include control information, such as terminal data, in the BEA TUXEDO application source code that you develop. For instance, you can include terminal control codes in VIEW definitions that are associated with the eLink TCP for TUXEDO configuration.

  For information about the normal input requirements of BEA TUXEDO services, see the BEA TUXEDO Programmer's Guide.

  #### Output Data Considerations

  To maintain the location transparency of the BEA TUXEDO environment, eLink TCP for TUXEDO does not preserve data from BEA TUXEDO input buffers in the associated output buffers. Hence, the consequences of using the same buffer for input and output must be understood to avoid problems.

  In particular, some existing BEA TUXEDO applications may use FML buffers to accumulate results or to maintain application context across service requests. Developers adding eLink TCP for TUXEDO to such an application must do one of the following:

  - Maintain a copy of the necessary data in the client program (or service routine) that makes requests.

  - Ensure that the remote service returns input data with the output record.

  This requirement is no different from the requirement that existed before the use of eLink TCP for TUXEDO. That is, application programs that accumulate output data in FML buffers must ensure that services return replies in original FML input buffers (with output data added)-not in new or re-initialized buffers.

  ### Limitations on the Use of Certain ATMI Functions

  The ATMI interface includes several features and functions-related primarily to conversations, transactions and client identities-that application programs cannot propagate to other application programs through eLink TCP for TUXEDO.

  In this guide, permanent limitations of this sort are referred to as operational considerations. Specific operational considerations are described in the following sections.

  Note: In this discussion, a local application program is one that resides within the immediate BEA TUXEDO region. A remote application program is one that resides outside the immediate BEA TUXEDO region.

  #### Conversational Communication Functions

  Conversational communication functions are subject to the following operational considerations:

  - Local client and server programs cannot use the `tpconnect()` function to establish conversations with remote services.

  - Remote client and server programs cannot use the `tpconnect()` function to establish conversations with local services.

  - Similarly, the `tpsend()`, `tprecv()` and `tpdiscon()` functions may not be used for communication through eLink TCP for TUXEDO.

  #### Non-Transactional Communications

  BEA eLink TCP for TUXEDO supports only non-transactional communications. Therefore, all communications via eLink TCP for TUXEDO are subject to the following operational considerations:

  - Remote services called by local client or server programs are always invoked outside the boundaries of any local transaction.

  - Local services called by remote client or server programs are always invoked outside the boundaries of any local transaction.

  - Local client or server programs calling remote services should invoke the `tpcall()` function, or the `tpacall()` and `tpgetrply()` functions, outside the boundaries of any local transaction (i.e., outside of any `tx_begin()`/`tx_commit()` or `tpbegin()`/`tpcommit()` pair).

  - If local client or server programs must call remote services within the boundaries of a local transaction, TPNOTRAN must be specified as one of the flags to the `tpcall()` or `tpacall()` function.

  #### The tpsprio() and tpgprio() Functions

  The `tpsprio()` and `tpgprio()` functions are subject to the following operational considerations:

  - Local client and server programs cannot use the `tpsprio()` function to set the priority at which remote services are processed. Instead, a call to the `tpsprio()` function causes the priority of a local eLink TCP for TUXEDO gateway to be set.

  - Remote client and server programs cannot use the `tpsprio()` function to set the priority at which local services are processed.

  - When local client or server programs use the `tpgprio()` function to determine the priority of a remote service, the priority of a local eLink TCP for TUXEDO Requester is returned.

  #### The tpbroadcast() and tpnotify() Functions

  The `tpbroadcast()` and `tpnotify()` functions are subject to the following operational considerations:

  - Local client programs cannot use the `tpbroadcast()` function to send unsolicited messages to remote client programs (and the reverse).

  - Local services cannot use the `tpbroadcast()` or `tpnotify()` functions to send messages to remote client programs (and the reverse).

  ### Error Handling

  There are three kinds of errors that local application programs can encounter when they send requests through eLink TCP for TUXEDO gateways:

  - Gateway errors

  - Problems on remote systems

  - Errors from remote application programs

  The following sections explain how eLink TCP for TUXEDO handles these different kinds of errors.

  #### Gateway Errors

  When local or remote gateway errors occur, they are logged in the BEA TUXEDO ULOG file and associated service requests fail. Also, appropriate error codes are returned to callers.

  #### Remote System Failures

  When remote systems encounter problems, service requests may fail or time out. The exact outcome depends on whether the remote system provides a means for eLink TCP for TUXEDO to detect failure.

  If the remote target system does not make it possible for eLink TCP for TUXEDO to detect particular types of failure, the eLink TCP for TUXEDO blocking timeout parameter can be tuned to provide timely detection of the problem.

  For more information about the blocking timeout parameter, see "Configuring BEA eLink TCP for TUXEDO."

  #### Application Errors

  Application errors are similar to remote system failures. That is, remote systems may or may not use error indicators to pass information back to the local eLink TCP for TUXEDO gateway resulting in the generation of error messages. If no such error indicators exist, service routines typically use their own mechanisms to report failures to callers.

  When application errors occur, some service routines may not return their usual output records at all. Instead, they may return some other data indicating that there has been an error, such as a string that contains a failure message.

  When eLink TCP for TUXEDO receives a service failure message from a remote system, it:

  - Converts the output buffer as required based on instructions it finds in the GWICONFIG file

  - Writes an error record in the ULOG file if the configuration directs it to do so

  - Returns the appropriate type of BEA TUXEDO buffer to the caller

    Note: When BEA TUXEDO applications detect service failures, they should not assume that returned buffers are the expected type. In practice this may not be an issue, since BEA TUXEDO application programs may ignore return buffers when failures occur. If you need to check a buffer type, you can use the BEA TUXEDO `tptypes()` function. Once the type is known, the buffer can be handled accordingly (for example, by displaying a window containing an error string).

  TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC | INDEX