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@VM.MARIST.EDU] On Behalf Of Skylar Thompson Sent: Wednesday, May 27, 2015 9:14 AM To: ADSM-L@VM.MARIST.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, madu...@gmail.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 (skyl...@u.washington.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.
