Version 9.5 Fix Pack 3 delivers the following enhancements:

• Deploy HCL Workload Automation containers on AWS EKS
• Enhanced integrations
• Alerting system for widgets in the dashboards
• Customizing roles
• Optimized file transfer operations
• A new dashboard for monitoring file transfer jobs
• Launch in context
• Automatic SSL configuration
• Automatic evaluation of critical jobs at risk
• Export and import a dashboard
• Dashboards support XML-based data sources
• Compression integration
• Encryption integration
• Workload Automation on HCL SoFy
• HCL Workload Automation is Red Hat certified
• Support for Db2 Version 11.5 Standard Edition

Changed features and feature capabilities

New Web site for the HCL Workload AutomationHCL product documentation

The latest version of the HCL Workload Automation product documentation, version 9.5 Fix Pack 3/SPE3 can be found on the HCL Software Product Documentation web site at https://help.hcltechsw.com/workloadautomation/welcome/index.html. The former website, https://workloadautomation.hcldoc.com/help/index.jsp, continues to host previous versions of the product documentation (version 9.4.0.x).

Support for file transfer jobs on agents at Version 9.3

Agents at Version 9.3 can run existing file transfer jobs without problems. Jobs you create or edit from the Dynamic Workload Console at Version 9.5, Fix Pack 3 are not supported on agents at Version 9.3, but you can work around this problem by saving the jobs in the composer command line after editing them with the Dynamic Workload Console. The best practice is applying the latest fix pack level to the agents.

Skip objects when importing a workload application template

You can select the objects within a workload application template you do not want to import, both from the Dynamic Workload Console and wappman command. If you choose to skip an object, an object with the same name must be present in the target environment, otherwise an error message is returned. For more information, see wappman.

New optman option to specify the default licensing model for HCL Workload Automation workstations

You can now use the defaultWksLicenseType option to specify the default licensing model to be applied to HCL Workload Automation workstations. In a Docker environment, this causes all workstations to be created with the value assigned to the defaultWksLicenseType option. For more information, see Global options - detailed description.

The term $SLAVES was removed from the security file and replaced with the term $AGENTS

Because it is politically incorrect, the term $SLAVES, which applies to all fault-tolerant agents in both the classic and role-based security models, was replaced with the term $AGENTS with the same scope. No change is required to your existing scripts nor environments. For more information, see Configuring user authorization (Security file).

Improvements in time zone management for external follows dependencies for jobs and job streams

When the product evaluates matching criteria to resolve external follows dependencies it compares the start times using local time if both job stream instances use the same timezone, or it uses UTC in case they use different timezones. For more information, see Managing external follows dependencies for jobs and job streams.

Support for proxy servers when contacting the license server

You can now use a proxy server when contacting the license server. This is especially useful when your HCL Workload Automation environment cannot connect to the Internet. To set up communication with the proxy server, use the licenseProxyPassword, licenseProxyServer, licenseProxyServerPort, licenseProxyUser global options. For more information about global options, see setting global options .

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.5 Fix Pack 3 delivers the following RFEs:

RFE 18054: Custom role privileges

Now you can define new custom roles, assign specific privileges to a set of users, and also assign privileges outside the scope of the existing system role.

RFE 116406: Add state=cancl on showjobs command

You can now filter jobs which are in canceled status. For more information, see wildcards.

REF 116762: Improvements for Event Driven Workload Automation

You can now optionally modify the event processor server, for example to use a load balancer, by adding the Broker.Workstation.evtproc property in the BrokerWorkstation.properties file. For more information, see BrokerWorkstation.properties file.

RFE 117719: End time column available for job streams in monitoring panel

This column is available when creating a job task, with this enhancements the end time column is also available for job streams.

RFE 123642: DWC historical reports' self-cleaning option

A new self-cleaning property has been enabled to remove all temporary files created after a report generation.

RFE 124339: New Graphical View order settings.

Now you can reorganize the dependencies view in the Graphical View by clicking on the Graphical view button and choosing the order in which you want to see them. The available options are:

• From right to left
• From left to right
• From top to bottom
• From bottom to top

By default, it is set to from top to bottom.

You can also edit the TdwcGlobalSettings.xml file to customize the default Graphical View settings.

RFE 126163: DWC user with read only access locks out an ISPF user with modify privilege

z/OS environment only. Now if you open a list of job dependencies from the Dynamic Workload Console, the related ISPF panel is locked and it is not possible to edit dependencies until the job dependencies panel is closed.

RFE 85329 / RFE 130134: Ability to clean the query history

