The following new product features, enhancements (RFE), and changes are introduced with this Fix Pack:

DevOps made easier with workload applications

If you have a few use cases where the workload application templates replicated in your workload environment are a little too rigid, then this new enhancement will add the flexibility you are looking for.

After a workload application is exported into a workload environment, the contents such as, job streams, jobs, and other objects, are created in the environment and an association to the workload application is maintained. This allows for easy subsequent updates and synchronization between the workload application template exported from the source environment and the workload application in the target environment. The workload application can be easily replaced and updated. However, there might be certain circumstances where you prefer not to have an association to the workload application so that the imported objects can be freely updated or deleted.

When importing a workload application template, you can now specify whether you prefer to import only the objects contained in the template, without any ties to the workload application, or to import the objects maintaining their association to the workload application. Even after you have imported the contents of a workload application template into a target environment, removing the association to the original workload application template, you still have some options through the wappman command line that enable you to manage the objects as a whole, such as deleting all of the objects or replacing all of the objects.

These workload application template enhancements are supported when connected to an engine with version 9.4.0.4 or later.

For details about importing a workload application template, see Importing a workload application template. For information about the new options available for wappman see wappman.

Additional support for agents

Support for fault-tolerant agents, dynamic agents, and z/OS agents has been extended on Sun Solaris SPARC 64-bit.

Automatically register agents to pools

Starting from version 9.4 Fix Pack 4, you can automatically register dynamic agents in pools by editing a file.

Starting from version 9.4 Fix Pack 1, you can automatically register dynamic agents in pools by editing the pools.properties file located in <TWS_home>/ITA/cpa/config.

The file is composed by a series of lines with a list of pools to which the agent will be automatically registered. To make the changes in this file effective on the agent, you must stop and start the agent.

Because an agent can encounter problems and is not able to register and go online, for example, if it does not find a pool defined in the system, there are options that can be used in the pools.properties file to allow the agent to go online even if some pools are not defined.

This alternative way of registering dynamic agents to a pool can be useful when you need to quickly add more than one agent to a pool, or when you want to associate multiple pools to a dynamic agent.

Satisfying Requests for Enhancements (RFEs)

Requests for Enhancements (RFEs) give customers the opportunity to collaborate directly with the product development team and other users. The team prioritizes and develops new product features based on proposals made by customers.

HCL Workload Automation V9.4 Fix Pack 4 delivers the following RFE:

RFE 117399: Windows 2016 WSCF cluster support

Support has been extended to Microsoft Windows Server 2016 Failover Clustering (WSCF) on agents.

To view a complete list of RFEs, new, planned, and delivered, see: RFE online community .

Option to determine when fileCreated event is sent

The -modificationCompletedTime option can optionally be specified with the -event fileCreated argument to determine when the fileCreated event is sent. The filemonitor utility is used to check for changes in files (files that are either created or modified). You can now specify the -modificationCompletedTime <seconds> option with the -event fileCreated argument to determine when the fileCreated event is sent. This option is optional and when specified, if a file is created, the event is not sent immediately, but only after the interval of time specified by -modificationCompletedTime<seconds> has elapsed, and during which no subsequent changes were made to the file, which includes the file being deleted and recreated with the same name.

Managing pools and agent connectivity

Starting from HCL Workload Automation version 9.4 Fix Pack 4, you can automatically register dynamic agentsin pools by editing a file.

Starting from version 9.4 Fix Pack 1, you can automatically register dynamic agents in pools by editing the pools.properties file located in <TWS_home>/ITA/cpa/config.

The file is composed by a series of lines with a list of pools to which the agent will be automatically registered. To make the changes in this file effective on the agent, you must stop and start the agent.

Because an agent can encounter problems and is not able to register and go online, for example, if it does not find a pool defined in the system, there are options that can be used in the pools.properties file to allow the agent to go online even if some pools are not defined.

This alternative way of registering dynamic agents to a pool can be useful when you need to quickly add more than one agent to a pool, or when you want to associate multiple pools to a dynamic agent.

