Release Notes

View changes, fixed and known issues, supported platforms, and system requirements.
HID_ReleaseNotes
This Release Notes article explains the key features for each release of CA Workload Automation System Agent Version 11.4.
2
2
New Features
The following sections describe the new features that are included in each 11.4.00 release of the agent.
11.4.01
Security Enhancements and Plug-In Support
This release includes security enhancements and additional support for plug-in agents.
11.4.00
Improved Process for Upgrading the System Agent
This release introduces improvements to the upgrade process by automatically creating a backup of the Agent files before an upgrade and rolling back the changes if an upgrade cannot be completed.
To perform an upgrade by using the silent installation method, you run a command to specify the location of the directory of an existing installation to be upgraded. You can specify a directory other than the default for the backup by using the property UPGRADE_BACKUP_LOCATION.
Support for Amazon Linux
The agent now supports Amazon Linux. See the Workload Automation System Agent Platform Support Matrix for information about the platforms that are supported by the agent.
(UNIX/Linux) Agent Detects Reused PIDs on Reboot 
When the agent is restarted, it tries to determine the state of jobs that were running at the time it was shut down. To do determine the state of jobs, the agent checks for the PID of the job process. If the PID exists, the agent considers the job to be running. If the PID does not exist, the agent considers the job to be FAILED with a status of “Lost control." Due to this behavior, the possibility exists that a different process may be started with the same PID of a previously running job.
The agent now checks to verify that the PID is that of a running job and not a different process.
Expanded Security Algorithms for SSH Communications
The agent can take advantage of an expanded list of supported ciphers, MACs, and key algorithms for SSH communications.
For the complete list of supported security algorithms, see the Reference topic Supported Security Algorithms. For information about configuring ciphers and MACs with the security.ssh.ciphers and security.ssh.macs parameters, see CA WA Agent for UNIX, Linux, Windows, or iSeries Agent Parameters.
Support for HPE Integrity NonStop x86 Processors
The agent now includes support for HPE NonStop Integrity x86 processors.
Support for HPE Integrity NonStop Agents to Run with a Java 1.8 JVM
CA WA Agent for HPE Integrity NonStop runs with Java 1.8.
Known Issues
The following sections include the known issues for each 11.4 release of the agent.
11.4.01
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. Workaround: 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:
  • EST5EDT
  • CST6CDT
  • MST7MDT
  • PST8PDT
You must stop and restart the agent for this change to take effect.
SYSAGT 342: Restarting a Windows agent can result in LOST CONTROL of jobs that were running without having had a user specified
On a Windows Agent, a restart of the agent can result in LOST CONTROL of jobs that were running without having had a user specified.
RUN jobs unexpectantly return a status of LOST CONTROL after an agent restart on Windows. Inspection of the agent machine shows the job process is still executing, however.
Jobs must be restarted or manually verified and a forced complete execute within the scheduler.
WorkAround: The job may be executed with a user defined.
ps -e output does not display the cybAgent process name in zLinux
The CybAgent.bin process name is not displayed correctly in the ps -e output. The output will show "Thread 7".
# ps -e | grep 50655
50655 ? 00:00:45 Thread-7
But the ps -ef Output displays the process name correctly.
# ps -ef | grep 50655
root 50655 1 0 Jan30 ? 00:00:45 ./cybAgent.bin -a
The above behavior is seen when running with an older JRE version:
# ./jre/bin/java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build pxz6470sr7-20140410_01(SR7))
IBM J9 VM (build 2.6, JRE 1.7.0 Linux s390x-64 Compressed References 20140409_195732 (JIT enabled, AOT enabled)
J9VM - R26_Java726_SR7_20140409_1418_B195732
JIT - r11.b06_20140409_61252
GC - R26_Java726_SR7_20140409_1418_B195732_CMPRSS
J9CL - 20140409_195732)
JCL - 20140409_01 based on Oracle 7u55-b13
When a newer version of JRE is used, the above mentioned behavior is not seen.
Agent installer fails on Red Hat Enterprise Linux 7.6
Agent installer fails on Red Hat Enterprise Linux 7.6 if fontconfig is not present on the system.
Workaround:
You can successfully run the agent installation by first installing fontconfig.
iSeries with ASP – FTP Incorrectly Identifies Native Files
When using ASP (Auxiliary Storage Pool), native files are not correctly identified during FTP transfer and are received with no end of line markers. Therefore, a file that is transferred from iSeries to UNIX appears as a single long record instead of as individual lines.
Native iSeries files that are sent to non-iSeries boxes cannot be processed.
There is no workaround at this time.
iSeries File Triggers That Use ASP Not Activated
iSeries file triggers that use an ASP (Auxiliary Storage Pool) are not correctly activated when a new native iSeries file arrives. These iSeries triggers do not correctly look for native files, which appear to be directories to the Java code.
For example, the following file name does not work correctly: path /QAS/QSYS.LIB/PAGVEN_MEX.LIB/BA*
To address this problem, install Patch T5H3194.
The chkusr Utility Does Not Run on 64-bit HP-UX
(HP-UX only) When you run the chkusr utility on 64-bit HP-UX, the chkusr utility does not run, and the following error is generated:
Unable to load pam library: Unable to find library 'libpam.sl'.
Also, if you try to use CONTROL VERIFY from either CA-7 or from Workload Control Center, it also fails.
This issue occurs because the agent does not load the 64-bit PAM libraries when it runs on 64-bit HP-UX.
To work around this issue, either copy the chkusr utility from the 32-bit HP-UX installation to the 64-bit installation, or set the environment variable EWAPAMLIB to point to the 64-bit library, as shown in this example:
EWAPAMLIB=libpam.so export EWAPAMLIB
Extended ASCII Characters in Passwords
After updating the System Agent from release 11.3.05 or earlier, passwords with extended ASCII characters (accented characters or other characters in the Latin-1 supplement character code range) might fail.
To work around this issue, either revert to an older version of the System Agent, or use passwords with no extended ASCII characters.
Environment Variable Names on Windows Converted to Uppercase
(Windows only) For Workload Automation System Agent releases between 11.3.06 and 11.4.01, variable names in environment variables that are sent to the agent are converted to uppercase.
Even though Windows is case-insensitive, problems can occur when other programs or scripts expect the variable name in environment variables to be lowercase or mixed case.
To work around this issue, you can use one of the following options:
  • Use case-insensitive comparisons for environment variable names.
  • Use the 11.3.05 release (or older) of the agent.
  • Use an agent newer than release 11.4.01.