When you have a very high number of past queries saved in the Query drop-down list, it is not easy to find the query that you really need. With this fix pack, you can manage the list either by removing single queries or clearing all the query history.

RFE 133936: Enhancement to composer binary to allow schedule objects to be pulled via "Active" or "DRAFT" status

Two new filters (draft and active) are now available with the composer command to filter job stream in draft or active status. For more information, see filters and wildcards.

RFE 134893: default licensing model for HCL Workload Automation workstations

You can now specify the default licensing model for HCL Workload Automation workstations. By setting appropriately the values of the defaultWksLicenseType and licenseType global options, you can define the default licensing model to be applied to each workstation at creation time. For more information, see the detailed description of global options.

RFE 137834: Modify the configureDB upgrade script to include any Subsequent additional IDs

Modify the configureDB database upgrade script to include any additional Subsequent Database IDs for DB2. In the script which translates 9.3 database to the 9.5 structure, capture the roles assigned to the views before they were dropped and recreate them so you can reassign those roles at the end of the process. It should also assign those roles to any new views created. For more information, see How can I avoid providing the database administrator credentials when creating the database with DB2

RFE 139348: The report output limit has been improved to avoid Dynamic Workload Console issues

The default value for the Enable output limit checkbox has been increased from 5000 to 10000. This enables you to obtain the expected report output, and the Dynamic Workload Console to continue to work correctly without issues.

Furthermore, if a different default value is needed, a user with administration grants can uncomment the new SQL_REPORT_HTML_FORMAT_RESULT_MAX_NUMBER key in the TDWCGlobalsettings.xml file and enter the desired default value (either higher or lower to the default 10000).

Note: For HTML format, the SQL_REPORT_HTML_FORMAT_RESULT_MAX_NUMBER key is valid for all reports. For PDF format, the key is valid for Custom reports only.

If you want to generate a report with less than 30000 records, you can use both HTML and PDF formats. If you want to generate a report with more than 30000 records, use only the PDF format to avoid reliability issues with the browser.

For further information about how to modify the TDWCGlobalsettings.xml file, see the Customizing your global settings section in the Dynamic Workload Console User's Guide.

RFE 140107, 140108: Ability to perform actions on engines in the Dynamic Workload Console through a script or API call

To be able to schedule and run HCL Workload Automation processes in an automated way without having to log in to the Dynamic Workload Console, you can now perform actions such as create/edit, share/unshare, and delete on an engine through a script or by calling an API.

RFE 140216: Update optman global Options through REST API

You can now use REST APIs to update global options, in addition to the standard optman command.

RFE 141849: Justification fields for Workload Application Template import operation

You can now maintain an audit trail recording any changes and the related justifications while creating workload application templates with the wappman command. For more information, see wappman .

RFE 143098: Add all authenticated users

Simply adding a line into the authentication file, now it is possible to add all new users to a group and - without any other configuration - they will be authorized to login into the Dynamic Workload Console.

From now it is not necessary to assign a role to every single user. If the user registry already contains groups of users that are properly defined for using the console, it is possible to assign roles to groups too. If groups are not available in the user registry, then the special role all authenticated users can be used to assign roles to all the users at once.

For more information, see the Configuring roles to access the Dynamic Workload Console

RFE 143162: Prevent job streams from completing in error when the start condition is not met

The new enStartCondSuccOnDeadline global option is now available to specify if you want your job stream to be cancelled when the start condition is not met, even if the Start once option is not selected. By setting this option, you can avoid that your job stream completes in error due to just one failed run, also in the case when it previously ran successfully several times. With the new enStartCondSuccOnDeadline global option set to yes, when the deadline for the start condition is met, the monitoring job is confirmed in SUCC status and the job stream is canceled. When the option is set to no, the monitoring job is killed, so both the monitoring job and the job stream change to ABEND status. For more information, see Global options - detailed description.

RFE 143169/143839: Managing an event rule in the Dynamic Workload Console

Usability improvements for event rule actions such as editing, duplicating, and deleting event rules in the Dynamic Workload Console Workload Designer. In addition, more space is now provided in the properties section for events and actions.

RFE 143196: possibility to select object to be imported during a WAT import

You can now select the objects to be imported while creating a workload application template and skip unwanted objects. For more information, see wappman.

RFE 143260: Latest Start included in the critical path list and hot list

To identify problems related to a critical path that has a potential or high risk, the Latest Start time is now included in the critical path, in the hot list, and in the results of a monitor critical job query in the Dynamic Workload Console. The time before which the job must start is displayed provided all dependencies are satisfied.

