> Talking about implementation, here's a FAIR way of looking at ADSM.
> GREAT IDEA!  Nice having somewhat consistent backup interface
> across literally any and all platforms.


So far, I can agree with this.  Pretty hard not to -- it's a good product. 

> QUESTIONABLE implementation. It is customary to respect those that
> actually have done such a project, but when rubber meets the road,
> there are potholes and speedbumps.  What makes this worse is
> how the whole ADSM package is coded: ie by whom and where.  Expecially
> what happens when different pieces are brought together.  ISO schm-ISO.

This I disagree with. Most of the major problems/complaints I have or 
regulalrly see with ADSM are caused by:

a) poor design of the operating system and software being backed up (NT is a 
classic example)
b) user unwillingness to take the time to read and understand the 
documentation. 

I'm not sure which of these I consider to be more serious, and b) is certainly 
not a flaw in the product,  but in the users. 
Almost everything I've ever needed to do is IN the documentation -- there are 
very few products that can say that, particularly
when dealing with "open systems" products. We're not dealing with toys here -- 
this is industrial strength stuff that CAN handle terabytes of data and tens of 
thousands of clients. 
IMHO, it SHOULDN'T be -- OR TRY TO BE -- "point and click". 

> And the documentation, kills trees,
> also makes for a good doorstop!  (See Messages Guide or Admin Ref)

At least these documents EXIST. None of the other "enterprise" backup systems 
are as extensively documented. Yes, the messages guide isn't up to date.
This isn't an easy proposition. I use the admin ref constantly. 

> BTW, Tivoli is just a Marketing front, IBM is still driving the car.


Good.  From what I've seen of Tivoli products, I'd really RATHER it be IBM.