New options added to pool.properties

Two new options, ;optional and ;skip, have been added to the pool.properties file to manage situations where a dynamic agent is unable to link to the master domain manager. The ;optional option discards problematic pools allowing the agent to go online. The ;skip option can be used to maintain a pool in the list of pools, but avoid it being used.

Updated version of GSKIT

Fix Pack 4 has been updated with GSKIT version 8.0.50.88.

Updated OpenSSL libraries

HCL Workload Automation has been updated with OpenSSL version 1.0.2o.

IBM SDK for Java

Fix Pack 4 has been updated with Java version 8.0.5.10/8.0.5.11, depending on the platform.

The following new product features, enhancements (RFE), and changes are introduced with this Fix Pack:

Modifying job instances in the plan (RFE 89523)

Modify a job instance in the plan before it runs or modify an instance of a job in the plan that has already run and rerun the modified job.

You can modify a job definition in the database whenever and as many times as you want. However, there are times when you need to make changes to the job definition, but it has already been submitted into the plan and runs as is. This results in extra work and lost time in updating the definition in the database and then getting it into the plan to run.

This feature adds the flexibility you need so that you can now make changes to the definition even after it has already been submitted into the plan, maintaining the original definition in the database. With this additional flexibility, you can edit the job definition on-the-fly before it runs or rerun a job with a different definition. This can be done from either the Job Stream Graphical View, the job monitoring view, or from the conman command line.

Maybe you want to substitute the command or script executed by the job with a different one? Maybe you just need to tweak an argument? Maybe you need to rerun a job updating the logon name, priority, or connection server? Whatever the change, this enhancement allows you to quickly react and avoid possible disasters, and increase your productivity by addressing additional scenarios in your workload that were not contemplated at the time you modeled or planned your workload.

For details about how to modify the job definition in the plan using the conman command line, see the commands Altjob and Rerun.

See the video: New opportunities to react and recover on the Workload Automation YouTube channel.

Easy installation for patches on agents

You can now easily install patches on agents using the twsinst command with the -patch option.

Enhancements to IBM i job monitoring and control (RFE 114590)

Monitoring and control facilities for IBM® i jobs have been enhanced to simplify the management of IBM i inquiry messages.

Automated reply to inquiry messages

For the most frequent IBM i inquiry messages, you can define standard rules to automate the reply to the waiting messages. When defining an IBM i job, by using the Workload Designer of the Dynamic Workload Console or the composer command line, you can specify the list of messages for which you want to set up an automated reply. When specifying the automated replies, a new parameter has been added to the job definition: the Message Max Replies parameter. It represents the maximum number of automated replies accepted for a specific message. This new parameter optimizes the management of IBM i inquiry messages.

For example, when you set a wrong reply to a message in the job definition, IBM i system keeps on sending out the same inquiry message repeatedly, while waiting for the correct reply. To avoid this issue, HCL Workload Automation has now the capability to intercept and disable the wrong reply and require, with a prompt, a direct reply from the Dynamic Workload Console. The job remains in SUSP (suspended) status until the correct reply is provided.

Reliable monitoring of IBM i job status changes

As an inquiry message receives an automated reply, the IBM i job status changes from SUSP (suspended) to EXEC (executing) and vice versa. All the job status changes are monitored and tracked. This is useful, for example, when you want to create an event rule definition to send an email every time a job status change occurs.

Improved trace facilities

Trace facilities for IBM i jobs have been improved. To specify the desired tracking level, customize your IBM i agent by setting the required parameters in the JobManager.ini file, in accordance with the settings on the IBM i system.

For more information, see Scheduling and monitoring jobs on IBM i systems. See the video Simplify workload management for your IBM i Systems.

New Plug-ins for Cloud Automation

Amazon EC2, IBM SoftLayer®, and Microsoft Azure plug-ins are available to manage the provisioning and de-provisioning of virtual machines in the cloud, on as-needed basis.