(AIX only) Agent Service Does Not Start on AIX After Installation
After installing the agent for AIX from the DVD, an error is produced when the agent service is started. It produces a core dump, and only one log file is created, runner_os_component.log. The log file contains the following information:
Database check succeeded
CA Workload Automation Agent for AIX 11.4, Build 1609
OS component - 16384074
uname: s=AIX n=wdevtacdqp1 r=1 v=7 m=00F9EBCF4C00
Locale: en_US en_US en_US en_US en_US en_US
Jars found: jars/agent.jar:jars/installer.jar:jars/js.jar:jars/snmpagent.jar:jars/ext/axis-ant.jar:jars/ext/axis-schema.jar:jars/ext/axis.jar:jars/ext/bcprov-ext-jdk15on.jar:jars/ext/commons-codec.jar:jars/ext/commons-discovery.jar:jars/ext/commons-httpclient.jar:jars/ext/commons-logging.jar:jars/ext/jaxrpc.jar:jars/ext/jsafeJCEFIPS.jar:jars/ext/saaj.jar:jars/ext/sinetfactory.jar:jars/ext/wsdl4j.jar:
To work around this issue, use the sedmgr command to see if Execution Disable Protection (SED) is enabled:
# sedmgr
Stack Execution Disable (SED) mode: all
If SED is enabled, either turn if off or selectively disable it:
To set it to select mode, enter the command:
# sedmgr -m select
To exempt cybAgent.bin process from SED, enter the command:
sedmgr -c exempt cybAgent.bin
For more information about this issue, see the following articles in the IBM Knowledge Center:
(Red Hat Linux) Agent Fails to Start and Reports Java SIGBUS Error
A flaw in the Red Hat Linux kernel might prevent the agent from starting. This issue occurs in the following Red Hat kernel versions; it is fixed in later versions of the Red Hat Linux kernel:
  • RHEL 7: 3.10.0-514
  • RHEL 6: 2.6.32-696
