gtpa3m0dApplication Requester User's Guide

TPF Requirements

This section contains information about how to configure your system for the TPF Application Requester feature.

Configuring TPFAR

To include TPFAR in your system, you must specify TPFAR=YES on the SIP CONFIG macro for TPF Application Requester support.

For additional information about the SIP CONFIG macro, see TPF System Generation.

Defining the Applications for LU 6.2

For TPFAR to connect with the DB2 system by using LU 6.2, both the local TPF/APPC application in the TPF system and the remote DB2 system primary logical unit (PLU) must be defined to the communication network as TPF/APPC resources.

Defining the Local TPF/APPC Applications for LU 6.2

To define the local TPF/APPC application to TPF, the SIP stage 1 deck must be updated with an entry for the TPF/APPC application. This is done with the MSGRTA macro. Use the MSGRTA APPL parameter to specify the local TPF/APPC application name. Use the name on the MSGRTA macro when you define the TPF application. The application is defined by one of two ways, depending on whether your system is loosely coupled. For example, we will define the TPF system application as TPAR, that is, APLIC=TPAR.

If your TPF system is loosely coupled, you need to define a separate local TPF/APPC application in TPF for each processor in the TPF system loosely coupled complex. These are known as service LUs. Note that the name of the service LU is SVCx, where x is the processor (CPU) ID.

Using the service LUs is the recommended way to define the local TPF/APPC application to the TPF system for maximum efficiency. Another method of defining the local TPF/APPC application is documented in TPF ACF/SNA Data Communications Reference.

Defining the Remote DB2 PLU Application for LU 6.2

To define the DB2 system to the TPF system, the resource deck input to offline SNA table generation (OSTG) function can be updated to have the DB2 system defined as an LUTYPE=L6PLU resource, if dynamic LU is not used. For example: to have DB2 defined as an LUTYPE=L6PLU resource, for example:

    TPFDB2T RSC LUTYPE=L6PLU

For more information about OSTG, see TPF ACF/SNA Network Generation. See the TPF ACF/SNA Data Communications Reference for more information about how to define SNA resources.

Attaching to the LU 6.2 Communications Cloud

The TPF system attaches to the communications system, which attaches to the remote system running the DB2 system.

Defining the Channel-Attached Link Station for MVS

The connection between the DB2 system and TPF Application Requester is either a 37x5 running a Network Control Program (NCP) defining the TPF system as a type PU 2.1 or type 5 node, or a 3088 Channel-to-Channel (CTC) connection defining the TPF system as a type PU 5 node. Both types of connections can have an entry in the adjacent link station (ALS) deck of the OSTG.

Each CTC link is uniquely defined to VTAM by its qualifier number. This number is needed when setting up the definitions for a CTC connection on VTAM and when defining the CDRSC statement on VTAM. See Defining the TPF Application LUs to VTAM for more information about how this is needed for the VTAM definitions.

See the TPF ACF/SNA Network Generation for more information about coding CTC and ALS statements in an OSTG deck.

Defining the Channel-Attached Link Station for the DB2/6000 System

TPF Application Requester and IBM DATABASE 2 AIX/6000 system (DB2/6000) connection uses an enterprise systems connection (ESCON) adapter (5765-603) or a block multiplexer channel adapter.

Activate a PU 2.1 link between the TPF system and the RISC System/6000 (RS/6000) in one of several ways:

Communications Requirements for the RS/6000 System

See ESCON Users Guide and Service Information and SNA Channel Connectivity for AIX for information about the required software.

Communications Requirements for the PS/2

The TPF Application Requester communicates with the DB2 system on a Personal System/2 (PS/2) through an LU 6.2 connection.

Defining the TPFAR Storage Areas

In the SNAKEY macro, the following additional definitions are required. All of these storage areas are carved out of storage above the 16-MB line.

Note:
In a loosely coupled environment, each processor has its own copy of keypoint 2.

For detailed information about the SNAKEY macro, see the TPF ACF/SNA Network Generation.

Other TPF System Storage Requirements

TPF Application Requester affects storage on the TPF base system. When an SQL call is issued, all processing for that ECB is suspended until control is returned.

Note:
When developing an application, be careful of any locks, file records, or core blocks associated with an ECB over an SQL call. All processing for this ECB is suspended until a response is received from the remote AS. This can result in a TPF system resource problem.

For TPFAR, you need to assess the following TPF system resources to ensure that storage requirements are adequately met:

LU 6.2 Requirements

TPFAR can use the TPF/APPC code for communication between the remote application server (AS) and TPF.

