Release Notes

Summary of enhancements, fixes, and open issues.
This Release Notes article explains the key features for each release of Workload Automation System Agent Version 12.0.
New Features
The following sections describe the new features that are included in each 12.0 release of the agent.
Consolidated Agent Installer
During the installation of the System Agent, the installer will now install all the binaries associated with the system agent and all the plug-ins including Hadoop AI. The plug-in cfg files (renamed from pak to cfg files in R12) will now only contain the configuration setup files and no longer distribute the plug-in jars. Each plug-in, except for Hadoop AI, will have to be enabled and configured using PluginInstaller and the respective 12.0 cfg file. For example use this command to enable the database plugin: ./PluginInstaller database.cfg . The Hadoop AI still uses its own installer instead of the PluginInstaller.
During the upgrade of the System Agent, the installer will upgrade all the binaries associated with the system agent and all the plug-ins including Hadoop AI. The existing plug-ins which are enabled prior to the upgrade will continue to be enabled and functional after the upgrade of the system agent. Additional plug-ins can be enabled and configured using PluginInstaller and the respective 12.0 cfg file.
During the uninstall of the System Agent, the installer provides an option to retain the configuration files. If this is set, then all the agent and plugin configuration files are retained on uninstall. If it is not set, the files are removed. In the silent install, this new property is called RETAIN_CONFIGFILES with default of false.
Support for the System Agent Continuing to Execute in a Non-persistence Mode During Low Disk Space Conditions
When resource monitoring has been enabled, the agent will now continue to execute, but in a non-persistent manner when the disk space has dropped below the critical threshold. Prior to this change the agent would have shutdown in this situation. The parameter agent.resourcemon.threshold.disk.critical.shutdown can be used to restore the prior behavior by setting it to 'true'.
The Nonstop System Agent Now Accepts the "~;" In Run Command Job Definitions
The NonStop System agent has been enhanced to accept the "~;" in run command job definitions. This allows users whose job definitions ran in versions 11.3.4 and earlier of the NonStop Agent for Guardian using "~;" to run the same job definitions in version 12.0.0 or newer of the System Agent. For more information on run command jobs please refer to your Scheduling Manager documentation.
The command statement in run command job definitions can be of two forms. In the first form the command statement allows to specify a command or script to run. In the second form, the command statement allows you to specify the two character sequence "~;" to denote that the value of the args statement that follows in the job definition is a delimited sequence of TACL built-in functions or TACL commands to execute.  Please refer to your Scheduling Manager documentation for more information about run command job definitions.
Support for NonStop System Agent to run as a Named Process
This enhancement allows you to optionally specify Guardian RUN command options such as process name, priority, and a CPU when installing the System Agent. For NonStop only, the System Agent installer has been modified to:
  • Accept a process name: This will be the name of the Guardian process under which the agent will run.
  • Accept a process priority: This will be the priority under which the agent will run.
  • Accept a CPU assignment: This will be the CPU under which the agent process will run.
