← Using the DCL Definition TypeUsing the OS Native Definition Type →

Using Platform Definition Types

Platform definition types define a type of process definition and the service required to execute the process definition of that type on external systems. When definition types are assigned to a process server, they define the type of processes that the process server can run and the services that are needed. When you submit a process definition, ensure there is a process server capable of running the definition type serving the queue or your process will never start..

note

Installing and using Redwood Server platform agents on Unix, HP OpenVMS, and Windows Servers requires a specific license, please check the License section for more information.

The server has knowledge of which agents and process server services are capable of executing which definition types, in theory. Some combinations are allowed that do require optional software on the actual operating system that it will run on. For instance, the platform agent for an operating system is capable of starting Perl, but this does require that the Perl interpreter is installed on that particular system. The same holds for the UNIX definition types such as BASH, CSH and KSH. They will only run successful if the appropriate shell is actually installed. These UNIX definition types can also run on Microsoft Windows servers with one of the many 'UNIX emulation' packages available.

Interpreter

You can override the default interpreter for some definition types by specifying an interpreter on process server-level with the LocalInterpreter_<JOBDEFINITIONTYPE>process server parameter, for example, you set LocalInterpreter_BASH to /usr/local/bin/bash. You can also specify a list of allowed interpreters on process server-level using the InterpreterWhitelist_<JOBDEFINITIONTYPE>process server parameter and override the default interpreter on process definition-level with the parameter JCS_INTERPRETER_<JOBDEFINITIONTYPE>. Simply create the parameter and point it to your preferred interpreter, it must exist and be white-listed using the InterpreterWhitelist_<JOBDEFINITIONTYPE> process server parameter.

note

When you create or edit a process server, the required services are added automatically to the process server based on the definition types you configured, so there is no need to change services on a process server. The only exception is for process servers that are used for file events exclusively, there you do not need to specify a definition type, however, the PlatformAgentService has to be added manually.

To view a definition type, choose a definition type in the overview table. The definition type details are shown in the lower detail pane.

The following standard definition types are provided with Redwood Server:

UNIX Definition Types

  • BASH - For writing Bourne Again SHell scripts. BASH is installed on all Linux systems and optionally on all UNIX (compatible) platforms that Redwood Server runs on.
  • CSH - For writing C Shell scripts. Available on most UNIX systems.
  • KSH - For writing Korn Shell scripts.
  • PERL - For writing Perl scripts.
  • PERL (Unicode) - For writing Perl scripts with UNICODE characters in your script source.
  • Python - For writing Python scripts.
  • SQLPLUS - For writing SQL*Plus scripts.
  • FTP - For writing FTP process definition.
  • OS Native - For writing OS Native process definition which can potentially run on any platform agent using its default shell.
  • Groovy - for writing Groovy process definitions which can potentially run on any platform agent, provided a suitable JVM and groovy runtime are available
  • R - For writing R scripts.

Microsoft Windows Definition Types

note

All UNIX definition types will also run on Windows, provided you have the command interpreter installed. For Perl we suggest Activestate, for SQLPLUS you require an Oracle client that includes SQL*Plus, and for BASH, CSH and KSH we recommend Cygwin.

HP OpenVMS Definition Types

Users

RunAsUser is generally used to control the user account under which the OS process runs on the host where the platform agent runs. RemoteRunAsUser is used to control an extra user account that is used in particular definition types only.

There are two historic exceptions: SQLPLUS and JCL_FTP, where the RunAsUser is used to control the account that is used for the remote account, as there is no use for the local RunAsUser and these predate the RemoteRunAsUser.

The RemoteRunAsUser attribute is currently only useful in FTP processes where it is used to control the initial account that the FTP command connects to.

Controlling the RunAsUser and/or RemoteRunAsUser at submit time

When there is a need to control the user account at submit time you can override the user, password (and endpoint) parts of a credential set by using the following parameters:

  • JCS_USER
  • JCS_ENDPOINT- (for SQLPLUS and JCL_FTP only)
  • JCS_REMOTE_USER
  • JCS_REMOTE_ENDPOINT
note

The endpoint for definition types other than SQLPLUS and JCL_FTP is fixed to the EndPoint process server parameter, or if that is not set the RemoteHostName process server parameter.

Environment on UNIX and Microsoft Windows

The Os processes do not automatically source UNIX style profile files because profiles usually contain statements that are not suited for batch programs. Also, if we allowed this then the next question is which profile should be used for definition types such as Perl or Groovy, which are usually not the login shell. Redwood Server does offer alternative methods to set the environment for each managed OS process.

The environment that a platform agent process starts with on UNIX is:

  1. A subset of the variables that the agent started with, limited by the ProcessServer parameter KeepEnvironmentVariables.
  2. The following variables are set to the appropriate value: PATH, SHELL, HOME, LOGNAME, USER, USERNAME, TMPDIR, TMP, TEMP, JCS_JOB_FILES_DIR, JCS_JOB_ID.
  3. The parameters as defined by the JobDefinition.

On Microsoft Windows the variables come from a slightly different set:

  1. The System Environment Variables as set in the Control Panel.
  2. The following variables are set to the appropriate value: PATH, USERNAME, USERDOMAIN, USERPROFILE, TMPDIR, TMP, TEMP, JCS_JOB_FILES_DIR, JCS_JOB_ID.
  3. The parameters as defined by the JobDefinition.

You can extend this using the following mechanisms:

  • If you have variables that you want to set per ProcessServer and control the values from the scheduler you set them in the EnvironmentVariables parameter.
  • If you have variables that you want to set per ProcessServer and control the values from the operating system you place them in a file and point the EnvironmentFile parameter to that file, for example /opt/redwood/agent/etc/environment or C:\\Program Files\\Redwood\\Agent\\environment.
  • If you have variables that you want to set per user or home directory and control the values from the operating system you place them in files relative to a variable and point the EnvironmentFile parameter to those files, for example ${HOME}/.environment or C:\\Users\\${USERNAME}\\environment.

The last method works because EnvironmentFile allows substitution variables that are evaluated on the agent in the context with the above parameters set.

EnvironmentFile, after resolving any variables, should point to a file with entries in the format

<var>=<value>
<var>=<value>
...

If you want to use special characters you can use " to define variables that include spaces, and \ to escape special meaning of characters. Variables that are already set can be referred to by ${<var>} (the braces are not optional as in KSH or BASH.) Use a separate line for each variable. # introduces a comment that lasts until the end of the line.

note

The file format does not allow programming constructs. It is interpreted by the job-processor, not executed by any shell.

See Also

← Using the DCL Definition TypeUsing the OS Native Definition Type →