IBM Workload Automation Reviews

The features most valuable to us are the diverse array of scheduling options, including run and exclusion calendars (holidays). The dependency management system allows us to build just about any scheduled batch process imaginable. Tivoli consistently runs jobs as scheduled and precisely as defined. This is critical, as we need our scheduler to be dependable and consistent.

We can also export job and schedule definitions to a flat file and then import them into a higher environment. This is critical for treating jobs and schedules as code, checking the definitions into version control, and deploying them cleanly. We can manage jobs and schedules ourselves without needing to turn to a designer in production.

Tivoli Workflow Scheduler provides a centralized tool for all scheduled jobs, including design, monitoring, and support. With thousands of jobs running each day, this would be unmanageable using Windows scheduled tasks, cron jobs, or a home grown scheduler based on Quartz or similar framework.

One area of improvement is the user interface. While it is extremely functional, it’s not very user friendly and it’s difficult to visualize the flow of a complicated job schedule. A visual flow would be very useful to see how far a schedule has progressed, where it failed, and why.

We’ve been using Tivoli Workload Scheduler for 4.5 years.

We have had no issues with scalability. However, we have less than 100 batch servers across all environments, so our environment is not very large.

I can’t rate technical support. I have never worked with IBM technical support on an issue with TWS. However, our number of support requests has been low due to the reliability of the product.

I have not used a previous solution. TWS was already in use when I started working here.

The initial setup is somewhat complex when taking into account the following factors:

• the supported\recommended database types are Oracle or DB2 for Windows shops
• deployment of agents across all batch processing servers
• security configuration
• load balancing and redundancy on the MASTER

Upgrades are also complex as all existing jobs, schedules, and other entities must be ported over and tested.

I have not dealt with pricing or licensing.

I did not evaluate other products as TWS was already in use when I started working here.

Before purchasing Tivoli Workflow Scheduler, check out Automic One Scheduler. It’s much more expensive, but it does a lot more than just scheduling. If you are using TWS, make sure you provide training to your batch developers. Design a model for promoting jobs and schedules between environments. Utilize “composer” extracts and check your jobs and schedule definitions into a version control repository.

Automation capabilities with dependencies, long-term plan and modifying current plan, and ease of use are the product's most valuable features to me.

When there is a holiday or emergency closing, we query the Long-Term Plan to identify what will or will not be running during the closure. Application owners review and sign off of the plan, making everyone aware of the scheduled jobs for that time frame.

We are using an outdated version. We had issues with the file dependencies. We are uncertain if it was due to application setup or the product itself.

I have used this solution for 6.5 years.

This has been a dependable product for us.

We did not encounter any scalability issues.

We have not utilized technical support in six years.

As with any new application/utility, make sure you have good training; if possible, request a trial version to become familiar with product; and ensure it meets your needs.

• Event-based scheduling
• Support for other applications via connector, such as Oracle, SAP and data warehousing software

If you want to run any Oracle, SAP or data warehousing job, you don't need to install a TWS client on the target server. You just have to install a connector on one of your TWS systems and provide the required parameters such as system credentials in an encrypted format.

It supports almost all of the different groups in the organisation for automating their tasks, such as finance and accounting, transport department, procurement department and several others as well.

Whenever we find any bug/vulnerability, we immediately inform IBM and they provide us a fix, so I can say it is being continuously improved.

A few things are missing but I can manage without them, such as a cross-reference report. For example, if you want to find particular job script, it is very difficult to do so from the TWS command line or from the TDWC (Tivoli Dynamic Workload Scheduler) tool. On the other hand, there is a Germany-based company Horizont, which has a very nice tool, TWS/WebAdmin, which provides such a facility.

The second thing is that there is no built-in facility to run SFTP/FTP file transfer jobs. You have to create your own SFTP/FTP scripts to run these types of jobs.

An internal change management tool is also not available in IBM TWS, but other scheduling software do offer one.

