Plan Mirroring on Database

Since 9.1 IBM Workload Scheduler has introduced a new copy of the plan in the Relation Database, this is often called the "Plan Mirroring".

This copy of the plan is used only for plan monitoring from the UI (and from Java APIs) and is still not used for scheduling purposes that continue to work using the Symphony file to assure consistency between Master and agents.
This change has tremendously improved the scalability of the UI with performance test that has shown almost no performance degradation increasing the number of users monitoring the plan.

For end users or cloud customers this is completely transparent, but for IWS Administrators that are managing an on-premise environment this introduces new components in the product architecture that need to be understood, monitored and eventually managed and recovered.

Recover FINAL on Tivoli Worload Scheduler

As said on the Scheduling FINAL post, and as TWS administrator knows, the extension of the plan is one of most important process to monitor in the product. If it fails the plan is not extended and the new job stream instances are not available to run.
For this reason it's important that any TWS administrator is able to recover the FINAL quickly, without, possibly without the need to open a PMR and wait to have L2 or L3 support on-line to help with the recovery, at least in the most common situations.

Of course, if you are using IBM Workload Automation SaaS you don't have to worry about this, IBM is managing the environment and is monitoring and is ready to recover it in case of failure.

In this post I'll explain the role of each job in the FINAL and FINALPOSTREPORTS job streams and how each of them can be recovered in case of failure.

Prevent and solve queuing issues in Tivoli Workload Scheduler

In this article I've talked about Tivoli Workload Scheduler message queues and how they work as input queue for TWS processes.
In large and busy environment these message files can start growing creating delay issues.

I've just published with Paolo Salerno a new article on developerworks about monitoring message files, detect issues and a new feature introduced with 9.2 FP1 that allows TWS administrators to  prevent and solve delays issues monitoring how much of the mailman capacity is used and which workstation should be moved under a mailman server to have a more reliable environment.

The article is available here: http://bit.ly/wablog-mailman-queues

If you like this article and you find it useful, please share it on social media so other people may take advantage of it.