Changed features and feature capabilities

A list of features changed since the previous release

The following features have changed or have been introduced since the previous release:
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 showcpus and list
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 Workstation class definition.

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 Continuous operation with automatic failover.
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 IBM Workload Scheduler using the Job Brokering Definition Console, see the documentation in the previous release at IBM Workload Automation 9.4.0 and browse to the Scheduling Workload Dynamically manual.
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. For more information about the folderDays option see Global options - detailed description.