Solution and Workaround
To correct this problem, Red Hat recommends that you update to a newer version of the Linux kernel.
To work around this issue, Red Hat recommends that you increase the Java stack size by setting "-Xss2m" in the Java startup parameters. For the System Agent, that means you must add the following setting to the agentparm.txt file.
oscomponent.jvm.x.options=-Xss2m
For more information from Red Hat about this issue, see the following documents:
Installer Indicates Success when Installation Fails Due to Invalid JVM Version
On the iSeries, 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.7 or higher is required for installation. If a version lower than 1.7 is used, the installation fails with the following error: The installer cannot run with the given JVM. Java 1.7+ is required. However, the output reflects an exit code of 0. See the following example output from an iSeries v5 installation:
$ /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/bin/java -jar setup.jar
===============================================================================
CA WA Agent 11.4.00.00 (created with InstallAnywhere)
-------------------------------------------------------------------------------
The installer cannot run with the given JVM. Java 1.7+ is required.
$ echo $?
0
(AIX only) Agent May Crash with Core Dump When Using Java 8 on POWER 8 Systems
When running an agent that uses Java 8 on AIX on POWER 8 systems, it is possible for the AIX runtime instrumentation to cause the agent to crash with a core dump.
The workaround for this issue is to disable runtime instrumentation by setting the following in the agentparm.txt file:
oscomponent.jvm.x.options=-XX:-RuntimeInstrumentation
If parameters are already set in the oscomponent.jvm.x.options setting, you must separate the new setting from the existing one with a semicolon, similar to the following example: oscomponent.jvm.x.options=existingparameters;-XX:-RuntimeInstrumentation
For more information about this issue, see the following documents from IBM:
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.
Migrating an R6 or R7 agentparm.txt File to 11.4.00
The 11.4.00 installer does not support the migration of an R6 or R7 agentparm.txt file to 11.4.00. To use an R6 or R7 agentparm.txt file in 11.4.00, you must install the 11.4.00 version of the agent and manually copy any customized entries from the R6 or R7 agentparm.txt file into the 11.4 agentparm.txt file.
Workload Automation AE 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 Workload Automation AE 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, use one of the following methods:
Install a version of the agent earlier than 11.3 SP4 Incremental 2.
Change the syntax of the command to begin with "cmd.exe /c" followed by the original command.
UNC Path Containing Parentheses in File Trigger Fails
(Workload Automation DE only) A file trigger that references a UNC file name that contains special characters, such as parentheses, fails to create the trigger.  For example, the following file name does not work: \\myshare\myfile(1).txt
The job fails with a status of Scan Failed and a detailed status such as:
The <directory> does not exist or not a directory.
To work around this issue, begin the UNC file path with four backslashes instead of two, for example, \\\\myshare\myfile(1).txt
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, for example.
File Watcher Requires r + x Permission for Each Directory in a Path
(Valid on some versions of UNIX, such as AIX and HP-UX) A file watcher job requires read and search (r+x) for every directory in the path; otherwise, the job continues to run indefinitely even though the file exists. This issue is caused by a limitation in the AIX implementation of the glob() system call. When one of the directories in a file path specifies x permission, but not r permission, the AIX version of the call does not work as documented. Instead of returning the file path to the file (if it exists) or returning NOMATCH if it does not exist, AIX returns the directory of the file only and a code of success. This problem does not exist with version 4.51 of the agent.
Until a fix is implemented in the AIX code, ensure that file watcher has both read and search (r+x) permission for every directory in the path.
Resource Temporarily Unavailable Errors on AIX
(Valid on AIX) When running jobs on AIX, some of the jobs fail to complete with submission errors (SUBERROR). The job log contains the following error message:
CAWA_E_20039 Cannot fork a new process to execute the job:/usr/bin/ksh, reason:Resource temporarily unavailable.Error code: 11
The error can occur because of a memory issue.
To see the maximum number of user processes on your system use the following command:
lsattr -E -l sys0 -a maxuproc
Sample output:
maxuproc 128 Maximum number of PROCESSES allowed per user True
To resolve the issue, we recommend that you increase the number of user processes to 1024 using the following command:
chdev -l sys0 -a maxuproc=1024
Unable to Restart the Agent on z/Linux or AIX
(Valid on z/Linux and AIX)
After you run UNIX jobs and stop the agent, it cannot be restarted. The defaultlog_agent.log contains the following exception and the stack trace:
main.MainThread.CybTcpipControllerPlugin.initialize[:283] - cybermation.library.communications.CybConversationException: Address already in use …
The issue occurs when the operating system does not release the agent listening port.
To prevent this issue from occurring on z/Linux, set the following parameter in the agentparm.txt file:
oscomponent.closefds=200
This parameter causes the agent to close file descriptors, preventing the scripts or binaries of the user from inheriting them.
Note:
If this setting does not resolve the issue, increase the value of oscomponent.closefds up to a maximum of 300.
On AIX, oscomponent.closefds is set to 200 by default, but it can be increased to a maximum of 300 if necessary.
Chkusr Utility Not Supported on iSeries
(Valid on iSeries) The chkusr utility that is provided with the agent is not supported on iSeries because the standard PAM (Pluggable Authentication Modules) library that chkusr uses is not applicable to the iSeries environment. This issue will be addressed in a future release.
Resource Monitoring Not Supported in the iSeries Agent
(Valid on iSeries) The resource monitoring should send an alert to the scheduler when available disk space reaches the threshold that is defined in the agentparm.txt file. This feature is not yet supported in the iSeries Agent.
For information about previous releases of CA Workload Automation Agent and agent plug-ins, see the Agents Release Notes for the agent or agent plug-in that you are interested in to find the enhancements, fixed issues, and known issues for each release.
Extended ASCII Characters Garbled After Upgrade
(Valid on schedulers other than Workload Automation DE) After updating the System Agent from 11.3.05 or earlier, extended ASCII characters may become garbled or corrupted. Accented characters or other characters in the Latin-1 supplement character code range (0x80 to 0xFF) can become corrupted when sent from the manager to an upgraded agent. A job might also fail with an "Invalid AFM" error.
Jobs that worked before the agent upgrade may now fail or behave differently.
To work around this problem, add the following setting to the agentparm.txt file and restart the agent:
communication.v2.nativeafmencoding=true
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.
11.4.00
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. Workaround: 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:
  • EST5EDT
  • CST6CDT
  • MST7MDT
  • PST8PDT
