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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Allen S. Rout
Sent: Monday, April 03, 2006 1:10 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM server automation products
>> On Sun, 2 Apr 2006 09:52:52 +0200, Jurjen Oskam
<jurjen AT STUPENDOUS DOT ORG> 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
|
