You should consider the values of the following configuration parameters when you are setting up your TP Monitor environment:
The tp_mon_name database configuration parameter identifies the name of the transaction processor (TP) monitor product being used. For example, "CICS" or "ENCINA".
The tpname database configuration parameter identifies the name of the remote transaction program that the database client must use when issuing an allocate request to the database server when using the APPC communications protocol. This database manager configuration parameter is set in the configuration file at the server and must be the same as the transaction processor (TP) name configured in the SNA transaction program. See the Quick Beginnings manuals for more information.
The tm_database database configuration parameter identifies the name of the transaction manager (TM) database for each DB2 instance. A TM database can be a local database or a remote database that is not accessed though DRDA protocols. A TM database can be used as a logger and coordinator, and is used to perform recovery of indoubt transactions.
The maxappls database configuration parameter specifies the maximum number of active applications allowed.
The value of this parameter must be large enough to accommodate the application (user) connections to the database, as well as the number of indoubt units of work and the number of user transactions that have entered, but not yet completed, a two-phase syncpoint process.
As a result, for a Transaction Processing Monitor environment (for example, CICS for AIX) you may need to increase the value of the maxappls parameter. Increasing the value helps ensure that all TP Monitor processes can be accommodated.
This database configuration parameter specifies whether the RESTART DATABASE routine will be invoked when needed. The default is yes (that is, enabled).
A database containing indoubt transactions will require the RESTART DATABASE command/routine to be invoked in order to start up. If the autorestart option is not enabled, when the last connection to the database is dropped, the next connection will fail and require an explicit RESTART DATABASE again. This condition will exist until the indoubt transaction has been removed either by the transaction manager's resync operation, or through a heuristic operation performed by the administrator. When the RESTART DATABASE is issued, a message will be displayed if there are any indoubt transactions in the database. The administrator can then use the LIST INDOUBT TRANSACTION command and other command line processor commands to find out information about those indoubt transactions.