Satisfying Requests for Enhancements (RFEs)
IBM Workload Scheduler satisfies 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.
IBM Workload Scheduler V9.5 Fix Pack 2 delivers the following RFEs:
- 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 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 Defining the configuration options.
- 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.
- 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 133169: Additional query filter criteria has been added for multiple homogeneous engine selection
- When monitoring your workload from the Dynamic Workload Console with a multiple engine selection, only filters in common between distributed and z/OS engines were shown. This behavior is still valid for the selection of non-homogeneous engines. For multiple homogeneous engines, the same filter options for a single engine are now available.
- RFE 134569: DWC 9.5 not rendering properly (height) in resolutions over 1100px
- The Dynamic Workload Console now supports every kind of resolution.
- 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 Global options - detailed description for more details about the untilDays global option. - RFE 137732: Wappman functionality does not support the replacing or modifying of an existing job stream
- In IBM® Workload Scheduler 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 IBM Workload Scheduler 9.5 Fix Pack 2, the import, export and replace with wappman has been reintroduced.
- RFE 137969 - Dynamic Workload Console Explore: ITEMS visible in List View
-
Workload Designer explore is now available with list view along with data view. By default, data view will be listed in Dynamic Workload Console when explore option is clicked. List view can be traversed from explore view and gives the details Name, type, workstation and object locked by.
It is easy to switch between the views from explore and once the view is switched, it retains the last view for easy reference in Dynamic Workload Console.
- 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.
For more information about the -skipdbcheck parameter, see , Database configuration - configureDb script.
- RFE 139443: The Dynamic Workload Console does not accept special characters (#, $ etc. ) in the Application Description name but these characters are allowed in IBM Z Workload Scheduler
- Special characters are valid for the z/OS job stream name, which corresponds to the application ID.
- 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 140989: Add an SSH client in the DOCKER image of the IBM Z Workload Scheduler Agent (z-centric)
- An SSH client has been added to the IBM Z Workload Scheduler Agent DOCKER image which allows secure and encrypted remote connections.
- RFE 139843: Possibility to specify the maximum number of objects shown in each graphical view
- By changing a property in the setting file it is now possible to edit the maximum number of objects shown in a graphical view. see this section for more information: https://www.ibm.com/support/knowledgecenter/SSGSPN_9.5.0/com.ibm.tivoli.itws.doc_9.5/distr/src_tsweb/General_Help/awsadgraphviews.htm
To view a complete list of RFEs, new, planned, and delivered, see: RFE online community.