Updated: 24 May 2001

DECnet-Plus

Order Number: AA--Q18ZE--TE

This manual describes using DECnet-Plus tools to isolate and correct simple DECnet-Plus problems in the OpenVMS and DIGITAL UNIX environments.

Revision/Update Information: This is a revised manual.

Operating Systems: OpenVMS VAX Version 7.1
OpenVMS Alpha Version 7.1
DIGITAL UNIX Version 4.0

Software Versions: DECnet-Plus for OpenVMS Version 7.1
DECnet/OSI for DIGITAL UNIX
Version 4.0

Digital Equipment Corporation Maynard, Massachusetts

Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description.

Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from DIGITAL or an authorized sublicensor.

DIGITAL conducts its business in a manner that conserves the environment and protects the safety and health of its employees, customers, and the community.

© Digital Equipment Corporation 1996. All rights reserved.

The following are trademarks of Digital Equipment Corporation: Bookreader, DDCMP, DEC, DECdirect, DECnet, DECNIS, DECserver, DECsystem, DECwindows, DIGITAL, DNA, InfoServer, OpenVMS, PATHWORKS, ULTRIX, VAX, VAX DOCUMENT, VAXcluster, VAXstation, VMS, VMScluster, and the DIGITAL logo.

The following are third-party trademarks:

Macintosh is a registered trademark of Apple Computer, Inc.
MS-DOS is a registered trademark of Microsoft Corporation.
OS/2 is a registered trademark of International Business Machines Corporation.
OSF/1 is a registered trademark of Open Software Foundation, Inc.
SCO is a trademark of Santa Cruz Operations, Inc.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Co. Ltd.

All other trademarks and registered trademarks are the property of their respective holders.

This document was prepared using VAX DOCUMENT, Version V3.2m.

Contents

Index

DECnet-Plus Problem Solving describes how to use DECnet-Plus tools to isolate and correct simple DECnet-Plus problems in the OpenVMS and DIGITAL UNIX environments.

Intended Audience

DECnet-Plus Problem Solving is for network managers and system managers who work in a DECnet-Plus environment.

Assumed knowledge

Readers of this book are expected to have a basic understanding of DECnet and OSI networking concepts. It is assumed that readers have experience with DECnet-Plus network management tools such as the Network Control Language (NCL), and DECnet Phase IV tools, such as the Network Control Program (NCP).

Related Documents

• DECnet Phase IV management documentation
• Phase IV network troubleshooting documentation
• DECnet-Plus network management documentation
• DECnet-Plus NCL reference documentation
• OSI Applications Kernel (OSAK) documentation
• DECdns or other name service documentation
• DECdts documentation
• The Common Trace Facility Use manual
• X.25 problem-solving documentation
• FTAM and Virtual Terminal documentation

Reader's Comments

DIGITAL welcomes your comments on this manual or any of the DECnet-Plus documents. Send us your comments through any of the following channels:

Internet	openvmsdoc@zko.mts.dec.com
Fax	603 881-0120, Attention: OSSG Documentation, ZKO3-4/U08
Mail	OSSG Documentation Group, ZKO3-4/U08 110 Spit Brook Rd. Nashua, NH 03062-2698

How To Order Additional Documentation

Use the following table to order additional documentation or information. If you need help deciding which documentation best meets your needs, call 800-DIGITAL (800-344-4825).

Conventions

The following conventions apply to this book.

Convention	Meaning
special type	Indicates a literal example of system output or user input. In text, indicates command names, keywords, node names, file names, directories, utilities, and tools. On a DECnet-Plus for ULTRIX system, enter the word or phrase in the exact case shown. You can abbreviate command keywords to the smallest number of characters that OpenVMS, DIGITAL UNIX, NCL, DECdns, DECdts, and the other utilities accept, usually three characters.
italic	Indicates a variable.
bold	Indicates a new term defined either in the text or in the glossary section of the Introduction and User's Guide manual for your operating system.
[Return]	Indicates that you press the Return key.
[Ctrl/] x	Indicates that you press the Control key while you press the key noted by x.
[ ]	In command format descriptions, indicates optional elements. You can enter as many as you want.
{ }	In command format descriptions, indicates you must enter at least one listed element.

Other Conventions

• All numbers are decimal unless otherwise noted.
• All Ethernet addresses are hexadecimal.

A necessary part of any type of problem solving is fault isolation. Fault isolation is the process used to determine the source of a problem. Quick and efficient fault isolation is key to resolving network problems.

Topics in This Chapter

The topics in this chapter are:

• Understanding the DECnet-Plus Network Model ( Section 1.1)
• Classifying Problems ( Section 1.2)
• DECnet-Plus Component Relationships ( Section 1.3)
• Methods for Isolating Faults ( Section 1.4)

1.1 Understanding the DECnet-Plus Network Model

Figure 1-1 DECnet-Plus Network Model

Table 1-1 briefly describes the functions of the OSI network layers.

Table 1-1 OSI Network Layers

OSI Layer	Name	Function
7	Application	Contains the application services and supporting protocols that use the lower layers. Allows distributed processing and access.
6	Presentation	Coordinates data and data format conversion to meet the needs of individual application processes.
5	Session	Organizes and structures the interaction between pairs of communicating application processes
4	Transport	Transfers data between end systems and has error recovery and flow control. Supported protocol classes are: Class 0 (TP0)---Simple protocol class for highly reliable network services Class 2 (TP2)---Same as Class 0 with multiplexing feature Class 4 (TP4)---Provides error detection and recovery for highly unreliable network services
3	Network	Permits communications between network entities in open systems, whether they are adjacent systems on the same subnetwork or are connected by a path that crosses multiple subnetworks and intermediate systems. DECnet-Plus supports Connection-Oriented Network Service (CONS) and Connectionless-mode Network Service (CLNS), as well as communications between Phase IV and DECnet-Plus systems.
2	Data Link	Specifies the technique for moving data along network links between defined points on the network, and tells how to detect and correct errors in the Physical layer.
1	Physical	Connects systems to the physical communications media.

