Documentation is something that people like to read–but typically do not like to create! Good documentation is worth its weight in gold. It is a great tool for learning about your network environment–and it helps to reduce the time it takes to resolve a problem.

The IBM VTAM and TCP/IP network product manuals are very detailed. Such proportionate detail might be necessary in regard to the processes, diagrams and setup information relevant to your organization. The information found in this type of documentation might include:

• Network component overview diagram

  Types of devices, protocols in use, mainframe network interfaces, LPAR names, TCP/IP addresses, network and subnetwork addresses, VTAM SSCP names, data center switches, and routers the mainframe is connected to. This information might not be shown all on one diagram, but somewhere it must all be documented and available.

• Network component description

  Describe the components in the diagram (such as VTAM, TCP/IP, routing, and interfaces) and explain how they are defined within your organization. Include IP network and subnetwork (network ID) information.

• Application descriptions

  Document application names and describe how they connect to the network.

• External connections

  Include details about connections to other organizations, as well as a brief description of what the connections are used for. Also include WAN service provider details, the protocol used, and the equipment used by the WAN service.

  Remember to cover the existence of any virtual private network (VPN) capabilities to external sites.

• Network naming conventions

  Document the data set names of source libraries, and where to find started task procedures, VTAM names of devices, applications and resources. TCP/IP naming conventions might include information about host names.

• Network processes

  Document the processes relevant to the networking role, common tasks you might have to perform such as problem diagnosis, change control, call out procedures, and describe where to find additional information.

• Network-related products, tools, exits, and automation

  Document the network controlling and monitoring products, as well as exits that might have been implemented and why. Also cover automation dependencies, and explain how to start or stop components manually.

• Change log

  Keep a log of all changes, describing when, what, and why a change was undertaken.

• Problem log

  Some organizations want you to record any network issues you might have, and to document their resolution.

• Contact details

  Document the people and group contacts that you work with, either in changes or problems, internally and externally.

• Security policy

  A security policy should never be far from a network administrator's mind. The network generally represents the most vulnerable aspect of a host. Any changes and all processes must be in accordance with an organization's security policies. Consequently, any or all of the documentation described here might include information on security classification or usage guidelines.

There are many other categories that could be included here. It sometimes seems as though documentation is more work than is worthwhile.

However, documentation is an integral part of a high availability network and host environment. Some say the document should be a living and breathing thing–the network rarely stands still!