These are a few flaws in TWS, but operation-wise and handling-wise, it is a superb tool as compared to other batch job scheduling tools.

One thing is true: You will not get all of the facilities in one tool, so I recommend you go with TWS for smooth automation delivery.

I have used this solution for the last seven years.

We never encountered any stability issues. If your TWS administrator is very good with TWS, then he/she should always keep your TWS landscape stable.

We never encountered any issues with scalability.

We used BMC Control-M first, but later we changed to TWS due to its efficiency, accuracy and scalability.

If you have strong knowledge in TWS, then initial setup is just like bread and butter for you.

I heard it is very expensive compared to other job scheduling tools.

Go ahead and use the TWS solution. It is really a very good product.

The introduction of the TDWC (Tivoli Dynamic Workload Console) was nice to have, preventing additional code installs for the JSC.

It gives end users the ability to monitor their jobs/workflows in real time, which helps with MTR when they experience issues.

When deleting jobs from the database that have interdependencies within other job streams, there is no warning about those dependencies, which could cause other job streams to have issues later on.

We starting using it back when it was named Maestro 5.X.

I did not encounter any stability issues. It’s been a very stable and reliable product.

We have not had any scalability issues.

I rate technical support 9.5/10. I have not opened any cases over the past 1.5 years. They have always been very supportive and helpful in the past.

Initial setup was fairly straightforward. However, configuring and setting up the TDWC was somewhat of a challenge; we had to consult with Level 3 support several times to get things working properly.

Consult with a third-party vendor to assist with price discounts.

I did not evaluate other products before choosing this one. However, they are asking us to look at other solutions, due to cost for licensing the TWS product.

I would have to recommend installing the TWS Master/Backup Masters on a Linux platform, not Windows.

TWS has two command line interfaces to help manage items in the active plan and database. This allows you to create custom scripts to make mass updates to job definitions in the plan\database. You can even schedule these custom scripts to make the updates at a later time (e.g., holding a set of jobs prior to a planned outage and releasing after). It also has an event processor that lets you define custom rules based on certain events (e.g., when a job fails, when a job hasn’t finished within a certain time or within 30 minutes of its predecessor, when a file is available, when a job is stuck, etc.).

Aside from basic scheduling features and Windows/Unix job types, this product gives us a lot of options to integrate with other systems:

• Custom plug-ins (SAP, DataStage, PeopleSoft, Cognos)
• Database & integration job types (Oracle, MS SQL, Web Services, J2EE)
• File transfer and remote command job types

It is a great way to centralize your enterprise workload to provide better visibility to support groups and better cohesion between applications. Mobile app features are also available to empower users to monitor\manage their workload on the go.

The web UI is a bit cumbersome in terms of navigation, although it seems some improvements were made on the most recent release, v9.3. Also, scheduling is driven based off of a Symphony file, which is a flat file that outlines scheduled work for the day and its progress. This file is prone to corruption during networking/hardware issues. TWS also has a daily refresh process that refreshes the Symphony file each day. Any permanent changes to the TWS network are dependent on this process.

Time zone management can also use some improvements. We have to schedule creatively to account for the hard-coded plan start/end times with other time zones. Ideally, it would be a seamless effort.

I have used it for four years.

None; overall the product is very stable, but can give you odd results if the environment is unstable (hardware\network issues). Once the environment issues are resolved and job scheduling has resumed, you might still experience strange behavior with dependency resolution and cyclic job functionality, which typically clears up with the next daily refresh.

None; we’ve had no issues with scalability other than time zone management, which requires some creative scheduling scenarios to account for the hard-coded plan start/end time and time differences between master server and remote agents.

7/10; technical support is virtually impossible to get via direct phone call. You have to rely on trouble tickets and wait for a return phone call, which can take several hours depending on what time of day you are calling. You will need to keep constant follow-up on your ticket, as well, because it can slip through the cracks and go unnoticed for days. However, once engaged, especially on a conference call, the team is knowledgeable, courteous and very helpful.