Note:
Ensure that the following areas have values sufficient for TPFAR:

Additionally, in order to use TPFAR in a PU 5 environment, the SNAKEY parameter NETID must be coded with the network id of the TPF system.

See the TPF ACF/SNA Data Communications Reference and TPF ACF/SNA Network Generation for additional information about TPF/APPC requirements.

TCP/IP Requirements

TPFAR can use the TCP/IP code for communication between the remote application server (AS) and the TPF system.

Notes:

  1. Configure the remote AS to use the same port number that was specified with the ZSQLD command for TPF to connect to the server. See TPF Operations for more information about the ZSQLD command.

  2. The TPFAR feature requires that the server accept a security protocol of USERID only. The userid that TPF provides is the complex name that is contained in keypoint I.

  3. The TPFAR feature uses one socket for each connection, so the number of available sockets must at least equal the number of connections. Use the MAXSOCK parameter of the SNAKEY macro to set the maximum number of sockets, including any additional sockets needed for the remote AS. If hotcons are used, sockets are then saved in the hotcon table (HCT). See TPF ACF/SNA Network Generation for more information about the SNAKEY macro and the hotcon table.

See TPF Transmission Control Protocol/Internet Protocol for additional information about TCP/IP requirements.

Commands

The following commands are particularly applicable when using TPFAR.

For detailed information about these commands, see TPF Operations, Messages (System Error and Offline), and Messages (Online).

Coding the SQL Trace Table User Exit

Each SQL command that is issued by the application is logged in the SQL trace table (if it is defined via the MAXSMTB parameter in SNAKEY). When the table is full, it wraps and subsequent SQL commands overwrite the existing entries in the table.

A user exit (segment UAR1) can be utilized to process the information in the SQL trace table before it is overwritten.

Character Sets

A number of offline tasks must be completed before you can use a new character set on the TPF system or connect to a remote server that uses a character set that does not have a translate table loaded on the TPF system. See TPF Application Programming for more detailed information about character sets.

Choosing a New Character Set

Character sets are chosen on the basis of the kinds of letters and symbols required. Once these requirements are understood, you can choose the appropriate character sets. To learn more about character sets, see Character Data Representation Architecture Reference and Registry.

Translating Character Sets

A character set is referred to by a number called a coded character set identifier (CCSID). Each DB2 system contains characters in one or more CCSIDs. The TPF system also contains characters in one or more CCSIDs (or TPFCCSIDs).

Characters residing in the DB2 system must have a corresponding form in the TPF system to be used in the TPF system database. When the CCSIDs match, no translation is necessary. If the character sets are different, a translation mechanism must exist to transform each character from the remote CCSID to a corresponding character of the TPF system CCSID.

Seeing the Overall Character Flow

The ZSQLD command defines the TPF system CCSIDs and verifies the remote CCSIDs. Consider, for example, the CCSID of a remote DB2 system CCSID (xx) and the TPF system CCSID (yy). The xxyy table name must appear in the CPGS table to identify the name of the DLM to be used for the translation from the remote database to the TPF system. The DLM name found in CPGS is used to make the conversions from one character set to the other. The ZSQLD command verifies that the CCSIDs specified have the correct STYLE. It does not verify the compatibility of the CCSIDs.

Converting Numbers

Processors differ in how they represent numbers. These differences are automatically detected and accounted for by the TPF system.

Loosely Coupled Requirements

When using TPFAR in a loosely coupled environment, be aware of the following conditions:

  1. Each SDD is processor unique. When setting up the relational database (RDB) information, you must enter the ZSQLD command on each processor that handles TPFAR applications.
  2. Because each processor has its own copy of keypoint record 2 (CTK2), you have to setup the CTK2 (using SNAKEY) parameters need to be set up for each processor.
  3. For LU 6.2, separate service LUs must be defined for each processor in the complex. For more information about service LUs, see Defining the Local TPF/APPC Applications for LU 6.2.

Subsystem Requirements

The TPFAR applications must be defined in each of the subsystems that accesses TPFAR. See TPF System Generation for more information about defining applications for subsystems. In addition, each subsystem has its own unique SDD record; for each subsystem communicating with the DB2 system, the RDB information must be added to the SDD by using the ZSQLD command.

Additionally, the originating subsystem where an ECB issues its first SQL command must be the subsystem where all subsequent processing must occur. This ECB cannot change subsystems after an SQL command has been issued. This requirement also applies when using the DBSAC and DBSDC macros/functions.