In the typical application server configuration, the action definition is located on the same system as the application executable. However, actions can be written to execute commands on other systems. In this configuration, the system containing the application is called the execution host.
The action definition may be located on the session server or on a system that provides action and data type services to the session server--called a database server or database host.
Action definitions use the EXEC_HOST
field to specify where their commands (EXEC_STRINGs) should be run. For example, the following action definition specifies
that an xload client be run on a system with host name SysDDD:
ACTION XloadSysDDD { TYPE COMMAND EXEC_HOST SysDDD EXEC_STRING /usr/bin/X11/xload -label SysDDD }
If the EXEC_HOST
field specifies
more than one host name, then the desktop tries to execute the EXEC_STRING on each host in order until it finds one that can run the action.
For example, the following EXEC_HOST
field specifies that the action should first attempt to run the EXEC_STRING on SysDDD, and, failing this, try SysEEE.
EXEC_HOST SysDDD,SYSEEE
If the EXEC_HOST
field is
not set for an action, it defaults to the value %DatabaseHost%.
The value of %DatabaseHost% is obtained from the database
search path.
For example, suppose the database search path has been modified by adding the following line to /etc/dt/config/Xsession.d/0010.dtpaths:
DTSPSYSDATABASEHOSTS=SysAAA:,/net/SysBBB/etc/dt/appconfig/types/C
SysAAA is specified using the host-qualified syntax--SysAAA:. An action definition found using this element of the search path sets the database host to SysAAA. However, an action found using the /net/SysBBB... portion of the search path sets the database host to the local system because the syntax does not include the host qualifier.