RFE 142794

HCL Workload Automation Version 9.5 Fix Pack 3 has been updated with OpenSSL version 1.1.1g.

HCL Workload Automation includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/).

RFE 148080: Provides the capability to constrain a product component pod to run on particular nodes

The nodeAffinityRequired parameter has been added to the configurable parameters that can be customized when deploying product components with containers. With this parameter, you can determine on which nodes a component can be deployed using custom labels on nodes and label selectors specified in pods. Red Hat OpenShiftAmazon EKSAzure AKS

To submit a new RFE, write us here: HWAinfo@hcl.com

Entitlement to Db2 V11.5

With HCL Workload Automation, version 9.5, Fix Pack 3, you are entitled to use Db2 V11.5 Standard Edition.

Supported WebSphere Application Server Liberty Base version

HCL Workload Automation Version 9.5 Fix Pack 3 was formally tested using WebSphere Application Server Liberty Base version 20.0.0.10. and 20.0.0.11.

Updated OpenSSL libraries

HCL Workload Automation Version 9.5 Fix Pack 3 has been updated with OpenSSL version 1.1.1g.

HCL Workload Automation includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/).

CIT

Fix Pack 3 has been updated with CIT version 9.2.21.0000.

Updated version of GSKIT

Fix Pack 3 has been updated with GSKIT version 8.0.55.6.

OpenJDK Runtime Environment

Fix Pack 3 has been updated with Java version 1.8.0_265-b01.

Resolved Common Vulnerabilities and Exposures (CVE)

The following CVEs have been resolved with this fix pack:

Java

• CVE-2020-2800
• CVE-2020-2754
• CVE-2020-2757
• CVE-2020-2781
• CVE-2020-2830
• CVE-2020-2755
• CVE-2020-2756
• CVE-2020-4329
• CVE-2020-14583
• CVE-2020-14581
• CVE-2019-17639
• CVE-2020-14593
• CVE-2020-14577
• CVE-2020-14579
• CVE-2020-14578
• CVE-2020-14621
• CVE-2020-14556
• CVE-2020-2601
• CVE-2020-2590

UBI

CVE-2020-16122

OpenSSL

CVE-2020-1968

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.

Automation Hub: the future of automation

For more information about the new automation command center, see Automation Hub: the future of automation

Workload Automation Lutist Development Kit: do-it-yourself!

For more information about the new tool that enables you to create and publish your own integrations, see Workload Automation, Lutist Development Kit: do-it-yourself!

Continuous operation with automatic failover

For more information about the automatic switchover, see Continuous operation with automatic failover

Organize scheduling objects in workflow folders

For more information about folders, see Organize scheduling objects in workflow folders

Enhance security with encrypted passwords

For more information about password encrypting, see Enhance security with encrypted passwords

Enable support for long object names in the security file

For more information about scheduling object names, see Enable support for long object names in the security file

Deploying HCLWorkload Automation components on Red Hat OpenShift v. 4.x

For further details about the deployment on OpenShift refer to Deploying HCL Workload Automation components on Red Hat OpenShift

Changed features and feature capabilities

A new home for Workload Automation plug-ins

Automation Hub is a new concept for automating business workflows.

In previous versions, all job plug-ins were provided with the product and obtaining new plug-ins meant you were bound to the product releases.

With Fix Pack 2, you can still access the usual plug-ins from the product, but going forward, any updates, and the related documentation, can be found on Automation Hub. Furthermore, the continuous delivery of new plug-ins - now called integrations - enables you to download and use new integrations in the product, at any time.

A new way to automate your business workflows and a more flexible solution to having only the integrations of your interest integrated in the product.

But that is not all, if you do not find the integration that you are looking for, you can make a request for it or, you can create it yourself. To create a new integration, you can use the Workload Automation, Lutist Development Kit, and then share your integration with the community.

Let's automate more and automate better.

Identifying workstations, resources, and prompts

Fix pack 2 adds the support for defining scheduling objects in folders. As a consequence, workstations, resources, and prompts are no longer identified in the plan solely by their names, but also by the folder in which they are defined. The name and folder association is mapped to a unique identifier. In the localopts file, the this_cpu option is the unique identifier of the workstation. You can verify the unique identifier for workstations, resources, and prompts by submitting the composer list command, together with the ;showid filter, or by submitting the conman commands: showcpus, showresources, and showprompts, together with the ;showid filter.

