Agreed. The docs word in a way to make you believe you need to do it. Thanks!

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda
Sent: Thursday, May 17, 2007 11:37 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] 'define machine' for DRM, is it necessary?

No, you don't have to do the define machine.
 
I think it was supposed to be a long-ago way to save information on the TSm
server about what was necessary to get critical clients up and running again
(and in what order), so that once you had the TSm data base restored, all
your recovery instructions are there.
 
But in practice, it's too hard to keep the info current and updated, IMHO.
 
Easier just to put the doc in a file, and save that in a group space where
everybody can keep it updated.  If you know where it is, you can always
restore it first thing.  Or email it to yourself.  Or FTP it somewhere.  Or
have all managers keep a paper copy in their car.  Whatever.  I think it's
more important to keep it current, than to keep it in TSM.
 
 
 

________________________________

From: ADSM: Dist Stor Manager on behalf of Bell, Charles (Chip)
Sent: Wed 5/16/2007 10:47 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: 'define machine' for DRM, is it necessary?



If what you see below is what I have set up for DRM, do I have to set up
machines and associations for my TSM server and clients in TSM? Will this
info not be brought back after mksysb and TSM DB restore (using DRM)?



tsm: TSM>q drmstatus



Recovery Plan Prefix: /drm/plan/tsm

Plan Instructions Prefix: /drm/instruction/tsm

Replacement Volume Postfix: @

Primary Storage Pools: DATABASE_MANAGE DATABASE_MIGRATE

DATABASE_MIGRATE_LTO2 DATABASE_VTL_3592

EMAGEON2_MIGRATE EMAGEON_MANAGE

EMAGEON_MIGRATE EXCHANGE_MIGRATE

EXCHANGE_VTL_3592 INFORMIX_MANAGE

INTEL_MIGRATE META_DISK META_MIGRATE

SANDIRECT_MIGRATE SPACEMGPOOL UNIX_MANAGE

UNIX_MIGRATE

Copy Storage Pools: DATABASE_OFFSITE DATABASE_OFFSITE_LTO2

EMAGEON2_OFFSITE EMAGEON_COPY

EXCHANGE_OFFSITE INTEL_OFFSITE

META_OFFSITE SANDIRECT_OFFSITE

UNIX_OFFSITE

Not Mountable Location Name: Waiting for Courier

Courier Name: Iron Mountain

Vault Site Name: Iron Mountain

DB Backup Series Expiration Days: 5 Day(s)

Recovery Plan File Expiration Days: 14 Day(s)

Check Label?: No

Process FILE Device Type?: No

Command File Name:



God bless you!!!

Chip Bell
Network Engineer I
IBM Tivoli Certified Deployment Professional

Baptist Health System
Birmingham, AL







-----------------------------------------
Confidentiality Notice:
The information contained in this email message is privileged and
confidential information and intended only for the use of the
individual or entity named in the address. If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this information is strictly
prohibited. If you received this information in error, please
notify the sender and delete this information from your computer
and retain no copies of any of this information.