DR documentation presents special problems in at least two respects.

You will need to ensure that DR documentation survives the type of disaster 
covered by the documentation. Depending on your employer's policies and 
infrastructure, this may entail treating DR documentation as an exception to 
normal policies governing storage of online documentation.

The level of detail in DR documentation should allow for the unpleasant 
possibility of having the procedure carried out by consultants familiar with 
the relevant products but not familiar with your site's local conventions. I 
still remember the occasion some years ago when two groups of IS staff arrived 
at the machine room at the same time to work on unrelated problems. One group 
consisted of both Unix administrators on the IS Department payroll at the time. 
The other group consisted of the primary TSM administrator (me) and a co-worker 
who was both the backup TSM administrator and the primary system administrator 
for the MVS system that hosted the TSM server.

Thomas Denier
Thomas Jefferson University

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Skylar Thompson
Sent: Wednesday, May 27, 2015 9:14 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Documenting TSM

I find it's good to split documents into three different types - configuration 
(long-term, can be complex), operations (daily, should be simple), and DR 
(infrequent, but still should be simple). All of our documents live in a Twiki 
wiki.

On the configuration side, I try not to duplicate the vendor (IBM, library
vendor) docs too much, but will fill in holes where they're inadequate, and 
definitely will document local customizations and conventions. I might not 
document exact steps or commands for these, though, as these documents. I try 
to split out the TSM docs from the library docs.

On the operations side, I've found it's good to be as explicit and procedural 
as possible. Daily tasks and alerts both come through as tickets, with a link 
to the specific step-by-step procedure needed. The goal is for someone without 
a deep knowledge of TSM to be able to accomplish these tasks. As needed, I 
might combine the software and hardware steps here, for the sake of simplicity.

Like-wise, our DR docs are painfully explicit. In an emergency, you don't want 
to be thinking too hard, as you'll be scrambling and stressed even if 
everything is going right.

On Sat, May 23, 2015 at 08:45:23AM +0300, madunix AT gmail DOT com wrote:
> Starting to document the Installing/Implementing TSM7.1 environment
> and I'm wondering what type of information and the amount detail
> others are putting into their docs?  How are you documented TSM?  Security? 
> Database?
> Scripts?  Installation steps? troubleshooting?installing clients? ...etc.
>
> Does anyone have a good documentation example  day-to-day
> operation/administration?
>
> -mad

--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
The information contained in this transmission contains privileged and 
confidential information. It is intended only for the use of the person named 
above. If you are not the intended recipient, you are hereby notified that any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender by reply email and destroy all copies of the original message.

CAUTION: Intended recipients should NOT use email communication for emergent or 
urgent health care matters.