Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Converter

With Release 2.7.0 a the Converter becomes available to migrate job configurations from AutoSys® JIL files to JS7:

...

  • The Converter Java classes can be used with Java LTS editions of JRE or JDK 17 and newer.
  • The Converter Start Script is available for
    • Linux, MacOS® and AIX® using bash, dash, ksh and zsh shells.
    • Windows 10, 11, Windows Server

Download

Download of the Job Converter from the js7_converter_autosys.tar.gz tarball and js7_converter_autosys.zip archive file is available within the scope of migration services.

...

SettingDefaultExplanation
parserConfig.extensionsjil

The default file name extensions for looking up AutoSys® JIL files in the input directory. If more than one extension is specified, they are separated by semicolon.

Example:

parserConfig.extensions = jil;txt

parserConfig.excluded.fileNames

Specifies files from their name that should be excluded when looking up AutoSys® JIL files in the input directory.  If more than one file name is specified, they are separated by semicolon.

Example:

parserConfig.excluded.fileNames = machines.jil

Section: Autosys

SettingDefaultExplanation
autosys.input.splitConfiguration
true
false

Creates separate XML files containing the original AutoSys® job definition for each standalone job (a job without any conditions) or for each box job.

Example:

autosys.input.splitConfiguration =

false

true

autosys.input.diagram.generate
true
false

Specifies that diagram files in SVG format should be created.

Example:

autosys.input.diagram.generate =

false

true

autosys.input.diagram.optimize.dependenciesfalse

Attempts to resolve AutoSys® job conditions in order to reduce the dependencies (arrows) between various jobs in diagrams.

autosys.input.diagram.outputFormatsvg

Specifies the output format of diagram files.

autosys.input.diagram.size0


autosys.input.diagram.graphviz.executable

Specifies the location of the graphviz dot executable to create SVG output files for diagrams.

Example:

autosys.input.diagram.graphviz.executable = C:/Program Files/Graphviz/bin/dot.exe

autosys.input.diagram.graphviz.cleanupDotFilesfalse

Specifies

if existing SVG output files should be deleted on start of conversion

whether the converter should delete the .dot (internal Graphviz format) files once the conversion is complete.

Example:

autosys.input.diagram.graphviz.cleanupDotFiles = true

Section: Workflow

SettingDefaultExplanation
workflowConfig.default.timezoneEtc/UTC

Specifies the default time zone that is added to converted workflows. This time zone for example is applied to JS7 - Admission Times for Jobs.

See List of tz database time zones

Section: Workflow Job

SettingDefaultExplanation
jobConfig.forced.GraceTimeout
15

Specifies the grace timeout after which a running job is terminated if the cancel/force operation is used, see JS7 - Job Instruction.
jobConfig.forced.parallelism
1

Specifies the number of parallel tasks that a job can be running for, see JS7 - Job Instruction.

jobConfig.forced.failOnErrWrittenfalseSpecifies the handling of job output to the stderr channel. If set to true then output to stderr is considered an error, otherwise such output is logged and no error is raised, , see JS7 - Job Instruction.
jobConfig.forced.warnOnErrWrittenfalse

Specifies the handling of job output to the stderr channel. If set to true then output to stderr is considered a warning, otherwise such output is logged and no warning is raised, , see JS7 - Job Instruction.

jobConfig.forcedV1Compatiblefalse

JS7 workflows can be operated in a JS1 compatibility mode. If set to true then

  • for order variables and workflow variables in shell jobs respective environment variables are created that are prefixed with SCHEDULER_PARAM_ followed by the uppercase variable name.
  • for job arguments of shell jobs accordingly environment variables are created.

Consider that environment variables are not added by the Converter but are created on-the-fly by the Controller and Agents.

jobConfig.forced.retry.maxTries

Forces use of the indicated maximum for use of the JS7 - Retry Instruction. Without this setting the AutoSys® n_retrys option is used to specify the maximum number of retries. 