All of the above three RUN command options must conform to Guardian conventions. In addition, these options only apply to the cybAgent process not job executions. If the user chooses not to specify or enter one or more of these Run options the agent will continue to install and run as before. In this case the agent will run with Guardian assigned Run options, i.e. with a PID instead of a process name, with a OS assigned priority, or with a OS designated CPU.
The NSK agent is enhanced so that the –v switch works when the agent process is running as a Guardian named process.
This feature applies to new installs. For existing System Agent installations, please see How to Upgrade the Agent Startup Script to use Run Command Options.
New variable that specifies the path to the file that defines manager-specific variables
The new
variable specifies the path to the file that defines manager-specific variables. This file will be sourced before the file specified in
setting is sourced.
For more information, see Define Environment Variables.
New Silent Installer property to perform agent upgrade checks and stop Agent if required
The new
Silent Installer property specfies whether to perform agent upgrade checks and stop the Agent if required. For more information, see Silent Installer Properties.
Known Issues
The following sections include the known issues for each 12.0 release of the agent.
Nonstop System Agent Fails Submit STATE COMPLETE Messages to the Manager Even Though Jobs Complete Successfully
Due to known timezone issues with the OSS and Guardian, runtime libraries no STATE COMPLETE messages are sent back to the Scheduling Manager hours before the Spring DST (Daylight Savings Time) transition takes place. There are no known issues during the Fall DST (Daylight Savings Time) transition.
Edit the agent's startup script located in the root/base installation folder. The default full name of the startup script is /opt/CA/WA_Agent/cybAgent. Add a line like the following:
export TZ=<tz-value>
The value of <tz-value> can be any of the following, depending on your timezone:
You must stop and restart the agent for this change to take effect.
Installer Indicates Success when Installation Fails Due to Invalid JVM Version
On the IBM i, NonStop, z/Linux , PPC, and PPCLE platforms, the installer returns an exit code of 0, indicating a successful installation, even though the installation fails due to an invalid JVM version.
A version of Java 1.8 or higher is required for installation. If a version lower than 1.8 is used, the installation fails with the following error: The installer cannot run with the given JVM. Java 1.8+ is required. However, the output reflects an exit code of 0. See the following example output from an IBM i v5 installation:
$ /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/bin/java -jar setup.jar =============================================================================== CA WA Agent (created with InstallAnywhere) ------------------------------------------------------------------------------- The installer cannot run with the given JVM. Java 1.8+ is required. $ echo $? 0
Some Agent Files Remain After Uninstallation
(UNIX and Linux platform only) When you run the uninstaller to uninstall an agent, the following message is generated:
Uninstall Complete ------------------ Some items could not be removed.
In some cases, such as with a new installation of an agent that has never been started, the message displays even though the agent and agent directory are removed. In other cases, such as with an agent that has been run or is running jobs, some files and directories remain in the agent directory, such as /log, nohup.stderr, and nohup.stdout.
This message is generated by the installation application and currently has no fix. If you see this message, and your agent installation is not completely removed, manually remove the remaining files.
AutoSys Workload Automation Command Jobs That Start with Double Parentheses Might Fail
Jobs that contain a command that begins with two parentheses, for example, “((“ can fail. This issue occurs with 11.3 SP4 Incremental 2 of the Workload Automation agent running AutoSys Workload Automation jobs. When the parentheses are used to group commands and are not part of the executable or batch file name, the job fails. These same jobs run successfully with versions of the agent prior to 11.3 SP4 Incremental 2.
When the job fails, the job log contains a line at the end similar to the following:
Command to be executed: "C:\Windows\system32\cmd.exe" /c "("("
To retrieve the job log, use the command "autosyslog -j jobname -tA")
To work around this issue, change the syntax of the command to begin with "cmd.exe /c" followed by the original command.
Text File Monitor Jobs Do Not Support ISO-2022 File Encodings
Text file monitor jobs do not support files encoded with encodings in the ISO-2022 family, such as ISO-2022-CN, ISO-2022-JP, and ISO-2022-KR.
The Agent Can Report Back That It Is Running on Windows 2012 When the Agent Is Installed on a Windows 2016 Server
Under certain scenarios, the agent reports back that it is running on Windows 2012, when in fact the agent is installed on a Windows 2016 server. This is a known bug in the version of Java shipped with the agent, AdoptOpenJDK8. This has been fixed in the new release of AdoptOpenJDK11 which will be shipped with the agent at a later date.
System Agent on AIX is not sending 'Status' information When a Job Is Killed by a User
The System agent on AIX is not sending 'Status' information when a job is killed by a user.
Fixed Issues
Unable to kill HTTP V2 Job
An attempt to kill the HTTP V2 job that was in the middle of the retry_on_failure_count cyle use to fail. This issue is now resolved.
SYSAGT-353: Shell Specified for a Script May Not Be Used When Running Command Jobs in UNIX
Shell Specified for a Script May Not Be Used was returned when running command jobs in UNIX, the shell directive (first line in shell script) was not honored by the agent. Also, this fix allows Perl scripts to run correctly.
SYSAGT-352: Abort Signal 6
On systems using PowerBroker software run jobs would first report success followed by abort signal 6.
SYSAGT-351: High Vulnerability in Jackson Library
High security vulnerabilities were detected in the Jackson library provided in the initial 11.5 release.
SYSAGT-349: IBM i FTP Download Large Files
FTP download jobs to native filesystem would fail, if the file exceeded 13000 records in size.
SYSAGT-347: Windows Agent Installation onto the Non-primary Drive (C:) Fails
Installation of the Windows agent onto the non-primary drive (C:) would fail. The non-primary drive could be either a second installed/partitioned drive or a mounted drive (net use).
SYSAGT-346: IBM i Completion Code Incorrect
When a *SEVERITY error was returned, the response would not include the completion code.
SYSAGT-345: After Starting the Agent, It Consumes an Excessive Amount of CPU on the Machine
After starting agent, the agent consumed an excessive amount of CPU on the machine. The CPU usage by the agent would approach the maximum amount allowed by the operating system for that process the entire time the agent is running. Also, the runner_spool_cleaner.log file would be full of messages containing:
java.lang.NullPointerException: null
Jobs would fail to run properly due to the lack of a specified spooldir in the agentparm.txt file. .
The agent would not be able to effectively process jobs due to the lack of a defined spooldir in the agentparm.txt file. .
Additionally, other processes on the machine may have been slowed due to the excessive amount of CPU being used by the agent process.
SYSAGT-344: Autoping -s Failed if Autosys Encryption Was Disabled
Autoping with -S fails with "Program can only be run from within the agent" error if Autosys encryption was disabled.
SYSAGT 342: Restarting a Windows agent could result in LOST CONTROL of jobs that were running without having had a user specified
On a Windows Agent, a restart of the agent could result in LOST CONTROL of jobs that were running without having had a user specified.
RUN jobs unexpectedly return a status of LOST CONTROL after an agent restart on Windows. Inspection of the agent machine showed the job process was still executing, however.
Jobs needed to be restarted or manually verified and a forced complete execute within the scheduler.