| I have many customers come to my Polycenter classes because they had
tried to set up the product to meet their needs and they just were not
able to do it with the existing documentation. It might not be possible
to address all of these in on-line help but maybe yopu might have other
ideas on how to help POLYCENTER users through these trouble areas.
The main trouble areas that they talked about were:
1. The documentation often empasises "...plan your namespace..."
For many folks, this is their first exposure to a
distributed name space and they have no idea how to
even begin to do this planning. Why should the namespace be
planned? What happens if it is not? What things would
constitute a well defined, efficent namespace, as compared
to one that is haphazzard?? What factors in my network
and/or system environment would effect the namespace?
Would it be possible to give some insight into the factors that should
be taken into consideration when laying out the namespace? Maybe
examples of a good namespace structures for a networks consisting of a
LAN with several thousand nodes in a small geographic area could be
contrasted with structure required for a large network consisting of
many, many LANs interconnected by various means. Line by line namespace
architecture is not needed; just an analysis of what one good and one
bad namespace structure could look like for each example network, what
factors were considered in determining the namespace structure, what
factors made one good and one bad, what would be the results of using
each one, etc.
2. Alarm rules are always big topics for discussion. A "cook book"
approach to creating, enabling, saving, monitoring, logging, clearing,
modifying, and reusing alarm rules would be greatly appreciated.
Along the same lines, many customers could make great use of a
guidebook on using POLYCENTER features to troubleshoot and otherwise
manage their network. I know this toipic is as broad as all outdoors
but when you think about it, network managers NEVER had the kind
management and troubleshooting power provided by POLYCENTER and, because
of this, they have all of these wonderful tools with which monitor and
analyze in their network without the slightest idea of how to apply the
information they provide. I would assume that the various Customer Support
Centers and the Field Support Organizations could provide some insight
into, say for example, the top ten or fifteen common problems seen
in networks. From this, some guidelines for important things to monitor
to detect these problems in a timely manner so as to prevent them from
taking down the network. With good examples, based on what has been
seen in the real world to use as a guide, the power and verstility of
POLYCENTER should be eradily apparent!
3. It sure would be nice to have a help menu associated with each and
every window (windows requiring data entry, that is) to explain what
each field is for, what goes in it, and a sample entry for it. (Maybe
another item like "Expand Field"...??)
Oh well, back to the salt mine.... Bob
|
| RE: -1
The main trouble areas that they talked about were:
1. The documentation often empasises "...plan your namespace..."
For many folks, this is their first exposure to a
distributed name space and they have no idea how to
even begin to do this planning. Why should the namespace be
planned? What happens if it is not? What things would
constitute a well defined, efficent namespace, as compared
to one that is haphazzard?? What factors in my network
and/or system environment would effect the namespace?
kjn>> hmmmm.... The PolyCenter products take advantage of a lot of
kjn>> Digital's product set. We cannot possibly document every product
kjn>> associated with PNM. The DECdns group put out a wonderful document on
kjn>> planning and designing namespaces. I believe that the PNM documentation
kjn>> points the network manager to that document for more information.
kjn>> Perhaps, at the same time, PNM can include a bit more information
kjn>> on setting up namespaces.
...
2. Alarm rules are always big topics for discussion. A "cook book"
approach to creating, enabling, saving, monitoring, logging, clearing,
modifying, and reusing alarm rules would be greatly appreciated.
kjn>> The Alarm Manager will fill that need. It is included as a prototype in
kjn>> V1.3 and will ship with the next release of the PNM Fault Management
kjn>> Package. The Alarm Manager has a knowledge base of rule templates,
kjn>> what they are useful for, and suggested resulting action procedures.
kjn>> The PNM Fault Management Package also includes the Network
kjn>> Troubleshooting Guide which should give the network manager some
kjn>> help. If the Network Troubleshooting Guide is not sufficient,
kjn>> then maybe that piece of documentation should be updated.
|
| Based on an analysis of problems reported and questions asked from
various sources for Versions 1.2 and 1.3, we've come up with this "top
ten" list of useful HELP topics:
1. Troubleshooting DECmcc
2. Creating alarm rules*
3. Setting up notification*
4. Setting up DECnet/OSI event logging
5. Bridge firmware revision levels
6. Using SNMP private MIBs
7. DECmcc upgrade information
8. Setting up the Historian*
9. Using maps
10. Configuration management
*Topic already in on-line HELP
Together, these ten topics (out of 40 categories) answer 130 of the 224
questions I picked out. So these are the topics I'm tackling.
(My data and research methodology are available on request.)
|