The JS7 Controller, Agents and JOC Cockpit make use of Unicode. When files are created or used then UTF-8 encoding applies.
- Unicode support works across any supported JS7 - Platforms.
- Limitations have to be considered in mixed environments that include Windows operating systems that ship without Unicode support and use a two byte subset UTF-16 LE.
JOC Cockpit requires the JS7 - Database to support UTF-8 encoding in order to store objects that hold such characters.
- For UTF-8 a single character stored to a JS7 database table requires 1 to 4 bytes.
- For example, NVARCHAR(10) specifies a column width of 10 characters that can consume 40 bytes.
The JDBC Drivers in use have to support Unicode.
When designing workflows with the Configuration -> Inventory view users can make use of any Unicode characters within the scope of JS7 - Object Naming Rules.
- Download workflow for Unix (upload .json): pduLanguage-日本語.workflow.json
- Download workflow for Windows (upload .json): pdwLanguage-日本語.workflow.json
The Configuration -> Inventory view allows object names and job scripts to be specified using Unicode characters:
The Workflows view displays workflows using Unicode characters accordingly:
- The example below makes use of Japanese object names.
- In addition, the JOC Cockpit interface language has been switched to Japanese by use of JS7 - Profiles - Preferences.
The Log view window displays output of jobs and instructions.
- Output is partly created from the JOC Cockpit and is qualified with markers such as [MAIN], [SUCCESS], [DETAIL].
- Output is partly created from job scripts executed with an OS shell. Such output is marked as [STDOUT] and [STDERR].
- Output from Unix Operating Systems
- Unix Operating Systems ship with built-in support for Unicode and UTF-8 encoding.
- Output from Windows Operating Systems
- Windows does not offer Unicode. Instead the OS ships with different code pages preinstalled depending on the location in which the OS is used.
- Some experimental Unicode support is available starting from Windows 10, however, as most Windows programs are not aware of Unicode there can be side-effects.
- Therefore the encoding of output created by jobs depends on the code page in use for the Windows OS which an Agent is operated on.
The Controller does not read or write files related to execution of workflows and jobs. The Controller reads configuration files and writes component log files only.
- Configuration files use UTF-8 encoding.
- Component log files are created with UTF-8 encoding.
Agents use an OS shell to execute jobs scripts. Agents collect output of jobs that is available from the stdout and stderr channels.
- For Unix environments the OS creates output in UTF-8 encoding.
- For Windows environments the OS makes use of a code page to encode output.
Use with Windows Code Pages
The Agent makes use of the code page that is active for the computer the Agent is operated on.
- In Asia code page 65001 or specific code pages such as 932 for Japan are frequently used.
- In Western Europe code page 850 is frequently used.
FEATURE AVAILABILITY STARTING FROM RELEASE 2.3.0
Supported Code Pages
The Agent automatically detects and makes use of the following code pages:
Specifying the Code Page
The Agent detects and makes use of the code page used by the Windows OS
- for code pages from the above list,
- for code pages that are prefixed with
CP#with # being the number of the code page.
Users can enforce use of a supported code page by adding a setting to the Agent's
JS7_AGENT_CONFIG_DIR/agent.conf configuration file such as:
- This setting specifies the MIME type not the numeric code page identifier, for example
- Users should be aware that modifying the Agent's code page will not modify the code page of the underlying OS shell.
- OS commands will continue to encode output with the OS code page.
Examples for Windows Code Pages
The following examples explain use of Windows code pages.
Workflow Jobs: ハローワールドジョブ
- The first job is assigned an environment variable
JOB_NAMEfrom a built-in global variable like this:
- Line 3: The output of the
JOB_NAMEenvironment variable can be scrambled if the server does not use a compatible code page, see chapter Log View.
- Line 4: The job displays Unicode characters that have been directly added to the job script.
- Line 6, 7: The job creates two variables for use with later jobs:
var1: the variable directly holds Unicode characters.
last_job_name: the variable holds the name of the current job.
- Line 9: The job displays the current code page.
- Line 1: The job script creates a new shell and switches to a Unicode code page.
- Line 3: The output created for the current job name is readable from the log view as the code page now includes Unicode support.
- Line 4: The output of the
last_job_namevariable will be scrambled if the predecessor job created this variable from a non-matching code page.
- Line 5, 6:: The output is readable in the log.