Customers choose to move their application to the cloud to focus on business optimization. Once in the cloud, applications rely on systems provisioned and de-provisioned to run defined business workflows but unpredictable workload volumes. Customers face a new question: Is it better to over-provision cloud resources with the risk of wasting them, or under-provision with the risk of degrading performance and delay the business process?

How about provisioning just the right amount of resources for only the time-period you need them? Exactly what you need, when you need it, and rather than incur extra costs and waste, de-provision when you’re done, all automatically.

To succeed in this challenge, a new approach is required, that strictly ties business workflows with cloud resource management. While managing a business application, IT organizations need to be able to orchestrate provisioning and de-provisioning of the infrastructure needed by the business application in the cloud.

HCL Workload Automation provides three Cloud Automation plug-ins, for different cloud providers, to manage the provisioning and de-provisioning of virtual machines in the cloud, on as-needed basis. By orchestrating the application workflow and the workflow that manages the entire lifecycle of the virtual machines needed by the applications (including the actions: start, stop, snapshot, etc…), HCL Workload Automation can increase both business and infrastructure agility. The plug-ins are:

• Plug-in for Amazon Web Services (EC2)
• Plug-in for IBM SoftLayer
• Plug-in for Microsoft Azure

Select your cloud provider, and add one or more jobs in the job stream that automates your business process flow to provide a flexible and dynamic allocation of cloud resources to your workload.

For more information about the Cloud Automation plug-ins, see Scheduling Applications with HCL Workload Automation.

See the video: Workload Scheduler for Cloud Automation on the Workload Automation YouTube channel. More videos are available for the features released with V9.4 Fix Pack 3 on this dedicated playlist: Workload Scheduler V9.4, Fix Pack 3.

Apache Spark Plug-in

With the new HCL Workload Automation plug-in for Apache Spark, you can schedule, monitor and control Apache Spark jobs.

Apache Spark a lightning-fast cluster computing technology, designed for fast computation. It is based on Hadoop Map Reduce and extends the MapReduce model to efficiently use it for more types of computations, which includes interactive queries and stream processing. The main feature of Apache Spark is its in-memory cluster computing that increases the processing speed of an application. HCL Workload Automation provides a plug-in for Apache Spark that helps you manage your big data processing and analytics. With the plug-in for Apache Spark, you can define, schedule, monitor, and control Apache Spark jobs. Add one or more Apache Spark jobs in the job stream that automates your business process flow to obtain an end-to-end workload management solution.

For details, see Scheduling Applications with HCL Workload Automation.

Restarting JSR 352 Java™ Batch jobs from the point of failure (RFE 110252)

You can restart JSR 352 Java Batch jobs from the point of failure.

During the execution of a JSR 352 Java Batch job, when monitoring the job from the Dynamic Workload Console

More flexibility in managing successors for job actions

You can now hold, release and rerun the successors during your job monitoring.

You have a list of all successors for the selected job, view the successors in two separate tables and decide if you want to run all internal successors, all internal and external successors, or a subset of them. By default, all successors are selected. By selecting the mode you can also control how successors are selected: manually, including successors in the same job stream or including successors in other job streams.

For more information about how to rerun successors from the command line, see the Listsucc and Rerunsucc commands.

Updated version of WebSphere Application Server (WAS)

Fix Pack 3 has been tested using WAS version 8.5.5.13

Updated OpenSSL libraries

HCL Workload Automation has been updated with OpenSSL version 1.0.2l.

Resolved Common Vulnerabilities and Exposures (CVE)

The following CVEs have been resolved with this Fix Pack:

• CVE-2017-15095
• CVE-2017-7525
• CVE-2017-17485

Additional support for agents

Support for Oracle Enterprise Linux version 6.x has been extended to fault-tolerant agents, dynamic agents, and z/OS agents.

The following new product features, enhancements, and changes are introduced with this Fix Pack:

Support for updated versions of WebSphere Application Server (WAS)

Fix Pack 2 has been tested using WAS version 8.5.5.12