You must stop and restart the agent for this change to take effect.
SYSAGT 342: Restarting a Windows agent can result in LOST CONTROL of jobs that were running without having had a user specified
On a Windows Agent, a restart of the agent can result in LOST CONTROL of jobs that were running without having had a user specified.
RUN jobs unexpectantly return a status of LOST CONTROL after an agent restart on Windows. Inspection of the agent machine shows the job process is still executing, however.
Jobs must be restarted or manually verified and a forced complete execute within the scheduler.
WorkAround: The job may be executed with a user defined.
ps -e output does not display the cybAgent process name in zLinux
The CybAgent.bin process name is not displayed correctly in the ps -e output. The output will show "Thread 7".
# ps -e | grep 50655
50655 ? 00:00:45 Thread-7
But the ps -ef Output displays the process name correctly.
# ps -ef | grep 50655
root 50655 1 0 Jan30 ? 00:00:45 ./cybAgent.bin -a
The above behavior is seen when running with an older JRE version:
# ./jre/bin/java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build pxz6470sr7-20140410_01(SR7))
IBM J9 VM (build 2.6, JRE 1.7.0 Linux s390x-64 Compressed References 20140409_195732 (JIT enabled, AOT enabled)
J9VM - R26_Java726_SR7_20140409_1418_B195732
JIT - r11.b06_20140409_61252
GC - R26_Java726_SR7_20140409_1418_B195732_CMPRSS
J9CL - 20140409_195732)
JCL - 20140409_01 based on Oracle 7u55-b13
When a newer version of JRE is used, the above mentioned behavior is not seen.
The chkusr Utility Does Not Run on 64-bit HP-UX
(HP-UX only) When you run the chkusr utility on 64-bit HP-UX, the chkusr utility does not run, and the following error is generated:
Unable to load pam library: Unable to find library 'libpam.sl'.
Also, if you try to use CONTROL VERIFY from either CA-7 or from Workload Control Center, it also fails.
This issue occurs because the agent does not load the 64-bit PAM libraries when it runs on 64-bit HP-UX.
To work around this issue, either copy the chkusr utility from the 32-bit HP-UX installation to the 64-bit installation, or set the environment variable EWAPAMLIB to point to the 64-bit library, as shown in this example:
EWAPAMLIB=libpam.so export EWAPAMLIB
Extended ASCII Characters In Passwords
After updating the System Agent from release 11.3.05 or earlier, passwords with extended ASCII characters (accented characters or other characters in the Latin-1 supplement character code range) might fail.
To work around this issue, either revert to an older version of the System Agent, or use passwords with no extended ASCII characters.
Environment Variable Names on Windows Converted to Uppercase
(Windows only) For Workload Automation System Agent releases 11.3.06 and newer, variable names in environment variables that are sent to the agent are converted to uppercase.
Even though Windows is case-insensitive, problems can occur when other programs or scripts expect the variable name in environment variables to be lowercase or mixed case.
To work around this issue, you can use one of the following options:
  • Use case-insensitive comparisons for environment variable names.
  • Use the 11.3.05 release (or older) of the agent.
Password Script Fails to Upgrade During Upgrade of Agent
(Linux and UNIX only) In some cases, when a 64-bit agent older than 11.3 SP5 is upgraded to Version 11.4.00, the agent is successfully upgraded, but the password script is not. When the password script is run, the follow error occurs:
Error: Could not find or load main class cybermation.utility.password.PasswordUtil
To work around this issue, edit the password script to read:
#!/bin/sh
./jre/bin/java -cp ./jars/agent.jar:./jars/ext/bc-fips.jar:./jars/ext/bcprov-ext-jdk15on.jar cybermation.utility.password.PasswordUtil "$1"
(AIX only) Agent Service Does Not Start on AIX After Installation
After installing the agent for AIX from the DVD, an error is produced when the agent service is started. It produces a core dump, and only one log file is created, runner_os_component.log. The log file contains the following information:
Database check succeeded
CA Workload Automation Agent for AIX 11.4, Build 1609
OS component - 16384074
uname: s=AIX n=wdevtacdqp1 r=1 v=7 m=00F9EBCF4C00
Locale: en_US en_US en_US en_US en_US en_US
Jars found: jars/agent.jar:jars/installer.jar:jars/js.jar:jars/snmpagent.jar:jars/ext/axis-ant.jar:jars/ext/axis-schema.jar:jars/ext/axis.jar:jars/ext/bcprov-ext-jdk15on.jar:jars/ext/commons-codec.jar:jars/ext/commons-discovery.jar:jars/ext/commons-httpclient.jar:jars/ext/commons-logging.jar:jars/ext/jaxrpc.jar:jars/ext/jsafeJCEFIPS.jar:jars/ext/saaj.jar:jars/ext/sinetfactory.jar:jars/ext/wsdl4j.jar:
To work around this issue, use the sedmgr command to see if Execution Disable Protection (SED) is enabled:
# sedmgr
Stack Execution Disable (SED) mode: all
If SED is enabled, either turn if off or selectively disable it:
To set it to select mode, enter the command:
# sedmgr -m select
To exempt cybAgent.bin process from SED, enter the command:
sedmgr -c exempt cybAgent.bin
For more information about this issue, see the following articles in the IBM Knowledge Center:
(Red Hat Linux) Agent Fails to Start and Reports Java SIGBUS Error
A flaw in the Red Hat Linux kernel might prevent the agent from starting. This issue occurs in the following Red Hat kernel versions; it is fixed in later versions of the Red Hat Linux kernel:
  • RHEL 7: 3.10.0-514
  • RHEL 6: 2.6.32-696
