I think stability and running the batch apps while keeping track of them, since otherwise, it is impossible to keep track of them easily, are the valuable features of the solution.

The key valuable feature is that jobs can be triggered in multiple nodes. We're also able to pre-schedule jobs which is great.

This solution has a request feature where users can request the added features they need to have developed. Based on client voting for those features, these are developed and released.

The interface for the applications team is really the most valuable part of the product in my opinion.  

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

The DWC, when configured correctly, is a great GUI tool to provide Self-Service Scheduling capabilities to the user community. The variety of agents available allows for an extremely flexible Enterprise WLA solution. The WAPL (formerly SOE) functionality is one of the major things that sets IWA apart from the other platforms. With its use, you can automate tasks that other platforms can only dream about.

The event notification feature is beneficial since it allows for prompt and immediate notification in relation to any errors occurring in the system.

• Seamless integration with different applications like Oracle, SAP, Hadoop, JMS etc.
• Web console with single sign on feature.
• TWS as a tool has features that integrate with different applications and backend technologies, as mentioned, to run the jobs more native to the platform. Say, for example, if I would like to trigger a SAP job from TWS scheduler, I can specify most of the parameters from the TWS forms. As an enterprise scheduler, I have more control over most of the enterprise applications to which it is connected to.

Workload automation (WLA) these days is no static business. It’s all about running the right workload sequence, at the right time, often triggered by a variety of possible (combination of) events. For instance, we use this principle for running a daily Oracle backup workload batch, which (per backup) involves different systems that in real time have to exchange certain real-time information to be able to successfully end and register the backup in RMAN. Therefore, we use complex event rules that monitor events during the backup process, take care of passing the desired info from one system to the other, and dynamically submit certain jobs that cannot not be defined in advance.

ERP (SAP) connectivity: Thanks to this technology, we were able to fully integrate SAP OS, ABAP and BI (proceschain) workloads with non-SAP workloads, so that a complete business process involving SAP and non-SAP systems could be modelled within one TWS batch. Example: a non-SAP MFT job delivering data @ SAP-PI; in-time PI channel trigger modifies the data for next job; SAP ABAP job works the data into the system involved.

Conditional Branching: WLA often is about critical paths that determine if a batch will be able to end just in time. For instance, C.B. makes it possible to dynamically decide if parts of a predefined batch can or should run in sequence or parallel, depending on the outcome of a certain measured condition, therefore able to meet end-time requirements, even when parts of the batch encounter delay.

HA-DR implementation: No system engineers are required to realize value from these resources @ the application level. TWS makes it possible to use resources, provided at the Application Management level, to meet business requirements for high availability and disaster recovery (HA-DR). We use these resources a lot, not only in case of disaster (e.g., scheduling plan breakdown on master manager; switch to backup-master manager management), but also when TWS management systems in one DC need technical maintenance. In that scenario, we simply switch all our TWS management activities to backup counterparts in another DC, that silently have received up-to-date data from message broadcasts within the TWS network.

The most valuable feature is the job scheduler.

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

The most important feature is the creation of folders. It's a really great feature because you can organize the process with naming conventions. 

• Alerting on ABENDS: When a job abnormally ends (ABENDS), the solution notifies us when the job did not complete successfully. This is a nice feature for job streams that require successful completion of one job before it moves on to another. It’s still “reactionary” in nature, but allows us to run a job stream again. This occurs, in some cases, before the end users of our data services know there’s a problem.
• When changing a cycling ID, we only have to change it once.

• Moving jobs from Dev to Prod only takes a text file script, which is straightforward.

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

The whole product is valuable because it is a tool for batch automation.

Dynamic scheduling: This is one feature which helped us achieve some important business objectives without the need to install TWS on a server. Some of the servers in our organization have restricted access and dynamic scheduling helped us schedule jobs on these servers without the need to install TWS.

The simplicity of the GUI is the most valuable feature for us.

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.

With FTA (Fault Tolerant Agent) on remote servers, you have Agents to run jobs. An FTA does not need a network connection to do the job, except when the master sends the daily production plan to the FTA. This feature is very nice because POF is only one time a day. So FTA removing POF from the final schedule is very valuable.

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

The FTA agents feature is most beneficial, as it easily resolves local dependencies on the workstation, even when there is a network disconnect between the MDM and FTA.

• 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

The API is a valuable feature as it allowed us to integrate the inventory, change and ticketing systems to fully automate most of the monitoring processes for new devices, decommissioned devices and during approved changes.

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

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

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.