ADSM-L

Aggravating recordkeeping failure in TSM.

2001-11-12 18:40:46
Subject: Aggravating recordkeeping failure in TSM.
From: asr AT UFL DOT EDU
Date: Mon, 12 Nov 2001 18:38:09 -0500
How do YOU keep track of what primary stgpools _ought_ to be backed up?  Not
what are we doing, but what should we be doing?


There's a set of data that we all need to keep track of, which TSM simply
punts: 'where should this primary stgpool be backed up to?'.

I don't know about most of you, but I have stylized stgpool names, which let
me identify candidate copy pools from nomenclature alone.

YADDA-DISK
YADDA-TAPE
YADDA-OPTICAL

all back up to

YADDA-C1

and

YADDA-C2

and so forth, if they are there.


But this is an immensely clumsy way to do it.  I want a way to set, in the TSM
database, the notion "BLOTZMO-DISK, WAKKO-TAPE, and AAGRAVAAG-OPTICAL should
be backed up to ARCHIPELAGO-MOOSETHROTTLE".  Then I could issue a command of
the sort:

back stgpool BLOTZMO-DISK figure_it_out_youre_the_computer=yes

Not only does the lack of recordkeeping make it impossible to do automatic
maintainance as I suggest, it makes it a priori impossible to write a
monitoring tool without maintaining some sort of external configuration file
to hold the data.

This could be solved officially from the inside, or it could be solved by
letting us add "columns" to the "table" STGPOOLS.  We could come up with
standardized names for this kind of data, and we'd at least be able to do
-something- with the base package.  Heck, even a single-value field
BACKSTGPOOL to match NEXTSTGPOOL would be something.  Of course, to do it
BACKSTGPOOL to match NEXTSTGPOOL would be something.  Of course, to do it
right you'd want a relation: there's no technical reason to prevent peole from
backing up all their primary stgpools to all their copypools.



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