Hi Tom,

 > >In the end: I would say that IBM must do something here. It must always
be
 > >possible to rebuild the DB from all the volumes currently being used.
Even
 > >without the volhist backup, an external tape manager providing the
DSN's or
 > >a plain paper list of volumes must be all what is needed. Otherwise the
DB
 > >is too much at risk in my opinion.
 > I disagree. IBM provides all of the tools necessary within ADSM
 > to backup the database during normal operations of ADSM. Why
 > would you have backups of your ADSM server from a product other
 > than ADSM, but *not* have a backup of the ADSM database via the
 > "backup db" command? That sounds to me like putting the cart
 > before the horse. Why go to the trouble of setting up a backup
 > procedure that is guaranteed to be unreliable, when the very
 > product you are trying to backup is providing you with the tools
 > necessary to guarantee a consistent and reliable backup?
 > The first thing I would do after any ADSM server installation is
 > set up schedules to backup the database. That's why IBM provides
 > those tools, and makes them so easy to administer. One of the
 > great benefits of managing an ADSM server is that, although at
 > its core it is a very complex relational database package, there
 > are tools provided that do not require many years of database
 > administration experience.

The only problem I have with doing so is that the scheduled events in ADSM
for VM do not always run properly. Sometimes the scheduled backups simply
get 'missed'. This is not from time to time, it occured after max two or
three weeks and sometimes I get that problem after just two days. The
ADSM/VM server is 2.1.0 and the levels where I have seen this are level 09
and level 17 (no others tried).

This was known by my IBM support rep and, he told me the circumvention
almost instantly: Restart the ADSM server. The disadvantage is that we use
the ADSM server almost any time around the clock and we don't want to
restart it without a notice to the clients (and our clients are 'only' all
our NT file, application and print servers, Lotus Notes Servers, misc. Unix
platforms with SAP, and so on) ...

Another possible circumvention may be an external scheduler which autologs
a userid that issues the commands that are needed. This has the
disadvantage that I have to look at more than one place for schedule and
afterwards execution related things.

Since level 09 and level 17 of ADSM 2.1.0 for VM do this in the same way, I
do not want to have to rely on it. And that is my reason for asking IBM to
do something *-in addition-* here. This should be not too difficult as the
data needed may already be on the tape.

Maybe I ask the wrong thing from IBM. Well, partially yes, IBM should
resolve that scheduling problem. But I feel that two safety belts are here
better than just one. The ADSM database consists of data that can be
retrieved from somewhere and why should that not be done? BTW: We have
around 600-700 GB data stored on ADSM storage pools and the DB is around
2.7 GB assigned capacity (2.1 GB used) in size, so it's no peanuts that I
would loose in case of an ADSM DB problem ...

Ciao - Andreas