Solution and Workaround
To correct this problem, Red Hat recommends that you update to a newer version of the Linux kernel.
To work around this issue, Red Hat recommends that you increase the Java stack size by setting "-Xss2m" in the Java startup parameters. For the System Agent, that means you must add the following setting to the agentparm.txt file.
oscomponent.jvm.x.options=-Xss2m
For more information from Red Hat about this issue, see the following documents:
Installer Indicates Success when Installation Fails Due to Invalid JVM Version
On the iSeries, 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.7 or higher is required for installation. If a version lower than 1.7 is used, the installation fails with the following error: The installer cannot run with the given JVM. Java 1.7+ is required. However, the output reflects an exit code of 0. See the following example output from an iSeries v5 installation:
$ /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/bin/java -jar setup.jar
===============================================================================
CA WA Agent 11.4.00.00 (created with InstallAnywhere)
-------------------------------------------------------------------------------
The installer cannot run with the given JVM. Java 1.7+ is required.
$ echo $?
0
Agent for iSeries on Release DVD Cannot Run UNIX Jobs
Workload Automation Agent for iSeries distributed on the 11.4.00 release media (a DVD) cannot run UNIX jobs. It is limited to native iSeries (i5) jobs.
(AIX only) Agent May Crash with Core Dump When Using Java 8 on POWER 8 Systems
When running an agent that uses Java 8 on AIX on POWER 8 systems, it is possible for the AIX runtime instrumentation to cause the agent to crash with a core dump.
The workaround for this issue is to disable runtime instrumentation by setting the following in the agentparm.txt file:
oscomponent.jvm.x.options=-XX:-RuntimeInstrumentation
If parameters are already set in the oscomponent.jvm.x.options setting, you must separate the new setting from the existing one with a semicolon, similar to the following example: oscomponent.jvm.x.options=existingparameters;-XX:-RuntimeInstrumentation
For more information about this issue, see the following documents from IBM:
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.
Migrating an R6 or R7 agentparm.txt File to 11.4.00
The 11.4.00 installer does not support the migration of an R6 or R7 agentparm.txt file to 11.4.00. To use an R6 or R7 agentparm.txt file in 11.4.00, you must install the 11.4.00 version of the agent and manually copy any customized entries from the R6 or R7 agentparm.txt file into the 11.4 agentparm.txt file.
Workload Automation AE 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 Workload Automation AE 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, use one of the following methods:
Install a version of the agent earlier than 11.3 SP4 Incremental 2.
Change the syntax of the command to begin with "cmd.exe /c" followed by the original command.
UNC Path Containing Parentheses in File Trigger Fails
(Workload Automation DE only) A file trigger that references a UNC file name that contains special characters, such as parentheses, fails to create the trigger.  For example, the following file name does not work: \\myshare\myfile(1).txt
The job fails with a status of Scan Failed and a detailed status such as:
The <directory> does not exist or not a directory.
To work around this issue, begin the UNC file path with four backslashes instead of two, for example, \\\\myshare\myfile(1).txt
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, for example.
File Watcher Requires r + x Permission for Each Directory in a Path
(Valid on some versions of UNIX, such as AIX and HP-UX) A file watcher job requires read and search (r+x) for every directory in the path; otherwise, the job continues to run indefinitely even though the file exists. This issue is caused by a limitation in the AIX implementation of the glob() system call. When one of the directories in a file path specifies x permission, but not r permission, the AIX version of the call does not work as documented. Instead of returning the file path to the file (if it exists) or returning NOMATCH if it does not exist, AIX returns the directory of the file only and a code of success. This problem does not exist with version 4.51 of the agent.
Until a fix is implemented in the AIX code, ensure that file watcher has both read and search (r+x) permission for every directory in the path.
Resource Temporarily Unavailable Errors on AIX
(Valid on AIX) When running jobs on AIX, some of the jobs fail to complete with submission errors (SUBERROR). The job log contains the following error message:
CAWA_E_20039 Cannot fork a new process to execute the job:/usr/bin/ksh, reason:Resource temporarily unavailable.Error code: 11
The error can occur because of a memory issue.
To see the maximum number of user processes on your system use the following command:
lsattr -E -l sys0 -a maxuproc
Sample output:
maxuproc 128 Maximum number of PROCESSES allowed per user True
To resolve the issue, we recommend that you increase the number of user processes to 1024 using the following command:
chdev -l sys0 -a maxuproc=1024
Unable to Restart the Agent on z/Linux or AIX
(Valid on z/Linux and AIX)
After you run UNIX jobs and stop the agent, it cannot be restarted. The defaultlog_agent.log contains the following exception and the stack trace:
main.MainThread.CybTcpipControllerPlugin.initialize[:283] - cybermation.library.communications.CybConversationException: Address already in use …
The issue occurs when the operating system does not release the agent listening port.
To prevent this issue from occurring on z/Linux, set the following parameter in the agentparm.txt file:
oscomponent.closefds=200
This parameter causes the agent to close file descriptors, preventing the scripts or binaries of the user from inheriting them.
Note:
If this setting does not resolve the issue, increase the value of oscomponent.closefds up to a maximum of 300.
On AIX, oscomponent.closefds is set to 200 by default, but it can be increased to a maximum of 300 if necessary.
Chkusr Utility Not Supported on iSeries
(Valid on iSeries) The chkusr utility that is provided with the agent is not supported on iSeries because the standard PAM (Pluggable Authentication Modules) library that chkusr uses is not applicable to the iSeries environment. This issue will be addressed in a future release.
Resource Monitoring Not Supported in the iSeries Agent
(Valid on iSeries) The resource monitoring should send an alert to the scheduler when available disk space reaches the threshold that is defined in the agentparm.txt file. This feature is not yet supported in the iSeries Agent.
For information about previous releases of CA Workload Automation Agent and agent plug-ins, see Release Information. Expand the section for the agent or agent plug-in that you are interested in to find the enhancements, fixed issues, and known issues for each release.
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.
Resolved Issues
The following issues have been resolved:
11.4.01
SYSAGT-334 The System Agent uninstall on the I5 platform did not uninstall/remove the installation library
After uninstalling a System Agent on I5, the library where the agent was installed into continued to exist. You had to manually uninstall the library and/or the library name would not be able to be reused if the agent was reinstalled.
SYSAGT–325 FTP Job Creates Empty Target When Source is Missing
When a local file does not exist for an FTP upload, the job fails; however, a zero-length file is created on the FTP server.
The existence of files on the server may make it seem that the transfer was successful, when it was not.
SYSAGT - 321 Agent for iSeries Cannot Execute UNIX Command Jobs
Agent for iSeries release 11.4 cannot execute RUN jobs that target the UNIX subsystem, because the jobs do not execute properly. They remain in a stuck or hung state, with no job execution or failure information being sent to the scheduler.
SYSAGT-320 SFTP Read Timeout Greater Than 30 Seconds Not Used
SFTP read timeout value greater than 30 seconds is not used. Setting the read timeout value for SFTP transfers greater than 30 seconds retains the 30 second timeout.
SYSAGT-319 Silent Installation Ignores LOCAL_SECURITY=ON
In release 11.4.00 of the agent, the silent installation does not honor the LOCAL_SECURITY=on value during a silent installation.
SYSAGT-318 Extended ASCII Characters Not Preserved
After upgrading to 11.4.00, extended ASCII characters are not preserved, even after setting communication.v2.nativeafmencoding to true.
SYSAGT-317 Error Message “tzmappings: Illegal format at near line 11” Occurs During Installation
On AIX PPC64 and HP IA-64 platforms, the following message sometimes appears during installation: tzmappings: Illegal format at near line 11.
SYSAGT-315 File Watcher Can be Triggered Twice
Workflow can be triggered twice with File Watcher jobs (File Trigger jobs that use RunExternal). This problem occurs because File Watcher jobs do not support the DropIfExists keyword that is supported with regular File Trigger jobs.
SYSAGT-314 File Watcher Returns File Already Created
File Watcher jobs (File Trigger with RunExternal) can return "File already created" even if the file does not exist when the job starts.
SYSAGT-313 CPU Load Balancing
(Agent for HPE Integrity NonStop only) The Agent for HPE Integrity NonStop supports load balancing. With this enhancement, you can specify a set of CPUs to be used for job execution. Jobs are automatically executed across the available CPUs in the specified set. If a CPU is not explicitly stated as part of the job definition, the job is allocated to the next available CPU.
SYSAGT-312 Plug-in Installation Fails When the Agent Installation Directory is Specified As "."
When you use the PluginInstaller to install a plug-in, if the agent installation directory is specified as "." instead of a full path (for example, “./PluginInstaller ./appservices.pak .”), the PluginInstaller fails while backing up the files with a message like:
… is not a file in the agent directory. It cannot be backed up.
SYSAGT-311 Memory Leak When Running File Triggers
A large number of File Trigger jobs can cause a memory leak. If over a period of time, a large number of file triggers are created and deleted, a small memory leak can occur, which causes the agent to run out of Java heap space.
11.4.00
SYSAGT-309 afmtransfer.breaklonglines
The afmtransfer.breaklonglines parameter enables the behavior of the agent before release 11.3.07 with regard to the transfer of spool files. Before release 11.3.07, if a line in a spool file exceeded 24576 bytes, the agent issued the message “Aborted line too long” and canceled the transfer of the spool file.
In release 11.3.07, this behavior was modified. When the scheduler requests a spool file that contains a line that exceeds 24576 bytes, the agent now inserts a line break within that line and transfers the file to the scheduler.
If you want to preserve the behavior prior to release 11.3.07, add the afmtransfer.breaklonglines parameter to the agentparm.txt file, and set it to false, as shown:afmtransfer.breaklonglines=false
SYSAGT-308 Java Does Not Correctly Identify Windows 2016 Operating System When Reporting Agent Status
In Windows 2016, the operating system name and version that the agent sends when reporting its status to the manager is not correct. Instead of sending “Windows Server 2016 for x86” as the operating system and version, the agent sends “Windows NT (unknown) for x86.”
This message is used because the current version of Java does not correctly identify Windows 2016.
SYSAGT-307 Installing the Agent in a Directory That Starts with the Letter U
(Windows only) You cannot install the agent on Windows in a directory that starts with a lowercase “u” (for example, \utils). Because the configuration file follows the standard Java properties file format, \u is used to escape Unicode. A directory name that starts with a lowercase “u” is recognized as an escape sequence. (See section 3.3 of the Java Language Specification for details.)
The installation fails if “\u” is in any part of the path, for example:
  • c:\utils
  • C:\Program Files\CA\utils
  • C:\apps\utils\CA
