ADSM-L

Re: Aggravating recordkeeping failure in TSM.

2001-11-18 20:48:25
Subject: Re: Aggravating recordkeeping failure in TSM.
From: asr AT UFL DOT EDU
Date: Sun, 18 Nov 2001 20:45:07 -0500
We seem to be making skew points here.  Let me try to explain.

=> On Sun, 18 Nov 2001 14:17:30 +0200, Zlatko Krastev/ACIT <acit AT ATTGLOBAL 
DOT NET> said:

> - Yes, I also missed your point: so you want this relation described,
> right? But let look to a script or macro like the following:
> backup stg primary1 copyA
> backup stg primary2 copyA
> backup stg primary2 copyB
> ..
> I can easily produce your relation table from this on the fly using awk.
> You might prefer Perl but it does not change the things.  The data is not
> processed - it just is in another format and format transform can be done in
> both directions without data loss. Depending on frequency of format usage
> you store the relation in that format and produce the other dynamically. If
> you more often need the info "which pool to which pool" then store this in a
> file and dynamically create scripts. I do not change this often but scripts
> are scheduled every day to run. So I prefer the other form. Just a matter of
> taste. And it isn't too complex (awk '{print $3,$4}').



I know how to maintain this information; I do so now.  I agree it's
straightforward to generate TSM scripts from external data; I do so now. I
have philosophical differences with some of the methods you'd choose, but
that's why they make different flavors of ice cream.

 My carping / request is that this data, since it's something every TSM admin
needs to keep track of, represents a -lot- of wheel-reinvention.  For example:

> For me the problems I had to resolve up to now were simple enough to handle
> them with awk&sed. So never had time to learn Perl in deep detail to use it
> effectively. XML is something I never had any benefit from.

So you do it one way, and I do it another, and Kelly Lipp is doing it some way
that makes both our methods look stupid. ;) But we all had to think about it,
we all designed our various data structures and storage methods, and our own
scripts to implement them.

This is dumb: Tivoli should come up with a way to represent this data (not
like it's hard) and give it to us, or explain why they think it's a bad idea.


> I've heard such thing exist but the only contact with it was on this
> list. And I was not satisfied at all - 10 weeks ago someone posted 32k XML
> to the list with his beloved MS Word. But in my mailer this looks like
> totally unreadable garbage. Maybe I am too conservative but do waste efforts
> only if it return some kind of benefit. I do not care how to store the font
> and the colour of filespace name in TSM database.


... If you want to talk XML, let's take it private; I'm rather a believer in
the tech, and I think you've been misled about its' meaning.


Allen S. Rout
<Prev in Thread] Current Thread [Next in Thread>