On 12/04/2010 10:16 AM, Steve Comstock wrote:
On 12/4/2010 8:55 AM, Joel C. Ewing wrote:
I've always felt it was a bad idea to have installation mainframe
documentation
too far separated from the mainframe platform itself or dependent on
any other
server platforms, under the general premise that in a DR situation if
we have
recovered the mainframe we want to be sure we have access to all
documentation
needed to operate it.
Some documentation was just kept as monocase or dualcase text files on
MVS, with
links from ISPF screens. Before DCF/Script became too expensive, some
large
documents were maintained as separate chapters in DCF SGML using DCF
to build
text and pdf versions of the document. Afterwards those SGML documents
were
converted to use docbook tools with docbook document source on MVS,
building
multi-html, single-html, and pdf version with free tools on a
workstation and
then porting various forms either back to MVS or to media that went
off site for
DR.
Because of the complexity of the docbook approach, there has been
pressure in
recent years to go to a more update-friendly wysiwyg solution, with a
management
preference for MS Word. My own preference is OpenOffice. The OO price
is right,
enabling everyone to afford the current version, while non-trivial
licensing
costs with MS Word typically mean there are multiple,
not-completely-compatible
versions floating around the corporation. My version of OpenOffice has
much
better support than my version of MS Word for maintaining documents of
several
hundred pages as a master document and separate chapters and optionally
generating both html and pdf document formats, which can be saved on
MVS and
elsewhere. I also find a much lower level of astonishment using
OpenOffice - it
seems like MS Word more often tries to do too much and makes erroneous
assumptions about my formatting intentions. And then of course there
is the
philosophical issue of having MVS documentation dependent on MicroSoft!
I am not averse to the concept of a wiki and I believe we actually
have one that
is available to Technical Services and used by PC Technical Support,
but to not
violate my requirement for availability of MVS documentation, some
form of the
information would have to be portable both to MVS and in some other
form (html,
pdf) that would be accessible without any functioning server in a DR
scenario.
But, z/OS could be your server, so you could host the
html pages from z/OS and access these from a browser.
[Or are you saying you only want docs that can be read
using ISPF?]
Just use the free HTTP server that comes with z/OS or
order the Apache-based no-charge server available with
the most recent ported tools.
There would also have to be some support to take a collection of separate
related articles and assemble them into a hard copy manual, such as
might be
required by Operations to restart the computer center after a complete
power
down when no servers are available.
Joel C Ewing
It is convenient to have some of the documentation be available directly
from ISPF, but in most cases we have found it highly useful to be able
to publish in multiple formats from the same source and allow multiple
methods of access. For example, we publish our general in-house Utility
Documentation as a text file under ISPF, as individual chapters under
MVS/QuickRef under ISPF, as web-served pdf and html documents, and on
shared network drives as pdf and html documents that are copied off-site
for DR.
We actually already run the free http server on z/OS to run book server
for z/OS manuals and to serve generated http and pdf versions of various
TechServ documents that are maintained in OpenOffice and docbook
formats, but our main corporate web servers are on MS platforms and our
corporate web standards are highly MS and ASP centric. We have to keep
a low profile since what we do with the web server on z/OS falls outside
our standards and is tolerated because it is only used in-house, uses
minimal resources, and doesn't consume enough of our time to be an issue.
Finding and installing free wiki software for that environment might not
be that difficult, but playing with it enough to determine if we can
also generate suitable hard-copy manuals or pdf documents where required
and then actually converting existing large documents to wiki format is
a major project that would need approval, which would be hard to get
unless we can first do enough off-the-clock research to prove it will
work for us and not be more difficult than converting the remaining
docbook documents to MS Word (arghh) or OpenOffice source document formats.
--
Joel C. Ewing, Fort Smith, AR [email protected]
----------------------------------------------------------------------
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
