gtpa3m13Application Requester User's Guide

Considerations That Are Different

Communications Overhead and Hotcons

In standard processing, when a transaction requires access to the application server (AS), an LU 6.2 conversation is allocated between the application requester (AR) and the AS. When this transaction ends, the conversation is deallocated. If the duration of the transaction request is short, for example, a single SQL INSERT command, setting up and tearing down conversations can cause a significant amount of overhead. Setting up and tearing down conversations can account for over half of the data flow between the AR and AS.

The hotcon method reduces this overhead. If hotcons are defined for a particular AS, conversations or connections to that AS are no longer deallocated when the transactions are over. Instead, they are saved in hotcon table entries and attached to the appropriate SQL DBMS directory (SDD) entry. The next request directed to that AS automatically gets a ready-to-use conversation or connection bypassing the overhead of allocating a new conversation or connection.

The use of hotcons is not without cost; namely, there is a loss of diagnostic information at the AS, as well as the holding of resources on TPF, VTAM, and DB2 systems for each conversation in the hotcon table. Because the logical unit of work identifier (LUWID) is associated with each conversation, one LUWID is now shared by many transactions. To DB2, it appears as a long running thread. The LUWID consists of a fully qualified LU name, a logical unit of work instance number, and logical unit of work sequence number that uniquely identifies a logical unit of work within the network.

Performance trace information cannot be gathered for a single transaction while hotcons are in use. If information needs to be gathered at the AS for a TPF application, hotcons should be turned off. See TPF ACF/SNA Network Generation for information about using hotcons.

When using TCP/IP, the hotcon method similarly reduces overhead. If hotcons are defined for a particular AS, connections to the application server are no longer closed when the transactions are over. Instead, they are saved in hotcon table (HCT) entries and attached to the appropriate SQL DBMS (SDD) entry. The next request directed to that AS automatically gets a ready-to-use connection, bypassing the overhead of starting a new TCP/IP connection.

Application Overhead

The design of the application programs themselves can reduce the amount of communications traffic and database activity. Each application instance, or entry control block (ECB), that issues a remote SQL INSERT command requires a subsequent SQL COMMIT command. An installation can batch the SQL INSERT commands through an intermediate queue and then issue the SQL INSERT commands from a single ECB followed by a single SQL COMMIT command. This method of implementing an application as described in Offloading Data from the TPF System, may cut in half the time it would have taken if each SQL INSERT command was followed by an SQL COMMIT command.

Note:
This method should not be used for applications requiring the data be current with other database updates.