|Table of Contents|
Some users observe the following error message when initially running jobs:
UnknownKey: No such environment variable: COMPUTERNAME
This problem can occur if example workflows have been used from JS7 - Download.
As a result some jobs of the example workflows fail with the above error message.
The error message indicates that an environment variable with the name
COMPUTERNAME is used in a job. However this environment variable does not exist.
- The reason is with the JS7 - Job Resources from the archive
Defaults.zipthat is offered from JS7 - Download. After import this archive is extracted to a JOC Cockpit folder with the name
Defaultsand a job resource with the name
Default. Find details from JS7 - Job Environment Variables.
Defaultjob resource includes an argument with the name
js7AgentHostnameand an environment variable with the name
JS7_AGENT_HOSTNAME. By default the argument is assigned this value:
js7AgentHostname = env('HOSTNAME', env('COMPUTERNAME'))
- The expression first makes use of a
HOSTNAMEenvironment variable (available for most Unix systems) and if this does not exist uses the
COMPUTERNAMEenvironment variable (available for Windows systems). Therefore running a job that makes use of the
Defaultjob resource on a Unix OS that does not provide the
HOSTNAMEenvironment variable causes the error.
HOSTNAMEenvironment variable that is assumed from the Job Resource in fact is a
bashvariable and might not be available if some other shell such as
tshis used or if the Agent's account is not assigned the
The assignment of the
js7AgentHostname argument is performed in the Configuration view for Job Resources like this:
Modify the value of the
js7AgentHostname argument like this:
js7AgentHostname = env('HOSTNAME', env('COMPUTERNAME', ""))
env()function makes use of two arguments: the first argument specifies an environment variable, the second argument specifies a default value should the environment variable not exist.
- Adding an empty default value - specified by two double quotes - as provided from the above example resolves the problem.
- To apply changes deploy the job resource after modification.
- As an alternative to this solution users can assign the
/bin/bashshell to the user account used by the Agent.