Specifying a Remote Execution Host

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.