Over the years that I have worked with TWS distributed I have worked with many different customers and it never ceases to amaze me how each one can use TWS in a different way. Of course the vast majority of TWS usage involves the scheduled execution of a process (usually batch) and does not differ greatly from one customer to the next.

The differences come when you look at the non-standard scheduling requirements, where each customer has resolved a particular scheduling requirement, within the limitations of the specific TWS version, using quite different techniques and approaches. I suppose that these differences help to prove how flexible TWS can be in helping to address these non-standard requirements.

However, I cannot help but notice that most of the customers I work with do not really exploit the functionality TWS provides for fully automating workload processing. This is especially true for customers who have been using TWS for many years and many versions. Having thought about the reasons why that is, I believe it is because TWS is its own worst enemy. Why?

There are two main reasons that I have come to this conclusion

1. Product stability. As indicated by the reasonably large number of customers still using older, now unsupported versions of TWS. When asked the reasons why they are still using older versions the response is frequently “if it’s not broken, why fix it” or “it does what we need” through to technical reasons such as application incompatibility with newer operating systems forcing some customers to stay with older TWS versions (at least for the FTA).
2. Backwards compatibility. From a software perspective TWS compatibility with previous TWS versions is possibly higher than any other product I have worked with. Although officially unsupported by IBM, tests have shown that agents from TWS 8.1 (and older!) will work with the latest TWS 9.x versions, with at least the basic functionality to execute a job. For some customers that is all that is required.
   TWS functionality is also backwards compatible with almost all functionality provided by earlier versions, including that provided by the early “maestro” product, is still supported by the latest TWS versions.

I think the functional backwards compatibility is the main reason why customers that have used early TWS versions are not fully exploiting the functionality available in the newer versions to fully automate their workloads from start to finish.

Unlike customers new to TWS, starting with a blank page and therefore free to examine the TWS functionality most suitable to meet their requirements, customers of previous TWS versions tend to upgrade the TWS software version and pay little, if any, attention to the new TWS functionality that is now available. This can be due to time constraints for completion of the TWS upgrade leaving no time available to look at the new TWS functionality or can simply be down to the existing process still works so why change it?

Another consideration is that it is sometimes difficult to justify the cost involved in redesigning existing processes (that work) to exploit the new TWS functionality. A typical simple example of this is

• Criteria: JobF executes every Friday, but can only execute if JobM from the previous Monday completed successfully
• A common technique used to meet this criteria with earlier TWS versions was
  • Create a file following the successful execution of JobM on Monday
  • Place a file dependency for the same file on JobF that executes on Friday
  • If the file does not exist when JobF is scheduled on Friday, JobF would not execute
  • If the file exists JobF would execute and when it completes successfully, delete the file ready for JobM to execute again next Monday

The above solution is limited by the functionality available in TWS 8.2. It is a somewhat “chewing gum and sticky tape” solution. When this workload is upgraded unchanged from TWS 8.2 to 8.3 etc. through to TWS 9.x, the same solution still continues to work. So why change it?

Alternatively a new customer to TWS 9.x attempting to address the same problem, would simply place a dependency on JobF stating that the previous execution of JobM must be successful before JobF can execute. TWS would then automatically track JobM on Monday and, if successful, automatically resolve the dependency on JobF on Friday.

So can the cost of changing the “chewing gum and sticky tape” solution to the built-in TWS dependency solution be justified? I think the answer is yes.

One issue with the “chewing gum and sticky tape” approach is that any failure to create the file on Monday or delete the file on Friday requires manual intervention to resolve the problem. There is a cost involved in this and if problems occur frequently could be significant. The built-in TWS dependency solution would require around 10-15 minutes to implement and result is more reliable execution of the two jobs.

When the business requires new workloads to be defined in TWS, it is common practice for the TWS administrators to copy an existing definition as the starting point for the new workloads (assuming the same or similar criteria). In the example given previously, this would result in propagating the “chewing gun and sticky tape” solution to the new workloads instead of using the much simpler and more reliable built-in job dependency functionality.

In upcoming blogs I will look at common workload processes that remain manual or semi-automatic despite the newer TWS versions being more than capable of fully automating the process from start to finish.

Visits: 44