To work around this issue, either install the agent in a directory starting with an uppercase “U” (for example, \Utils), or use a directory name that starts with a letter other than “u.”
SYSAGT-305 iSeries  FTP Job Cannot Retrieve a Spool File
(iSeries only) When trying to retrieve a spool file an FTP job returns the following message: "Spool file retrieval failed."
SYSAGT-304 Transfer Fails When Triple DES (3DES) Cipher is Used
When transferring a file, an SFTP job fails if the weak cipher 3DES is used. The job fails with the following message:
com.jscape.util.l.a.f: attempt to process more than 1048576 blocks with TripleDES
SYSAGT-303 Completed iSeries Jobs Remain in Executing State
(iSeries only) Some jobs remain in the executing state even though they were completed in iSeries. This issue with idling jobs can slow down new iSeries jobs.
SYSAGT-302 iSeries File Trigger Jobs with IASP Path Do Not Run
(iSeries System Agent only) FILETRIG jobs do not accept IASP (Independent  Auxiliary Storage Pools) QSYS.LIB as the file path.
Example
/QAS/QSYS.LIB/.....
When this path is used, the agent returns the following message:
STATE FAILED Status("Scan Failed")
SYSAGT-301 File Not Found with TargetOS Set to WINDOWS
SFTP jobs fail when the agent tries to connect to a UNIX server with the TargetOS set to WINDOWS.
The agent returns the following status:
Error downloading: File or directory not found.
SYSAGT-300 Common Algorithms Not Found
SFTP jobs fail when the agent attempts to connect to a server that uses optional HMACs, such as the following:
  • HMAC_SHA2_256_96
  • HMAC_SHA2_256
  • HMAC_SHA2_512_96
  • HMAC_SHA2_512
  • HMAC_SHA1_96
  • HMAC_SHA1
  • HMAC_M5_96
