Limitations on Dynamic Modification Using tmconfig


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Documentation \| Administering a BEA Tuxedo Application at Run Time \| Local Topics \| Previous Topic \| Next Topic \| Contents

Keep in mind the following restrictions when modifying your application dynamically using tmconfig. Be careful about setting parameters that cannot be changed easily.

Associated with each section is a set of key fields that are used to identify the record upon which operations are performed. (For details, see tmconfig, wtmconfig(1) in the BEA Tuxedo Command Reference.) Key field values cannot be changed while an application is running. Normally, it is sufficient to add a new entry, with a new key field, and use it instead of the old entry. When this is done, only the new entry is used; the old entry in the configuration is not booted by the administrator.
Generally speaking, you cannot update a parameter while the configuration component with which it is associated is booted. For example, you cannot change an entry in the MACHINES section while the machine associated with that entry is booted. Specifically:
Carefully track the section of the configuration file in which you are working; tmconfig does not warn against performing an operation in the incorrect section. For example, if you try to update the ENVFILE parameter (in the MACHINES section) while you are working in the RESOURCES section, the operation appears to succeed (that is, tmconfig returns TAOK), but the change does not appear in your unloaded UBBCONFIG file. You can be sure an update is done only when the TAUPDATED status message is displayed.

In a multiple-machine configuration, always perform the following tasks:

Specify a backup for the MASTER machine, along with the MIGRATE option (even if a need for application server migration is not anticipated).
For MAXSERVERS, MAXSERVICES, and other parameters that define maximum limits, assign settings that are high enough to allow for sufficient growth. If your application is initially deployed on only one machine, but is expected to grow to a multiple-machine configuration, use the MP model, specifying the LAN option and a network entry for the initial machine.
Set the parameters in the MACHINES section carefully because updating them requires shutting down the machine (and switching the MASTER to the backup in the case of the MASTER machine).

Tasks That Cannot Be Performed on a Running System

Most elements of the BEA Tuxedo system can be changed dynamically, through either manual intervention or automatic processes. For example, new servers can be spawned, new machines can be added, timeout parameters can be changed, and so on. A few parameters, however, cannot be changed while a system is operational:

Any parameter that affects the size of the bulletin board is not dynamic. Most of these parameters begin with the string MAX, such as MAXGTT, which defines the maximum number of in-flight transactions allowed within the BEA Tuxedo system at any time.
The name of a machine being used in a running application is not dynamic. New machines (that is, machines with new names) can be added, but an existing machine name cannot be changed.
Once server executables are assigned to run on both master and backup machines, the assignment of the master and backup cannot be changed.

Note: You can configure new copies of a server executable to run on additional machines, but you cannot change existing servers with unique identifiers.