IBM Workload Automation Reviews

Real-time database updating: With other schedulers, you have to upload and download changes. Updating in real-time is less time consuming. You do not have to turn the job on; you can simply leave it off the schedule if it is not needed until a certain date, and you can give it a first-run date. In Control-M, there are a lot of extra steps (uploading or downloading to the database). You have to repeat those steps for turning the job off or on.

I like the layout of Tivoli, it almost functions like an Excel sheet. I like the "tree" to the side and also you can set up different views. If I only have to monitor certain applications, it makes that easier. I also like the filters and views within the scheduling console.

Setting an alternate plan is a good tool when you would like to go to a previous day to see how long a job took to process. I use that a lot.

I wish I had more training. I'm kind of on my own, we are one person per shift right now. I have the user guides that came with the product and wish I had more time to read through. Right now, I use them if I have issues. Because I "get it" when it comes to scheduling (I've been doing it since 1999), I didn't need too much training to pick it up.

Right-clicking options such as reruns and also dependencies come in handy. (I do wish it had the "why" option as I mention below.) But it isn't difficult to find why a job is not running.

Maybe a better way to see what a job is waiting on. (Control-M has a "why" function that would be good here). With Tivoli, you have to investigate for what the job is waiting for, i.e., files, prompts, predecessors.

I have been using it for 1.5 years.

I have not encountered any stability issues.

I have not encountered any stability issues.

I have not used technical support.

It is very good scheduling software.

• Valuable Features:
• Time zones: As we are a global company, scheduling jobs in different time zone is mandatory (especially due to DST changes).
• Web interface: Easy access for end users.- CLI: Even more automation is possible than by using the standard features.
• User/group-based roles for access segregation
• AD integration: To use the same user repository

This product has increased the level of automation with no / minimum downtime and predictable scheduling.

The web interface (TDWC) is a bit slow.

I personally got in touch with it in 2003 (as soon as I was employed).

There were some stability issues with older versions we used. There have not been any on the current one (8.6.02) since we started using it, for ~3+ years.

We encountered scalability issues. There are some parameters that need to be tuned once you reach a certain level, and it is not clearly stated / explained in the product documentation.

Technical support is 4/10.

Initial setup was a bit complex, as we did it without any consultant and the coding is not perfect or the same for different platforms (i.e. Windows, different Linux flavors, Solaris, AIX, etc.).

It is expensive, but reliable (in short, you GET what you pay for).

If cost is not an issue, I definitely recommend it.

The TWS GUI was an excellent feature. Job monitoring and scheduling using the front end was extremely easy.

Job scheduling is an integral part of deploying data warehousing jobs. I was a part of the developer team and while coordinating with the support team who did the actual job scheduling, it was easy for them to coordinate with us on what job to release first, what to cancel, what to release dependencies, etc.

If there was a way to monitor SLA breaches from within TWS, it would have been great. The only way to monitor job failures on TWS was to check the GUI for any failed streams. This said, there are ticketing systems associated with batch and real-time jobs that triggered an alert whenever something failed and that works well with TWS.

The one scenario that I encountered (and found a solution to by implementing a script from outside of TWS) was when a critical job does not start running even after the scheduled time, say due to an unexpected outage on one of the dependencies listed on TWS, there was no way to alert the owners of the application. And no ticketing system would alert anyone because technically, there is no failure. Or there was no way to trigger an alert from within TWS for a long running job, that is running way past it’s ETA.

I used the solution for two years.

None that I encountered during my two-year tenure at Chase.

Deployments and issues with the TWS server were handled by a different team. Other than periodic maintenance outages, there was no other major downtime that I encountered.

Individual access setup was relatively easy. But I think I would attribute this to the setup teams, to the on-boarding team at Chase. We had a specialized request procedure and an access team handled the request.

Things shifted after I joined. They evaluated Control-M and decided to pursue Control-M and discontinue use of TWS. Control-M had a far superior user interface and also had a notification system which TWS lacked.

There are multiple factors that would influence my preference to this product. In purely ease of use, functionality etc, I would rate it 8/10. I am not considering the cost of license etc.