jobConfig.forced.retry.delays

Forces the indicated delay between retries.

jobConfig.forced.shell.unix.commandPrefix

Forces a prefix to be used for Unix shell jobs.

Example:

jobConfig.forced.shell.unix.commandPrefix = source

jobConfig.forced.shell.windows.commandPrefix

Forces a prefix to be used for Windows shell jobs.

jobConfig.default.shell.unix.shebang#!/bin/bash

Specifies the shebang to be inserted to the begin of job scripts:

Example:

jobConfig.default.shell.unix.shebang = #!/bin/sh

Section: Agent

SettingsDefaultExplanation
agentConfig.forced.forcedControllerIdcontrollerId
Forces use of the given ControllerId for all generated agents.
agentConfig.default.defaultControllerIdcontrollerId
This setting specifies Specifies the ControllerId to be used for generated agents if the Master ID in JS1 (process_class.spooler_id) is emptyno ControllerId is provided in the agentConfig (forced.agent, default.agent, mappings) for a specific agent.
agentConfig.forcedAgentforced.agent

Forces use of the given Agent for all converted jobs.

Agent definition:

  • Expects a JSON value.
  • The JSON can be provided as:
    • JSON text
      or
    • JSON include file (relative to the properties file)
  • JSON elements:
    • NameDefaultExplanation
      platformUNIXForces use of the UNIX or WINDOWS platform.
      subagentClusterId
      Forces use the given subagentClusterId for converted jobs when an agentCluster is used.
      standaloneAgent
      See agent-schema.json.
      agentCluster
      See clusterAgent-schema.json.
  • Examples:
    • {"platform":"UNIX"}
      • Forces use of the UNIX platform for all converted jobs.
    •  {"standaloneAgent":{"url":"http://localhost:4445"}}
      • Forces use of the standalone Agents in all converted jobs with the given url.
    •  {"platform":"UNIX", "standaloneAgent":{"agentName":"forced_agent", "url":"http://localhost:4445"}}
      • Forces use of a standalone Agent forced_agent in all converted jobswith the given url.
agentConfig.default.defaultAgentagent
NameURL
default_agenthttp://localhost:4445

Without an Agent being specified the JS1 executes jobs with the Master. In JS7 an Agent has to be used. This setting specifies an Agent that is used for jobs that are executed with a Master in JS1This agent is used when an AutoSys® job does not provide machine information.

The syntax for assignments: see agentConfig.forced.forcedAgent agent Agent definition.

agentConfig.mappings

By default the Converter handles the mapping of Agent Names found in JS1 process classes (<process_class>) like this:

  • Agents are determined by the unique URL assigned the Agent in existing process classes.
  • The name of a process class is mapped
    • to a Standalone Agent if it includes a single Agent
    • to a Cluster Agent if it includes more than one Agent

AutoSys® job  machine attribute:


The syntax The syntax for mapping includes:

<js1<autosys-agent-name>=<Agent definition>

<js1<autosys-agent-name> is the name of the JS1 AutoSys® Agent(machine).
<Agent definition> see agentConfig.forcedAgent forced.agent Agent definition..

Example:

js1autosys_agent1={"platform":"UNIX", "standaloneAgent":{"agentName":"primaryAgent", "url":"http://unix:4445"}};js1autosys_agent2={"platform":"WINDOWS", "standaloneAgent":{"agentName":"secondaryAgent", "url":"http://win:4445"}}

  • The process class js1 machine autosys_agent1 is mapped to the JS7 Agent with the name primaryAgent that is operated for Unix.
  • The process machine class js1autosys_agent2 is mapped to the JS7 Agent with the name secondaryAgent that is operated for Windows.

or

 js1 autosys_agent1=examples/agent_standalone.json; js1 autosys_agent2=examples/cluster_agent.json

  • The process class js1The machine autosys_agent1 is mapped to the JS7 Agent defined in the examples/agent_standalone.json file.
  • The process class js1 machine autosys_agent2 is mapped to the JS7 Agent defined in the examples/cluster_agent.json file.

