gtpa3m0d | Application Requester User's Guide |
This section contains information about how to configure your system for the TPF Application Requester feature.
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.
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.
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.
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.
The TPF system attaches to the communications system, which attaches to the remote system running the DB2 system.
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.
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:
See ESCON Users Guide and Service Information and SNA Channel Connectivity for AIX for information about the required software.
The TPF Application Requester communicates with the DB2 system on a Personal System/2 (PS/2) through an LU 6.2 connection.
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.
Hotcons are described as follows depending on the communication protocol used:
For detailed information about the SNAKEY macro, see the TPF ACF/SNA Network Generation.
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.
For TPFAR, you need to assess the following TPF system resources to ensure that storage requirements are adequately met:
Attention: Ensure that the short term pool cycle time is large enough for records to still be present when the DBSAC macro/function is used to reattach the STP and associated blocks.
See TPFAR Working Storage Blocks for more information about the DBSAC and DBSDC macros/functions. See also TPF General Macros and TPF C/C++ Language Support User's Guide for additional information about the DBSAC and DBSDC macros/functions.
TPFAR can use the TPF/APPC code for communication between the remote application server (AS) and TPF.
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.
TPFAR can use the TCP/IP code for communication between the remote application server (AS) and the TPF system.
Notes:
See TPF Transmission Control Protocol/Internet Protocol for additional information about TCP/IP requirements.
The following commands are particularly applicable when using TPFAR.
The following parameters are important when using the ZSQLD command to add an entry to the SDD.
The following is an example of a ZSQLD command to add an SDD entry:
ZSQLD ADD RDB-DB23TST,LU-TPFDB2T,MAXHCT-5,MODE-TPFMOD1 ZSQLD MOD RDB-DB23TST,LU-TPFDB2T,CCSID-897.301.932,TPFCCSID-282.300.930
You can use the ZSTTD command to display trace entries either in summary or in detail. The detailed form includes exception fields from the SQLCA.
For detailed information about these commands, see TPF Operations, Messages (System Error and Offline), and Messages (Online).
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.
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.
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.
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.
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.
Processors differ in how they represent numbers. These differences are automatically detected and accounted for by the TPF system.
When using TPFAR in a loosely coupled environment, be aware of the following conditions:
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.