Things should be balanced netween simplicity and flexibility. At the same
time there is always room for improvements. Nowadays I feel satisfied with
the current syntax.
I missed that for the relation. Sorry. This changes the point and I do
agree with you. Anyway such many-to-many relation requires another table
not just a field added to the current table.
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}').
As an answer to your last question - No, I am not using both Perl and
XML. 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. 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.
Zlatko Krastev
IT Consultant
asr AT UFL DOT EDU on 16.11.2001 17:34:18
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Aggravating recordkeeping failure in TSM.
=> On Fri, 16 Nov 2001 14:34:52 +0200, Zlatko
Krastev/ACIT<acit AT attglobal DOT net> said:
> More parameters you have to put more choices are available and more
flexible
> the product is.
Well, yes; exactly. :)
> Some people want to be able to make more than one stgpool backup in more
> than one copy pools. You suggestion would limit them.
Not at all.
> asr AT UFL DOT EDU on 13.11.2001 01:38:09 said:
>> 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.
If done correctly, there should be copy-pool associations just like
schedule
associations. As I said, there's no technical reason not to back up all
stgpools to all copy pools. Practical reasons, but no techical obstacles.
> Why not to create few simple scripts called BACKUP_BLOTZMO, BACKUP_WAKKO
and
> BACKUP_AAGRAVAAG or even a single "bigger" script
> BACKUP_ALL_THIS_STUFF_youre_the_computer ?
I think you missed my point: This does not solve the problem of maintaining
the data "which primary pool should back up to which copypool". I would
still
need e.g. an outside database that maintains that data, and periodically
verifies that the right scripts are defined.
In fact, the method you describe is the method I use on my server right
now: I
maintain an outside authority, which happens to be an XML file mapping
stgpool
heirarchies and copy pool correspondences. From this "canonical source", I
generate backup scripts of various sorts, which are loaded into TSM on a
periodic basis by administrative schedules. Other administrative schedules
run the scripts so generated.
All of this is baroquely complex, given that very simple additions to the
data
model would let all that information live _inside_ TSM. Even if Tivoli
decided not to make the
BACK STG source figure_it_out=yes
command availiable, we'd at least have a common background in which to
frame
our discussions. This would help understanding and promote best practices.
How many of you happen to be using XML and PERL to manage your copy pools?
Not many, I bet. We'd have more to learn from each other if we were doing
it
more the same way. Tivoli is the obvious source of authority for that way.
Allen S. Rout
|