Support for updated versions of Dashboard Application Services Hub (DASH)

Fix Pack 2 has been tested using DASH version 3.1.3.0 CP4

Support for updated versions of JazzSM

Fix Pack 2 has been tested using Jazz version 1.1.3

Rollback procedure

Roll back a master domain manager to a previous Fix Pack level or release if the master domain manager was installed with IBM Installation Manager.

To roll back a master domain manager to a previous Fix Pack level or release, you first need to create a backup before installing the new Fix Pack or release. This allows you to then perform a rollback procedure after the Fix Pack or release has been installed.

The roll back procedure is supported starting with Version 9.3 Fix Pack 3.

The following are requests for enhancements (RFEs) introduced in Fix Pack 2:

RFE 179819: Database job executor handles stored procedure errors

Enhance the database job executor to handle stored procedure errors.

RFE 15616: Actual workstation displayed when monitoring jobs

The name of the workstation where a job, scheduled to run on a pool or dynamic pool, actually ran.

When jobs are scheduled to run on pools or dynamic pools, you might want to monitor the job or the workstation where the job ran. Previously, this information was available only in the job log. With this enhancement, the name of the actual workstation where the job ran is also available in a new column in the monitor job query. This detail is available if the job has started or has already run. This information can also be output in reports.

This information can also be useful when you need to determine your license consumption and therefore need to know on which workstation in the pool the job actually ran.

For details about the actual workstation see the columns that can be defined when monitoring jobs in the Dynamic Workload Console. The runtime information contained in the conman showjobs command also contains this information.

RFE 108425: File monitor support for already created files

Normally the filemonitor utility runs an initial scan and then runs subsequent scans to detect any new or changed files since the initial scan that match specific criteria. This means that if there are any existing files matching the criteria when the initial scan runs, they are not considered. The utility has been updated with a new parameter to be able to discover existing files during the initial scan that match the criteria and can therefore generate an event. For more information see the -generateEventsOnFirstScan argument for the Filemonitor command.

RFE 111032: Need ability for File monitor in IWS z/OS to detect file existence on UNC path

Use the filemonitor utility to check for changes of files (files that were either created or modified). This could be useful when, for example, you want to make sure that a file exists before running a job that processes that file. By defining a job that runs the filemonitor utility, you can implement file dependency, that is, a relationship between a file and an operation in which specific activity on the file determines the starting of the operation.

Job Management Plug-in

The new Job Management plug-in is available in the Automation Utilities plug-in category. Automation Utilities are plug-ins that facilitate specific HCL Workload Automation operations. Use the Job Management plug-in, to run one of the following actions on any job in the job stream where the Job Management job is running:

Table 1.

Actions that you can run on a job
Rerun Rerun the job and all its successor jobs Rerun the job and its successor jobs in the same job stream Release Release Dependencies Cancel Cancel Pending Hold Kill Confirm ABEND Confirm SUCC

The Job Management plug-in simplifies recovery scenarios and enables the automation of iterative workflows.

For more information, see Job Management jobs.

Automation of Iterative Workflows

For complex workflows, the iteration of a sequence of jobs within the overall orchestration can be a challenging task. By selecting the option to rerun a job with all its successors jobs in the same job stream, the Job Management plug-in enables iterative processing of a sequence of jobs while a condition is met. It is like a DO WHILE statement in programming languages.

It is just a matter of adding a Job Management job at the end of the sequence of jobs that you want to iterate. The Job Management job requests to rerun the first job in the sequence along with its successor jobs. The iteration is controlled by the output conditions of the first job in the sequence: it stops when the condition is no longer satisfied.

For more information, see Job Management jobs.

Advanced rerun flexibility

The new advanced rerun options help you orchestrate your workflows seamlessly, building recovery logic into the job definition itself and rerunning job successors directly from the Monitor Workload view.

When you create a job definition, you can now specify that you want the job to rerun for a specific number of times and after a specific interval, in case of failure. This ensures that fewer alerts are generated and the workflow continues smoothly. For example, if you have a job that needs to connect to a server which is periodically restarted, you can specify in the job definition that you want the job to rerun for a specific number of times and after a specified interval.