Identifying workstations and resources by their unique identifier avoids the problem that occurred in previous versions when objects were renamed in the plan. For example, if an object was renamed and then carried forward to a new production plan, references to the old object name were lost. With the implementation of the unique identifier, this will no longer occur and dependencies will be correctly resolved. However, if a workstation or resource is renamed, its new name is visible to all V9.5FP2 instances (or later), but earlier instances continue to see the old name of the object.

For examples, see the conman showcpus command and the composer list command in the User's Guide and Reference.

Modification of the use of wildcards in workstation classes

With the introduction of folders in which to define workstation classes, a change has taken place with respect to the use of wildcards in specifying members of a workstation class. While in the previous releases, wildcards included all workstations, starting from version 9.5, Fix Pack 2, wildcards include all the workstations defined in the same folder (including sub-folders, if any) as the workstation class definition.

For more information about the use of wildcards in workstation classes, see the topic about workstation class definition in User's Guide and Reference.

Extended agent installed with a master domain manager

With a fresh installation of a master domain manager on Linux and UNIX, a new extended agent is installed on the master domain manager workstation which is used to communicate where to run the FINAL job stream. With an extended agent, the $MASTER keyword can be used to indicate that the agent's host workstation is the master domain manager. If the role of the master domain manager is switched to another workstation, then the $MASTER keyword automatically detects the new master domain manager. This change is to facilitate the automatic failover feature. See automatic failover in the Administration Guide.

Scheduling objects defined using REST APIs

Starting from product version 9.5, Fix Pack 2, the composer command line to create object definitions uses REST APIs. This means that when you create a definition using composer, new APIs are used, which are not compatible with the APIs installed on master domain managers with previous product versions. As a result, you cannot use a composer at version 9.5, Fix Pack 2 level, to create a definitions on a master domain manager where a previous version of the product is installed. This change applies to the following object definitions:

• calendar
• domain
• prompt
• resource
• variable table
• variable and parameter
• Windows user
• workstation
• workstation class

The default value for the mm resolve master local options has changed

With this fix pack, the default value for the mm resolve master local option in the localopts file has changed from no to yes.

Create a JSDL job definition

To create a JSDL job definition in HCL Workload Automation using the Job Brokering Definition Console refer to the previous documentation releases.

Remove deleted folders, prompts, workstations, and resources from the database

When deleting a workstation, if the workstation is still in the plan, then another workstation cannot be renamed with the name of the deleted workstation for the number of days specified by the global option folderDays. However, a brand new workstation can be created with the name of the deleted workstation. This behavior applies only to dynamic agents, pools, and dynamic pools. The default value is 10 days.

When deleting a folder, a prompt, or resource, if there are still objects in the plan that reference these objects, then another folder, prompt, or resource cannot be renamed with the name of the deleted folder, prompt or resource for the number of days specified by folderDays. However, a brand new folder, prompt, or resource can be created with the name of the deleted object. .

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.5 Fix Pack 2 delivers the following RFEs:

RFE 138951: Support for an existing Oracle user

When creating and populating the Oracle database schema during a fresh installation of the server or Dynamic Workload Console component, by default a check is performed to detect if the Workload Automation Oracle user already exists. If the Oracle user is found, but it does not contain the Workload Automation schema, the database schema is not created for this user. If no user is found, the installation creates the Oracle user and the Workload Automation schema. This behavior can be configured using the -skipdbcheck parameter in the installation scripts. By default this parameter is set to false. If this parameter is set to true, the installation creates the Workload Automation schema even if the existing Oracle user does not contain the Workload Automation schema.

RFE 132029: Add run number check within MakePlan before locking the database

The MakePlan process was modified to perform a check on the previous day run number and comparing it with the new run number ensuring it has increased by 1. If the new run number is not reflected in the database, MakePlan should abend. This check must be done prior to the locking of the database by Planner.

RFE 136191: JS EVERY DONOTSTART is not using untilDays. Allow configuration of the value for the global option untilDays for job streams

The untilDays option removes obsolete job and job stream instances from the plan. In previous versions, a hardcoded value of 2 days was set for job streams that did not have an until time set, resulting in cancellation of the job stream after two days. In the case of a job stream with the EVERY ONOVERLAP DONOTSTART keywords, if one or more jobs defined in the job stream abend, and are not resolved within the 2-day period specified by UntilDays, then the abended jobs are not carried forward and the job stream is canceled. This global option can now be configured for the number of days most appropriate for your scheduling environment. If you require maintaining a job stream longer than the number of days specified by untilDays, you can explicitly set an until time for that specific job stream.

