Background to my $.02 - in my former life as the main TSM admin in the frozen north of Michigan, our management was frankly too tight to "waste" money on 3rd party tools that "only" allowed me to do my job more effectively. Consequently, my only option was to code it myself. By the time I left, we had totally automated the daily processing of all admin functions, complete with tape checkin/out, with offsite tape slot management and other niceties. Beyond that, we had an entire menu of custom ad-hoc reports we could run at will, and a problem detection system that scanned all our potential problem areas in TSM every 10 minutes, generating emails, pages, and/or helpdesk tickets depending on how we setup our config file. Not too shabby, especially since it was all developed using Rexx running on our z/os mainframe (althought I was the TSM Admin, another group "owned" AIX where TSM lived, and were reluctant to give me any access beyond the bare minimum).
When I moved down to sunny Tennessee, I swore I would not get locked into supporting that complex of a home-grown system ever again. I intended to use whatever was in place or the TSM Admin could convince mgmt to buy (I only deal with the Intel client side of TSM now). They bought a 3rd party tool from a vendor who shall remain nameless. When I was invited to meet with this vendor to discuss any additional reporting needs I had, I gave him printouts and source code from my most-used and I felt very needed ad-hoc report. This report presented daily session data in html and included logic to filter and/or sort the data so it could be used in a wide variety of troubleshooting scenarios. As soon as I finished my description, his reply was "I'll build you a static html report, but nothing dynamic, because I'm not interested in becoming a web developer". He was not impressed with my comment that I thought he should become interested in anything his customers were interested in buying. Needless to say, I'm back to coding. Thankfully, because Rexx is so darned portable, the move from z/os to Windows has been fairly painless, so we should have what we need relatively soon. Now if I could only rake in some of the thousands of $$$ we paid for our reporting package... My biggest drawbacks to self-developed code are: 1. I'm never satisfied, so I constantly "enhance" it, which takes time 2. Changes to TSM, such as message formats, break my code and require time to fix I personally feel that most of the arguments about self-developed code being cursed by future generations can be eased by: 1. More documentation in the code than you think you really need 2. Putting as much of the "custom" stuff in config and setup files as possible, rather than being hard-coded 3. I love the "open-source" suggestion Steve Schaub Systems Engineer, WNI BlueCross BlueShield of Tennessee 423-752-6574 (desk) 423-785-7347 (cell) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Allen S. Rout Sent: Monday, April 03, 2006 1:10 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM server automation products >> On Sun, 2 Apr 2006 09:52:52 +0200, Jurjen Oskam <[EMAIL PROTECTED]> said: > On Sat, Apr 01, 2006 at 09:46:00PM -0500, Allen S. Rout wrote: >> Speaking as someone buried in my own PERL up to my nose: > [snip: quite a good argument] >> I don't think I could be as effective with a third-party product as I >> am with my own stuff. I do think that the person who gets my job >> after I get hit by a truck will curse me for years. > Thanks, those are good points. But it does beg the question: how bad > is your current situation? :) I'll allude to a bit of logical pedantry by suggesting a google of 'beg the question' :) In any case, the question is an excellent one. > I mean, is it such a spaghetti that nobody, except you as the > developer, can *really* get it? Isn't *that* something you could > change, so that your successor can as effective as you are? The philosophical / design / practical problem here is very complex. I'd guess the average TSM clue of those admins writing their own automation code is at least a standard deviation higher than that of the larger TSM-admin population. How much of that clue may be implicit in the code, and how much must be explicit, accessible to a newcomer? Designing your code for maintainability is one thing, and we mostly think we're trying to do that. Designing your code so that a domain novice (or domain much-less-clued) can debug it is a totally different question. It may simply be an impossible task. Unfortunately, that's the problem we're talking about. I mean, issues of arrogance and modesty aside, I've been working with TSM since 1998, and with PERL since before 1992. The person hired after I get hit by a truck is in all probability going to be less experienced in both of these areas, perhaps profoundly so. But it gets worse: our automation code reflects a somewhat smeary snapshot of our TSM operations philosophy, including aspects we might not have been able to state when we coded them. Much of my migration automation is still kicked off by manipulations of HIGHMIG and LOWMIG; I am gradually changing to use MIGRATE STGPOOL. When I wrote the existing code, MIGRATE STGPOOL didn't exist, there was no reason to discuss its' use. But it's the obvious tactic today, and my use of the archaic method would be confusing to an observer. So even an expert in TSM and PERL who comes in behind me might be short on critical context to understand why SERVER-A is migrating fine, but SERVER-B is having problems. So at every turn, you weigh improved effectiveness, maintainability, fidelity to your architecture, the forthcoming changes in your architecture... For your successor to be "as effective", or even close, they need most of that context. > (Implementing and migrating to a third party product costs time and > money, wouldn't that better be spent cleaning up the custom code?) Oh, I'm in complete agreement: I think that local code is a superior solution all around, once you've paid the overhead to get the novice sufficiently clued. The best would be something -like- a Servergraph or a TSMManager, but open-source (duck from the third-party vendor slings and arrows) so we would -all- (most) be familiar with the -same- codebase. > Third-party programs are indeed spread more widely, but this also > means they must be more complex because they must support > configurations which you don't even use. Homegrown code has only the > complexity you need. I have to disagree with you there. There's stuff I need, which I haven't written yet. There's stuff I have (which represents time spent), which is no longer relevant. Worst of all, there's stuff I'm too dense or nearsighted to have figured out I need. When I eventually learn I need it, it's going to be painful. And -that- is the function folks hope to get out of the third-party tool, for which they're willing to sustain complexity and render up many dollars. - Allen S. Rout Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm