This blog is co-authored by Francesca Ziantoni, Marina Fabbri and Maria Baldassarri. Do you have Tivoli Workload Scheduler V8.5.1 installed in your environment and are you satisfied with it?
If you are, then why should you switch to the latest version IBM Workload Scheduler V9.3 Fix Pack 1?
The answer is simple, read this blog to discover the 10 main reasons to upgrade your environment from TWS V8.5.1 to IBM Workload Scheduler V188.8.131.52 in a few steps.
Before analyzing the 10 main reasons to upgrade to V9.3 Fix Pack 1, we want to describe and analyze the upgrade procedure. There’s no doubt that a software update always generates some amount of worry.
We would almost like to have a time machine that would carry on with our existing environment without disruption while the update is applied.
So which best practice should I adopt when performing an upgrade in a complex environment? Where should I start? Am I performing the correct action?
Questions and doubts like these are quite common so, to help you, we’ve laid out the high-level steps to perform an upgrade from Tivoli Workload Scheduler V8.5.1 latest
Fix Pack to IBM Workload Scheduler V9.3 latest Fix Pack.
Usually, a complex environment consists of a machine where the master is installed and acts as a primary node and another machine where the backup master is installed and acts as a secondary node. In this way, the role of the master can be switched between the two nodes.
This configuration is particularly useful during an upgrade.
The following video shows the steps you must perform to upgrade such an environment.
Let’s take a closer look, analyzing each step mentioned in the video.
Step 1: Upgrade your backup master domain manager
First of all, before you start, ensure you download the prerequisite software. To upgrade to the latest version of IBM Workload Scheduler, you will use Installation Manager, a product that runs the installation of many IBM solutions and the WebSphere Application Server (WAS). Starting from IBM Workload Scheduler version 9.1, WAS is no longer embedded, but is instead installed separately using an installation image provided with IBM Workload Scheduler.
You can choose to install using either the wizard or the silent installation procedure. The wizard starts Installation Manager to guide you to fill in the required fields and run the upgrade procedure. If you already have Installation Manager installed, ensure it is at least version 1.8.2.
OK, we are now ready to start with the backup master upgrade. The backup master domain manager component is not required but recommended. You can start to upgrade it or you can choose to install a new one.
Before you run the installation, stop the scheduling on the backup master, and close all active sessions of the command line.
The following procedure describes how to upgrade using the Installation Manager wizard. This upgrade process brings you to V9.3 General Availability (GA) level plus the latest fix pack available, with just one single step. From the fix pack eImage, run the following command pointing to the GA eImage:
setupTWS -gapath <gapath>
The following Installation Manager panel opens:
Click “Install” and when prompted for the installation path, make sure you point to the Tivoli Workload Scheduler V8.5.1 directory.
The wizard procedure guides you during the upgrade process. Much of the information is automatically retrieved by the installation so you only have to fill in a few required fields. At the end of the installation, the backup master domain manager will be upgraded as well as the database schema for DB2 and Oracle databases. For the other supported RDBMS, you will need to perform a manual procedure to update the schema.
When the installation completes, if you configured specific security settings, these settings must be manually merged with the new settings before you build the final security file to be used in your new environment.
Now, you can restart the scheduling processes.
Step 2: Switch the master domain manager to the upgraded backup master
OK, let’s proceed with the master domain manager upgrade. To complete this step, you must switch the manager from the master to the backup master. The master will then be the inactive node and the scheduling actions will be performed by the backup master which has already been upgraded.
Before you switch your master domain manager to the backup master, you must stop the dynamic workload broker server on the current master domain manager. Performing the switch by command line, the backup master acts as a new master so you must switch the event processor too.
The procedure promotes the backup master domain manager to the role of master domain manager and you can start to use and explore the new features.
In particular, from version 8.5.1 to 9.x you can learn more about the dynamic agent and its dynamic capability.
So, if you’re using the new master with dynamic agents already installed, but you need to switch to the old master, make sure you set the dynamic agents to ignore. In this way, running JnextPlan on the old master, no messages will be sent in the pobox.
Step 3: Customize and submit the final job stream
Depending on when you plan to perform the master domain manager upgrade, you must consider if the switch must be made permanent.
After the switch, the next run of JnextPlan, re-establishes the previous role between the master and backup master.
So, if the master upgrade will not be completed in the plan cycle, you must manually configure the switch manager to permanently set the role just defined.
OK, we are ready to upgrade the old master that, at the moment, is playing the role of backup master.
Step 4: Upgrade the current backup master (old master domain manager)
To upgrade the current backup master (that is, the old master domain manager), the same considerations described above apply. Therefore, stop the scheduling process on the old master and start the wizard installation.
Would you prefer to use the silent installation? From the fix pack eImages, choose the response file appropriate for your environment, set all required information, and run the Installation Manager command to perform the silent upgrade.
After the master upgrade completes, merge the file containing the customization with the newer one and restart all processes.
Step 5: Switch back to your previous master and backup master
If you switched managers, you can switch back to your old master domain manager, which has now been upgraded.
The master and backup are now upgraded. You can continue to use your network with old agents and upgrade them later. This approach is designed to minimize your out-of-service time and ensure data integrity.
Remember, after upgrading the master and backup master, before you can use the Dynamic Workload Console, you must upgrade it!
And now? Start playing with the new version!
You are now ready to explore the features and advantages available with version 9.3 Fix Pack 1.
1) Monitor workload with direct query line
From the Web UI, it's possible to define a monitoring task through a query line using a syntax similar to conman and it's also possible to have the command automatically written while you define your task graphically.
2) Define more complex scheduling rules with fewer steps using Run Cycle groups
A new distinct database object has been added, to make the definition of scheduling rules more flexible, easier, and reusable, reducing human intervention to a minimum.
It contains enhanced ability to map all environment constraints and dependencies that can be used on different job streams, allows the use of a logical AND, and is fully compatible with traditional run cycles.
3) Plan data replicated in the DB (mirroring)
All plan data is stored in the database enhancing the impact on Web UI performances of monitoring tasks.
4) New Application Template for sharing and reuse of Patterns
You can create a workload application object, container for all the TWS scheduling assets (jobs, job streams, run cycles, variables, dependencies) to be used as “Patterns”, with all WA assets in a single entity.
Import and export facilities.
Easy changes to match the target environment standards.
5) Applying conditional branching logic
Add even more flexibility to your job flows by choosing which job to run depending on the result of the job status or output of a previous job. Whenever you have conditions that specify whether or not a segment of your job flow should run, then that is a conditional dependency.
6) What-if analysis
You can perform an impact analysis of maintenance and schedule-related actions (what-if) in GANTT view.
GANTT chart for visualization of jobs duration, What if scenarios to visualize impact of plan changes.
7) Automates the execution of Big Data workflows and processes
Using pluggable Job Executor capability of Dynamic agents, partners or clients can develop custom solutions to integrate heterogeneous products into one single IBM Workload Scheduler workflow.
Now IBM continuously delivers out-of-the-box new integrations with many products, such as:
- Hadoop File System
- Hadoop MapReduce
- JSR352 Java Batch
- MQTT queues
- Sterling Direct:Connect
- WebSphere MQ
- Oracle eBusiness
- SAP BusinessObjects reporting
- Restful service
8) Firewall friendly Dynamic agents
Dynamic agents can be connected to the IBM Workload Scheduler engine through firewalls using a new component called Gateway.
Any dynamic agent can be elected to be a Gateway in your network.
9) New scheduling features
- Enhancing your job stream definitions with the EVERY option
- Defining a job as non-operational (NOP)
- Convert Crontab schedules and Windows Task Scheduler into IBM Workload Scheduler workload
- File dependencies on dynamic agents
10) It is easy!
The described upgrade procedure is intricate but easy, and many features are available to satisfy your needs. Take courage, leave the past behind, and updated your environment!
If you still have doubts about upgrading your environment, try a free 30-day trial available from IBM Service Engage! You can explore and learn about new features by trying Workload Automation Software as a Service.