gtpa3m0b | Application Requester User's Guide |
TPFAR can be used to enhance your enterprise in these processing areas:
Figure 5. Transaction Logging with a Frequent Flyer Database. Identical data resides on both the TPF and remote systems.
Transaction logging can be used when the data you are working with normally resides on TPF, but the decision support is done on the remote application server (AS). It can also be used if there is a requirement for the data on the AS to be current with the data on TPF. A transaction logging implementation can be used in which the TPF application issues the SQL INSERT or UPDATE command to the AS whenever the data on TPF is updated.1 Thus, the application guarantees that the data on RDBM and TPF are identical. The remote unit of work method of accessing distributed relational data does not support a two phase commit. Therefore, if the data must be identical on both the relational database manager (RDBM) and TPF, the application must guarantee that the data is identical.
Figure 5 shows how transaction logging can work with a frequent flyer database.
The user requests an update for frequent flyer data. The application finds the TPF record, makes the change and files it. Then, the application issues an SQL UPDATE or SQL INSERT command to make the same change to the remote relational database. In this case, the application maintains identical data on both TPF and the relational database manager (RDBM) at all times.
Bulk data transfer can be used when the data you are working with normally resides on TPF, but the decision support is done on the remote application server (AS). However, in this case, the data on the AS need not be current with the data on TPF, and the number of changes made to the data is high. A bulk data transfer implementation can be used in which the TPF application queues the data in a TPF file. At a specified time, another application reads all of the data from the TPF file and ships it to the AS using SQL INSERT and UPDATE commands. The savings occurs in that each application does not need to issue an SQL CONNECT and an SQL COMMIT command.2 Instead, one application issues an SQL CONNECT command, does all of the inserts, and then issues the SQL COMMIT command. A detailed implementation of bulk data transfer is found in Using Assembler Language with TPFAR.
This method is also useful when only certain pieces of the data are needed on the remote DB2 subsystem. For example, on your DB2 subsystem you need the information on who flew on what flight. Until that flight takes off, this information is constantly changing. Keeping a DB2 database synchronized with the TPF database is costly. Instead, after a flight has taken off, a program can send the final information over to DB2 for processing either immediately or during off-peak hours.
Figure 6 shows how bulk data transfer can work with a customer account database.
Figure 6. Bulk Data Transfer. Large amounts of data are transferred to the remote system.
The user requests a change to account information. The first application takes control and updates the TPF record with the new information and exits. A second application retrieves the record and issues an SQL INSERT command to log that this transaction occurred. A program can then be written on the remote system to gather statistical information on the types of transactions made by the user.
Figure 7. Single Line Query. A single data record is retrieved from the remote system.
Single line query can be used when there are a relatively low number of TPF transaction requests for data that normally reside on the remote application server (AS). A single query using the SQL SELECT INTO command can be issued to retrieve the needed information.3
Figure 7 shows how single line query can work with a phone directory database.
The user requests a telephone number. The application issues an SQL SELECT INTO command to retrieve the information. The telephone number is returned to the application.
Figure 8. Block Query. Many data records are retrieved from the remote system.
A block query can be used when the data you are working with resides on the remote application server (AS), and a refresh of that data is needed on TPF. Using the SQL SELECT INTO command, a block query can be issued to retrieve the needed information.
Figure 8 shows how block query can work with a new rate file.
The user requests a refresh of the rate table. The application issues an SQL OPEN command to open a cursor to retrieve the rate information. The SQL FETCH command is then used to retrieve each individual row of data.4 A cursor is a control structure used by an application to retrieve, update, or point to information in a table. The SQL FETCH command is repeated until all of the information has been retrieved.
The main difference between the block query and single line query is that with block query, an SQL FETCH command goes across the network to DB2 only once to retrieve a block of data. From then on, the SQL FETCH takes place at the local level between the application and TPFAR. This is explained in more detail in Request Unit Size Considerations.