Sometimes we have issues with the solution's stability. So, stability can be improved.

Reporting and visibility of the solution need improvement. These days, we need more visibility. We need to access the logs and databases easily. You need to keep track of the running number of logs, like which ones are executed, completed, etc. So if there would be a good reporting dashboard, then it would be good.

There's room for improvement in the solution since it is a challenging thing when we want to use the solution's technology with our new technologies. For example, if we need to use TWS on our OpenShift platform, the solution's API is not capable enough. So the product itself needs to be aligned with new technologies.

Each day the schedule refreshes and that's a challenge for us. In comparison, the ESP scheduling tool refreshes immediately and automatically reconnects. The simulation in Workload Automation is very complicated and difficult.

This solution does have bugs and could be improved in this regard. However, these bugs are resolved relatively quickly. 

The interface for the operator is not so good. I do not think it is as complete as something like Control-M by BMC Software (named for former Shell executives Scott Boulette, John J. Moores, and Dan Cloer). A few other things could be better like the scheduler and linking between jobs and dependencies.  

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.

The performance of the previous versions could be better. We encountered certain issues with the lower version of it, the 9.2. Things have greatly stabilized since then. However, as with any IBM tool, things are a bit tricky. I would give a rating of four or five out of ten, as we encountered certain issues with the domain controller with the lower versions. 

It would be nice if we could get support for earlier versions. Generally speaking, IBM insists that we move on to their latest one. 

In respect of the dependency diagrams, the job dependencies across the business process should be improved. 

This may not be the norm, but slow down on the releases a bit. I fully understand that IWA functionality is increasing at an amazing rate, but trying to keep up with the upgrades is rough. Figure out a way to speed up the DWC response a little.

The integration and monitoring within the extended agents such as SAP, PeopleSoft mainframe etc needs to be improved.

Extended agents such as SAP, PeopleSoft, CA-7, etc do not have the ability to trace child jobs or dependencies within the extended tools. The ability to do so would be a great added-feature in the next iteration of the application.

TWS is evolving from V 8.3 to V9.3 on the features and no major changes on the architecture. The user experience side of the console is being improved in all these versions, however, the console is not very fast as expected.

It would be good if the TWS consoles and front end reporting explores different users like business, technology and application teams and seamless and faster experience like mobile apps.

If these supported applications would be provided without additional licenses, it would be good.

Today, TWS (TWA) has evolved into version 9.x and the product is now also available as a cloud-provided service (the management parts, from IBM SmartCloud).

I think that is a good and modern development, but the first v9.x releases (and maybe also the latest, I don’t know) lacked the event-driver WLA functionality that was already available for years in older on-prem versions of the product.

That doesn’t help IBM have customers migrate from older on-prem versions to these modern cloud-provided versions, when they would like to migrate.

IBM should have its cloud service deliver at least the same functionalities as their on-premise service has been delivering for years.

I would like to be able to access the return value or result from one job, in the following job. This is a feature that other solutions have and is very helpful. I had to create my own workaround for it because the capability is important for me.

It would be helpful to have a mobile app that could be used to follow the job schedule. Most IT applications now have mobile app support.

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.

Other solutions like Control-M are better than this solution. IBM should have better integration with the cloud. 

It should support other schedulers that aren't IBM products. 

• It is complex to use
• Lacks scalability
• It is difficult to set up jobs to run
• We need to be able to elevate privileges like Task Scheduler

With Windows Server 2012, there is a setting for User Access Control. UAC is a security feature that prompts the user, and even administrators, when running a job that requires a higher elevation because of its interaction with the Operating System.

When you’re trying to automate tasks and run them in the background, this prompt still comes up and asks if it’s OK to raise the privilege level. That hangs the job.

When running the solution, there’s no way to get around that prompt. Any job that requires that elevated privilege sits and waits for the user to answer it.

With Windows Task Scheduler, there is a check box in the Scheduled Task that says “Run with Highest Privilege”. If that’s checked, then it automatically bypasses the UAC prompt, and completes successfully.

The only other way to get around that is to lower the UAC restriction on the server, making it more vulnerable to malicious code.

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.

There should be more custom documentation, specifically around Java APIs. There should also be more training.

In terms of features, we are currently using only 50% of its features. We don't use all features that are available, but there is always room for improvement in all of the tools. 

• Monitoring
• Reporting

TWS doesn’t have in-built monitors to capture and report READY/INTRO state jobs. In our environment, we use TWS to schedule jobs in SAP and without an in-built monitor to capture these, we use custom-built scripts to report jobs stuck in READY/INTRO state.

Out of the box reporting and provision for customization/integration with other products are the areas where this product can be improved.

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.

Have a more simple GUI for end-users. This is simply because I am used to using the command line. The GUI is not easy for non-technical users.

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.

There is need to add any type of utility which can convert workload definitions of other syntax to the TWS syntax, during workload migration and conversions. Currently, there is no utility as such with TWS.

For example, there could be one scenario, where the customer wants to switch from the existing scheduling tool to TWS. Every tool has its very own syntax for defining workload definitions.

During migration project activities, it gets very difficult for converting the existing workload syntax to TWS syntax. We need to create our own scripts or different methods, that helps us in achieving this task.

If I remember correctly, the BMC Control-M tool does have such utility of converting any workload definition syntax to Control-M based workload definition syntax, i.e., upto a certain extent. Hence, this is one area where TWS can be improved.

The web interface (TDWC) is a bit slow.

A lot of the automation that we added to the product should come built into it, so that every customer doesn't have to reinvent the wheel. This will eliminate the need for us to modify our code, in order to make it compatible with each future release.

Below are examples of automation that we developed which should be built into the product:

• Integration with the inventory system, so that alerts go to the proper teams. For example, alerts for servers classified as development would go to the apps support team or alerts for servers classified as production would go to the monitoring center. Also, alerts would stop when a server is marked as decommissioned.

• Integration with the change management system so that alerts would be suppressed during the change window for approved changes. Thus, alerts would begin for approved changes adding new servers.

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 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.

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.