js.conf

This is the configuration file for Process Manager. Process Manager Server receives its configuration information on startup from its configuration file js.conf.

When you make changes in this file, restart jfd with the commands jadmin start and jadmin stop to make changes take effect.

The file js.conf is created automatically during the installation of Process Manager. The values in js.conf are set automatically when you install Process Manager Server as follows:

  • On UNIX, from the values you specify in install.config before running jsinstall
  • On Windows, from the values you specify when prompted by the installation program
  • Some values default during installation

    If, for example, when you installed the failover daemon, the default port was already in use, you can change that value directly in js.conf. The next time Process Manager Server is started, the new values take effect.

    Some values in js.conf are generated and cannot be changed without causing problems. This is indicated in the parameter description.

Format

Each entry in js.conf has one of the following formats:

NAME=VALUE
NAME=
NAME="STRING1,STRING2,..."

The equal sign (=) must follow each NAME even if no value follows and there should be no space beside the equal sign.

Lines starting with a pound sign (#) are comments and are ignored. Do not use #if as this is reserved syntax.

Parameters

JS_ADMINS

Syntax

JS_ADMINS=primary_admin[,admin2,admin3,...]

Description

REQUIRED.

Specifies the administrators who run Process Manager. The first entry is the primary Process Manager administrator, and must be a valid user ID. This name is set at installation time. Any additional administrators specified can be user IDs, UNIX user group names, or Windows active directory user group names.
Tip: To prevent users from viewing detailed information for jobs that belong to other users, you can set the SECURE_INFODIR_USER_ACCESS parameter to Y or G in the LSF system's lsb.params file. If set, also ensure that the primary Process Manager administrator is primary LSF administrator so that the Process Manager server daemon (JFD) can read the lsb.event file. Set this configuration within the JS_ADMIN parameter for the install.config file during installation.

If you change the list of administrators specified in this parameter, or change the membership in a user group specified in this parameter, these changes will be applied at the next scheduled update or by running jreconfigadmin.

Windows user IDs and active directory user group names must include the domain name. To specify a list, separate the names with a comma without a space. If the Windows user ID or active directory user group name contains spaces, enclose the user ID or group name in quotation marks.

For example, to specify Windows users and user groups:

JS_ADMINS=DOMAIN\lsfadmin,"DOMAIN\Engineering Group",DOMAIN\userA

Default

There is no default for this parameter. A value for the primary Process Manager administrator is set at installation time.

JS_ADMIN_UPDATE_INTERVAL

Syntax

JS_ADMIN_UPDATE_INTERVAL=days

If set to 0, scheduled updates is disabled.

Description

Specifies the interval between scheduled updates of the list of Process Manager administrators.

If the membership in a user group changes, the list of Process Manager administrators needs updating. This parameter specifies the interval of time between scheduled updates. You can also manually update the list of Process Manager administrators using the jreconfigadmin command.

If you disable scheduled updates (by setting this interval to 0), you need to manually run jsreconfigadmin whenever you modify the JS_ADMINS or JS_CONTROL_ADMINS parameters, or whenever you modify any user groups specified in the JS_ADMINS or JS_CONTROL_ADMINS parameters.

Default

The default is one day.

See also

JS_ADMINS, JS_CONTROL_ADMINS

JS_ALARM_CMD_TIMEOUT

Syntax

JS_ALARM_CMD_TIMEOUT=seconds

Description

Specifies the maximum number of seconds that an alarm script executes before Process Manager forcefully terminates it.

Default

The default is 180 seconds.

JS_BSUB_RETRY_EXIT_VALUES

Syntax

JS_BSUB_RETRY_EXIT_VALUES=exit_code[, exit_code...]

Description

Specifies bsub exit codes to retry job submission. Separate multiple exit codes with a comma (,).

When job submission fails and the LSF bsub command exits with any of the specified exit codes, Process Manager retries to submit the job again. The number of retries is specified with the parameter JS_START_RETRY in js.conf.

Default

Undefined-there is no retry when job submission fails.

See also

JS_START_RETRY

JS_CHANGE_FLOW_OWNER

Syntax

JS_CHANGE_FLOW_OWNER=false | true

Description

Specifies whether non-administrator users can trigger flows from other users’ flow definitions and own the triggered flows.

Applies only to Published flows.

When this parameter is set to false:

  • Only the Process Manager administrator, the Process Manager control administrator, and the user who committed the flow definition can submit the flow. The user who committed the flow definition is the owner of the flow. In Flow Manager, the Run As field in the job definition has this user name.

When this parameter is set to true:

  • Any user can submit the flow. The user who submits the flow is the owner of the flow.
  • In Flow Manager, the value defined in the job definition Run As field is replaced with the user name of the user who submitted the flow.

If a flow definition has a trigger event defined, the flow owner is the user who committed the flow definition.

If a user runs a flow with the jrun command or through Run Now in Flow Editor, the flow owner is the user who invokes the command or the Run Now action.

Permissions

The following table illustrates control permissions when JS_CHANGE_FLOW_OWNER=true.

Can submit other users’ non-published flow definitions

Can submit other users’ published flow definitions

Flow owner/ job owner

Primary administrator, Control administrator

Y

Y

User who submit the flow.

Non-administrator users

N

Y

User who submit the flow.

The following table illustrates control permissions when JS_CHANGE_FLOW_OWNER=false.

Users

Can submit other users’ non-published flow definitions

Can submit other users’ published flow definitions

Flow owner/ job owner

Primary administrator, Control administrator

Y

Y

User defined in the flow definition.

Non-administrator users

N

N

Not applicable.

User interface affected

In Flow Manager:

  • When a user opens the a job definition dialog from the flow diagram, the Run As field always displays the actual job owner.
  • Flow and job control action permissions are based on flow owner. The flow owner can:
    • Flows: kill, suspend, resume, rerun, query
    • Jobs: kill, rerun, resume, set job complete, set rerun point
    • Set variables
    • Complete dependencies
    • Complete/query manual jobs

    Commands:

    • jtrigger -u user_name

    When JS_CHANGE_FLOW_OWNER=false, -u specifies the name of the user who owns the flow definition. This is the user who committed the flow definition to Process Manager. Use this option if you have administrator authority and you are submitting the flow on behalf of another user.

    When JS_CHANGE_FLOW_OWNER=true, -u specifies the name of the user who owns the flow definition. The flow is owned by the user who submitted the flow. Jobs in the flow run under the submission user, and the submission user is able to control the flow and its jobs.

  • Flow commands:

For flow-related commands such as jflows, jkill, jmanuals, jrerun, jresume, jstop, -u specifies the owner of the flow: the user who submitted the flow.

In the output of the jflows command, the USER field indicates the flow owner: the user who submitted the flow. In the NAME field, the full name of the flow definition is displayed (example: LSFAD/lsfadmin:untitled).
  • Job commands:
For job-related commands such as jcomplete, jjob, -u specifies the owner of the job.
  • For the jhist command, -u specifies the user who owns the category specified by the -C option.

    In the following example, -u indicates the owner of the flow definition (user who committed the flow definition):

    jhist -C myflowdef -u user1 -f myflow

    In the following example, -u specifies the owner of the flow (user who submitted the flow):

    jhist -C flow -u user1 -f myflow

    In the following example, -u specifies the owner of the job (user who submitted the flow):

    jhist -C job -u user1 -f myflow
    • In the history.log file, the user in the User Name field is the owner of the category. For example, the user name in the FLOWDEF category is the flow definition owner(user who committed the flow definition), the user name in the FLOW category is the flow owner(user who submitted the flow) and the user in the JOB category is the job owner(user who submitted the flow).

Default

JS_CHANGE_FLOW_OWNER=false

See also

JS_LIMIT_USER_VIEW

If you are using JS_LIMIT_USER_VIEW to limit users from viewing other users' flows, when you set JS_CHANGE_FLOW_OWNER=true:

  • The user who is logged on can view and control flows that he owns. For example, if userA committed and published the flow definition, but userB triggered a flow from the flow definition, userB can see the flow definition because he is the owner of the flow.

JS_CONN_TIMEOUT

Syntax

JS_CONN_TIMEOUT=seconds

Description

Specifies the maximum number of seconds a Process Manager Client waits for a response from Process Manager Server.

Default

The default is 1024 seconds.

JS_CONTROL_ADMINS

Syntax

JS_CONTROL_ADMINS=cadmin[,cadmin1,cadmin2,...]

Description

OPTIONAL.

Specifies one or more control administrators who can control any flows or jobs in Process Manager, regardless of who the owner is. These administrators cannot commit or remove flows belonging to other users.

Any administrators specified can be user IDs, UNIX user group names, or Windows active directory user group names.

If you change the list of administrators specified in this parameter, or change the membership in a user group specified in this parameter, these changes will be applied at the next scheduled update or by running jreconfigadmin.

Windows user IDs and active directory user group names must include the domain name. To specify a list, separate the names with a comma without a space. If the Windows user ID or active directory group name contains spaces, enclose the user ID or group name in quotation marks.

For example, to specify Windows users and user groups:

JS_CONTROL_ADMINS=DOMAIN\admin,"DOMAIN\QA Group",DOMAIN\userA

Default

There is no default for this parameter.

See also

JS_ADMINS

JS_CREATE_WORKING_DIR

Syntax

JS_CREATE_WORKING_DIR=false | true

Description

Controls whether Process Manager automatically creates the work directory for a work item. This is useful in cases in which Process Manager does not have access to local directories on server hosts.

When JS_CREATE_WORKING_DIR=true(default value), if a work directory is specified for a work item in its definition, Process Manager creates the specified directory if it does not exist.

When JS_CREATE_WORKING_DIR=false, if a work directory is specified for a work item in its definition, Process Manager assumes the directory already exists in the specified location. Ensure the directory exists or the work item will fail.

Default

JS_CREATE_WORKING_DIR=true

JS_DATACAPTURE_TIME

Syntax

JS_DATACAPTURE_TIME="cal_name@user_name:hour[:minute]"

Description

Periodically, Process Manager Server interrupts its processing to take an image of the workload in Process Manager, and saves it for recovery purposes. Depending on the amount of workload that passes through your server, recovery of Process Manager following an outage may take some time. The more recent the system image, the shorter the recovery time.

JS_DATACAPTURE_TIME specifies the schedule that determines when an image of the workload in the system is saved for recovery purposes. The schedule is specified in the form of a calendar name and owner and time, and is enclosed in double quotes. You can specify one or more schedules in a comma-separated list.

During data capture, Process Manager Server does not submit new work. Ideally, schedule this activity at a time when Process Manager is least busy. You may need to adjust this schedule to find the balance between frequency and duration of the process, to ensure server productivity.

Default

The default is Daily@Sys:0:0 (daily at midnight).

JS_DEFAULT_FLOW_WORKING_DIR

Syntax

JS_DEFAULT_FLOW_WORKING_DIR=path

Description

Specifies the default working directory that is used by flows when no working directory is defined in the flow definition or passed to Process Manager with the variable JS_FLOW_WORKING_DIR.

Process Manager creates the default working directory and any specified subdirectories if the directories do not exist.

To specify subdirectories, you can use the built-in variables:

  • %u for user name
  • %t for time stamp
  • #{JS_FLOW_NAME}
  • #{JS_FLOW_ID}

Work items inherit the flow working directory unless users override the working directory in individual work items.

The override order for working directories is (in order of highest precedence):

  1. The working directory defined at the job level, in the Job Definition.
  2. The working directory defined at the subflow level, in the subflow's Flow Attributes.
  3. The working directory defined at the flow level, in the Flow Attributes.
  4. The working directory specified with the variable JS_FLOW_WORKING_DIR when you trigger a flow.
  5. The working directory defined with JS_DEFAULT_FLOW_WORKING_DIR in js.conf.
  6. The execution user's home directory:
    • Linux®: $HOME
    • Windows: %HOMEDRIVE%%HOMEPATH%

Requirements for the working directory:

  • The directory and parent directories to the working directory must be shared and accessible to the Process Manager server and all LSF® execution hosts.

    For example, if you specify JS_DEFAULT_FLOW_WORKING_DIR=/home/lsfadmin/#{JS_FLOW_NAME}_%t, the directory /home/lsfadmin must exist and must be shared.

  • The shared directory must be writable by the user who submits the flow, and by execution users of individual work items(Run As user).
  • If the root directory cannot be shared, the directory:
    • Must exist on all LSF execution hosts
    • Must have the same path on all LSF execution hosts
    • Must be writable by the user who submits the flow definition and by execution users of work items in the flow and any subflows
  • Windows: The working directory must be set to a physical drive on the machine such as C:\ . If you need to refer to a network drive, create a symbolic link inside your C:\ drive.

Automatically created directories have the following permissions:

  • Owner is the execution user
  • Owning group is the execution user's group
  • Read and write execute permissions are set for the owner
  • Linux: read and write execute permissions are set for all
  • Windows: new folders have full permissions set for the execution user

Default

Undefined. When no working directory is specified for the flow in the flow definition or with JS_FLOW_WORKING_DIR, the location that is used for the working directory is the execution user's home directory:

  • Linux: $HOME
  • Windows: %HOMEDRIVE%%HOMEPATH%

Examples

Create a separate directory for each flow that is triggered from the flow definition in the user's home directory, with a time stamp at the end:

  • Linux: JS_DEFAULT_FLOW_WORKING_DIR=/home/%u/#{JS_FLOW_NAME}_%t

    If the user is user1, the flow name myflow, and the flow ID 123, the directory that is created is:

    /home/user1/123:user1:myflow_1366648793

  • Windows: JS_DEFAULT_FLOW_WORKING_DIR=C:\shared\%u\#{JS_FLOW_NAME}_%t

    If the user is user1, the flow name myflow, and the flow ID 123, the directory that is created is:

    c:\shared\123_user1_myflow_1366648793

JS_DEFAULT_USER_VARIABLE_VALUE_IS_EMPTY

Syntax

JS_DEFAULT_USER_VARIABLE_VALUE_IS_EMPTY=false | true

Description

Defines how a user variable whose value is not set is interpreted by Process Manager.

When set to false, when a flow runs and a user variable is specified in the flow and its value is not set, Process Manager interprets the variable as specified. For example: if in the job definition you specified the command ls #{MYDIR}, when the flow runs and MYDIR is not set, Process Manager interprets the command as: ls #{MYDIR}.

When set to true, when a flow runs and a user variable is specified in the flow and its value is not set, Process Manager interprets the variable as being set to empty. For example: if in the job definition you specified the command ls #{MYDIR}, when the flow runs and MYDIR is not set, Process Manager interprets MYDIR=" ", and the command as: ls.

Default

The default is false.

JS_DTD_DIR

Syntax

JS_DTD_DIR=JS_HOME/9.1.0.0/etc

Description

DO NOT CHANGE THIS VALUE.

Specifies the directory containing the DTD files required by Process Manager.

Default

The default is JS_HOME/10.2/etc

JS_ENABLE_DOUBLE_QUOTE

Syntax

JS_ENABLE_DOUBLE_QUOTE=true | false

Description

Applies only to Linux/UNIX.

Applies to LSF jobs. Configures whether job commands are to be quoted with single quotation marks or double quotation marks.

When this parameter is set to false, the LSF bsub job command is always quoted with single quotation marks.

When this parameter is set to true:

  • If the LSF bsub job command does not contain single quotation marks, the job command is quoted with single quotation marks.

  • If the LSF bsub job command contains single quotation marks, it is quoted with double quotation marks.

    Adding double quotation marks means that the command will be interpreted before it is sent to LSF.

    For example, if the command is ls -l | awk {print '$2}', it becomes: bsub "ls -l | awk {print '$2}'".

Default

False. The LSF bsub job command is always quoted with single quotation marks.

JS_ENABLE_GROUP_ADMIN

Syntax

JS_ENABLE_GROUP_ADMIN=true | false

Description

When set to true, users that are specified in the GROUP_ADMIN column for an LSF user group in the configuration file lsb.users are considered Process Manager Group administrators. In addition, the Owner field is displayed in the Flow Attributes in Flow Editor, and in the Calendar description in Calendar Editor.

For flows:

  • Group administrators can operate on flows that are owned by accounts that are listed in the column GROUP_MEMBER in lsb.users for their group.

    Tip: If you want a Group administrator to be able to submit, trigger, and control flows that are owned by another Group administrator, specify the other Group administrator account in the column GROUP_MEMBER in lsb.users.

For calendars:

  • Group administrators can modify and delete calendars that are owned by accounts that are listed in the column GROUP_MEMBER in lsb.users for their group.

    Tip: If you want a Group administrator to be able to modify and delete calendars that are owned by another Group administrator, specify the other Group administrator account in the column GROUP_MEMBER in lsb.users.

Default

The default is false. Group administrators that are defined in lsb.users have no special privileges in Process Manager.

JS_ENCRYPTION

Syntax

JS_ENCRYPTION=true | false

Description

Specifies whether to encrypt communication between Process Manager Server and Process Manager Client.

Default

The default is false—do not encrypt communication.

JS_EXTERNAL_EXECUTION

Syntax

JS_EXTERNAL_EXECUTION=false | true

Description

UNIX only.

Specifies that the external execution daemon (EED) is to be enabled. This allows the Process Manager daemon (JFD) to delegate any command execution to the EED so that the JFD does not need to use the fork() function to execute commands. This provides a significant performance enhancement if the JFD’s memory footprint is large (usually greater than 1 GB).

JFD communicates with EEDs through full-duplex pipes. JFD passes the commands to execute to the EEDs and reads the output of the commands from the EEDs. The EEDs collect the exit status of the commands.

JFD maintains the connection between itself and the EEDs, and restarts any EED that shuts down. If JFD is shut down, the EED will exit in 15 seconds.

Default

The default is JS_EXTERNAL_EXECUTION=false.

JS_FAILOVER

Syntax

JS_FAILOVER=false | true

Description

OPTIONAL if failover is not used. REQUIRED if failover is used.

Specifies that the failover feature is to be enabled. The failover feature provides automatic failover in the event the Process Manager Server host becomes unavailable.

Default

The default is JS_FAILOVER=false.

See also

JS_FAILOVER_HOST, JS_FOD_PORT

JS_FAILOVER_HOST

Syntax

JS_FAILOVER_HOST=host_name

Description

OPTIONAL if failover is not used. REQUIRED if failover is used.

Specifies the fully-qualified host name of the failover host.

If you specified JS_FAILOVER=true, specify the name of the host where Process Manager Server will run if the primary Process Manager Server host is unavailable.

Default

The default is the same host name as that specified for Process Manager Server.

See also

JS_FAILOVER, JS_FOD_PORT

JS_FILE_AGE_EVENT_REPEATABLE

Syntax

JS_FILE_AGE_EVENT_REPEATABLE=true | false

Description

Specifies whether Process Manager can repeatedly trigger a flow with a file event and the condition of last modified (age).

When JS_FILE_AGE_EVENT_REPEATABLE=true, Process Manager can repeatedly trigger a flow with a file event and the condition last modified (age), if the event condition is met.

Default

JS_FILE_AGE_EVENT_REPEATABLE=false

JS_FILEAGENT_SENSITIVITY

Syntax

JS_FILEAGENT_SENSITIVITY=seconds

Description

Specifies the time interval in seconds at which Process Manager checks for changes in the file system. This value is used when testing file events.

Default

The default is 30 seconds.

JS_FLOW_STATE_MAIL

Syntax

JS_FLOW_STATE_MAIL=true | false

Description

Specifies whether or not to allow flow email notifications. When set to true, flow email notification occurs as specified by the user in each flow. When set to false, flow email notification does not occur. This setting has no effect on individual job email notifications or alarm email notifications.

Default

The default is true—enable flow email notification.

See also

JS_MAIL_SIZE

JS_FOD_PORT

Syntax

JS_FOD_PORT=number

Description

OPTIONAL if failover is not used. REQUIRED if failover is used.

Specifies the port number of the failover daemon fod.

If you specified JS_FAILOVER=true, specify the port number to be used for communication between the failover daemon and the Process Manager Server daemon.

Default

The default is 1999.

See also

JS_FAILOVER, JS_FAILOVER_HOST

JS_FY_MONTH

Syntax

JS_FY_MONTH=n

Description

OPTIONAL.

Specifies the number that corresponds to the starting month of the fiscal year. This value is used in certain system calendars. Specify a value from 1 (January) to 12 (December). For example, to specify March, specify JS_FY_MONTH=3.

Default

The default is 7 (July).

JS_HISTORY_ARCHIVE_DIR

Syntax

JS_HISTORY_ARCHIVE_DIR=/path

Description

Path and name to the directory in which history logs are archived. If the directory does not exist, it is created by Process Manager.

When JS_HISTORY_ARCHIVE_DIR is not defined, any history log files older than the time period specified by JS_HISTORY_CLEAN_PERIOD are deleted by Process Manager.

When JS_HISTORY_ARCHIVE_DIR is defined, any history log files older than the time period specified by JS_HISTORY_CLEAN_PERIOD are moved to the directory specified by JS_HISTORY_ARCHIVE_DIR.

The directory specified by JS_HISTORY_ARCHIVE_DIR must have the same owner and permission as JS_HOME/work/history/. The directory must be owned and must be writable by the Process Manager administrator, and must be readable by everyone. JFD checks permissions and reports error messages in jfd.log.xxx if it does not have permission to move the history logs into the specified directory.

If failover is configured, the directory specified by JS_HISTORY_ARCHIVE_DIR must be on a shared file system and accessible by both the primary Process Manager server and the failover hosts.

If after setting JS_HISTORY_ARCHIVE_DIR you need to change the location, manually move existing archived history logs to the new location.

You can use the command jhist -t to view archived history logs by running jhist from the Process Manager server host. When jhist is run from the Process Manager server host, Process Manager searches both JS_HOME/work/history/ and JS_HISTORY_ARCHIVE_DIR for history logs. When jhist is run from a host that is not the Process Manager server host, Process Manager only searches JS_HOME/work/history/ for history logs.

Default

Undefined. History log files are deleted according to the time period defined by JS_HISTORY_CLEAN_PERIOD.

JS_HISTORY_CLEAN_PERIOD

Syntax

JS_HISTORY_CLEAN_PERIOD=days

Description

Specifies the time period in days for which history log files are stored. When JS_HSITORY_ARCHIVE_DIR is not defined, any history log files older than the specified time period are deleted by Process Manager. If JS_HISTORY_ARCHIVE_DIR is defined, any history log files older than the specified time period are moved to the directory specified by JS_HISTORY_ARCHIVE_DIR.

Default

The default is 15 days.

JS_HISTORY_LIFETIME

Syntax

JS_HISTORY_LIFETIME=hours

Description

Specifies the time period in hours for which history data is collected before a new history log file is created. If the size of the log file exceeds the file size specified in JS_HISTORY_SIZE, a new log file is created, regardless of how many hours of data it contains.

Default

The default is 24 hours.

See also

JS_HISTORY_SIZE

JS_HISTORY_LIMIT

Syntax

JS_HISTORY_LIMIT=number_of_records

Description

Specifies the maximum number of history records retrieved when the jhist command is used and your Process Manager Client and Process Manager Server are on different hosts. If more than the maximum number of records are available, only the oldest number of records you specify in this parameter are retrieved.

Default

The default is 1500 history records.

JS_HISTORY_SIZE

Syntax

JS_HISTORY_SIZE=bytes

Description

Specifies the maximum number of bytes a history log file can grow to before a new log file is created. If the number of hours of data exceeds the time period specified in JS_HISTORY_LIFETIME, a new log file is created, regardless of its size.

Default

The default is 500000 bytes (500 KB).

See also

JS_HISTORY_LIFETIME

JS_HOME

Syntax

JS_HOME=/path

Description

Specifies the full path to the top-level installation directory.

Corresponds to JS_TOP in install.config.

Default

There is no default for this parameter. A value is set at installation time.

JS_HOST

Syntax

JS_HOST=host_name

Description

REQUIRED.

Specifies the fully-qualified domain name of the host on which Process Manager Server runs—the name of the host to which the clients connect under normal operations. You cannot specify more than one host.

Default

There is no default for this parameter. A value is set at installation time.

See also

JS_PORT

JS_IM_ACTIVEPOLICY

Syntax

JS_IM_ACTIVEPOLICY=JF_IM_IPolicy | JF_IM_TPolicy

Description

Specifies the criteria used by Process Manager to determine when to delete a completed flow from the working set. Also controls the amount of information saved to the cache file.

Specify JF_IM_IPolicy if you want to use the number of occurrences of the flow as the criteria to delete the flow. The oldest occurrence is deleted first.

Specify JF_IM_TPolicy if you want to use the length of time since the flow completed as the criteria to delete the flow. The oldest occurrence is deleted first.

Default

The default policy is JF_IM_IPolicy.

See also

JS_IM_POLICY_CHECKING_INTERVAL

JS_IM_POLICY_CHECKING_INTERVAL

Syntax

JS_IM_POLICY_CHECKING_INTERVAL=minutes

Description

Specifies the time interval in minutes at which Process Manager applies the policy specified in JS_IM_ACTIVEPOLICY.

Default

The default interval is 12 minutes.

See also

JS_IM_ACTIVEPOLICY, JS_IM_POLICY_LIFETIME, JS_IM_POLICY_NOOFFLOWS

JS_IM_POLICY_LIFETIME

Syntax

JS_IM_POLICY_LIFETIME=days

Description

Specifies the time interval in days after which completed flows are deleted from the Process Manager working set.

This value takes effect when JS_IM_ACTIVEPOLICY = JF_IM_TPolicy. The oldest occurrence is deleted first.

Default

The default is 5 days.

See also

JS_IM_ACTIVEPOLICY, JS_IM_POLICY_CHECKING_INTERVAL, JS_IM_POLICY_NOOFFLOWS

JS_IM_POLICY_NOOFFLOWS

Syntax

JS_IM_POLICY_NOOFFLOWS=number

Description

Specifies the number of completed flows per flow definition that are retained within the Process Manager working set. Specify a number greater than 0.

This value takes effect when JS_IM_ACTIVEPOLICY = JF_IM_IPolicy. The oldest occurrence is deleted first.

Default

The default is 36 completed flows per flow definition.

See also

JS_IM_ACTIVEPOLICY, JS_IM_POLICY_LIFETIME, JS_IM_POLICY_CHECKING_INTERVAL

JS_JOB_SUBMISSION_RETRY

Syntax

JS_JOB_SUBMISSION_RETRY=true | false

Description

Deprecated. Use JS_BSUB_RETRY_EXIT_VALUES instead.

Specifies whether to retry job submission after the job fails.

If JS_JOB_SUBMISSION_RETRY=true and JS_BSUB_RETRY_EXIT_VALUES is not defined, job submission is retried when the LSF bsub exit code is 1, 255, 127, -1, 128.

If JS_BSUB_RETRY_EXIT_VALUES is defined, JS_JOB_SUBMISSION_RETRY is ignored and considered deprecated, and Process Manager retries to submit the job again when LSF bsub exits with the exit codes specified in JS_BSUB_RETRY_EXIT_VALUES.

If JS_BSUB_RETRY_EXIT_VALUES and JS_JOB_SUBMISSION_RETRY are not defined, there is no retry when job submission fails.

Default

False. There is no retry when job submission fails.

JS_JOB_SUBMISSION_TIMEOUT

Syntax

JS_JOB_SUBMISSION_TIMEOUT=seconds

Description

Applies to job scripts.

Maximum number of seconds that the job script can take to submit jobs to LSF before the Process Manager daemon (jfd) terminates the script.

Specify 0 to set the maximum time to unlimited.

Default

300 seconds

JS_JOB_SUBMISSION_SCRIPT_TIME_OUT

Syntax

JS_JOB_SUBMISSION_SCRIPT_TIME_OUT=seconds

Description

Specifies the length of time for which the job submission script can run before the Process Manager daemon (JFD) kills the script.

Default

The default is 300 seconds.

JS_JOB_SUBMIT_NOTICE_THRESHOLD

Syntax

JS_JOB_SUBMIT_NOTICE_THRESHOLD=number

Description

Specifies when job queue size is logged. When the job queue reaches the size specified by JS_JOB_SUBMIT_NOTICE_THRESHOLD and every multiple of that number, the job queue size is logged in $JS_TOP/log/jfd.log.host_name. It is logged at LOG_NOTICE level.

Default

100 entries

JS_KRB_KEYTAB_FILE

Syntax

JS_KRB_KEYTAB_FILE=/path/filename

Description

Used for Kerberos integration with Process Manager, when the parameter JS_KRB_USE_KEYTAB=true.

Path to the Kerberos keytab file on the Process Manager server host.

Default

If this parameter is not specified, the default value is /etc/krb5.keytab on the Process Manager Server host.

See also

JS_KRB_USE_KEYTAB

JS_KRB_USE_KEYTAB

Syntax

JS_KRB_USE_KEYTAB=true | false

Description

Used for Kerberos integration with Process Manager. When set to true, this parameter specifies to Process Manager to use the Kerberos keytab file to generate user TGTs before reaching the maximum renewal lifetime defined by the parameter LSB_KRB_RENEW_MARGIN in lsf.conf. This is useful when you run flows repeatedly over a long period of time (monthly, annually) or when you have flows that run for a very long time so that user TGTs are renewed before the maximum renewal lifetime period is reached.

When set to false, Process Manager automatically renews user TGTs but will be unable to renew them once the maximum renewal lifetime period has been reached. To prevent jobs from failing due to lack of credentials, users with accounts used to run jobs will need to log into Process Manager at least once during the maximum renewal lifetime period so that Process Manager can generate a new user TGT before the maximum renewal lifetime period is reached.

Default

JS_KRB_USE_KEYTAB=false

See also

JS_KRB_KEYTAB_FILE

JS_KRB_USE_KINIT

Syntax

JS_KRB_USE_KINIT=true | false

Description

Used for Kerberos integration with Process Manager. This parameter works only when JS_LOGIN_REQUIRED=true.

When JS_LOGIN_REQUIRED=false, this parameter is ignored.

When JS_KRB_USE_KINIT=false, Process Manager uses the Pluggable Authentication Module(PAM) on the Process Manager server to generate and renew a user TGT.

Note: You must configure the Pluggable Authentication Module(PAM) on the Process Manager server. Refer to Administering IBM Spectrum LSF Process Manager for instructions.

Set JS_KRB_USE_KINIT=true if for some reason the system does not allow Process Manager to generate a user TGT or you are unable to configure the Pluggable Authentication Module(PAM) on the Process Manager server. When JS_KRB_USE_KINIT=true, each time the user logs in to Process Manager server, Process Manager generates a TGT for the user even if the TGT did not expire.

Note: To generate a TGT, Process Manager uses the Kerberos command kinit. Ensure the Kerberos command kinit is accessible and executable by the execution user on the Process Manager Server. For example, the execution user can log on to the Process Manager server host and run kinit to generate a Kerberos ticket.

Default

JS_KRB_USE_KINIT=false

See also

JS_LOGIN_REQUIRED

JS_LARGE_FLOW_SAVE

Syntax

JS_LARGE_FLOW_SAVE=y | n

Description

Used to improve client performance in Flow Editor and Flow Manager when a user opens or submits a flow that is larger than 12 MB.

When set to y, a temporary file is saved in the system temporary directory (Windows: user's temporary directory, Unix/Linux: /var/tmp or /tmp) when a user opens or submits a large flow. This improves client performance as the file is not saved in memory, but temporarily on disk. Once the flow is open or submitted, the file is automatically deleted.

When set to n, when a user opens or submits a flow, the flow is saved in memory.

Default

Undefined, same as n: the flow is saved in memory when it is opened or submitted.

JS_LIMIT_FLOW_CHART_VIEW

Syntax

JS_LIMIT_FLOW_CHART_VIEW=true | false

Description

Specifies whether users can see the chart view of a flow and flow definition.

When this parameter is set to false, users who can view a flow or flow definition, can see everything about the flow: flow chart, general information, subflows and jobs, flow data, and flow history. These users can also perform job and subflow-specific actions.

When this parameter is set to true, there are restrictions on which users can see the flow chart of a flow and flow definition and associated actions the user can take on components of the flow.

Permissions

The following table illustrates permissions when JS_LIMIT_FLOW_CHART_VIEW=true.

Can see the flow chart of a flow definition

Can see the flow chart of a flow

Process Manager administrator (as defined by JS_ADMINS)

Y

Y

Control administrator (as defined by JS_CONTROL_ADMINS)

Y, if the user is the flow definition owner.

Y, if the user is both the flow definition owner and flow owner.

For example, if a user submitted a flow from another user's published flow definition, he will not be able to view the flow chart. He is the flow owner, but not the flow definition owner.

Non-administrator users

Y, if the user is the flow definition owner.

Y, if the user is both the flow definition owner and flow owner.

For example, if a user submitted a flow from another user's published flow definition, he will not be able to view the flow chart. He is the flow owner, but not the flow definition owner.

The following table illustrates permissions when JS_LIMIT_FLOW_CHART_VIEW=false.

Can see the flow chart of a flow definition

Can see the flow chart of a flow

Process Manager administrator (as defined by JS_ADMINS)

Y

Y

Control administrator (as defined by JS_CONTROL_ADMINS)

Y, if the user can see the flow definition.

Y, if the user can see the flow.

Non-administrator users

Y, if the user can see the flow definition.

Y, if the user can see the flow.

User interface affected

In Flow Manager:

  • If the user does not have permission to see the flow chart: the Open and Open in New Frame on the right-click menu and top drop-down menu will be disabled.

In IBM Spectrum LSF Application Center:

  • If the user does not have permission to see the flow chart, the Flow Chart tab will not be displayed in the flow definition list page, flow submission form page, and flow/job list page. Consequently, any actions that can only be taken from the Flow Chart view will also not be available. Users can select the Subflows and Jobs tab, and click on the ID of a job to navigate to the Jobs page and take action on individual jobs.

Default

The default is false.

See also

JS_ADMINS, JS_CONTROL_ADMINS, JS_LIMIT_USER_VIEW, JS_CHANGE_FLOW_OWNER

JS_LIMIT_USER_VIEW

Syntax

JS_LIMIT_USER_VIEW=true | false

Description

Specifies whether a user’s view of flows is limited to their own flows, or includes all flows in Process Manager. For a guest user, limits the access so that no flows are viewable.

When this parameter is set to true and JS_CHANGE_FLOW_OWNER is set to true:

  • The user who is logged on can view and control flow definitions that he owns
  • If the flow definition was not created by the user who is logged on, operations on the flow definition are disabled.
  • The user who is logged on can view and control flows that he owns.

Default

The default is false.

See also

JS_CHANGE_FLOW_OWNER

JS_LIMIT_MODIFY_GLOBALVAR

Syntax

JS_LIMIT_MODIFY_GLOBALVAR=true | false

Description

Specifies whether to allow or deny users the privilege of controlling global variables through jsetvars or flow manager. When set to true, only administrators can modify global variables. When set to false, users and administrators can modify global variables.

Default

The default is true.

JS_LOCAL_EXECUTION_TIMEOUT

Syntax

JS_LOCAL_EXECUTION_TIMEOUT=seconds

Description

Specifies the amount of time, in seconds, that each local job is allowed to run before Process Manager forcefully terminates the job. If you set this to be zero or less, Process Manager uses the default value.

Default

Linux and UNIX: no timeout on the job. There is no limit on how long the local job can run.

Windows: 180 seconds.

JS_LOCAL_JOBS_LIMIT

Syntax

JS_LOCAL_JOBS_LIMIT=number_of_jobs

Description

Specifies the maximum number of local jobs that can be run in parallel on the Process Manager Server.

When this parameter is set to 0, local jobs are disabled:

  • If any existing flows contain local jobs, the local jobs are not run and exit with an exit code of 1.
  • In Flow Editor, local jobs cannot be inserted in the flow definition, and any flow definitions that contain local jobs cannot be submitted.
  • In Flow Manager, flow definitions that contain local jobs cannot be triggered, released, or published.

Default

The larger number between 1, and the number of cores on the Process Manager host - 2. For example, if the Process Manager host has 4 cores, the maximum number of local jobs that can be run in parallel is 2.

JS_LOGDIR

Syntax

JS_LOGDIR=/path

Description

Specifies the name of the directory containing the jfd.log file, the error log file for the Process Manager Server daemon.

Default

The default is JS_HOME/log.

JS_LOGIN_REQUIRED

Syntax

JS_LOGIN_REQUIRED=true | false

Description

Specifies if a user login is required to access Process Manager. Set as true if you want to require users to log in before using Process Manager.

If you set this parameter to true on the Process Manager server, set JS_LOGIN_REQURED=true in the js.conf file of all Process Manager clients. An error is displayed to the user when the value of the JS_LOGIN_REQUIRED parameter on the client does not match that of the server.

If you set this parameter to false on the Process Manager server, you can set JS_LOGIN_REQURED to either true or false on Process Manager clients. When set to false, users are not required to specify a user name and password to use Process Manager.

Default

The default is false; users are not required to log in to use Process Manager.

See Also

JS_KRB_USE_KINIT

JS_LOGON_RETRY

Syntax

JS_LOGON_RETRY=number

Description

Specifies the number of times Process Manager should resubmit the same job to LSF when logon fails.

Default

The default is 0.

JS_LOGON_RETRY_DELAY

Syntax

JS_LOGON_RETRY_DELAY=seconds

Description

Specifies the number of seconds to wait in between each try to resubmit the same job to LSF when logon fails.

Default

The default is 10 seconds.

JS_LOG_MASK

Syntax

JS_LOG_MASK=value

Description

Specifies the error logging level used. Change this value only as directed by IBM Technical Support. Valid values from highest to lowest are:

  • LOG_EMERG
  • LOG_ALERT
  • LOG_CRIT
  • LOG_ERR
  • LOG_WARNING
  • LOG_NOTICE
  • LOG_INFO
  • LOG_DEBUG
  • LOG_DEBUG1
  • LOG_DEBUG2
  • LOG_DEBUG3

The level specified by the log mask determines which messages are recorded and which are discarded. All messages logged at the specified level or higher are recorded, while lower level messages are discarded.

For debugging purposes, the level LOG_DEBUG contains the fewest number of debugging messages and is used for basic debugging. The level LOG_DEBUG3 records all debugging messages, and can cause log files to grow very large; it is not often used. Most debugging is done at the level LOG_DEBUG2.

Default

The default is JS_LOG_MASK=LOG_NOTICE.

JS_LSF_COMMAND_TIMEOUT

Syntax

JS_LSF_COMMAND_TIMEOUT=seconds

Description

Maximum number of seconds that any LSF command can take to execute before the Process Manager daemon (jfd) terminates it. This is used when the Process Manager daemon (jfd) calls any LSF command. If there are problems with command execution, the Process Manager daemon will terminate the process after the specified timeout value.

Default

300 seconds

JS_MAILHOST

Syntax

For Windows: JS_MAILHOST=[SMTP: | EXCHANGE:]hostname
For Unix: JS_MAILHOST=hostname

Description

OPTIONAL.

Specifies the name of the mail server host.

On Windows, specify the protocol and name of the mail server host. For an SMTP mail host, specify SMTP:hostname. For a Microsoft Exchange mail host, specify EXCHANGE:hostname. That is:

JS_MAILHOST=[SMTP: | EXCHANGE:]hostname

On UNIX, specify just the name of the mail server host. That is:

JS_MAILHOST=hostname

Note: JS_MAILHOST is equivalent to LSB_MAILSERVER in LSF.

Default

If Process Manager Server is installed on Windows, the default is EXCHANGE:localhostname. If Process Manager Server is installed on UNIX, the default is localhostname.

JS_MAILPROG

Syntax

JS_MAILPROG=file_name

Description

Path and file name of the mail program used by Process Manager to send email. It affects all emails sent, such as the sending of messages from the Flow Attribute, from alarms, and from manual jobs. Equivalent to LSB_MAILPROG in LSF.

You can write your own custom mail program and set JS_MAILPROG to the path where this program is located.

The program:

  • Can be a shell script, a binary executable, or, a .bat file on Windows. Any program or shell script that accepts the arguments and input, and delivers the mail correctly, can be used.
  • Must read the body of the mail message from standard input. The end of the message is marked by end-of-file.
  • Must be executable by any user.
  • Must follow the same protocol as sendmail. For example:
/usr/mymail.sh -oi -F "Subject" -f "JFD" usera@ibm.com </dev/stdin

Process Manager calls JS_MAILPROG with three arguments: one argument gives the full name of the subject -F "Subject", the other argument gives the address of the sender -f , and the third argument the email address to which to send the message.

If you change your mail program, restart jfd with the commands jadmin start and jadmin stop to make changes take effect.

In a mixed cluster, you can specify different programs for Windows and UNIX. You can set this parameter during installation on Windows.

For your convenience, Process Manager provides the lsmail program for Unix and the lsmail.exe mail program, which supports SMTP and Microsoft Exchange Server protocols on Windows. If lsmail is specified, the parameter LSB_MAILSERVER must also be specified in LSF. On Windows, lsmail.exe can be configured directly. On Unix, the full path to the lsmail binary is required for configuration.

Examples

JS_MAILPROG=/serverA/tools/lsf/bin/unixhost.exe

Default

By default, this parameter is undefined and the following default mail programs are used:

  • UNIX: /usr/lib/sendmail
  • Windows: lsmail.exe

See also

JS_MAILHOST to specify the name of the mail server host.

JS_MAILSENDER to specify the email address of the sender.

JS_MAILSENDER

Syntax

JS_MAILSENDER=emailaddress@emaildomain

Description

OPTIONAL.

Specifies the email address that is used to send the job notification email. This email address is the sender address of any job notification or alarm emails.

Valid values

Any valid email address. There cannot be any spaces in the email address.

Default

The default name of the email sender is JFD.

JS_MAIL_SIZE

Syntax

JS_MAILSIZE=bytes

Description

OPTIONAL.

Specifies the maximum size allowed for a flow email notifications. An email larger than the maximum size specified is truncated.

Default

The default is 1000000 (1MB).

JS_MAX_VAR_SUBSTITUTIONS

Syntax

JS_MAX_VAR_SUBSTITUTIONS=number

Description

OPTIONAL.

Specifies the maximum number of variable substitutions that can be performed in a single job definition field.

Default

20 substitutions

JS_PAC_SERVER_URL

Syntax

JS_PAC_SERVER_URL=http://host_name:port | https://host_name:port

Description

Used for Flow Editor in IBM Spectrum LSF Application Center. Required when submission forms are included in flow definitions.

Specifies the URL to connect to IBM Spectrum LSF Application Center. Process Manager daemon(jfd) contacts LSF Application Center server to submit workload with the submission forms included in flows.

Default

http://localhost:8080

Examples

JS_PAC_SERVER_URL=http://host1.example.com:8080

JS_PAC_SERVER_URL=https://host1.example.com:8443

See also

JS_SUBMIT_PAC_FORM_TIMEOUT

JS_PORT

Syntax

JS_PORT=number

Description

REQUIRED.

Specifies the port number to be used by the Process Manager Client to connect with the Process Manager Server.

Default

The default port number is 1966.

See also

JS_HOST

JS_POSIX_TZ

Syntax

JS_POSIX_TZ=time_zone

Description

Use only if your Process Manager server is running on AIX® 6.1, and Olson time zone is set in the /etc/environment file or through the TZ environment variable.

Specifies a time zone according to the POSIX time zone specification. The set time zone must be the equivalent of the Olson time zone set for the system.

This time zone setting does not affect the operating system setting. This setting is used by the Process Manager Server to work around a known issue in AIX 6.1 that ignores the set Olson time zone and uses instead Coordinated Universal Time(UTC)/Greenwich Mean Time(GMT).

The time_zone must be indicated according to the POSIX specification:

std offset dst [offset],start[/time],end[/time]

where:

  • [ ] indicate optional parameters
  • std offset specifies the standard time when the time zone is not in dst
  • dst [offset] specifies the time during dst for the time zone
  • start[/time] specifies the start time of dst
  • end[/time] specifies the end time of dst
  • start and end is in the format, Mm.w.d:
  • m is the month (number between 1 - 12, and 1 is January)
  • w is the week (number between 1 - 5, 1 is first week, 5 is last week of the month)
  • d is the day (number between 0 - 6, 0 is Sunday)
  • [/time] is in regular time format. For example: 3:00, or simplified to 3. If no time is specified the default is 02:00 or 2.

For additional information on the POSIX time zone, refer to: http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html.

Examples

Olson time zone

Equivalent POSIX time zone

America/New_York

EST5EDT, M3.2.0,M11.1.0

Europe/Paris

CET-1CEST,M3.5.0,M10.5.0/3

Europe/Brussels

CET-1CEST,M3.5.0,M10.5.0/3

Default

Undefined, the time zone used is the time zone set on the operating system of the Process Manager Server.

JS_PROXY_DURATION

Syntax

JS_PROXY_DURATION=minutes

Description

Specifies the length of time within which proxy events should remain valid after becoming true.

A value of 0 indicates that the proxy event will always remain valid and will never expire after it becomes true.

Default

The default is 0.

JS_SERVICE_STOP_PEND_WAIT

Syntax

JS_SERVICE_STOP_PEND_WAIT=milliseconds

Description

Windows only.

Specifies the amount of time that the Process Manager daemon (JDF) instructs the Windows service controller to wait before killing the service during a system reboot or shutdown.

When a host is being rebooted or shut down, the Process Manager daemon (JFD) sends a STOP_PEND message together with a waitHint to the Windows service controller to wait for this amount of time before allowing the system to kill the service.

The system registry key HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > WaitToKillServiceTimeout normally specifies the amount of time that Windows waits before killing all services. JS_SERVICE_STOP_PEND_WAIT must be less than or equal to this value; otherwise the Windows service controller kills the service in the amount of time as specified in this registry key, before this parameter can take effect.

Default

The default is specified in the system registry key HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > WaitToKillServiceTimeout. The default value for this system registry key is 20000 milliseconds (20 seconds).

JS_START_RETRY

Syntax

JS_START_RETRY=retries

Description

Specifies the maximum number of times Process Manager tries again to submit a job or job array, or start a job or job array before raising a Start Failed exception.

Default

The default is 20 times.

See also

JS_BSUB_RETRY_EXIT_VALUES

JS_SUBMISSION_FORM_EXEC_AGENT_THREADS

Syntax

JS_SUBMISSION_FORM_EXEC_AGENT_THREADS=1 | 2 | 3 | 4 | 5

Description

Used when Process Manager is used in IBM Spectrum LSF Application Center. Maximum number of submission forms that can be simultaneously submitted. This parameter is useful to improve performance when submission forms are included in flow definitions. When submission forms are used by many concurrent users, specify a larger number for this parameter to improve system response.

Default

2

JS_SUBMIT_PAC_FORM_TIMEOUT

Syntax

JS_SUBMIT_PAC_FORM_TIMEOUT=seconds

Description

Maximum number of seconds that the Process Manager daemon(jfd) waits to communicate with IBM Spectrum LSF Application Center. This is used when submission forms are included in flow definitions.

Default

300 seconds

See also

JS_PAC_SERVER_URL

JS_SU_COMMAND

Syntax

JS_SU_COMMAND="command %u"

Description

Used by Process Manager server to impersonate users for job submission within flows. The Process Manager server runs as root and uses the command /bin/su to impersonate other users.

In some cases, you may want Process Manager server to use a different command to impersonate users. Specify the exact command required by the root user to impersonate another user (%u).

When JS_SU_COMMAND is set to a value, the parameter JS_SU_NEW_LOGIN is ignored.

Examples


JS_SU_COMMAND="/bin/su %u"
JS_SU_COMMAND="op %u"
Note:

If you specify the op command, configure op in op.conf so that the root user can execute "op user_name bash_script_to_bsub". For example:

op lsfadmin /tmp/bsubSubmit.sh

An example of op.conf:

 lsfadmin /bin/bash $* ; uid=lsfadmin

Default

Unset. The default value of JS_SU_COMMAND depends on the setting of JS_SU_NEW_LOGIN. If JS_SU_NEW_LOGIN=false(default value), the default value of JS_SU_COMMAND is "/bin/su - %u". If JS_SU_NEW_LOGIN=true, the default value of JS_SU_COMMAND is "/bin/su %u".

JS_SU_NEW_LOGIN

Syntax

JS_SU_NEW_LOGIN=true | false

Description

This parameter is ignored if JS_SU_COMMAND is set. Specifies whether or not to start a new login shell when Process Manager server submits jobs to LSF. When this parameter is set to true, a new login shell is started when a job is submitted to LSF.

Default

JS_SU_NEW_LOGIN=true

JS_TIME_EVENT_OFFSET

Syntax

JS_TIME_EVENT_OFFSET=integer

Description

Specifies the time event offset to adjust the LSF Process Manager server time. The offset is added to all the time events of a flow so that they are triggered according to the adjusted server time. The time event calculation compares the difference between the current server time and the time event. The resulting difference is added to the offset defined in JS_TIME_EVENT_OFFSET so that all time events of the flow are triggered according to the adjusted calculation.

The valid range is -180 to 180 minutes.

If a country temporarily changes their time zone (for example, delaying Daylight Savings Time (DST) by a week), or the latest time zone data from https://github.com/unicode-org/icu-data/tree/master/tzdata/icunew does not contain the required time zone changes, it may be necessary to use the JS_TIME_EVENT_OFFSET parameter as a temporary measure.

When the time zone offset is no longer required, JS_TIME_EVENT_OFFSET can be disabled (set to 0) and LSF Process Manager restarted so that time events are scheduled at the current time zone.

Example

Setting JS_TIME_EVENT_OFFSET=90 will trigger all time events 1.5 hours later. If a flow or job within the flow is normally triggered at 2:00, when JS_TIME_EVENT_OFFSET=90, it will be triggered at 3:30.

Setting JS_TIME_EVENT_OFFSET=-90 will trigger all time events 1.5 hours earlier.

Default

0

JS_TIME_ZONE

Syntax

JS_TIME_ZONE=client | server | UTC

Description

Specifies the time zone displayed by the client. The time zone is displayed and used to define and schedule flows.

Server time zone is the time at the server.

Client time zone is the time at the client.

UTC time zone is Coordinated Universal Time (also known as Greenwich Mean Time or GMT).

Note: If you are scheduling a future event that takes place after a seasonal time change (such as Daylight Savings Time) and you have configured either server or client time zones, the time displayed at submission is the time at which the job runs.

When the server and the client are in the same time zone, the server time zone is displayed.

Default

The default is client.

JS_UNICODE_ESCAPE_CONVERT

Syntax

JS_UNICODE_ESCAPE_CONVERT=true | false

Description

Specifies whether Process Manager translates double-byte character sets to the Unicode character escape sequence.

When JS_UNICODE_ESCAPE_CONVERT=true, Process Manager supports double-byte character sets. For example, if a job name contains Chinese characters, Process Manager translates it to the Unicode character escape sequence such as \u1234.

In some cases, you may already have Unicode escape sequences in user names, job names, and so on. You do not want Process Manager to translate to the Unicode character set. You want Process Manager to use the text without converting it into Unicode format. In such cases, set JS_UNICODE_ESCAPE_CONVERT=false. Note, however, that setting JS_UNICODE_CONVERT=false disables double-byte character support and as a result, you may see garbled characters.

Default

JS_UNICODE_ESCAPE_CONVERT=true: Process Manager supports double-byte character sets and translates to the Unicode escape sequence.

JS_VARIABLE_CLEANUP_PERIOD

Syntax

JS_VARIABLE_CLEANUP_PERIOD=hours

Description

Specifies the cleanup frequency of variable log files. At the specified cleanup period, the JFD Process Manager daemon rewrites the variable.log file to reduce its size. This helps to reduce the startup time next time JFD restarts.

Default

The default cleanup period is set to 24 hours: JS_VARIABLE_CLEANUP_PERIOD=24

JS_WORK_DIR

Syntax

JS_WORK_DIR=/path

Description

Specifies the name of the directory containing work data.

Default

The default is JS_HOME/work.

LSF_ENVDIR

Syntax

LSF_ENVDIR=/path

Description

REQUIRED.

Default

Specifies the directory where the LSF configuration files are stored. There is no default for this value. A value is set at installation time.