If the parent job ran on a workstation that is part of a pool or a dynamic pool, you can decide whether it must rerun on the same workstation or on a different one. This is because the workload on pools and dynamic pools is assigned dynamically based on a number of criteria and the job might be rerun on a different workstation.

Also, if a job fails, you can identify all its successors at a glance and decide whether you want to rerun the job with its successors. You can rerun either all successors in the same job stream, or all successors overall, both in the same job stream and in other job streams, if any.

For more information about how to specify the rerun options in the job definition from the command line, see Defining job rerun and recovery actions and Controlling job and jo stream processing.

For more information about how to rerun successors from the command line, see the Listsucc and Rerunsucc commands.

Use the Job Management plug-in to further automate your workflows. With the plug-in, you can perform a number of actions on jobs, such as rerun the job, with or without its successors, release its dependencies, or cancel the job, and many more. For example, in a recovery scenario, you can insert a Job Management job in your workflow. This causes the original job to rerun automatically when the relevant recovery job completes successfully, reducing effort and time consumption.

Job Stream Submission Plug-in

The new Job Stream Submission plug-in is available in the Automation Utilities plug-in category. Automation Utilities are plug-ins that facilitate specific HCL Workload Automation operations. Use the Job Stream Submission plug-in to submit a job stream for processing.

By adding the Job Stream Submission plug-in to your workflow, you can automate the submission of a specific job stream, minimizing code scripts and manual effort. Also, you can specify the earliest start time for the job stream and define the variable table associated to the job stream.

For more information, see Job Stream Submission jobs.

Condition-based workload automation

Condition-based workload automation provides a simple and immediate way to have your workflows start at just the right time. You can define in your job stream a condition that, when met, releases the job stream to run as scheduled.

For example, if you have a job stream containing jobs which analyze one or more files, you can have the job stream start only after the file or files have been modified or created. Also, if the job stream contains jobs which process the data in a database, you might want to have the job stream start after enough rows have been written into the database. You can also have HCL Workload Automation check repeatedly whether the condition is met.

You can start your workflow based on one of the following conditions:

• One or more files being created
• One or more files being modified
• A job completing with its output condition satisfied. You can apply this logic to the job stream or to specific jobs in the job stream.

For more information, see Condition-based workflow automation.

Monitor file changes using the filemonitor utility

Use the filemonitor utility to check for changes of files (files that were either created or modified). This could be useful when, for example, you want to make sure that a file exists before running a job that processes that file. By defining a job that runs the filemonitor utility, you can implement file dependency, that is, a relationship between a file and an operation in which specific activity on the file determines the starting of the operation.

You can use the filemonitor utility as a stand-alone command, or you can set the filemonitor keywords as additional parameters for the start condition of a job stream, either in the Workload Designer or from the composer command line. For more information about the start condition, see Condition-based workflow automation.

For more information, see Filemonitor.

New keyword for defining the latest start time in job streams

The jsuntil keyword defines the latest start time of a job stream. It also determines the behavior of the jobs in the job stream when the job stream is approaching its latest start time. Use the jsuntil keyword to avoid that the job stream is either suppressed, canceled, or set to continue (depending on the action specified in the onuntil keyword) if it starts before its latest start time. For example, if you have a job stream with jsuntil set to 10:00 am, and one of the jobs starts running at 9:59 am, the job and its successors run as scheduled.

This keyword is mutually exclusive with the until keyword.

There is also a major difference with between the until and jsuntil keywords:

If you specify the until keyword in your job stream definition

This keyword is evaluated also after the job stream has started. As a result, if the latest start time expires before the job stream completes successfully, the action specified in the related onuntil keyword is performed on the job stream and on its jobs, which have not yet started.

If you specify the jsuntil keyword in your job stream definition

