---------------------<snip>-----------------------
OK, I admit to not having had enough sleep. But the following insanity came to
me today. So I thought that I'd ask some, hopefully, sane people about it.
I always seem to have problems finding documentation on how a product was installed. That
is, what jobs were run, where were they submitted from, what did they do, where is there
output, and so on. There is also the "problem" of where to keep the
documentation, especially PDF files. So I got this weird idea. Why not keep all this
stuff in the UNIX filesystem on the z/OS system itself? Something along the lines of:
The base directory for &version of &product-name from vendor &vendor would all
be kept below the subdirectory:
/products/&vendor/&product-name/&version
For each such "base directory", there would be a set of directory along the
lines of:
./vendor-documentation (for vendor supplied doc, TEXT files, PDFs, etc)
./user-documentation (for things that the shop wants to document like FAQs,
installation notes, etc) This would also document any customization done to the
product, such as exits.
./install-job-output (a separate file for each job run, something like:)
./install-job-output/install.dsn.member.run.1
the .1 would be incremented so that if a job is run multiple times, you can see
the output from each successive job.
So, do I need another vacation?
-----------------------<unsnip>-------------------------
No, you don't need another vacation. But I would suggest one further
step, like this:
Cut a pair of CD-ROM's with all this doc available. Store one at your
primary site, along with the original copies of the product doc. Store
the second copy at your chosen DR repository, along with another copy of
the original product doc. Whether you keep one CD-ROM for each product
or put everything for all products on one or more CD-ROM's or DVD's is
your choice, but be sure that you have the means to use them
effectively, both in the regular workplace and in any DR site you might
be forced to use. You might also wish to cut copies for your
home-support users.
I can tell you from experience, (The Great Chicago Flood) that no matter
how insignificant a piece of doc might seem, the likelihood of needing
it will rise enormously when accessability starts to drop. I think
that's a corollary of Murphy's Law. :-)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html