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.
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=daysIf 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=secondsDescription
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 | trueDescription
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.
- Job commands:
- 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=secondsDescription
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 | trueDescription
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=pathDescription
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):
- The working directory defined at the job level, in the Job Definition.
- The working directory defined at the subflow level, in the subflow's Flow Attributes.
- The working directory defined at the flow level, in the Flow Attributes.
- The working directory specified with the variable JS_FLOW_WORKING_DIR when you trigger a flow.
- The working directory defined with JS_DEFAULT_FLOW_WORKING_DIR in js.conf.
- 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 | trueDescription
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/etcDescription
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 | falseDescription
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 | falseDescription
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 | falseDescription
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 | trueDescription
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 | trueDescription
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_nameDescription
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 | falseDescription
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=secondsDescription
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 | falseDescription
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=numberDescription
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=nDescription
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=/pathDescription
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=daysDescription
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=hoursDescription
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_recordsDescription
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=bytesDescription
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=/pathDescription
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_nameDescription
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_TPolicyDescription
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=minutesDescription
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=daysDescription
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=numberDescription
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 | falseDescription
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=secondsDescription
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=secondsDescription
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=numberDescription
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/filenameDescription
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 | falseDescription
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 | falseDescription
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.
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.
Default
JS_KRB_USE_KINIT=false
See also
JS_LOGIN_REQUIRED
JS_LARGE_FLOW_SAVE
Syntax
JS_LARGE_FLOW_SAVE=y | nDescription
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 | falseDescription
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 | falseDescription
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 | falseDescription
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=secondsDescription
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_jobsDescription
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=/pathDescription
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 | falseDescription
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=numberDescription
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=secondsDescription
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=valueDescription
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=secondsDescription
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:]hostnameDescription
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
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@emaildomainDescription
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=bytesDescription
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=numberDescription
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:portDescription
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=numberDescription
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_zoneDescription
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=minutesDescription
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=millisecondsDescription
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
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
. The default value for this system registry key is 20000 milliseconds (20 seconds).JS_START_RETRY
Syntax
JS_START_RETRY=retriesDescription
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 | 5Description
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=secondsDescription
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"
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 | falseDescription
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=integerDescription
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 | UTCDescription
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 | falseDescription
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=hoursDescription
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=/pathDescription
Specifies the name of the directory containing work data.
Default
The default is JS_HOME/work.
LSF_ENVDIR
Syntax
LSF_ENVDIR=/pathDescription
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.