This keyword is evaluated only once, as soon as all dependencies of the job stream are satisfied and the job stream state changes to READY. If the latest start time defined using the jsuntil keyword has not expired at this time, it is no longer evaluated and the job stream runs independently of it. However, to prevent the job stream from remaining in READY state indefinitely, two days after the time specified in the jsuntil keyword has expired, the job stream is suppressed by default.

For more information, see jsuntil.

New keyword for defining actions on late jobs

The onlate keyword defines the action to be taken on a job in job stream when the job's deadline expires. If the job is running when the deadline expires, it is killed. Killed jobs end in the ABEND state. Any jobs or job streams that are dependent on a killed job are not released. If the dependency on the job is a conditional dependency on the job completing in ABEND state, that dependency is released.

For more information, see onlate.

Preparing and installing a Docker image for dynamic agents

A Docker container automates the task of installing a running dynamic agent, along with everything that is required to run it: code, runtime, system tools, system libraries, and settings.

It provides a mechanism known as a Dockerfile, which is used to codify the steps to install and configure your dynamic agent. This is a plain text file that uses a standard set of commands to perform the all the installation and configuration steps. The resulting Docker image is a static image of the full set of software for the dynamic agent with the exact configuration.

An image is then built to become a Docker Container, which is a unique running instance of the software with its own processes, state, and configuration. You can start as many Docker Containers from a given image as necessary. This gives you the possibility to quickly provision multiple running instances of your software, each with their own processes, state, and configuration, quickly and easily.

For more information, see Creating a Docker image to run dynamic agents.

For a detailed video about this feature, see the Docker Agent for Workload Scheduler video available on the Workload Automation YouTube channel.

New options in managing workload applications

The following new options are available:

Export a job stream definition as a workload application template

From the Workload Designer, you can export a job stream definition and save it as a workload application template in a compressed file. The job stream definition can then be imported in another environment.

For more information, see Exporting a job stream definition as a workload application template.

Rename a workload application during the import process

A new parameter -workloadApplicationName <workload_application_name> is available for the wappman -import command to rename the workload application during the import process.

For more information, see wappman.

Modify the mapping file according to rules defined using regular expressions

You can optionally request that the mapping file produced by the export process is automatically modified by the import process, according to rules defined using regular expressions and specified in ad-hoc files. For more information, see Using regular expressions to modify the mapping file.

Integration with IBM UrbanCode Deploy

Workload applications can be created and then exported so that they can be imported in other HCL Workload Automation environments.

To export and import a workload application you can use either the Dynamic Workload Console or the wappman command line.

In alternative to the import process, you can automate the deployment of an application from one environment to another by using the Workload Automation plug-in of the IBM UrbanCode Deploy tool. For details about this plug-in, see the IBM UrbanCode Deploy documentation.

For a comprehensive library of videos about the new features for this release, see the Workload Scheduler version 9.4, Fix Pack 1 playlist available on the Workload Automation YouTube channel.

MSSQL database support extended on Linux

Microsoft SQL Server Enterprise Edition database is now supported on Linux.

Windows 2016 support

Windows 2016 is supported on all components.

For more information about new features introduced with this fix pack, see Summary of enhancements.

Helpful videos demonstrating new features for HCL Workload Automation is available on Workload Automation YouTube channel.

This section lists APARs and internal defects solved by Fix Pack 4.

This Fix Pack includes a number of fixes for internal defects found by the verification team that mainly cover the following product capabilities: installation, auditing, and mirroring.

This section lists APARs and internal defects solved by Fix Pack 3.

This Fix Pack includes a number of fixes for internal defects found by the verification team that mainly cover the following product capabilities: installation, auditing, and mirroring.

This section lists APARs and internal defects solved by Fix Pack 2.

This Fix Pack includes a number of fixes for internal defects found by the verification team that mainly cover the following product capabilities: installation, auditing, and mirroring.

This section lists APARs and internal defects solved by Fix Pack 1.

This Fix Pack includes a number of fixes for internal defects found by the verification team that mainly cover the following product capabilities: installation, auditing, and mirroring.

