Remote command jobs

A remote command job runs on remote computers that are not required to have the HCL Workload Automation agent installed.

A description of the job properties and valid values are detailed in the context-sensitive help in the Dynamic Workload Console by clicking the question mark (?) icon in the top-right corner of the properties pane.

Note: On Windows systems, the RemoteCommand plug-in has a hardcoded timeout set to 5 minutes (300 seconds). It might happen that this timeout is reached when a job is still running, causing its abnormal ending. To prevent this, a new property file, RemoteCommandExecutor.properties, has been added to the plug-in, having the attribute timeout that can be set to a different amount of seconds to give more time to run to the job. The attribute format is as follows: timeout=sec, where sec is the amount of time in seconds. Restart the agent to make this change effective.
Note: A Remote Command job that runs on a Windows workstation that is configured to use the samba protocol version 2 or 3, without an active SSH server, fails.
This section describes the required and optional attributes for remote command jobs. Each job definition has the following format and arguments:
Table 1. Required and optional attributes for the definition of a remote command job
Attribute Description/value Required
application name remotecommand ✓

userName

 The user name authorized to start a connection on the remote computer using the defined protocol. As an alternative to hard-coding actual values, you can parametrize in one of the following ways:
  • Enter a username specified in the database with the user definition (it is applicable to all operating systems on this job type) and key the statement:
    <jsdl:password>${password:username}</jsdl:password>
    The password is retrieved from the username user definition in the database and resolved at runtime. See Using user definitions on job types with advanced options for further details.
    You can also specify the user of a different workstation and use the following syntax for the password:
    <jsdl:password>${password:workstation#username}
  </jsdl:password>
  • Enter a user and password defined with the param utility command locally on the dynamic agent that will run the job (if the job is to be submitted to a pool or to a dynamic pool, the definition must be present on all the agents of the pool). Provided you defined the user name with the variable user and a password, the corresponding credential statements would be:
    <jsdl:userName>${agent:user}</jsdl:userName>
    <jsdl:password>${agent:password.user}</jsdl:password>
 ✓
password The password of the authorized user. The password is encrypted when the job is created. See description for userName for more details.
server name The host name of the computer where the remote command instance is running. ✓
port The port number of the remote computer where the command runs. ✓
protocol Possible values:
AUTO
The protocol is selected automatically from the existing protocols: SSH, Windows, RSH and REXEC. The product tries using the SSH protocol first. If this protocol fails, the Windows protocol is used. When using SSH, the path has to be in the SSH format. In this case the Cygwin ssh server is mounted on /home/Administrator.
SSH
A network protocol that provides file access, file transfer, and file management functions over any data stream.
WINDOWS
The Microsoft™ file sharing protocol. The default port used is 445. At least one samba share must exist on the server regardless of the command to be executed.
RSH
Remote Shell Protocol (rsh) is a protocol that allows a user to execute commands on a remote system without having to log in to the system.
REXEC
The Remote Execution (REXEC) server is a Transmission Control Protocol/Internet Protocol (TCP/IP) application that allows a client user to submit system commands to a remote system. The Remote Execution Protocol (REXEC) allows processing of these commands or programs on any host in the network. The local host then receives the results of the command processing.
keystore file path The fully qualified path of the keystore file containing the private key used to make the connection. A keystore is a database of keys. Private keys in a keystore have a certificate chain associated with them which authenticates the corresponding public key on the remote server. A keystore also contains certificates from trusted entities. Applicable to SSH protocol only.
keystore password The password that protects the private key and is required to make the connection. This attribute is required only if you specify a keystore file path. If the keystore file path and keystore password combination fail to make a connection, then an attempt is made using the userName and password that correspond to the user authorized to start a connection on the remote computer. ✓
command Type the command to be submitted on the remote computer. ✓
environment The standard output and standard error files for the remote command. These files are located on the agent, not locally on the workstations where the remote command runs. Ensure you have write rights on the specified directories, otherwise no file will be created.
Standard Output
Specify the path and file name where the standard output for the command is to be saved. Specify either an absolute path name or a path name relative to the working directory. The file is overwritten each time the command produces a new output.
Standard Error
Specify the path and file name where the standard error for the command is to be saved. Specify either an absolute path name or a path name relative to the working directory. The file is overwritten each time the command produces a new error.
The following example shows the JSDL “application” section of a sample job definition for a remote command job:
$JOBS
NC112016#REMCMD
 TASK
 <?xml version="1.0" encoding="UTF-8"?>
<jsdl:jobDefinition xmlns:jsdl="http://www.ibm.com/xmlns/prod/scheduling/1.0/jsdl" 
   xmlns:jsdlremotecommand="http://www.ibm.com/xmlns/prod/scheduling/1.0/
    <jsdlremotecommand" name="REMOTECOMMAND">
  <jsdl:application name="remotecommand">
    <jsdlremotecommand:remotecommand>
			<jsdlremotecommand:RemoteCommandParameters>
				<jsdlremotecommand:taskPanel>
					<jsdlremotecommand:command>ping -c 10 localhost </jsdlremotecommand:command>
				</jsdlremotecommand:taskPanel>
				<jsdlremotecommand:environmentPanel>
					<jsdlremotecommand:standardOutput>stdout</jsdlremotecommand:standardOutput>
					<jsdlremotecommand:standardError>stderr</jsdlremotecommand:standardError>
				</jsdlremotecommand:environmentPanel>
				<jsdlremotecommand:serverPanel>
					<jsdlremotecommand:serverInfo>
						<jsdlremotecommand:serverName>9.168.112.16</jsdlremotecommand:serverName>
						<jsdlremotecommand:port>23</jsdlremotecommand:port>
						<jsdlremotecommand:protocol>ssh</jsdlremotecommand:protocol>
					</jsdlremotecommand:serverInfo>
					<jsdlremotecommand:credentials>
						<jsdl:userName>userName</jsdl:userName>
						<jsdl:password>{aes}mv0GJqOHWo8lbuhcpFaluL9RkGQKrYvTiAUpKTMgp90=
             </jsdl:password>
					</jsdlremotecommand:credentials>
					<jsdlremotecommand:certificates>
						<jsdlremotecommand:keystoreFilePath>/var/keyStoreFile</jsdlremotecommand:
                 keystoreFilePath>
						<jsdlremotecommand:keystorePassword>pwd</jsdlremotecommand:keystorePassword>
					</jsdlremotecommand:certificates>
				</jsdlremotecommand:serverPanel>
			</jsdlremotecommand:RemoteCommandParameters>
		</jsdlremotecommand:remotecommand>
  </jsdl:application>
</jsdl:jobDefinition>
 RECOVERY STOP

See also

From the Dynamic Workload Console you can perform the same task as described in

Creating job definitions.

For more information about how to create and edit scheduling objects, see

Designing your Workload.