Thanks to all who responded and reminded me about the location of the dsm.sys file for the 64bit Oracle agent. I just couldn't remember. Senility is... um, ... rough.
On another unrelated issue, I had the infamous ANR2209W on a copy pool volume - I audited it and got this message back - I don't recall ever seeing this before. I searched the FAQ and didn't get any hits on the string "NumEmptyVols", and I see a lot of questions on ADSM.org, but not many answers. Is it time to audit the DB? 03/25/04 08:28:22 ANR2208I Volume G01309 deleted from storage pool SPTBUCOLDRMCP. 03/25/04 08:28:22 ANR9999D asvol.c(916): ThreadId<69> NumEmptyVols went negative for pool -11. 03/25/04 08:28:23 ANR1341I Scratch volume G01309 has been deleted from storage pool SPTBUCOLDRMCP. Dale Jolliff Data Administration Team Backup and Recovery -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Wednesday, March 24, 2004 1:00 PM To: [EMAIL PROTECTED] Subject: Re: need help!! long time archiving and storing corresponding systemstatus Original requirement: the environment is w2k and nt client nodes (over 200) and in near future w2003. short description of my problem: i have to archive data for long time retention, with the possibility to recover servers completely out of this archived data. >thank you for your comment, using ntbackup was one of our suggestions to >solve this problem. >in my opinion the solution with ntbackup will work, but the customer don't >want to have it. > >what about generating backupsets instead of archiving the data. is it >possible to restore a complete server >with a backupset? > > the problem will be the large amount of tapes for the backupsets. I think your customer's requirements are confused and vaguely defined, and that is making the contemplation of solution confusing. Your users are seemingly thinking of "the computer system" as their data, and are thus requiring that the whole think be preserved as an entity. That's faulty thinking, and thwarts the enterprise management of business data. The business data should be physically and logically separate from the platform which facilitates its use, which is to say that the data files should be in one area (disk, partition, or major directory) which is wholly separate from operating system and applications. It is the data that is unique and needs to be regularly backed up to be recoverable: the operating system and applications are reinstallable things. With that perspective, the TSM Archive system is the appropriate tool to make long-term images of your organizational data - the kind of imaging which may be required by regulators or the like. And you need to perform regular backups of the continually changing, daily business data. Disaster recovery is facilitated by TSM DRM and/or other BMR methods, which allows recovery onto equivalent or comparable hardware. Your recovery plans may instead involve no presumption upon being able to obtain any given type of computer, and so you may simply contemplate installing whatever OS and application levels you can obtain at the time of recovery, and restore your data thereafter, to be used by that current platform environment. Don't let end users define IT and business practices: the IT department and company executives should do that. IT should define how to best implement computer technology to facilitate business operation and possible recovery: IT has the expertise and experience to make it all work. Richard Sims