The following are software limitations and workarounds that affect HCL Workload Automation version 9.4.0 Fix Pack 1, 2, 3 and 4. For a list of known problems and limitations documented for the V9.4 General Availability release, see the product Release Notes at https://workloadautomation.hcldoc.com/help/topic/com.hcl.wa.doc_9.4/distrDDguides.html.

9.4 Fix Pack 4:

Incorrect job status after completion in success of a predecessor job

1. Define the following job definitions:

   $JOBS 
   
   AGT1#CDJ_FIRST_PRED
   DOCOMMAND "netstat -an"
   STREAMLOGON "ITAuser"
   TASKTYPE UNIX
   RECOVERY STOP
   SUCCOUTPUTCOND STATUS_OK "RC=0"
   OUTPUTCOND STATUS_NOT_OK "(RC>0) or (RC=-1)"
   
   
   AGT1#CDJ_PRED
   DOCOMMAND "netstat -an"
   STREAMLOGON "ITAuser"
   TASKTYPE UNIX
   RECOVERY STOP
   SUCCOUTPUTCOND STATUS_OK "RC=0"
   OUTPUTCOND STATUS_NOT_OK "(RC>0) or (RC=-1)"
   RECOVERY STOP
   
   
   AGT1#CDJ7
   DOCOMMAND "netstat -an"
   STREAMLOGON "ITAuser"
   TASKTYPE UNIX
   RECOVERY STOP
   SUCCOUTPUTCOND STATUS_OK "RC=0"
   OUTPUTCOND STATUS_NOT_OK "(RC>0) or (RC=-1)"
   RECOVERY STOP

2. Define the following job streams definitions:

   SCHEDULE AGT1#JS_FEX
   :
   AGT1#CDJ_FIRST_PRED
   END
   
   SCHEDULE AGT1#JS_EXT
   :
   AGT1#CDJ_PRED
   FOLLOWS AGT1#JS_FEX.CDJ_FIRST_PRED IF ABEND
   END
   
   SCHEDULE AGT1#CDJS7
   FOLLOWS AGT1#JS_EXT.CDJ_PRED IF STATUS_OK
   :
   AGT1#CDJ7
   END

3. Submit the job stream: AGT1#JS_FEX and wait the job: AGT1#JS_FEX.CDJ_FIRST_PRED ends in success state.
4. Submit the job stream: AGT1#JS_EXT and wait the job: AGT1#JS_EXT.CDJ_PRED ends in suppress state because of the not satisfied conditional dependency
5. Submit the job stream: AGT1#CDJS7 and wait the job: AGT1#CDJS7.CDJ7 ends in suppress state because of suppression of its predecessor

   After the last step the status of : AGT1#CDJS7.CDJ7 job is displayed in suppress using the command: conman sj AGT1#CDJS7.CDJ7 and in HOLD state from the Dynamic Workload Console.

   After the last step the status of AGT1#CDJS7.CDJ7 job is displayed in suppress using the command:

   conman sj AGT1#CDJS7.CDJ7 and in HOLD state from the Dynamic Workload Console.

Workaround: A planman resynch command will allow the Dynamic Workload Console to align the status of AGT1#CDJS7.CDJ7 job to the expected suppress value.

9.4.0 Fix Pack 3

SSH protocol fails to perform remote command (71149)

File transfer and remote command do not work with the following version of SSH: 5.3p1 release 123.3l6_9

Usage for the command altjob is incomplete(70578)

Azure plug-in does not work after changing the default SSL (70807)

When trying to change the default SSL protocol to the Java Client Application, editing

TWA\TWS\JavaExt9.4.0.03\jre\jre\lib\security\java.security

to start Azure, the plug-in does not work.

Workaround: Open the file

/opt/HCL/TWA_ITAuser/TWS/JavaExt/jre/jre/lib/security/java.security

replace

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize 
< 768, 3DES_EDE_CBC, DESede, \ EC keySize < 224

with

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize 
< 768, \ EC keySize < 224

