In the previous section you learned about using DB2 Connect with an application server. An application server permits a large number of users to execute applications using a minimum of system resources.
An application server can be extended to allow coordinated transactions to be invoked from applications executed by the application server. This transaction coordination is generally known as a Transaction Processing (TP) monitor. A TP monitor works in conjunction with an application server.
A transaction can be thought of as a routine event, usually a request for service, in running the day-to-day operations of an organization. The orderly processing of transactions is the type of work for which TP monitors were designed.
Every organization has rules and procedures that describe how it is supposed to operate. The user applications which implement these rules can be called business logic. The transactions these business applications execute are often referred to as Transaction Processing or Online Transaction Processing (OLTP).
The key characteristics of commercial OLTP are:
In this figure, the APIs, as well as the connectivity mechanism between the application server and the back-end database servers, are provided by DB2 Connect Enterprise Edition.
The most common TP monitors on the market today are:
Microsoft Transaction Server Remote S/390, AS/400, and LAN database servers can be use within transactions coordinated by these TP monitors.
With DB2 Connect Version 6 and earlier versions, Tuxedo based applications were limited to read only access to host and AS/400 database servers. This restriction has been removed with DB2 Connect Version 7. Tuxedo based applications can now update host and AS/400 database servers within a Tuxedo coordinated transaction. Special configuration requirements and restrictions apply. For more information, see DB2 Connect Connection Concentrator.
An application executing business logic may be required to update multiple resources within a single transaction. For example, a bank application which implements a transfer of money from one account to another could require debiting one database (the "from" account) and depositing to another database (the "to" account).
It is also possible that different vendors provide these two databases. For example, one database is a DB2 Universal Database for OS/390 and the other is an Oracle database. Rather than have every TP monitor implement each database vendor's proprietary transaction interface, a common transaction interface between a TP monitor and any resource accessed by an application has been defined. This interface is known as the XA Interface. A TP monitor that uses the XA Interface is referred to as an XA compliant Transaction Manager (TM). An updatable resource that implements the XA interface is referred to as an XA compliant Resource Manager (RM).
The above listed TP monitors are all XA compliant TMs. Remote host, AS/400, and DB2 UDB LAN-based database servers, when accessed via DB2 Connect, are XA compliant RMs. Therefore, any TP monitor which has an XA compliant TM can use host, AS/400, and LAN based DB2 UDB database servers within business applications executing transactions.
This section describes the configuration steps necessary to use S/390 and AS/400 database servers within your TP monitor. This section assumes that you have an operational TP monitor and have installed DB2 Connect, as well as have configured and tested a connection to the host or AS/400 database server. For more detailed information, refer to DB2 Connect Quick Beginnings book.
The steps required to configure the most popular TP monitors are provided in the Administration Guide. There is no distinguishing between configuring for access to a LAN-based DB2 UDB database server versus a host or AS/400 database server. The following instructions outline the general configuration steps for TP monitors not listed in the Administration Guide.
To configure DB2 Connect to use S/390 and AS/400 database servers within your TP monitor, perform the following steps:
The SPM is a component of DB2 Connect which maps the XA two phase commit protocol into the two phase commit protocol used by host and AS/400 database servers. By default, the DB2 instance has pre-defined values for the SPM configuration parameters. The most significant parameter is the database manager configuration parameter SPM_NAME. It defaults to a variant of the first seven characters of the TCP/IP hostname.
If you are using TCP/IP to connect to DB2 for OS/390, then you should not have to change any of the default settings. In this case, there is no SPM configuration required since it is already operational. If you are using SNA to access host or AS/400 database servers, then you have to ensure the SPM_NAME value represents a valid SNA LU in your network. If the default SPM_NAME value is not acceptable then you should use the Multisite Update wizard to modify this value.