1.1.2 DNA Layer Functions

Table 1-2 briefly describes the functions of DNA network layers.

Table 1-2 DNA Network Layers

DNA Layer	Name	Function
7	DNA Application	Includes user-written programs and user-level services. It is used by operators and system programmers to plan, control, and maintain the operation of DECnet-Plus networks.
6 and 5	DNA Session Control	Allows communication between programs, regardless of either program's location through the use of DNA naming services. It also provides access control and authentication functions, and acts as a bridge between applications and the transport services.
4	Network Services Protocol (NSP)	Allows interoperability with Phase IV systems.
3, 2, and 1	Same as described in Section 1.1.1

1.1.3 TCP/IP Interoperability

The DECnet-Plus for DIGITAL UNIX applications, FTAM and Virtual Terminal, support RFC 1006 and can use TCP/IP transport services. This manual does not include problem-solving information for TCP/IP networks. Refer to your TCP/IP documentation for this information.

1.2 Classifying Problems

A reproducible problem consistently produces the same error message or symptom when reproduced under the same conditions.

Some reproducible problems produce different error messages or symptoms that can ultimately have the same underlying cause. These types of reproducible problems are considered inconsistent. Inconsistent problems generally involve several protocols or several layers of an architecture. The different error messages result from the ways different applications encounter the problem in the protocols and the architectural layers.

1.2.2 Intermittent Problems

An intermittent problem appears occasionally and displays the same error message or symptoms in the same circumstances. You can occasionally reproduce intermittent errors. Intermittent errors can occur when threshold values for various parameters are reached. Usually, during normal use, these thresholds are not reached; however, the thresholds can be reached during peak use and errors can result.

1.2.3 Transient Problems

Transient problems occur only occasionally, and can rarely be reproduced. Because you cannot reliably reproduce transient problems, they are by far the most difficult errors to isolate and fix.

As with intermittent problems, transient problems can result when threshold values for various parameters are reached. Because transient errors tend to occur at peak usage times, historical performance data is helpful in determining the cause of the problem.

1.3 DECnet-Plus Component Relationships

Figure 1-2 and Figure 1-3 show the relationships between the individual components in the DECnet-Plus environment on OpenVMS and DIGITAL UNIX systems. Use this information as a guide when you need to identify problems in a specific DECnet-Plus layer.

For information and problem solving procedures relating to X.400, DECdns, and DECdts software, refer to the appropriate software documentation.

1.3.1 Component Relationships (OpenVMS Only)

Figure 1-2 shows the OpenVMS component relationships.

Figure 1-2 Component Relationships (OpenVMS)

1.3.2 Component Relationships (DIGITAL UNIX Only)

Figure 1-3 shows the component relationships for DIGITAL UNIX.

Figure 1-3 Component Relationships (DIGITAL UNIX)

1.4 Methods for Isolating Faults

• The conditions that existed when an error appeared
• The relationships between DECnet-Plus components
• The type of problem you have: reproducible or intermittent
• The changes you made prior to the error appearing

Answers to the following questions can help identify a starting point for problem solving:

• Which components, systems, or applications are working correctly?
• When did you first notice the problem?
• Did you see any error messages?
• What were you doing when the problem occurred?
• Can you re-create the problem?
• Did you recently add or change hardware or software?
• How often has the problem occurred since you first noticed it?

Problem symptoms do not always indicate which DECnet-Plus component is the cause of the problem. To clarify where the problem exists, use another operation or application that relies on the same underlying services or components as the operation that failed.

The figures in Sections <REFERENCE>(OpenVMS_RELATIONSHIP\VALUE) and 1.3.2 show the relationship between the components in the DECnet-Plus environment.

1.4.3 DECnet-Plus Fault-Isolation Methodology

Isolating and solving network problems often requires a variety of approaches. You can use the general methodology illustrated in Figure 1-4 as a starting point for fault isolation.

Figure 1-4 Fault-Isolation Methodology (General)

1.4.4 Isolating Faults for Reproducible Problems

1. Find network activities that are similar, where one activity succeeds and the other fails. For example; if the OpenVMS command set host fails, try a similar operation to the same remote node. Then try the set host operation from the same local node to a different remote node.
2. Determine the most recent time when the operation succeeded. Then determine what has changed in the network since then.

You can use the following procedure when intermittent or transient problems occur:

1. Collect as much information as possible regarding the state of the network when the problem appears. This information includes any type of trace information that application trace utilities provide.
2. Examine historical and trace data to determine if any patterns exist; for example, if the FTAM application fails only when attempting a directory operation on a specific vendor's system.
3. Try to reproduce the problem by re-creating the state of the system when the problem first appeared.
4. If you can reproduce the problem, follow the process described in Section 1.4.4.

Documenting the steps you used to isolate a problem makes reporting the situation to DIGITAL representatives easier if you are unable to solve the problem yourself.

Always record the following:

• The conditions under which problems occurred
• The hardware and software version numbers used in your network
• The processes you used to identify problems
• The information you collected about the problems
• The procedures you used to solve problems

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6498PRO.HTML