9.4.0 Fix Pack 2

Changing language in Windows environment does not change HCL Workload Automation language as well (184736)

In a Windows environment, if you change the language from English to another language, HCL Workload Automation does not change the language, but remains in English.

Workaround: To workaround this problem, add the LANG environment variable and set it as new preferred language.

Japanese, Chinese, Korean Language: Warning message in installation panel: the temporary directory does not have at least 5 MB (184727)

Running the installation or the upgrade of HCL Workload Automation 9.4 Fix Pack 2, in Chinese, Korean and Japanese language, the Prerequisite Scan displays a warning message:

The scan cannot be run for different reasons: the temporary directory does not have at least 5 MB, the system registries are corrupted. Analyze the Installation Manager log files to see more details on the error. Check the Troubleshooting section of the Planning and Installation for a solution.

Despite this message the installation or the update process completes successfully.

Installation setup HCL Workload Automation fails if there is another HCL Workload Automation instance (184059)

When trying to install HCL Workload Automation 9.4 GA + Fix Pack 2 on a workstation where a master domain manager instance already exists, the installation fails.

Workaround: When launching the script to run Installation Manager, ensure that the script is launched from the folder where you unzipped the Fix Pack Image and specify the path to the folder where you unzipped the General Availability image.

Unexpected success message written in stderr instead of stdout (180169)

When using the composer command line, a message of success is erroneously written to the Standard Error instead of Standard Output.

9.4.0 Fix Pack 1

IV60757: AFTER SWITCHING MANAGER CANNOT BROWSE JOBLOGS

Conman cannot retrieve job logs in archived plans for jobs which ran on dynamic agents if the master domain manager in the archived plan is different from the current master.

178943: Agent installation does not find prerequisite 32 bit libraries on LINUX PPC64LE SELS 12 SP2

On LINUX PPC64LE workstations, the installation might fail because the following 32 bit libraries are missing with the following info in the log file/opt/HCL/TWA_twsuser/logs/result.txt:

The prerequisite fails because the 32 bit libraries are not available.
os.lib.libstdc.so.5_32   FAIL   Unavailable   /usr/lib/libstdc++.so.5
os.lib.libstdc.so.6_32   FAIL   Unavailable   /usr/lib/libstdc++.so.6
os.strings.libstdc       FAIL   Unavailable   /usr/lib/libstdc++.so.6:
GLIBCXX_3.4.6
  

Workaround: To workaround this problem,restart the installation using the twsinst script with the -skipcheckprereq parameter.

178681: JobStream re-submission does not work when the original job stream containing the start condition is defined on a workstation class

If you define a job stream for a workstation class specifying a start condition, you must select the Start Once option.

177195: supported number of concurrent filemonitor commands

If you plan to run hundreds of job streams containing start conditions on the same agent, you might want to take into consideration the resource overhead due to the filemonitor process.

HCL Workload Automation version 9.4.0 Fix Pack 4 supports all product versions indicated in the HCL Workload Automation version 9.4 Release Notes which can be accessed at the following link: https://workloadautomation.hcldoc.com/help/topic/com.ibm.tivoli.itws.doc_9.4/Release_Notes_for_HCL_Workload_Scheduler.htm#h3interop_tables.

For the most up-to-date information about disk space and memory requirements, see the hardware requirements at the following URL: https://workloadautomation.hcldoc.com/help/topic/com.ibm.tivoli.itws.doc_9.4/HCL_Workload_Automation_Supported_Hardware.htm.

<TWA_HOME>/TWS + <TWA_HOME>/TDWB + <TWA_HOME>/wastools + <TWA_HOME>/properties

Master domain manager or dynamic domain manger or their backups:

To uninstall using the IBM Installation Manager, see HCL Workload Automation .

Fault-tolerant agent or domain manager:

To uninstall the entire HCL Workload Automation instance, use the twsinst -uninst -uname username command from the TWS_home directory, where username is the name of the user for which the HCL Workload Automation agent is uninstalled.