Any number of mappings are specified separated by a semicolon. This setting can be split across a number of lines by use the "\" line continuation character at the end of each line that should be continueda semicolon. This setting can be split across a number of lines by use the "\" line continuation character at the end of each line that should be continued.


Configuration of mappings in a file:

  • With each run, the converter creates a report/agent_mapping.config file that lists all machine names on the left and empty mapping values on the right.
  • After manual adjustments, the file can be moved to another location and assigned as a file to the agentConfig.mappings in the next conversion.

Section: Mock

SettingDefaultExplanation
mockConfig.forced.jitl.mockLevel

Mock levels are used for dry runs of the conversion for JS7 - Job Templates (JITL JVM Jobs). If a mock level is specified then JVM Jobs will not be executed but will log and will optionally check arguments only.

The following values can be specified for this setting:

  • INFO: arguments are logged, execution of JVM Jobs is considered successful.
  • ERROR: arguments are logged, required arguments of JVM Jobs are checked and errors are raised in case of missing arguments.

Without this setting being specified the JITL JVM Jobs will be executed from the converted jobs.

mockConfig.forced.shell.unixScript

Mock scripts are used for dry runs of the conversion. The job scripts of converted Shell Jobs are replaced by the call to a mock script for Unix platforms. Consider that mock scripts have to be provided by the user and have to be available for Agents at run-time.

This setting specifies the path to a mock script for Unix, for example, $HOME/MockScript.sh

A mock script for Unix can look like this:

Code Block
languagebash
titleExample for Mock Script on Unix
linenumberstrue
collapsetrue
#!/bin/sh
echo "------------------------------------------------------------"
echo "Start Unix Mock Script: $0"
echo "------------------------------------------------------------"
echo "Arguments: $*"
echo "------------------------------------------------------------"

If no mock script is specified then the original JS1 job AutoSys® job script is used for the converted JS7 job.

mockConfig.forced.shell.windowsScript

Mock scripts are used for dry runs of the conversion. The job scripts of converted Shell Jobs are replaced by the call to a mock script for Windows platforms. Consider that mock scripts have to be provided by the user and have to be available for Agents at run-time.

Specifies the path to a mock script for Windows, for example, %UserProfile%\MockScript.cmd

A mock script for Windows can look like this: 

Code Block
languagebash
titleExample for Mock Script on Windows
linenumberstrue
collapsetrue
@echo off
@echo ------------------------------------------------------------
@echo Start Windows Mock Script: %0
@echo ------------------------------------------------------------
@echo Arguments: %*
@echo ------------------------------------------------------------

If no mock script is specified then the original AutoSys® job script is used for the converted JS7 job.

...

  • Agents
    • At least one Agent has to be available.
    • The Converter offers to map Agent Names from AutoSys® to JS7 Agents. Such Agents have to be available in the JS7 prior to conversion. Users can register Agents as Standalone Agents and as Cluster Agents, see JS7 - Agent Management.
  • Calendars
    • At lease one working day calendar has to be available. The calendar can be stored in an arbitrary folder. The name of the calendar can be specified with the scheduleConfig.forced.workingDayCalendarName and scheduleConfig.default.workingDayCalendarName settings or it will default to AnyDays.
    • Optionally a non-working day celandar can be available. The calendar can be stored in an arbitrary folder. The name of the calendar can be specified with the 
    • scheduleConfig.forced.nonWorkingDayCalendarName and scheduleConfig.default.nonWorkingDayCalendarName settings. By default no non-working day Calendar will be applied.
    • If the calendar specified by converted schedules is not available in the JS7 then imported schedules become invalid. They can be individually assigned a calendar in the JS7 inventory.

Delimitations

At the time of writing the following configuration elements are not supported:

  • generateConfig.cyclicOrders

...

    • .

Further Resources

...