Initial setup was somewhat complex, although it might be because we installed on Linux. Windows might have been a bit easier using the installation wizards.

It can get costly, as expected; IBM uses a Processor Value Unit (PVU) licensing model, which can be cumbersome to maintain.

I’ve used BMC Control-M in the past, at another company.

This product is a great product overall, but can behave strangely if any environmental issues occur (hardware/network). A lot of the issues we face, however, are supposed to be resolved with the later version. I’ve seen some demos of the latest release and it seems like large improvements have been made in terms of functionality and user experience.

• Support for multiplatform workload automation in a single solution
• Versatility of plan-based and event-triggered scheduling in a single solution

Our firm supports batch processing across many platforms from mainframe to iSeries and open systems. TWS enables consolidation of disparate workloads in a single database, removing the need for engineered interfaces between platforms and enabling simpler job to job dependencies and end to end management and monitoring of workloads.

Service-level management is a challenge using native TWS facilities. TWS lacks sophisticated predictive analytics capability. The limited analytics it does offer is predicated on user-defined variables such as job run duration estimates, which if miscalculated render outputs unreliable.

Another area of improvement is in job schedule design lifecycle management. TWS lacks robust automation for promoting job schedules up through testing cycles on to production deployment, requiring substantial manual operator intervention to prep schedules for deployment from one environment to another.

I have been using it for over two decades.

Stability of TWS is relatively good. Notably, most issues I’ve experienced personally have stemmed from distributed schedules, i.e., z-centric.

Scalability also is relatively good. Our firm also supports TWS/d schedules, which by comparison are significantly less scalable.

IBM’s technical support is good. We have a good relationship with their L3 Lab in Rome, and there’s frequent engagement through user group events throughout the United States, for example, ASAP. Unfortunately, ASAP does not operate outside the US.

We’ve supported numerous solutions at our firm, such as CA7, Control-M, Zeke. We chose to standardize on TWS for a number of reasons, including the fact that TWS hosted the majority of our workloads relative to other solutions, we possessed ample resources who specialized in TWS over others, and TWS best met the needs of our business.

Setup can be quite complex, especially when on-boarding workload that’s migrating from another solution. In those cases, extensive testing is required to ensure that all logical dependencies are properly defined, particularly where the legacy solution’s constructs do not have a like-for-like construct in TWS. JCLs and scripts also very likely require modification to meet TWS syntax requirements.

Compared with the other primary workload automation solution we use at our firm, CA’s Autosys, which is a purely event-triggered scheduler, the limitation with a purely event triggered scheduler is you must have round-the-clock expert analysts to support 24x7 operations For example, if a new deployment must be installed on a weekend at an odd hour, someone must be available at that specific time to support the activity, load JIL files to the database, etc. There are ways around this limitation, but it requires additional engineering or add-on products, which can be costly. Autosys does feature some advantages over TWS in other areas, which is why it remains a staple solution at our firm.

However, to continue the point, with a plan-based scheduler such as TWS, the scheduler is composed of two unique elements, a Long Term Plan (LTP) and a Current Plan (CP). The LTP is essentially a long-range forecast of future schedules, and the CP contains the present day’s schedule. That configuration enables schedule changes to be staged well in advance and stored in the LTP where they take effect in the CP for the specified implementation date, while the CPs leading up to the change remain unaffected. In a large organization like the one I work at, where we employ a full-scale global command center to support BAU operations, TWS allows us to scale back on expert scheduling resources and have them work a traditional 9-to-5 work day because virtually all deployments can be supported during normal business hours. And our command center employees, who are generally paid less than expert schedulers, look after day-to-day, 24x7 operations.

All workload automation solutions deliver on the basic idea of automating your batch processing. The right choice depends on your unique business requirements, such as the size of operations, mix and complexity of workloads, etc.

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.