The agent responds with the following message:
Common algorithms not found.
SYSAGT-299 iSeries Filetrig Job Cannot Accept ASP/IASP Path
(iSeries only) Agent for iSeries does not accept a file path that has a preceding path right before /QSYS.lib
Example:
/QAS/QSYS.lib
A preceding path indicates that user has set up either ASP or IASP.
iSeries System Agent returns STATE FAILED Status("Scan Failed")
SYSAGT-298 Job Fails When Blanks Are Used in Parameter
(iSeries only) Agent for iSeries does allow a scheduling manager to submit a job with a blank in the parameter.
SYSAGT-297 ESPmgr Prints Error Indicating that ESPAGENTTOKEN and ESPAGENTHASH Are Not Defined
When run from a command prompt, the ESPmgr utility prints the following messages:
  • Error: The ESPAGENTTOKEN environment variable is not set.
  • Error: The ESPAGENTHASH environment variable is not set.
These messages falsely indicate an error when none exists. You might see these error messages even when the environment variables are set. You can either ignore the messages or avoid them by copying an earlier version of ESPmgr (11.3.05 or earlier) to the System Agent directory to replace the current version of ESPmgr.
This problem was introduced in ESPmgr in the 11.3.06 System Agent.
SYSAGT-296 ESPmgr Passes Gibberish in LocalUser()\
(Windows only) When the version of ESPmgr that comes with the 11.3.06 and 11.3.07 releases of System Agent is run from the command line and not from a job, it can fail due to random, invalid bytes in the LocalUser() parameter, for example, "LocalUser(Ö…X)" instead of "LocalUser(TOSEUSER)." This issue makes ESPmgr.exe on Windows unusable from the command line.
SYSAGT-291 NonStop Job Terminates Prematurely Causing the Job to Abend
(NonStop only) System Agent for NonStop can terminate a job prematurely if the job has more than one TACL process. Although the agent shows the job as terminating with 0, in the NonStop environment the job is Abended.
SYSAGT-290 Process Not Killed Within Signals Interval
When a Workload Automation AE job is killed with a KILLJOB event and the process does not exit in the time specified by the KillInterval (default of 3 seconds for each signal in KillSignals), the KILLJOB might fail and report KILLJOBFAIL, even though the process eventually exits.
Spurious KILLJOBFAIL statuses for the job appear in autorep reports.
When a job is canceled with CONTROL CANCEL using a list of signals using the KillSignals keyword (or the oscomponent.killsignals agentparm.txt parameter) and the interval between signals is specified with SignalsInterval (or the oscomponent.killsignals.interval parameter), the process may not be killed by the first signal within the interval that is specified by SignalsInterval.
When this occurs, the agent attempts to send the next signal in the list. At this point, if the process has terminated, the agent sends a FAILED status for the CONTROL CANCEL. The status for the job iis “Aborted, signal x.” You can correct it by increasing the SignalsInterval (or oscomponent.killsignals.interval) to allow a larger interval between signals.
SYSAGT-289 Job Failed Because CA Workload Automation AE Cannot Retrieve Job Log
(iSeries only) If an i5 job does not produce output, the agent generates an error 4001 because it cannot open the spool file of an i5 job, because it does not exist. This condition occurs with iSeries jobs that use this parameter: ccexit=*severity.
SYSAGT-288 Extended ASCII Characters In STDOUT or STDERR Fail on Retrieval
Extended ASCII characters in the STDOUT or STDERR file can prevent the scheduling manager from retrieving the file.
Although the file retrieval fails, the file retrieval response messages stay in the queue. The agent continues to try to send them, blocking all other messages to the target manager. As a result, the scheduling manager does not receive any messages after the failure.
SYSAGT-287 Agent Does Not Start When Java Initialization Fails
Upon startup, the agent crashes or immediately shuts down. When the agent fails to start, the only log files are runner_os_component.log (when the agent crashes) or the defaultlog_agent.log (when the agent immediately shuts down).
The problem is due to slow initialization of static variables in the Java JVM. The JVM may take over 30 seconds to initialize, instead of one or two seconds, as in a normal environment. If you remove the cause of the slowdown in the machine, the agent starts typically.
SYSAGT-286 Agent Remains in Windows Add/Remove Programs List After Uninstallation
(Windows only) After uninstalling a System Agent on Windows, the Add/Remove programs list continues to show the agent as installed. If you attempt to uninstall the agent again through the
Add/Remove Programs
option, you see the following error:
An error occurred while trying to uninstall xxxx. It may have already been uninstalled. Would you like to remove xxxx from the Programs and Features list?
This occurs because the agent uninstallation procedure does not completely remove all related entries in the Windows registry. The remaining entry causes the Agent to appear as installed in the
Add/Remove Programs
list.
SYSAGT-285 "CRLF expected" Error Occurs with FTP and SFTP Jobs
When executing FTP and SFTP jobs, the jobs fails with the error "CRLF expected." This occurs with FTP and SFTP servers that transmit their login banner using only CR (/r) style line feeds. The agent can process only banners with CRLF or simply LF for line feeds.
SYSAGT-284 -VV Option Changes Status to Inactive
(UNIX only) When you execute the "-vv" command line option to show enhanced verbose agent information, the "Status" file containing information about the running state of the agent is overwritten and shows the agent  "Inactive." The agent itself if unaffected by the incorrect Status file, but the status might lead you to conclude that the agent is not running when it is.
SYSAGT-282 The chkusr Utility Fails to Run on 64-bit AIX(AIX only)
When you run the chkusr utility on 64-bit AIX, the following error is generated, and the chkusr utility does not run.
Unable to load pam library: Could not load module /usr/lib/libpam.a(shr.o). The module has an invalid magic number.
In addition, if you try to use CONTROL VERIFY from either CA-7or from WCC also fails.
This issue occurs because the agent does not load the 64-bit PAM libraries when it runs on 64-bit AIX.
To work around this issue, copy the chkusr utility from the 32-bit AIX installation into the 64-bit installation.
SYSAGT-281 Signals are Blocked with AutoSys KILLJOB
(HP-UX only) When you use CONTROL CANCEL (AutoSys KILLJOB) to terminate a job that uses a list of signals (KillSignals), blockable signals are blocked and not delivered.
The following symptoms occur:
  • A running job does not receive intermediate signals on an AutoSys KILLJOB.
The spool file (or the STDERR file) might contain messages such as:
  • Failed to unblock signal 14: 22 (Invalid argument)
  • Failed to unblock signal 1: 22 (Invalid argument)
  • Failed to unblock signal 2: 22 (Invalid argument)
  • ...
This issue occurs because the agent handles signal behavior on HP-UX differently than on other UNIX/Linux platforms.
SYSAGT-280 Agent Returns Error: Aborted Line Too Long
If the spool file for an executed job contains a line that is longer than 24576 characters, the scheduler may be unable to retrieve it. When attempting to retrieve a spool file from an agent for an executed job, the agent may return the following error:  Aborted line too long
SYSAGT-279 Logging System Errors Written to Console Are Not Seen in Windows
If the logging system cannot be initialized due to a bad parameter in the agentparm.txt file, the error is written to the console. These messages cannot be seen on Windows, where the agent is started as a service.