Creating Actions that Run Applications on Remote Systems

When discussing actions and remote execution, there are two terms that are used frequently:

In most situations, actions and their applications are located on the same system; since the default execution host for an action is the database host, no special syntax is required.

However, when the execution host is different from the database host, the action definition must specify where the execution string should be run.

The ability to locate actions and applications on different systems is part of the client/server architecture of the desktop. For a more in-depth discussion of networked applications, see “Administering Application Services”.

Creating an Action that Runs a Remote Application

Use the EXEC_HOST field in the action definition to specify the location of the application.

Valid values for EXEC_HOST are:

%DatabaseHost%	The host where the action is defined.
%LocalHost%	The host where the action is invoked (the session server).
%DisplayHost%	The host running the X server (not allowed for X terminals).
%SessionHost%	The host where the controlling Login Manager is running.
hostname	The named host. Use this value for environments in which the action should always be invoked on one particular host.
%"prompt"%	Prompts the user for the host name each time the action is invoked.

The default value is %DatabaseHost%, %LocalHost%. Thus, when the EXEC_HOST field is omitted, the action first attempts to run the command on the host containing the action definition. If this fails, the action attempts to run the command on the session server.

Examples

• This field specifies host ddsyd:

EXEC_HOST ddsyd

• The field prompts for a host name:

EXEC_HOST %"Host containing application:"%

• This field specifies that the action will attempt to run the application on the host containing the action definition. If this fails, the action will attempt to run the application on host ddsyd.

EXEC_HOST %DatabaseHost%, ddsyd