Thursday, 26 May 2011 14:48
Welcome to the first of hopefully many blogs on subjects mainly related to automation and scheduling issues. Although I will probably write about IBM Tivoli Workload Scheduler (distributed) (TWS/d) primarily, I would also like to cover other automation and scheduling products from time to time.
I am not intending for these blogs to be of a particularly technical nature, because the TWS (Maestro) mailing list does a very good job of addressing such issues. Instead, I plan to cover some of the wider, non-technical management and administration type issues encountered when working with automation and scheduling solutions. Occasionally, I may throw in some completely off topic articles that I hope will still be of interest!
I have recently been involved in a series of wide ranging discussions with some of our TWS/d customers about how best they can manage moving TWS/d scheduling definitions from one TWS/d environment to another e.g. from their test to production environments. TWS/d has some built-in command line tools to help extract definitions from one TWS/d environment to a text file. The text file can then be transferred to the production TWS/d system, edited to make any necessary changes and then using the same utility, loaded into the TWS/d production system.
Very simple, very easy – so what’s the issue?
I can think of a number of issues
- Number of definitions to be transferred – works for a small number of definitions, but becomes increasingly difficult as the number of definitions increases
- Relationships between the scheduling definitions – it is too easy to “miss” some of the definitions to be transferred e.g. resources, event rules, etc. With the introduction of variable tables, “template” jobs and event rules this will only get more complex
- Number of changes to be made – if you use different naming conventions for TWS/d test and production environments, this increases the number of manual changes that are required to the definition prior to loading into the TWS/d production environment and consequently increased the risk of introducing errors into the definitions
I am sure that there are other issues as well – use the comments section below to let me know of any that you are aware of.
These types of issues have been addressed so far by various means including
- Scripting (with Perl being a very popular option)
- Complex source control solutions to “modify” the definitions as they are checked in and out of different source repositories
- Excel spreadsheets to generate different definitions for each TWS/d environment
- Keeping the TWS/d object definitions with the same names across each environment to avoid any changes when moving from one environment to another
- Using a single TWS/d environment for test, development and production
Each of these “solutions” has their own positive and negative points, but in my experience the majority of TWS/d customers perform the transfer manually from one TWD/d environment to the next.
I would like to know if this is your opinion as well and if so, what you would like to see in terms of a more automated solution that would help to address these issues. Any thoughts or comments please let me know below.