For jobs, either you set an until time at the job level, or it assumes the until time of its job stream. If no until time is set for either job or job stream, then the until time is calculated by adding the setting for untilDays to the time the job enters the production plan.

With the release of this fix pack, the global option untilDays is now configurable. The default value is 0. If the default value is used, then for jobs, no default time is set for the until time (latest start time). For job streams, if the default is used, then the default until time is 2 days. See the Administration Guide for more information about the untilDays global option

RFE 120948: Intercept SAP jobs by SAP users, and limit executions on TWS by "n" jobs per user

Control and limit the number of jobs submitted by each user. When the established number of jobs for the specific user is exceeded, the jobs are queued and submitted at a later time. To implement this feature, two new options have been added in the options file:

MAX_JOBS_TO_RELEASE_FOR_USER

Defines the maximum number of jobs released for each user each time the release job is submitted. If this option is less than or equal to 0, the option is ignored and all jobs are released when the release job is submitted.

RELEASE_ALL_INTERCEPTED_JOBS_FOR_REQUEST

Releases jobs for each user on a cyclic basis, based on the number of jobs specified in the max_jobs_to_release_for_user option. The default value is ON, which means that all jobs are submitted for each user:

• If the max_jobs_to_release_for_user option is less than or equal to 0, all jobs are released for each user.
• If the max_jobs_to_release_for_user option is higher than 0, the specified number of jobs is submitted for each user on a cyclic basis. For example, if max_jobs_to_release_for_user=5, the first 5 jobs are submitted for each user, then the following 5 jobs for each user, and so on, until all jobs for all users are submitted.

If this option is set to OFF, it releases for each user only the number of jobs specified in the max_jobs_to_release_for_user option. The remaining jobs are submitted only when a new release job is submitted:

• If the max_jobs_to_release_for_user option is less than or equal to 0, all jobs are released for each user.
• If the max_jobs_to_release_for_user option is higher than 0, only the specified number of jobs is submitted, then no other job is submitted until the new release job. If max_jobs_to_release_for_user=5, the first 5 jobs are submitted for each user, then no other job is submitted until the new release job.

For more information, see the section about defining configuration options in Scheduling Applications with HCL Workload Automation.

RFE 140942: Ability to remove/control rerun option for broker jobs

By default, when a broker job fails because of a missing resource, the product attempts to find an available resource every 600 seconds, rerunning the job each time. With this enhancement, after the first failed attempt to find an available resource, the job FAILS. To enable this new behavior, add the hidden property, Broker.Workstation.Enable.RerunOnAllocFailure, to the BrokerWorkstation.properties file and set the property to "false". By default, the value of this property is "true".

RFE 137732: Wappman functionality does not support the replacing or modifying of an existing job stream

In HCL Workload Automation 9.3 Fix Pack 3, wappman import/export and replace is used for continuous deployment across environments. After the upgrade to V94FP5, wappman cannot be used to modify the existing job stream definitions and its related objects like resources and jobs. With HCL Workload Automation 9.5 Fix Pack 2, the import, export and replace with wappman has been reintroduced.

RFE 140989: Add an SSH client in the DOCKER image of the HCL Workload Automation Agent (z-centric)

An SSH client has been added to the HCL Workload Automation Agent DOCKER image which allows secure and encrypted remote connections.

RFE 128243: Job run numbers are not unique on a single agent in the plan when you have a very high number of rerun jobs

When you have a very high number of rerun jobs, accessing information about a specific job instance, specifying the CPUNAME and the job number, does not provide the expected result. With this fix pack, the job number is not considered an identifying factor when running conman commands. When submitting a conman command, you are prompted to confirm a selection of results that correspond to the filters specified with the exception of conman show commands (for example, conman showjob),where you are not prompted for confirmation but, instead, all results corresponding to the filters specified are displayed.

To submit a new RFE, write us here: HWAinfo@hcl.com

Updated version of WebSphere Application Server Liberty Base

HCL Workload Automation version 9.5 fix pack 2 was formally tested using WebSphere Application Server Liberty Base version 19.0.0.12, 20.0.0.2 and 20.0.03. Because of a known issue affecting version 20.0.0.1, APAR PH21281, we strongly recommend you avoid using it.

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 3.

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

This fix pack delivers support for scheduling objects in folders, including workstations. When monitoring workstations from a back-level agent workstation, the output displays the workstation unique identifier and not the workstation name for those workstations that were defined in folders different from the root folder. To identify the corresponding workstation name, run the conman command using the showid filter, showcpu ;showid, from an updated agent workstation.