← All Documents
VMS Software / Documentation / VSI X.25 for OpenVMS Problem Solving Guide

VSI X.25 for OpenVMS Problem Solving Guide

Document Number: DO-DX25PS-01A
Publication Date: April 2024
Software Version:
VSI X.25 for OpenVMS Version 2.1
Operating System and Version:
VSI OpenVMS IA-64 Version 8.4-1H1 or higher
VSI OpenVMS Alpha Version 8.4-2L1 or higher

Preface

This manual describes some of the problems that may occur when using the VSI X.25 for OpenVMS software, and how to solve them.

The information in this manual applies to the X.25 functionality provided by VSI X.25 for OpenVMS and VSI DECnet-Plus for OpenVMS VAX. Note that the X.25 functionality in VSI DECnet-Plus for OpenVMS VAX was formerly provided by VAX P.S.I. software.

Throughout this manual, the X.25 functionality provided by both VSI X.25 for OpenVMS and VSI DECnet-Plus for OpenVMS VAX is referred to generically as X.25 for OpenVMS.

This manual uses the term Packet Switching Data Network (PSDN) to refer to any public or private packet switching network that X.25 for OpenVMS supports.

1. About VSI

VMS Software, Inc. (VSI) is an independent software company licensed by Hewlett Packard Enterprise to develop and support the OpenVMS operating system.

2. Intended Audience

Read this manual if you are having problems using your X.25 system. This manual assumes that you understand and have experience with:

  • Local Area Networks (LANs)

  • Wide Area Networks (WANs)

  • Installation of software products on OpenVMS

  • X.25 Communications

  • VSI X.25 for OpenVMS

3. Document Structure

This manual has three chapters and three appendices:

  • Chapter 1, describes the preparation needed for problem solving.

  • Chapter 2, describes how to analyze and correct X.25–related problems.

  • Chapter 3, describes how to analyze and correct X.29–related problems.

  • Appendix A, describes how to test the communications link between an X.25 for OpenVMS system and the PSDN.

  • Appendix B, lists the X.25 cause codes used in X.25 for OpenVMS.

  • Appendix C, lists the X.25 diagnostic codes used in X.25 for OpenVMS.

4. Related Documents

The following sections describe VSI DECnet-Plus for OpenVMS, VSI X.25 for OpenVMS, and VSI OpenVMS manuals that either directly describe the X.25 for OpenVMS software or provide related information.

VSI DECnet-Plus for OpenVMS Documentation

The following DECnet-Plus manuals contain information useful to X.25 for OpenVMS managers, users, and programmers:

  • VSI DECnet-Plus for OpenVMS Introduction and User's Guide

    This manual provides general information on DECnet-Plus and describes the concept of packet switching data networks.

  • VSI DECnet-Plus for OpenVMS Installation and Configuration

    This manual describes how to install and configure VSI DECnet-Plus for OpenVMS software. For OpenVMS I64 and OpenVMS Alpha systems, this manual also describes how to install X.25 for OpenVMS software. Details on configuring X.25 for OpenVMS on OpenVMS I64 and OpenVMS Alpha systems are provided in the VSI X.25 for OpenVMS Configuration manual. For OpenVMS VAX systems, this manual also describes how to install and configure the X.25 functionality provided by VSI DECnet-Plus for OpenVMS VAX.

  • VSI DECnet-Plus for OpenVMS Network Management Guide

    This manual provides conceptual and task information about managing and monitoring a DECnet-Plus network. In addition, the manual devotes a section to the management of X.25 entities used by DECnet operating over X.25 data links.

  • VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide

    This manual provides detailed information on the Network Control Language (NCL), which is used to manage X.25 for OpenVMS management entities.

VSI X.25 for OpenVMS Documentation

The following manuals make up the X.25 for OpenVMS documentation set:

  • VSI X.25 for OpenVMS Configuration (OpenVMS I64 and OpenVMS Alpha)

    This manual explains how to configure X.25 for OpenVMS software on OpenVMS I64 and OpenVMS Alpha systems.

  • VSI X.25 for OpenVMS Security Guide

    This manual describes the X.25 Security model and how to set up, manage, and monitor X.25 Security to protect your X.25 for OpenVMS system from unauthorized incoming and outgoing calls.

  • VSI X.25 for OpenVMS Problem Solving

    This manual provides guidance on how to analyze and correct X.25–related and X.29–related problems that may occur while using the X.25 for OpenVMS software. In addition, the manual describes loopback testing for LAPB data links.

  • X.25 for OpenVMS Programming

    This manual describes how to write X.25 and X.29 programs to perform network operations.

  • X.25 for OpenVMS Programming Reference

    This manual provides reference information for X.25 and X.29 programmers. It is a companion manual to the X.25 for OpenVMS Programming.

  • X.25 for OpenVMS Utilities

    This manual describes how to use and manage X.25 Mail and how to use and manage a host–based PAD to connect to a remote system. It also describes how to manage the X.29 communication links used for both of these functions. In addition, this manual explains how to use OpenVMS DCL SET TERMINAL/X29 commands to manage remote host–based or network PADs.

  • X.25 for OpenVMS Accounting

    This manual describes how to use X.25 Accounting to obtain performance records and information on how X.25 is being used on your system.

VSI OpenVMS Documentation

The following OpenVMS manuals contain information useful to X.25 for OpenVMS managers, users, and programmers:

  • VSI OpenVMS DCL Dictionary

  • VSI OpenVMS System Management Utilities Reference Manual

  • VSI OpenVMS System Services Reference Manual

  • VSI OpenVMS Guide to System Security

5. OpenVMS Documentation

The full VSI OpenVMS documentation set can be found on the VMS Software Documentation webpage at https://docs.vmssoftware.com.

6. VSI Encourages Your Comments

You may send comments or suggestions regarding this manual or any VSI document by sending electronic mail to the following Internet address: . Users who have VSI OpenVMS support contracts through VSI can contact for help with this product.

7. Terminology

The terminology used in the VAX P.S.I. product has been replaced by the terminology used in the X.25 for OpenVMS product. Table 1 shows the correlation between VAX P.S.I. terms and their X.25 for OpenVMS counterparts.
Table 1. X.25 Terminology

VAX P.S.I.

X.25 for OpenVMS

VAX P.S.I.

X.25 for OpenVMS VAX

Access system

X.25 Client system

Native system

X.25 Direct Connect system

Multihost system

X.25 Connector system

Gateway system

X.25 Connector system

In addition to the terms shown in Table 1, the X.25 for OpenVMS documentation set uses the following standard terms for client systems, server systems, relay systems, and the X.25 for OpenVMS management entities that represent these systems:
Table 2. X.25 for OpenVMS Client/Server Terminology

Client system

A client system of an X.25 Connector system (and therefore a client of the X25 Server management module on the X.25 Connector system.)

Relay Client system

A client system of an X.25 Relay system (and therefore a client of the X25 Relay management module on the X.25 Relay system.)

Relay–Client

A shorthand term for an X25 RELAY CLIENT management entity on an X.25 Relay system that contains management information about an actual Relay Client system.

Relay system

An X.25 Direct Connect or Connector system with the X.25 Relay module enabled.

Server Client system

Another term for a Client system.

Server–Client

A shorthand term for an X25 SERVER CLIENT management entity on an X.25 Connector system that contains management information about one or more actual X.25 Client systems.

For more information about clients, servers, and relays in X.25 for OpenVMS, refer to the VSI X.25 for OpenVMS Configuration manual and the VSI X.25 for OpenVMS Management Guide.

8. Conventions

The following conventions are used in the X.25 for OpenVMS documentation set:
ConventionMeaning

UPPERCASE and lowercase

The OpenVMS operating system does not differentiate between lowercase and uppercase characters. Literal strings that appear in text, examples, syntax descriptions, and function descriptions can be entered using uppercase characters, lowercase characters, or a combination of both.

In running text, uppercase characters indicate OpenVMS DCL commands and command qualifiers; Network Control Language (NCL) commands and command parameters; other product–specific commands and command parameters; network management entities; OpenVMS system logical names; and OpenVMS system service calls, parameters, and item codes.

Leading uppercase characters, such as Protocol State, indicate management entity characteristics and management entity event names. Leading uppercase characters are also used for the top-level management entities known as modules.

system output

This typeface is used in interactive and code examples to indicate system output. In running text, this typeface is used to indicate the exact name of a device, directory, or file; the name of an instance of a network management entity; or an example value assigned to a DCL qualifier or NCL command parameter.

user input

In interactive examples, user input is shown in bold monospaced print.

$

In this manual, a dollar sign ($) is used to represent the default OpenVMS user prompt.

CTRL/x

In procedures, a sequence such as CTRL/x indicates that you must hold down the key labeled Ctrl while you press another key or a pointing device button.

italic text

Italic text indicates variables or book names. Variables include information that varies in system input and output. In discussions of event messages, italic text indicates a possible value of an event argument.

bold text

Bold text indicates an important term, or important information.

( )

In a command definition, parenthesis indicate that you must enclose the options in parenthesis if you choose more than one. Separate the options using commas.

{ }

In a command definition, braces are used to enclose sets of values. The braces are a required part of the command syntax.

[ ]

In a command definition, square brackets are used to enclose parts of the command that are optional. You can choose one, none, or all of the options. The brackets are not part of the command syntax. However, brackets are a required syntax element when specifying a directory name in an OpenVMS file specification.

Chapter 1. Preparations for Problem Solving

1.1. Introduction

This manual contains information to help you solve problems that may occur when using VSI X.25 for OpenVMS.

Problems can occur for a number of reasons. The problem solving procedures in Chapter 2 and Chapter 3 help you to determine where the problems are.

This chapter describes the problem solving tools that are used in the procedures, and the information you need to solve X.25 problems.

1.2. Problem Solving Tools

Sections 1.2.1 to 1.2.5 describe the problem solving tools that can be used to help you solve X.25 problems.

1.2.1. NCL

During problem solving, you will need to enter Network Control Language (NCL) commands from a suitable node. Refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide manual for details on how to start NCL on your node.

Note that changes made using NCL remain in effect until one of the following actions take place:

  • NCL commands are issued that override the current settings.

  • The system is rebooted. As part of this action, the NCL commands in the current configuration file are executed and therefore override any NCL commands previously issued.

  • The configuration program is run to generate a new configuration file and the system is rebooted.

1.2.2. Event Logging

Event Logging monitors the events generated by the network. Network events inform you of what is happening on the network and where there are any problems. Refer to the VSI DECnet-Plus for OpenVMS Network Management Guide manual for information on how to set up and manage event logging.

Refer to Table 2.1 in Chapter 2 of this manual for more details of the events logged by X.25 for OpenVMS.

1.2.3. Counters

Counters tabulate the number of times an entity has performed a particular operation or the number of times a certain condition or event has occurred since the entity was created. For example, you can determine the number of times an event has been generated by looking at the appropriate counter.

Counter values are dynamically maintained by the system and cannot be reset by the system manager.

For more information about counters, refer to the VSI DECnet-Plus for OpenVMS Network Control Language Reference Guide manual.

1.2.4. Common Trace Facility (CTF)

The Common Trace Facility (CTF) allows you to collect and display information about specific protocol exchanges between systems in a network.

For more information on the trace facility and its components refer to the DECnet/OSI for OpenVMS Common Trace Facility Use manual.

1.2.5. Loopback Tests

Loopback tests can be used to test the access to the physical link between the X.25 for OpenVMS system and the PSDN. Appendix A describes how to perform loopback tests.

1.3. Solving a Problem – General Procedure

Before you start problem solving, ensure that you have the following information available:

  • The necessary documentation to help you solve problems

  • Information on the PSDN, including the DTE addresses

When you have all the necessary information, refer to the chapter relevant to the problem you are experiencing. Instructions in each chapter detail how to proceed.

  • Chapter 2 describes how to analyze and correct X.25 problems.

  • Chapter 3 describes how to analyze and correct X.29 problems.

In the problem solving sections, the left–hand pages ask questions about the problem. When the answer to a question points you to a numbered note, read the specified note which is on the right–hand page. Read the note and perform any actions specified.

If as a result of solving the problem you have had to change one or more X.25 management entities, you should either add the changes to the appropriate user NCL script file (on OpenVMS I64 and OpenVMS Alpha systems) or re–run the configuration program. This action ensures that your network will maintain the same configuration the next time the system is rebooted.

For details on using NCL, refer to the VSI X.25 for OpenVMS Management Guide.

For details on configuring X.25 for OpenVMS on OpenVMS I64 and OpenVMS Alpha systems, refer to the VSI X.25 for OpenVMS Configuration manual.

For details on configuring X.25 for OpenVMS on OpenVMS VAX systems, refer to the VSI DECnet-Plus for OpenVMS Installation and Configuration manual.

If you cannot solve the problem by using the methods suggested in this manual, contact VMS Software, Inc. for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

Chapter 2. X.25 Problems

2.1. Introduction

This chapter describes how to analyze and correct X.25–related problems. Specifically, it details how to solve the following problems:

  • X.25 for OpenVMS fails to run after system reboot (refer to Section 2.4).

  • A DTE fails (refer to Section 2.5).

  • Incoming calls cannot be received on a local DTE (refer to Section 2.6).

  • Incoming calls cannot be received on Client systems (refer to Section 2.7).

  • Outgoing calls cannot be made (refer to Section 2.8).

  • Calls cannot be relayed by an X.25 Relay system (refer to Section 2.9).

  • A virtual circuit fails, terminating a call (refer to Section 2.10).

  • User application programs fail (refer to Section 2.11).

Each of the referenced sections describes a procedure that enables you to determine the exact nature of the problem, and recommends the action that should be taken to rectify the problem.

2.2. General Procedure

To determine and rectify a problem, adopt the following procedure:

  1. Log in to a suitably privileged account, for example, log in as SYSTEM.

  2. Enable event logging.

    Refer to the VSI DECnet-Plus for OpenVMS Network Management Guide manual for information on how to set up and manage event logging.

  3. Ensure that X.25 for OpenVMS has been started.

  4. Look in the event log for event messages that indicate possible problems and then refer to Section 2.3.

  5. Where relevant, follow the associated reference to the appropriate problem solving section.

  6. Follow the procedure described in the problem solving section to further isolate the cause of the problem, then take whatever action is recommended.

2.3. Event Messages

Table 2.1 contains an alphabetical list of the event messages that can be produced by the X.25 for OpenVMS management entities. Associated with each event message is:

  • An indication of which management module produced the event message

  • A brief description of the event message

  • The action to take to resolve the problem

Some event messages merely inform you of network conditions that do not represent problems; for example, a DTE becoming available. Such event messages therefore do not refer you to a problem solving section.

Some conditions generate a series of related event messages. For example, if the link between a DTE and the PSDN is disabled by a network management command, events will be generated in the event log that indicate the change of link state, the failure of virtual circuits operating over the link, and finally the failure of the DTE.
Table 2.1. Event Messages

Event Message

Generator

Description/Action

Client Connect Failed

X25 SERVER CLIENT

Description: Occurs when an attempt to establish a DECnet connection to the Client system fails. The Nodes argument displays the full name of the Client system. The Application argument displays the application number in the CLIENT entity.

Action: See Section 2.7 for additional problem solving information.

Connection Failed

X25 RELAY CLIENT

Description: Occurs when an attempt to relay an X.25 call fails. The Failure Reason argument specifies whether the connection failed at the incoming or outgoing stage.

Incoming Stage: A Failure Reason argument of Call Accept Failure indicates that the call has been forwarded, and accepted by the called DTE, but the Relay system could not pass the accept back to the calling DTE. The Call Accept Reason argument indicates why the call could not be accepted; the argument takes one of the following values:

  • Insufficient Resources. The Relay system could not allocate enough resources (usually memory) to relay the accept.

  • Cleared By Directive. The X25 ACCESS PORT entity being used to make the outgoing call was cleared before the call could be made.

  • Service Not Available. The X25 ACCESS entity has been disabled.

Action: Use the Call Accept Reason argument (specified above) to determine why the failure occurred.

Outgoing Stage: A Failure Reason of Outgoing Call Failure indicates the Relay system received the call, but could not forward it to the destination DTE. The Outgoing Failure Reason indicates why the call could not be forwarded;the argument takes one of the following values:

  • Insufficient Resources. The Relay system could not allocate enough resources (usually memory) to relay the call. This could also mean that all the X25 ACCESS PORT entities are in use.

  • Cleared By Directive. The X25 ACCESS PORT entity being used to make the outgoing call was cleared before the call could be made.

  • Service Not Available. The X25 ACCESS entity has been disabled.

  • DTE Class Members Not Active. There are no active (enabled) DTEs in the DTE class specified by the Relay Client when making the call.

Action: Refer to Section 2.9.

Connection Lost

X25 RELAY CLIENT
Description: Occurs when a connection that has been successfully established is abnormally terminated. The Reason argument specifies the reason for the loss of connection; it takes one of the following values:

  • Called DTE Clear. An abnormal Clear packet (that is, one with a non–zero cause code) was received from the called DTE. The Cause and Diagnostic fields arguments indicate why the network over which the call was relayed cleared the call.

    Action: Look up the cause and diagnostic codes in a Standards document or PSDN–supplied documentation to determine why the call was cleared. For details of the cause codes and diagnostic codes used in X.25 for OpenVMS, refer to Appendix B and Appendix C respectively.

  • Calling DTE Clear. An abnormal clear (that is, one with a non–zero cause code) was received from the calling DTE. The Cause and Diagnostic arguments indicate why the network over which the call was received cleared the call.

    Action: Look up the Cause and Diagnostic codes in a Standards document or PSDN–supplied documentation to determine why the call was cleared. For details of the cause codes and diagnostic codes used in X.25 for OpenVMS, refer to Appendix B and Appendix C respectively.

  • Network Error. The connection to the Network or to the Relay Client was broken. The Network Error Reason argument indicates why the connection was broken.

    Action: If a Network Error occurred, refer to the Network Error Reasons below and take the recommended action:

    • DTE Not Available. One of the DTEs involved with the call has been disabled.

      Action: Determine which DTE has been disabled and enable it. Refer to Section 2.5.

    • Cleared By Directive. The connection has been cleared by a network management command.

      Action: Reestablish the call.

  • Insufficient Resources. The Relay system ran out of memory.

    Action: Attempt to relay the call at a later time.

  • Service Not Available. The X25 ACCESS entity has been disabled at the Relay system.

    Action: Enable the X25 ACCESS entity.

  • Invalid Parameter. The Relay system has attempted to forward an interrupt containing more than one byte of data to a network that cannot accept more than one byte of interrupt data.

    Action: Restrict interrupt data to 1 byte.

Connection Lost

X25 RELAY PVC

Description: Occurs when a connection that has been successfully established is abnormally terminated. The Reason argument specifies the reason for the loss of the connection.

Action: Refer to each of the error reasons below and take the specified action.

  • DTE Not Available. One of the DTEs involved with the call has been disabled.

    Action: Determine which local DTE has been disabled and enable it. Refer to Section 2.5.

  • Cleared By Directive. The connection has been cleared by a network management command.

    Action: Reestablish the call.

  • Insufficient Resources. The Relay system ran out of memory.

    Action: Attempt to establish the PVC connection at a later time.

  • Service Not Available. The X25 ACCESS entity has been disabled at the Relay system.

    Action: Enable the X25 ACCESS entity.

  • Invalid Parameter. The Relay system has attempted to forward an interrupt containing more than one byte of data to a network that cannot accept more than one byte of interrupt data.

    Action: Restrict interrupt data to one byte.

Diagnostic Packet Received

X25 PROTOCOL DTE

Description: Occurs when the DTE receives a Diagnostic packet from the network.

Action: If the LCN on which the packet is received is non–zero, this event message is an informational message and requires no action.

If the LCN is zero, the PSDN is sending notification of a protocol error. In this case, this event is followed by a Switched Virtual Circuit Failed event; refer to Section 2.10.

DTE Down

X25 PROTOCOL DTE

Description: Occurs when the X25PROTOCOL DTE entity's State status attribute changes from Running to Off, Synchronizing, or Unsynchronized.

Action: Refer to Section 2.5.

DTE Up

X25 PROTOCOL DTE

Description: Occurs when the X25PROTOCOL DTE entity's State status attribute changes to Running from Off, Synchronizing, or Unsynchronized.

Action: This event message is an informational message, and requires no action.

FRMR Received
  • LAPB LINK
  • LLC2 SAP LINK

Description: Occurs when an FRMR (frame reject) frame is received from the remote station. This indicates a link protocol error of some kind, and will cause the DTE to fail, in which case a DTE Down event will be logged.

Action: Refer to Section 2.5.

FRMR Sent
  • LAPB LINK
  • LLC2 SAP LINK

Description: Occurs when the receipt of a frame causes an FRMR (frame reject) frame to be generated and transmitted to the remote station. This indicates a link protocol error of some kind, and will cause the DTE to fail, in which case a DTE Down event will be logged.

Action: Refer to Section 2.5.

Illegal Packet Received

X25 PROTOCOL DTE
Description:Occurs when the DTE receives an illegal packet from the network. This indicates some type of protocol error; the Failure Reason argument explains the nature of the error.
  • If Failure Reason is one of the following:
    • Invalid State
    • Unrecognized
    • Invalid GFI
    • Header Error

the DTE will fail, so the DTE Down event will also be logged.

Action: Refer to Section 2.5.
  • If Failure Reason is one of the following:
    • No Interrupt Sent
    • Too Long
    • Too Short
    • Unacknowledged Interrupt

the virtual circuit will fail, so the Switched Virtual Circuit Failed event will also be logged.

Action: Refer to Section 2.10.

Incoming Call Blocked

X25 ACCESS

Description: Occurs when an incoming call from the X25 Protocol module (or from the X25 Client module in an accessing system) is blocked by the X25 Access module's security mechanisms. The call is cleared by the X25 Access module.

This event may signal an attempted security violation. However, if the calling DTE is one that should actually be permitted to make incoming calls, the event indicates that X.25 security has been set up incorrectly.

Action: Refer to the VSI X.25 for OpenVMS Security Guide for more information.

Incoming Call Failed

X25 ACCESS

Description: Occurs when an incoming call from the X25 Protocol module (or from the X25 Client module in an accessing system) is cleared by the X25 Access module. The reason for the failure is given by the Failure Reason argument.

Action:

Link Halted
  • LAPB LINK
  • LLC2 SAP LINK

Description: Occurs when the status attribute Protocol State of the LAPB LINK or the LLC2 SAP LINK is Halted. This event is followed by the DTE Down event.

Action: Refer to Section 2.5.

Link Initializing
  • LAPB LINK
  • LLC2 SAP LINK

Description:Occurs when the link protocol is attempting to re–initialize. This event is followed by the DTE Down event.

Action: Refer to Section 2.5.

Link Inoperative
  • LAPB LINK
  • LLC2 SAP LINK

Description:Occurs when the status attribute Protocol State of the LAPB LINK or LLC2 SAP LINK is Inoperative. This event is followed by the DTE Down event.

Action: Refer to Section 2.5.

Link Maintenance

LAPB LINK

Description: Occurs when the status attribute Protocol State of the LAPB LINK is Maintenance, indicating that the link has been taken over by MOP. This event is followed by the DTE Down event.

Action: Refer to Section 2.5.

Link Resetting
  • LAPB LINK
  • LLC2 SAP LINK

Description: Occurs when the protocol is being reset.

Action: If the reset causes the DTE to fail, the DTE Down event will also be logged; see Section 2.5. Otherwise, no further action is required.

Link Running
  • LAPB LINK
  • LLC2 SAP LINK

Description: Occurs when the protocol has been successfully initialized and the status attribute Protocol State is Running. This event is followed by a DTE Up event.

Action: This event message is an informational message and requires no action.

Link Setup Failed
  • LAPB LINK
  • LLC2 SAP LINK

Description: Occurs when the protocol has failed to initialize correctly after the maximum number of allowed attempts.

Action: Refer to Section 2.5.

Link State Changed
  • LAPB LINK
  • LLC2 SAP LINK
  • XOT SAP LINK

Description:Occurs when the status attribute Protocol State of the LAPB LINK, LLC2 SAP LINK, or XOT SAP LINK entity changes from Off to On, or vice versa.

Action: If the state change is from On to Off, this event is followed by the DTE Down event; refer to Section 2.5. If the state change is from Off to On, the event message is an informational message only.

Network Initiated Reset

X25 PROTOCOL DTE

Description:Occurs when the DTE receives a Reset packet from the network.

Action: If the DTE fails as a result, the DTE Down event will also be logged; refer to Section 2.5.

Network Initiated Restart

X25 PROTOCOL DTE
Description:

  • Occurs when the DTE receives a Restart packet from the network, indicating that the PSDN has failed and has been restarted. This event may be preceded by a number of LAPB or LLC2 events indicating that the link has been halted and restarted.

    Action: No further action is required.

  • Alternatively, this event may indicate a link protocol error, in which case it is followed by a DTE Down event.

    Action: Refer to Section 2.5 for more information.

Outbound Connect Failed

XOT SAP LINK
Description: Occurs when an attempt to establish an outbound connection with a remote system fails. The event returns the following arguments:Failure Reason, Remote IP Address, Remote Port Number,and, if the Failure Reason argument indicates PWIP Error, PWIP Error Code. The Failure Reason argument indicates why the connection could not be made; the argument takes one of the following values:

  • Remote System Unreachable. The XOT module could not reach the requested remote system.

    Action: Refer to Section 2.5.4.1.

  • Connection Rejected. The XOT module was able to reach the remote system. However, the remote system denied the connection request.

    Action: Refer to Section 2.5.4.2.

  • PWIP Error. During the connection establishment process,the XOT module received an unexpected error from the PATHWORKS Internet Protocol (PWIP) interface it uses.

    Action: Refer to Section 2.5.4.1.

  • No Reason Specified. The XOT module could not establish a connection with the requested remote system. No additional information is available.

    Action: Refer to Section 2.5.4.1.

Outgoing Call Blocked

X25 ACCESS

Description: Occurs when the X25 Access module's security mechanisms prevent a client from making an outgoing call.

This event usually indicates an attempted security violation. However, if the client is one that should actually be permitted to make outgoing calls,the event indicates that X.25 security has been set up incorrectly.

Action: Refer to the VSI X.25 for OpenVMS Security Guide for more information.

Outgoing Call Configuration Error

X25 ACCESS

Description: Occurs when a call fails because X.25 security has been set up incorrectly.

Action: Refer to Section 2.8.

Port Terminated

X25 ACCESS

Description: Occurs when the call has been cleared by the network, by one of the DTEs, or by a network management command.

Action: This event message is an informational message and requires no action unless the call was cleared unexpectedly. If the call was cleared unexpectedly, refer to Section 2.10.

Protocol Error

XOT SAP LINK
Description: Occurs when an error occurs in the XOT protocol during a XOT protocol exchange with the remote system. The event returns the following arguments:Error Reason, Remote IP Address, Remote Port Number, and Received PDU. The Error Reason argument indicates what type of protocol error was detected; the argument takes one of the following values:

  • Invalid XOT Header. The XOT module received a PDU apparently destined for the XOT software, but the XOT header was not valid.

  • Invalid PVC Setup Packet. While attempting to establish a PVC connection with the remote system, the remote system returned an invalid response PDU. This error can also occur if the remote system attempts to establish a PVC connection with the local system and the PVC connection PDU is invalid.

Action: Refer to Section 2.5.4.3.

Protocol Error Detected

X25 PROTOCOL DTE

Description:Occurs when a protocol error is detected. The nature of the protocol error is given by the Failure Reason argument.

Action: Refer to Section 2.5.

PVC Access Blocked

X25 ACCESS

Description: Occurs when a client of the X25 Access module is denied access to a PVC.

This event usually indicates an attempted security violation. However, if the client is one that should actually be allowed access to the PVC, then the event indicates that X.25 security has been set up incorrectly.

Action: See Section 2.6.

PVC Failed

X25 PROTOCOL DTE PVC

Description: Occurs when the PVC fails during the data phase. The reason for the failure is given by the Failure Reason argument.

Action: If Failure Reason is DTE Disabled or Restart, this event will shortly be followed by the DTE Down event – see Section 2.5.

For other values of Failure Reason, see Section 2.10.

Reject Packet Received

X25 PROTOCOL DTE

Description:Occurs when the DTE receives a Reject packet from the network. This event is followed by a Switched Virtual Circuit Failed event.

Action: Refer to Section 2.10.

Retry Failed

X25 PROTOCOL DTE
Description: Occurs when one of the DTE's maximum retry counts has been reached. The Retry argument indicates which type of packet the event refers to:

  • Clear – this event is followed by the Port Terminated event.

    Action: Refer to Section 2.10.

  • Reset – this event is followed by the Switched Virtual Circuit Failed event.

    Action: Refer to Section 2.10.

  • Restart.

    Action: Refer to Section 2.5.

Retry Limit Exceeded

X25 RELAY PVC

Description: Occurs when an attempt to establish a connection between two X.25 protocol PVCs fails. The Local PVC Status and Relayed PVC Status arguments specify the reason for connection failure. If the problem exists with the local PVC, apply the solution to the local link;otherwise, apply the solutions provided to the relayed link.

The PVC status reported may be any one of the following:

  • Insufficient Resources. The Relay system could not allocate enough resources (usually memory) to relay the call. This could also mean that all the X25 ACCESS PORT entities are in use.

    Action: Attempt to establish the PVC connection at a later time.

  • Service Not Available. The X25 ACCESS entity has been disabled.

    Action: Enable the X25 ACCESS entity.

  • No Such PVC. The PVC specified in either the Local PVC or Relayed PVC arguments does not exist.

    Action: Modify the PVC name specified to match that of an X25 PROTOCOL PVC entity or create an X25 PROTOCOL PVC entity of the specified name.

  • PVC Already In Use. The PVC specified already has a client. That is, the X25 PROTOCOL PVC entity is being used by another X.25 relay PVC or by a user application.

SAP State Changed

XOT SAP

Description: Occurs when the specified XOT SAP entity changes state. The message includes a single argument: New SAP State.

Server Connect Rejected

X25 CLIENT

Description:The X25 Client module generates this event when a requested connection to the Connector node is rejected.

Action: Refer to Section 2.8.

Session Control Unavailable

X25 SERVER CLIENT

Description:Occurs when the server cannot contact the local Session Control module. The Module Extent argument displays whether the server detected the Session Control module. The Session Control Port State argument displays the port state returned by the SESSION CONTROL PORT entity if the Module Extent argument indicates that the Session Control module exists.

Action:Determine if the SESSION CONTROL entity's State status attribute has the value On.

Switched Virtual Circuit Failed

X25 PROTOCOL DTE

Description: Occurs when an incoming or outgoing call fails in the setup or data phase. The reason for the failure is given by the Failure Reason argument.

Action:

  • If the event occurs when trying to establish an incoming call on an X.25 for OpenVMS system, refer to Section 2.6.

  • If the event occurs when trying the establish an outgoing call, refer to Section 2.8.

  • If an established call fails with this event, refer to Section 2.10.

2.4. X.25 Fails to Run After System Reboot

Use this section if you cannot run X.25 after you have rebooted the system.

This section assumes that:

  • You have installed, configured and attempted to start X.25.

  • You have enabled event logging at your terminal.

Follow this procedure:

  1. Examine the messages logged at the console.

    Did one of the messages indicate that the X.25 license had not been installed? If YES, then your X.25 license has either expired or been deregistered, the license must be loaded and registered before X.25 can be used. Refer to the VSI DECnet-Plus for OpenVMS Installation and Configuration manual for more information.

    If NO, then--

  2. Contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

2.5. Local DTE Fails

Use this section if the local DTE fails to come up or if there is a problem with the DTE during normal operation.

This section assumes the following:

  • X.25 has loaded and started successfully.

  • You have enabled event logging.

  • You know how to start NCL.

Follow this procedure:
  1. Determine the state of the local DTE. Start NCL and enter the following command:
    ncl> show x25 protocol dte dte-name state
    Is the State attribute set to Off?→ YES See the section called “Note 1”
    • ↓
    • NO
  2. Is the State attribute set to Running?→ YES See the section called “Note 2”
    • ↓
    • NO
  3. Is the State attribute set to Unsynchronized?→ YES See the section called “Note 3”
    • ↓
    • NO

    The DTE state is Synchronizing indicating that a restart is in progress. The DTE should come up soon. If it does not, follow the procedures in Section 2.5.1.

Note 1

The DTE is disabled. To reenable the DTE, enter the following command:
ncl> enable x25 protocol dte dte-name

Note 2

The DTE is enabled and operating normally.

Note 3

If the DTE state is Unsynchronized, there is a problem with the link.

Determine the type of link that the DTE is using by issuing the following command:
ncl> show x25 protocol dte dte-name link service provider

If the link service provider is a LAPB link, refer to Section 2.5.2.

If the link service provider is an LLC2 link, refer to Section 2.5.3.

If the link service provider is a XOT link, refer to Section 2.5.4.

2.5.1. DTE Restart Failure

Use this section if the local DTE fails to come up and the State attribute of the X25 PROTOCOL DTE entity is Synchronizing. This state usually indicates that a restart is in progress. If the DTE fails to come up after a few minutes, it may indicate a problem with the DTE or the link.

The actual time to wait for the DTE to come up is governed by the value of the DTE's restart timer. This value can be obtained by entering the command:
ncl> show x25 protocol dte dte-name restart timer

The value of the restart timer is profile–dependent.

This section assumes that you have completed the procedures in Section 2.5 and waited longer than the timer value for the DTE to come up.
  1. Is the link service provider LAPB? → YES See the section called “Note 1”

Note 1

The link service provider is LAPB. Follow the procedure given in Section 2.5.1.1.

Note 2

The link service provider is LLC2. Follow the procedure given in Section 2.5.1.2.

2.5.1.2. LLC2 Links

Use this section if the DTE is in state Synchronizing, and the DTE's link service provider is an LLC2 link.
  1. Verify that the Profile attribute of the X25 PROTOCOL DTE entity specifies the correct profile; the profile should be ISO8881. Enter the following command:
    ncl> show x25 protocol dte dte-name profile
    Is the Profile attribute set to ISO8881?→ NO See the section called “Note 1”
    • ↓
    • YES
  2. Determine the setting of the Interface Type attribute of the X25 PROTOCOL DTE entity. Enter the following command:
    ncl> show x25 protocol dte dte-name interface type
    Is the Interface Type attribute set to Negotiated?→ NO See the section called “Note 2”
    • ↓
    • YES
  3. Determine the value of the Locally Initiated Restarts counter. Enter the following command and record the value of the counter:
    ncl> show x25 protocol dte dte-name locally initiated restarts

    Wait for a few minutes, then enter the command again and compare the value of the counter with that previously recorded.

    Is the counter incrementing? → NO See the section called “Note 3”
    • ↓
    • YES

    Continue at step 4.

    Note 1

    If the Profile attribute is incorrect delete the existing X25 PROTOCOL DTE entity and recreate it using the correct value for the Profile attribute, that is, ISO8881.

    To perform the specified actions, enter the following commands. Note that for clarity the full set of commands has been divided into a number of logical operations.

    Obtain the values of the Inbound DTE Class, X25 Address, and Link Service Provider attributes:
    ncl> show x25 protocol dte dte-name inbound dte class
ncl> show x25 protocol dte dte-name x25 address
ncl> show x25 protocol dte dte-name link service provider
    Disable and delete the existing X25 PROTOCOL DTE entity:
    ncl> disable x25 protocol dte dte-name
ncl> delete x25 protocol dte dte-name
    Recreate the X25 PROTOCOL DTE entity with the Profile attribute set to ISO8881:
    ncl> create x25 protocol dte dte-name profile ISO8881
    Set the Inbound DTE Class, X25 Address, and Link Service Provider attributes to the values previously obtained:
    ncl> set x25 protocol dte dte-name inbound dte class class-name
ncl> set x25 protocol dte dte-name x25 address address
ncl> set x25 protocol dte dte-name link service provider -
_ncl> llc2 sap sap-name link link-name
    Enable the X25 PROTOCOL DTE entity:
    ncl> enable x25 protocol dte dte-name
    Note 2
    If the Interface Type attribute is not Negotiated, enter the following commands to set it to Negotiated:
    ncl> disable x25 protocol dte dte-name
ncl> set x25 protocol dte dte-name interface type negotiated
ncl> enable x25 protocol dte dte-name
    Note 3

    If the Locally Initiated Restarts counter is not incrementing, verify that DTE is still in state Synchronizing. Refer to Section 2.5. The state of the DTE may have changed since its state was last examined.

    If the DTE is still in state Synchronizing, contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

  4. Verify that the link is operating correctly. Enter the following command to display the name of the LLC2 link:
    ncl> show x25 protocol dte dte-name link service provider
    Now, specify the names of the LLC2 SAP and LINK entities in the following command to obtain information on the counters associated with the link:
    ncl> show llc2 sap sap-name link link-name all counters
    From the information displayed, record the values of the following counters:
    • Times Link Halted
    • Times Link Initializing
    • Times Link Inoperative
    • Times Link Resetting
    • Times Link Running

    Wait for a few minutes, then enter the show llc2 sap ... command again and compare the set of counter values with those previously recorded.

    Are any of the counters incrementing? → YES See the section called “Note 4”
    • ↓
    • NO

  5. Examine the event log for events generated by the X25 PROTOCOL DTE entity. If the events indicate protocol problems, monitor protocol activity on the DTE by using the Common Trace Facility. Refer to the DECnet/OSI for OpenVMS Common Trace Facility Use manual for more information.

    Start CTF and issue the following command to commence protocol tracing at the specified DTE.
    CTF> start "x25l3 dte dte-name" /live

    If the trace output does not highlight the problem, use a line analyzer to look for bad frame sequences. These indicate a hardware or network fault. If you still have problems, contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

Note 4

If any of the counters are incrementing, there is a problem with the LLC2 link. Refer to Section 2.5.3.

2.5.4. XOT–Specific Problems

2.5.4.1. Remote System Cannot Be Reached

Follow this procedure:
  1. Verify that the local X.25 DTE is in the Running state. Enter the following command:
    ncl> show x25 protocol dte dte-name state
    Is the local DTE running? → NO See the section called “Note 1”
    • ↓
    • YES

  2. Verify that the remote TCP/IP system is reachable by using the ping command.

    Is the system reachable? → NO See the section called “Note 2”
    • ↓
    • Capture a TCP/IP trace demonstrating the problem and contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports.

2.5.4.2. Remote System Rejects Connection Attempt

Follow this procedure:

  1. Verify that the remote system is correctly configured to accept XOT connections. The system must support RFC1613 connections. Unless otherwise configured, the system should support these connections using TCP port number 1998.

  2. If the remote system is using a port number other than 1998, verify that the local XOT SAP LINK entity's Remote RFC1613 Port Number attribute is set to the correct port number.

2.5.4.3. Protocol Errors

Capture a TCP/IP trace demonstrating the problem and contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports.

Note 1
Determine the state of the XOT SAP associated with the DTE using the following commands:
ncl> show x25 protocol dte dte-name link service provider
Node node_a X25 Protocol DTE xot-dte-0
AT 2000-02-17-12:47:23.990-05:00I0.273

Characteristics

    Link Service Provider             = XOT SAP sap-0 Link link-0


ncl> show xot sap sap-name state
Follow the appropriate procedure based on the returned value for the State attribute:

  • On. Verify that the XOT SAP LINK entity specified in the DTE's Link Service Provider attribute is correct and that the XOT SAP LINK entity is in the On state. If the link is in the Off state,enable it.

  • Off. Enable the SAP and verify that the its State attribute transitions to On.

  • Connecting to PWIP. Verify that the TCP/IP software has been started and that the PATHWORKS Internet Protocol (PWIP) driver has been started. Once both the TCP/IP and PWIP software are started, the SAP's State attribute should transition to On within about 30 seconds.

Note 2

See the TCP/IP Services for OpenVMS documentation for information about diagnosing reachability problems within a TCP/IP network.

2.6. Incoming Calls Cannot be Received on a Local DTE

Use this section if you cannot receive incoming calls on an X.25 for OpenVMS system. This section assumes that:

  • X.25 for OpenVMS loaded successfully.

  • You know how to start NCL.

  • Event Logging has been enabled.

Follow this procedure:
  1. Determine the state of the DTEs. Start NCL and enter the following command:
    ncl> show x25 protocol dte * state
    Are all the DTE State attributes set to Running? → NO See the section called “Note 1”
    • ↓
    • YES
  2. Verify that the X25 Access module is enabled. Enter the following command:
    ncl> show x25 access state
    Is the State attribute set to Off? → YES See the section called “Note 2”
    • ↓
    • NO
  3. Determine whether the maximum number of virtual circuits allowed on the system has been reached. Enter the following command:
    ncl> show x25 access maximum active ports, active ports

    The maximum number of active ports and the number of active ports are returned.

    Are the two values equal? → YES See the section called “Note 3”
    • ↓
    • NO

    Continue at step 4.

Note 1

If any of the DTEs are not running, follow the procedures in Section 2.5.

Note 2

The X25 Access module is disabled. To enable the module, enter the following command:
ncl> enable x25 access

Note 3

The maximum number of virtual circuits allowed has been reached. This problem can be rectified in two ways:

  • By waiting for an application to release a port once the corresponding X.25 call is cleared.

  • By manually clearing an X.25 call. This can be achieved by clearing the port associated with a specific call:
    ncl> clear x25 access port port-name

    As this approach clears an X.25 call that may be currently in use, it should be used only in extreme circumstances.


  1. Determine whether incoming calls are being rejected by monitoring the value of the Incoming Calls Failed counter. Enter the following command and record the value of the counter:
    ncl> show x25 access incoming calls failed

    Attempt to make another incoming call, then enter the command again and compare the value of the counter with that previously recorded.

    Has the counter increased? → YES See the section called “Note 4”
    • ↓
    • NO
  2. Check that calls are not being blocked by X.25 Security. Enter the following command:
    ncl> show x25 access incoming calls blocked
    Is the value non–zero? → YES See the section called “Note 5”
    • ↓
    • NO
  3. Determine whether calls from the remote DTE are arriving at the local DTE by monitoring the value of the Incoming Calls Connected counter. Enter the following command and record the value of the counter:
    ncl> show x25 protocol dte dte-name incoming calls connected

    Attempt to make another incoming call, then repeat the command and compare the value of the counter with that previously recorded.

    Has the counter increased? → NO See the section called “Note 6”
    • ↓
    • YES

    The calls are reaching the local DTE, but are being cleared immediately. Continue the problem solving procedure at Section 2.10.

Note 4

If the Incoming Calls Failed counter increases when an incoming call is attempted, the node has received a call that it could not process. This indicates a configuration error.

Examine the event log for the Incoming Call Failed event. Follow the indicated procedure for the value returned in the Failure Reason argument:

  • No Filters

    There is an error in the configuration. To create a filter, enter the following command:
    ncl> create x25 access filter filter-name

  • Security Filter Not Found

    There is an error in the configuration. Refer to the VSI X.25 for OpenVMS Security Guide.

  • Security DTE Class Not Found

    There is an error in the configuration. Refer to the VSI X.25 for OpenVMS Security Guide.

  • Insufficient Resources

    Examine the amount of available memory on your system.

If the problem is due to a configuration error, rerun the configuration procedure. For details on configuring X.25 for OpenVMS on OpenVMS I64 and OpenVMS Alpha systems, refer to the VSI X.25 for OpenVMS Configuration manual. For details on configuring X.25 for OpenVMS on OpenVMS VAX systems, refer to the VSI DECnet-Plus for OpenVMS Installation and Configuration manual.

Note 5

Check the security protection on the filter used for the incoming call, and check the access rights of the calling DTE.

See the VSI X.25 for OpenVMS Security Guide for more information about security.

Note 6

If the Incoming Calls Connected counter has not increased while remote DTE shave been trying to connect, the calls are not reaching the local DTE. This may be due to:

  • The remote DTE specifying an incorrect DTE address. Verify that the address being used for the remote DTE is correct.

  • An X.25 Relay system is not relaying the call correctly. If the call was to arrive via an X.25 Relay system, follow the procedures described in Section 2.11.

  • A fault on the PSDN. Contact your PSDN authority.

2.7. Incoming Calls Cannot be Received on Client Systems

Use this section if you cannot receive calls on a Client system. This section assumes that:

  • The Connector system is receiving calls correctly.

  • You have enabled event logging at your terminal.

  • You know how to start NCL.


  1. Check that the Connector system can establish a session connection to the Client system. Start NCL and enter the following command:
    ncl> show node connector-node-id x25 server connection attempts failed
    Is the value greater than zero? → YES See the section called “Note 1”
    • ↓
    • NO
  2. Check that the X25 Server module is running on the Connector system. Enter the following command:
    ncl> show node connector-node-id x25 server state
    Is the State attribute set to On? → NO See the section called “Note 3”
    • ↓
    • YES

    Continue at step 4.

    Note 1

    The X25 Server module on the Connector system cannot establish a connection with the Client system.

    Note 2

    The X25 Server module on the Connector system does not recognize your Client system as one of its clients. This indicates an incorrect configuration at either the Client system or the Connector system.

    For details on using NCL, refer to the VSI X.25 for OpenVMS Management Guide. For details on configuring X.25 for OpenVMS on OpenVMS I64 and OpenVMS Alpha systems, refer to the VSI X.25 for OpenVMS Configuration manual.

    For details on configuring X.25 for OpenVMS on OpenVMS VAX systems, refer to the VSI DECnet-Plus for OpenVMS Installation and Configuration manual.

    Note 3

    The X25 Server module at the Connector system is disabled. To reenable the module, enter the following command:
    ncl> enable node connector-node-id x25 server
  3. Check that the maximum number of allowed session connections at the Connector system has not been reached. Enter the following command:
    ncl> show node connector-node-id x25 server maximum session connections, -
_ncl> active outbound session connections, -
_ncl> active inbound session connections
    Is the sum of active inbound and outbound connections equal to the maximum? → YES See the section called “Note 4”
    • ↓
    • NO
  4. Check that the maximum number of virtual circuits allowed on the Connector system has not been reached. Enter the following command:
    ncl> show node connector-node-id x25 access maximum active ports, active ports
    Are the two values equal? → YES See the section called “Note 5”
    • ↓
    • NO
  5. Check the state of the Client system. Enter the following command:
    ncl> show x25 client state
    Is the Client's State attribute set to On?→ NO See the section called “Note 6”
    • ↓
    • YES
  6. Check that the maximum number of allowed session connections allowed at the Client system has not been exceeded. Enter the following command:
    ncl> show x25 client maximum session connections, -
_ncl> active outbound session connections, -
_ncl> active inbound session connections
    Is the sum of active inbound and outbound sessions equal to the maximum? → YES See the section called “Note 7”
    • ↓
    • NO

    Continue at step 8.

Note 4

You have reached the maximum number of session connections allowed by the X25 Server module at the Connector system.

Wait until one or more of the currently active connections has terminated.

Note 5

You have reached the maximum number of virtual circuits allowed by the Connector system.

Wait until one or more of the currently active virtual circuits becomes free.

Note 6

Enable the Client system. Enter the following command:
ncl> enable x25 client

Note 7

You have reached the maximum number of session connections allowed by the Client system.

Wait until one or more of the currently active connections has terminated.
  1. Check that the maximum number of virtual circuits allowed on the Client system has not been exceeded. Enter the following command:
    ncl> show x25 access maximum active ports, active ports
    Are the two values equal? → YES See the section called “Note 8”
    • ↓
    • NO
  2. Check that calls are not being rejected by the Client system for some reason. Enter the following command:
    ncl> show x25 access incoming calls failed
    Is the displayed value greater than zero? → YES See the section called “Note 9”
    • ↓
    • NO
  3. Check that calls are not being blocked by X.25 Security on the Client system. Enter the following command:
    ncl> show x25 access incoming calls blocked
    Is the value non–zero? → YES See the section called “Note 10”
    • ↓
    • NO

    Contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

Note 8

You have reached the maximum number of virtual circuits allowed by the Client system.

Wait until one or more of the currently active virtual circuits becomes free.

Note 9

If the Incoming Calls Failed counter is greater than zero, the node has received a call that it could not process.

Examine the event log for the Incoming Call Failed event. Follow the indicated procedure for the value returned in the Failure Reason argument:

  • No Filters

    There is an error in the configuration. To create a filter, enter the following command:
    ncl> create x25 access filter filter-name

  • Security Filter Not Found

    There is an error in the configuration. Refer to the VSI X.25 for OpenVMS Security Guide.

  • Security DTE Class Not Found

    There is an error in the configuration. Refer to the VSI X.25 for OpenVMS Security Guide.

  • Insufficient Resources

    Examine the amount of available memory on your system.

If the problem is due to a configuration error, rerun the configuration procedure. For details on configuring X.25 for OpenVMS on OpenVMS I64 and OpenVMS Alpha systems, refer to the VSI X.25 for OpenVMS Configuration manual.

For details on configuring X.25 for OpenVMS on OpenVMS VAX systems, refer to the VSI DECnet-Plus for OpenVMS Installation and Configuration manual.

Note 10

Check the security protection on the filter used for the incoming call, and check the access rights of the calling DTE.

See the VSI X.25 for OpenVMS Security Guide for more information about security.

2.8. Outgoing Calls Cannot be Made on a Local DTE

Use this section if you cannot make outgoing calls.

This section assumes that:

  • X.25 for OpenVMS loaded successfully.

  • You know how to start NCL.

  • Event logging has been enabled.

Follow this procedure:
  1. Determine the state of the DTEs. Start NCL and enter the following command:
    ncl> show x25 protocol dte * state
    Are all the DTE State attributes set to Running? → NO See the section called “Note 1”
    • ↓
    • YES
  2. Verify that the X25 Access module is enabled. Enter the following command:
    ncl> show x25 access state
    Is the State attribute set to Off? → YES See the section called “Note 2”
    • ↓
    • NO
  3. Determine whether the maximum number of virtual circuits allowed on the system has been reached. Enter the following command:
    ncl> show x25 access maximum active ports, active ports

    The maximum number of active ports and the number of active ports are returned.

    Are the two values equal? → YES See the section called “Note 3”
    • ↓
    • NO
  4. Verify that the X25 ACCESS TEMPLATE entity used for the call includes a valid DTE Class attribute value. To display the DTE class defined in the template, enter the following command:
    ncl> show x25 access template template-name dte class
    Determine whether the DTE CLASS entity exists by issuing the following command:
    ncl> show x25 access dte class dte-class-name
    Does the DTE Class exist? → NO See the section called “Note 4”
    • ↓
    • YES

    Continue at step 5.

    Note 1

    If any of the DTEs are not running, follow the procedures in Section 2.5.

    Note 2

    The X25 Access module is disabled. To enable the module, enter the following command:
    ncl> enable x25 access

    Note 3

    The maximum number of virtual circuits allowed has been reached. This problem can be rectified in two ways:

    • By waiting for an application to release a port once the corresponding X.25 call is cleared.

    • By manually clearing an X.25 call. This can be achieved by clearing the port associated with a specific call:
      ncl> clear x25 access port port-name

      As this approach clears an X.25 call that may be currently in use, it should be used only in extreme circumstances.

    Note 4

    If the DTE class does not exist, take one of the following actions:
    • Specify an existing DTE Class for the X25 ACCESS TEMPLATE:
      ncl> set x25 access template template-name -
_ncl> dte class dte-class-name

      where template-name is the name of the template, and dte-class-name is the name of the existing DTE CLASS entity.

    • Create a new DTE CLASS entity:
      ncl> create x25 access dte class dte-class-name type local
      Then specify the DTE class for the X25 ACCESS TEMPLATE:
      ncl> set x25 access template template-name -
_ncl> dte class dte-class-name

      where template-name is the name of the template, and dte-class-name is the name of the created DTE class.

      You will now need to add some DTEs to the DTE class. Refer to the section called “Note 6”.

  5. Determine whether outgoing calls are being rejected by monitoring the values of the Outgoing Call Configuration Errors and Outgoing Calls Blocked counters. Enter the following command and record the value of the counter:
    ncl> show x25 access outgoing call configuration errors, -
_ncl> outgoing calls blocked

    Wait for a few minutes, then enter the command again and compare the value of the counter with that previously recorded.

    Have the counters increased? → YES See the section called “Note 5”
    • ↓
    • NO
  6. Verify that there are usable DTEs in the DTE class. Enter the following command:
    ncl> show x25 access dte class dte-class-name usable dtes

    The display shows the set of DTEs in the specified DTE class that have been enabled.

    Are there any usable DTEs? → NO See the section called “Note 6”
    • ↓
    • YES

    Continue at step 7.

    Note 5

    If the Outgoing Call Configuration Errors counter increases when an outgoing call is attempted, calls are being rejected due to X.25 Security configuration errors. This indicates that X.25 Security has been set up incorrectly for the attempted call. If the Outgoing Calls Blocked counter increases, X.25 Security is configured correctly but particular entity attributes may not have the correct values.

    Change your system's security so that the X25 ACCESS DTE CLASS entity has a valid Security DTE Class attribute value. Verify that the SECURITY DTE CLASS REMOTE DTE entities have the correct values. For details on using NCL, refer to the VSI X.25 for OpenVMS Management Guide.

    For details on configuring X.25 for OpenVMS on OpenVMS I64 and OpenVMS Alpha systems, refer to the VSI X.25 for OpenVMS Configuration manual.

    For details on configuring X.25 for OpenVMS on OpenVMS VAX systems, refer to the VSI DECnet-Plus for OpenVMS Installation and Configuration manual.

    For specific details on setting up security, refer to the VSI X.25 for OpenVMS Security Guide.

    Note 6

    The lack of any usable DTE in the specified DTE class may be due to:

    • DTEs not being specified in the Local DTEs attribute set.

    • DTEs specified in the Local DTEs attribute set, but not being made available for use. This can occur if a DTE is added to the Local DTEs attribute set after the DTE has been enabled.

    To determine the member DTEs of the Local DTEs attribute set, enter the following command:
    ncl> show x25 access dte class dte-class-name local dtes

    From the display, examine the set specified for the Local DTEs attribute.

    If there are no DTEs in the set, add one or more DTEs to the set using the following commands:
    ncl> disable x25 protocol dte local-dte
ncl> add x25 access dte class dte-class-name -
_ncl>  local dte local-dte
ncl> enable x25 protocol dte local-dte

    where dte-class-name is the name of the X25 ACCESS DTE CLASS entity, and local-dte is the X25 PROTOCOL DTE entity you are adding to the Local DTEs set.

    Next, determine the Usable DTEs attribute set by entering the command:
    ncl> show x25 access dte class dte-class-name usable dtes
    If the Local DTEs attribute set contains DTEs, but those DTEs do not appear in the Usable DTEs attribute set, the local DTEs need to be disabled and then re–enabled before they will be included in the set of usable DTEs. This can be achieved using the following commands:
    ncl> disable x25 protocol dte local-dte
ncl> enable x25 protocol dte local-dte
  7. Verify that the X25 ACCESS TEMPLATE for the call includes the correct DTE address for the remote node. Enter the following command:
    ncl> show x25 access template template-name destination dte address
    Is the Destination DTE Address attribute correct? → NO See the section called “Note 7”
    • ↓
    • YES
  8. Invoke CTF by using the following command:
    $ trace
    then issue the following command and attempt to make the outgoing call again:
    CTF> start "x25l3 dte *" /live
    Is the Call Request packet being sent? → NO See the section called “Note 8”
    • ↓
    • YES

  9. The response to the Call Request Packet can be a Clear packet or a Call Confirm packet.

    Is a Clear packet returned? → YES See the section called “Note 9a”
    • ↓
    • NO
    Is a Call Confirm packet returned? → NO See Note the section called “Note 9b”
    • ↓
    • YES

    The call has been accepted.

Note 7

If the destination DTE address is incorrect, enter the following command,specifying the correct DTE address:
ncl> set x25 access template template-name -
_ncl> destination dte address dte-address

where template-name is the name of the X25 ACCESSTEMPLATE entity, and dte-address is the correct address for the DTE.

Note 8

Verify that the correct DTE class was specified in the outgoing call and that the X25 PROTOCOL DTE entity's State attribute is set to Running. If this is the case, there is a problem with the software. Contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

Note 9a

There is a problem with the remote DTE or the network.

From the trace output, obtain the cause and diagnostic codes in the Clear packet. Consult the cause codes and diagnostic codes supplied in the network or called DTE documentation. If you do not have access to this documentation Appendix B and Appendix C may provide you with hints on why the call was cleared.

If the call was cleared by a non-OpenVMS remote DTE or by the network, the clear cause codes and diagnostic codes detailed in Appendix B and Appendix C might not apply. It is therefore recommended that you view your PSDN documentation for details of the cause code displayed. For help in interpreting the cause and diagnostic codes, contact your PSDN authority. These codes can also be found in ISO Standard 8208.

If the cause code from the trace output translates to one of the following PAD cause messages, verify that the X25 ACCESS TEMPLATE entity has the values and settings as specified:

  • Fast select refused

    The Fast Select attribute should be set to No Fast Select or Not Specified.

  • Invalid facility requested

    Amend the specified facility as appropriate.

  • Number not assigned

    Amend the Destination DTE Address attribute to specify a valid DTE address.

  • Reverse charging refused

    The Reverse Charging attribute should be set to False.

Note 9b

It may take some time before the Call Confirm or Clear packet is received. If there is no response to the Clear Request packet within a reasonable period of time, then there is a problem with the network or the remote DTE. Continue problem solving at the remote DTE.

2.9. Calls Cannot Be Relayed

Use this section if a call that is expected by means of an X.25 Relay system never arrives, and it has been determined (by following the procedures in Section 2.6) that the problem is with the X.25 Relay system.

This section assumes that:

  • Event logging on the X.25 Relay system has been enabled.

  • You know how to start NCL.

  • You have followed the procedures of Section 2.6, and suspect that the X.25 Relay system is receiving the call, but not relaying it correctly.

Follow this procedure:
  1. Examine the counters associated with the X25 RELAY CLIENT entity. Enter the following command and record the values of the counters:
    ncl> show x25 relay client client-name all counters

    Repeat this command after a call from the remote DTE fails to reach its destination and compare the values of the counters with the recorded values.

    Has the Connections Made counter increased? → YES See the section called “Note 1a”
    • ↓
    • NO
    Has the Connections Failed counter increased? → YES See the section called “Note 1b”
    • ↓
    • NO
    Has the Connections Lost counter increased? → YES See the section called “Note 1c”
    • ↓
    • NO

    Continue at step 2.

Note 1a

The call is being relayed, but is going to the wrong destination. Enter the command:
ncl> show x25 relay client client-name dte class
Verify that the Relay–Client's DTE Class attribute is correct. The DTE Class attribute should contain the DTE to which the call is to be relayed. Verify that this DTE is the expected destination by issuing the command:
ncl> show x25 access dte class dte-class-name usable dtes

If the DTE class is incorrect, specify the correct DTE class and attempt to relay another call.

Note 1b

The X25 RELAY CLIENT entity will have generated a Connection Failed event; find this event in the event log.

If the Reason argument is Outgoing Call Failure, verify that the template specified by the Relay–Client (or the Defaulttemplate if none is specified) does not contain any parameters that are invalid for the network to which the call is to be relayed. Also, verify that the DTE Class attribute specified for the Relay–Client is correct, then follow the procedures in Section 2.8.

If the Reason argument is Call Accept Failure, the call has been forwarded to the destination, the destination has accepted the call, but the Relay system could not pass the call acceptance back to the original caller. The Call Accept Reason argument indicates why the call acceptance could not be relayed. Refer to the description of the Connection Failed event in Table 2.1 for more information.

Note 1c

The call was abnormally cleared. The Reason argument indicates whether the clear was received by the X.25 Relay system on the original call (Calling DTE Clear) or the relayed call (Called DTE Clear). The Cause and Diagnostic arguments indicate why the call was cleared. Refer to the description of the Connection Lost event in Table 2.1 for more information. Details of the cause codes and diagnostic codes that can be returned are provided in Appendix B and Appendix C respectively.

  1. The call is not reaching the X.25 Relay Client, possibly because the X25 RELAY CLIENT entity is disabled.

    Enter the command:
    ncl> show x25 relay client client-name state
    Is the X.25 RELAY CLIENT entity's State attribute set to Off? → YES See the section called “Note 2”
    • ↓
    • NO
  2. Determine whether the X.25 RELAY CLIENT entity is listening on the correct filters. To display the names of these filters, enter the command:
    ncl> show x25 relay client client-name filters
    Is the Relay–Client listening on the correct filters? → NO See the section called “Note 3”
    • ↓
    • YES
  3. Determine whether the maximum active connections allowed has been reached. Enter the command:
    ncl> show x25 relay maximum active connections
    Compare the value displayed with the number of currently active connections. To determine the number of currently active connections, enter the following command:
    ncl> show x25 relay client * active connections
    Is the total number of active connections equal to the maximum number of connections? → YES See the section called “Note 4”
    • ↓
    • NO

  4. Follow the procedure in Section 2.8 to determine why the outgoing call cannot be made.

Note 2

The X25 RELAY CLIENT entity is disabled. To enable the X25 RELAY CLIENT entity, enter the following command:
ncl> enable x25 relay client client-name

Note 3

The specified X25 RELAY CLIENT entity should be disabled, the required filters added, and the X25 RELAY CLIENT entity then reenabled. These actions can be performed using the following commands:
ncl> disable x25 relay client client-name
ncl> set x25 relay client client-name filters {filter-list}
ncl> enable x25 relay client client-name

Note 4

You can either wait until an existing connection is cleared, or clear an existing connection immediately using NCL. To clear a connection you must determine and clear the ports associated with the connection. Enter the command:
ncl> show x25 access port * all stat, -
_ncl> with client x25 relay client client-name
and select the call that you want to clear. Now enter the command:
ncl> clear x25 access port port-name

2.10. Virtual Circuit Fails

Use this section if a virtual circuit fails after it has been successfully set up.

An event message indicating the reason for the failure will be logged on the X.25 for OpenVMS host that made or accepted the X.25 call. This event is the main source of diagnostic information.

This section assumes that the virtual circuit was successfully established prior to the failure. If the virtual circuit failed during call setup, refer to Sections 2.6 or 2.8 as appropriate.

Follow this procedure:
  1. Examine the event log for one of the following events:

    • Switched Virtual Circuit Failed or PVC Failed

    • Port Terminated

    Does the Port Terminated event appear? → YES See the section called “Note 1a”
    • ↓
    • NO
    Does the Switched Virtual Circuit Failed or PVC Failed event appear? → NO See the section called “Note 1b”
    • ↓
    • YES
  2. The failure reason in the Switched Virtual Circuit Failed event and PVC Failed event identifies where the error has occurred:

    • Level 2 Failure indicates that LAPB, LLC2, XOT failed.

    • Restart Received indicates that X25 Protocol DTE failed.

    Did the virtual circuit fail because of an X25 Protocol DTE, LLC2 link, LAPB link, or XOT link failure? → YES See the section called “Note 2”
    • ↓
    • NO
  3. Determine whether the underlying X25 PROTOCOL DTE entity was disabled. Enter the command:
    ncl> show x25 protocol dte dte-name state

    If the DTE has been disabled, the Failure Reason in the Switched Virtual Circuit Failed event will be DTE Disabled and the state will be Off.

    Has the X25 PROTOCOL DTE entity been disabled? → YES See the section called “Note 3”
    • ↓
    • NO

    Continue at step 4.

    Note 1a

    The call has been cleared by the network, by one of the DTEs, or by a network management command. This is considered by the X.25 for OpenVMS software to be normal termination of the virtual circuit so no Switched Virtual Circuit Failed event is logged.

    The cause and diagnostic codes from the Clear packet are included in the Port Terminated event log message.

    The cause and diagnostic codes are defined in CCITT Recommendation X.25 and in ISO Standard 8208, however the remote DTE is not constrained to using these definitions. Therefore you should also consult the manual for the software being used at the remote DTE to determine the meaning of these codes. The cause codes and diagnostic codes used by X.25 for OpenVMS are provided in Appendix B and Appendix C respectively.

    Note 1b

    Ensure that event logging has been enabled. If event logging is not enabled,enable it and then attempt to reproduce the original problem.

    Note 2

    There is an error in the underlying X25 Protocol DTE, LAPB link, LLC2 link, or XOT link. This may be a transitory error.

    If the failure was caused by a LAPB link error, enter the following commands:
    ncl> show lapb link link-name protocol state
ncl> show x25 protocol dte dte-name state
    If the failure was caused by a LLC2 link error, enter the following commands:
    ncl> show llc2 sap sap-name link link-name protocol state
ncl> show x25 protocol dte dte-name state

    If the failure was caused by a XOT link error, refer to Section 2.5.4.

    If both the link (LLC2 or LAPB) and DTE are in Running state then the problem was transitory and has corrected itself.

    If the LAPB link or the LLC2 link is not in Running state then follow the problem solving procedures in Section 2.5.2 and Section 2.5.3 respectively.

    If the X.25 DTE is in Synchronizing state then follow the problem solving procedures in Section 2.5.1.

    Note 3

    Determine why the DTE has been disabled and then re–enable it.

  4. As the DTE and link (LAPB, LLC2, or XOT) did not cause the error, the call must have been cleared for a reason specific to this virtual circuit.

    If the X.25 network cleared the call, the Failure Reason on the Switched Virtual Circuit Failed event will be Network Clear and the cause and diagnostic codes in the Clear packet will indicate the exact reason for the call clear.

    Was the call cleared by the network? → YES See the section called “Note 4”
    • ↓
    • NO

  5. Another possible reason for the failure is that a protocol error has occurred. If this is the case, the Failure Reason on the Switched Virtual Circuit Failed event will be Protocol Error.

    Was the call cleared because of a protocol error? → YES See the section called “Note 5”
    • ↓
    • NO
  6. If the Failure Reason on the Switched Virtual Circuit Failed event was one of the reasons listed below, then the call has failed during the call setup phase.

    • Call Timeout

    • Local Reject

    • No Taker

    • Call Cleared

    • Remote Reject

    • Call Collision

    • No Resources

    • Security

    • Invalid CUG Details

    Was the call cleared during call setup? → YES See the section called “Note 6”
    • ↓
    • NO

    An unexpected Failure Reason has occurred. Contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

Note 4

The Cause and Diagnostic fields in the Switched Virtual Circuit Failed event provide more information about why the network cleared the virtual circuit.

The cause and diagnostic codes can be found in the CCITT X.25 Standard or in ISO Standard 8208; they also may be described in your PSDN supplied documentation. If you don't have these documents, the explanations given in Appendix B and Appendix C might be helpful.

The error may be transient in nature so attempt to set up the virtual circuit again.

Note 5

The Cause and Diagnostic fields in the Switched Virtual Circuit Failed event provide more information about why the protocol error occurred. Examine these fields to determine why the protocol error occurred.

The cause code identifies whether the call was cleared locally or by the network:

  • A cause code in the range 1 to 127 indicates that the call was cleared by the network.

  • A cause code outside the range 1 to 127 indicates that the call was cleared locally. In this case, a diagnostic code is also provided. Appendix C explains each of the possible diagnostic codes.

Note that the error may be transient in nature so attempt to set up the virtual circuit again.

Note 6

Follow the error correction procedure described in Section 2.8.

2.11. User Application Programs Fail

This section contains information to help you diagnose problems when your application program fails.

Note that this section concerns only problems with the application program itself. If incoming calls are failing to reach your application, ensure that the call is reaching the system hosting the application.

  • If the application is on a Direct Connect system or the application is on a Client system and the call is not reaching the Connector node, refer to Section 2.6 for details on how to rectify the problem.

  • If the application is on a Client systems and the call is reaching the Connector node, refer to Section 2.7 for details on how to rectify the problem.

This section assumes that:

  • The Configuration Test Program has been run successfully.

  • Event logging is enabled at the terminal.


  1. Issue the DCL command:
    $ SHOW PROCESS/PRIVILEGES
    Does the process possess the appropriate rights identifiers and privileges? → NO See the section called “Note 1”
    • ↓
    • YES
  2. Does the process go into the MWAIT state? → YES See the section called “Note 2”
    • ↓
    • NO
  3. Is the network process using associated mailboxes? → YES See the section called “Note 3”
    • ↓
    • NO
  4. Does the process go into the RWMBX state, or appear to hang? → YES See the section called “Note 4”
    • ↓
    • NO
  5. Does the application exit with an unexpected QIO return status? → YES See the section called “Note 5”
    • ↓
    • NO

  6. Examine the application for programming errors. If you fail to find a problem with the application, contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

Note 1

Refer to the X.25 for OpenVMS Programming information on the privileges and rights identifiers necessary to perform specific X.25 operations. For general information on privileges and rights identifiers, refer to the VSI X.25 for OpenVMS Security Guide.

Note 2

Refer to the X.25 for OpenVMS Programming for details of the system resources you require. Verify that the account the process is running under possesses sufficient system resources (quotas) to handle all possible calls.

Use the OpenVMS AUTHORIZE utility to look for processes that run LOGINOUT.EXE.For detached processes examine the OpenVMS SYSGEN parameters using the SYSGEN utility's SHOW/PQL command. For details of the SHOW/PQL command, refer to the OpenVMS System Management Utilities Reference Manual.

Note 3

Ensure there is a mailbox created to handle out–of–band events. This mailbox must be large enough to handle several messages (each message may be up to several hundred bytes). For more information on mailboxes, refer to the X.25 for OpenVMS Programming.

Note 4

Ensure that the application always has an asynchronous read posted on the mailbox. The AST routine for this read should always empty the mailbox before completing. Refer to the X.25 for OpenVMS Programming for further information on mailboxes.

Note 5

Ensure that the application is checking the status value returned in the IOSB(For details of IOSBs, refer to the X.25 for OpenVMS Programming Reference manual).

VSI recommends that applications should identify whether events reported through the mailbox were generated by the remote DTE or by the PSDN. Ensure that the mailbox which handles routines can handle all possible mailbox types. Refer to the X.25 for OpenVMS Programming for further information on mailboxes.

2.12. Poor Datalink Performance on PBXDP–Ax Cards

The X.25 software takes no notice of the Ring Indicator (RI) signal;however, the RI signal can affect X.25 (and WANDD)operation with PBXDP-Ax boards. The PBXDP-Ax series of boards are wired so that RI transitions also cause a transition on Data Carrier Detect (DCD). If the corresponding modem connect line uses "full" modem control, this DCD transition may cause the loss of one or more incoming frames. The normal datalink protocol error recovery mechanisms recover from the frame loss by retransmitting the lost frames; however, the result is suboptimal performance due to the retransmissions. The frame is discarded by the modem connect module, because the DCD transition is seen as a loss of communication between the local and remote modems.

A DCD transition due to an RI transition shows itself through software in a number of ways:

  • A datalink trace shows a Line Up event without a preceding Line Down event. If the trace indicates lost frames before the Line Up event, then it is possible (but not certain) that the lost frames were discarded due to a DCD state transition.

  • A modem connect trace shows a modem connect line state transition from FDPX_BOTH (Full Duplex line, both receive and transmit enabled) to FDPX_TRANSMIT (transmit only enabled) on the "asserted to unasserted" transition of DCD, and a modem connect line state transition from FDPX_TRANSMIT to FDPX_BOTH on the "unasserted to asserted" transition of DCD. Any frames received while the modem connect line is in the FDPX_TRANSMIT state are quietly discarded (and do not appear in the trace).

Customers should ensure that the Ring Indicator signal on all PBXDP-Ax interfaces remains stable. Wiring RI to Signal Ground is one way of accomplishing this.

Chapter 3. X.29 and PAD Problems

3.1. Introduction

This chapter describes how to analyze and correct X.29 and PAD problems:

  1. Find the appropriate problem solving section.

  2. Follow the procedure described in the problem solving section to further isolate the cause of the problem, then take whatever action is recommended.

The problems covered in this chapter fall into the following categories:

  • SET HOST/X29 does not work (refer to Section 3.2).

  • An established outgoing X.29 call clears unexpectedly (refer to Section 3.3).

  • An incoming call to an X.29 application fails to connect (refer to Section 3.4).

  • An established incoming X.29 call clears unexpectedly (refer to Section 3.5).

3.2. SET HOST/X29 Does Not Work

Use this section if you have problems establishing an outbound X.29 call.

This section assumes that:

  • X.25 for OpenVMS has loaded and started successfully.

  • Your configuration of X.25 for OpenVMS matches the PSDN subscription.

  • You have enabled event logging at your terminal.

  • You know how to start NCL.


  1. Enter the following command:
    $ SET HOST/X29 dte-class.dte-address
    Does the command give a DCL error? → YES See the section called “Note 1”
    • ↓
    • NO
  2. Is the message
    %PAD-E-PSINOTLD, P.S.I. not loaded
    displayed? → YES See the section called “Note 2”
    • ↓
    • NO
  3. Are the messages
    %PAD-F-NWERROR, unexpected error on remote terminal link
%SYSTEM-F-NOPRIV, no privilege for attempted operation
    displayed? → YES See the section called “Note 3”
    • ↓
    • NO
  4. Is the message
    %PAD-E-NOLINES, no lines available for the call
    displayed? → YES See the section called “Note 4”
    • ↓
    • NO

    Continue at step 5.

    Note 1

    Ensure that you have entered the correct command. Refer to Chapters 3 and 4 of the X.25 for OpenVMS Utilities for descriptions of the SET HOST/X29 qualifiers.

    Note 2

    Start X.25 for OpenVMS on the local node, by running the command procedure SYS$STARTUP:X25$STARTUP.COM (OpenVMS I64 or OpenVMS Alpha systems) or SYS$STARTUP:PSI$STARTUP.COM (OpenVMS VAX systems).

    Note 3

    X.25 Security is preventing you making outgoing X.29 calls to the remote DTE. Refer to the VSI X.25 for OpenVMS Security Guide.

    Note 4

    If you have specified a DTE class, check that the DTE class is correct.

    If you have used the /LOCAL_DTE qualifier, check that you have specified the local DTE address correctly. Try the command without the /LOCAL_DTE. If this works, the local DTE address was incorrect.

    If the DTE class is of type REMOTE, refer to Section 2.5.

    If the DTE class is of type LOCAL, refer to Section 2.8.

  5. Does the call clear unexpectedly? → YES See the section called “Note 5”
    • ↓
    • NO
  6. Is the message
    %PAD-I-COM, call connected
    displayed? → NO See the section called “Note 6”
    • ↓
    • YES
  7. Do you obtain any response from the remote DTE? → NO See the section called “Note 7”
    • ↓
    • YES

    Continue at step 8.

    Note 5

    Secondary error messages give the reasons for clearing the call.

    If cause and diagnostic codes are displayed, refer to the technical documentation supplied by your PSDN for an explanation of these codes. For details of the cause codes and diagnostic codes used in X.25 for OpenVMS, refer to Appendix B and Appendix C respectively.

    Note 6

    Other PAD messages may be produced when you attempt to start a PAD session. Refer to the X.25 for OpenVMS Utilities for details of what action to take on receiving these messages.

    Note 7

    1. Make sure PAD parameter 8 (DISCARD_OUTPUT) is set to zero.

      To display this parameter, press Ctrl/P to enter PAD command mode, then at the PAD prompt, enter:
      PAD> SHOW PARAMETERS 8

      If the value of this parameter isn't zero, refer to the X.25 for OpenVMS Utilities for details of how to change the value of PAD parameters.

    2. Make sure the remote application can process your call. If the remote system is running X.25 for OpenVMS, you can refer to one of the following sections for details of how to solve problems with the remote system:

      • Section 2.5, for incoming calls that fail on a local DTE.

      • Section 2.7, for incoming calls that fail on a Client system.

      • Sections 3.4 and 3.5, for incoming X.29 calls that fail.

    3. Make sure your terminal is compatible with the remote application, by ensuring that the remote application can:

      • Process your character set.

        Pay particular attention to the “eighth bit”. 8–bit terminals must be set up in 7–bit mode if the remote system is to use the eighth bit for parity.

      • Recognize and support your type of terminal.

      • Support X.29 terminals.

  8. Do you obtain the expected response from the remote DTE? → NO See the section called “Note 8”
    • ↓
    • YES

  9. Determine whether you can send data by logging onto the remote machine and entering an interactive command (for example, DIRECTORY).

    Is the command successful? → NO See the section called “Note 9”
    • ↓
    • YES
  10. Does the X.29 terminal echo the data? → YES See the section called “Note 10”
    • ↓
    • NO
  11. Examine PAD parameter 2. To display this parameter, press Ctrl/P to enter PAD command mode, then at the PAD prompt, enter:
    PAD> SHOW PARAMETERS 2
    Is PAD parameter 2 set to 1? → NO See the section called “Note 11”
    • ↓
    • YES

  12. You should now be able to use the PAD successfully. If you still have problems, contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

Note 8

Make sure the PAD is configured to send data, by ensuring parameters 2 (ECHO), 3 (FORWARDING_CHARACTERS), 4 (TIMEOUT), and 8 (DISCARD_OUTPUT) are all set correctly.

To display these parameters, press Ctrl/P to enter PAD command mode, then at the PAD prompt, enter:
PAD> SHOW PARAMETERS

Refer to the X.25 for OpenVMS Utilities for details on how to display and change PAD parameters. In addition, ensure that your terminal and the application are compatible as in Note 7.

Note 9

Make sure the remote application is ready to receive data from an X.29 terminal. Refer to Sections 3.4 and 3.5 if necessary.

Note 10

You should now be able to use the PAD successfully. If you still have problems, contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

Note 11

Set PAD parameter 2 (ECHO) to 1. Refer to the X.25 for OpenVMS Utilities for information on how to change this parameter.

3.3. An Established Outgoing X.29 Call Clears Unexpectedly

Use this section if an established outgoing X.29 call clears unexpectedly.

This section assumes that:

  • X.25 for OpenVMS has loaded and started successfully.

  • Your configuration of X.25 for OpenVMS matches the PSDN subscription.

  • You have enabled event logging at your terminal.

  • You know how to start NCL.


  1. Does the call clear unexpectedly? → YES See the section called “Note 1”
    • ↓
    • NO
  2. Is the message
    %PAD-E-CLR_DTE, call cleared by remote DTE
    displayed? → YES See the section called “Note 2”
    • ↓
    • NO
  3. Is the message
    %PAD-E-CLR_ER, call cleared by network – local procedure error
    displayed? → YES See the section called “Note 3”
    • ↓
    • NO
  4. Is the message
    %PAD-E-CLR_INV, call cleared by network, invalid facility was requested
    displayed? → YES See the section called “Note 4”
    • ↓
    • NO

    Continue at step 5.

    Note 1

    Secondary error messages give the reasons for clearing the call.

    If cause and diagnostic codes are displayed, refer to the technical documentation supplied by your PSDN for an explanation of these codes. For details of the cause codes and diagnostic codes used in X.25 for OpenVMS, refer to Appendix B and Appendix C respectively.

    Note 2

    The remote DTE cleared the call. Verify that the remote system can receive X.29 calls at this time and that all the required information was provided in the call, for example USER data. For details of information that a call should provide, refer to the X.25 for OpenVMS Utilities. If the remote system is running X.25 for OpenVMS, refer to Sections 3.4 and 3.5 to solve the problem.

    Note 3

    The DTE being used may be wrongly configured for the PSDN. Compare the DTE parameters against the PSDN subscription and change them if necessary. Refer to the VSI X.25 for OpenVMS Management Guide for details of how to change DTE parameters.

    Note 4

    The problem is likely to be an error in the /FACILITIES qualifier or in the TEMPLATE entity.

    If any of the qualifiers /FACILITIES, /PACKET_SIZE, /WINDOW_SIZE, /CLOSED_USER_GROUP, /FAST_SELECT, /REVERSE_CHARGING were used,compare their use against the PSDN subscription.

    If no qualifiers were used, compare the values of the X29Login template attributes (OpenVMS I64 or OpenVMS Alpha or Default template attributes (OpenVMS VAX) against the PSDN subscription.

  5. Is the message
    %PAD-E-CLR_RPE, call cleared by network – remote procedure error
    displayed → YES See the section called “Note 5”
    • ↓
    • NO
  6. Is the message 
    %PAD-E-TIMEOUT, timeout on response from network
    displayed? → YES See the section called “Note 6”
    • ↓
    • NO
  7. Is the message 
    %PAD-I-COM, call connected
    displayed? → NO See the section called “Note 7”
    • ↓
    • YES

    The PAD has made a call, but the call could still be cleared by one of the above errors.

Note 5

The remote system may be wrongly configured. If the remote system is running X.25 for OpenVMS, verify the installation on the remote system, using the Configuration Test Program (CTP).

For details on using the CTP on OpenVMS I64 and OpenVMS Alpha systems, refer to the VSI X.25 for OpenVMS Configuration manual.

For details on using the CTP on OpenVMS VAX systems, refer to the VSI DECnet-Plus for OpenVMS Installation and Configuration manual.

Note 6

Your call timed out. The DTE may be wrongly configured for the PSDN, or there may be a PSDN problem.

Use the Configuration Test Program to see if the X.25 system is correctly configured for the PSDN. Examine the DTE parameters and change them if necessary. Refer to the VSI X.25 for OpenVMS Management Guide for details on how to change DTE parameters. If the PSDN is the problem, get in touch with the PSDN authority.

Note 7

Other PAD messages may be produced when you attempt to start a PAD session. Refer to the X.25 for OpenVMS Utilities for details of these messages, and what action to take on receiving them.

3.4. An Incoming Call to an X.29 Application Fails to Connect

Use this section if an X.29 application fails to receive an incoming connection request.

This section assumes that:

  • X.25 for OpenVMS has loaded and started successfully.

  • Your configuration of X.25 for OpenVMS matches the PSDN subscription.

  • You have enabled event logging on your terminal.

  • You know how to start NCL.

Note that APPLICATION entities exist on an X.25 Client and Direct Connect systems, but not on Connector systems. An APPLICATION entity delivers a call to an OpenVMS application.

Follow this procedure:
  1. Determine whether the APPLICATION entity is enabled. Enter the following command:
    ncl> show x25 access application application-name state
    Is the State attribute set to On? → NO See the section called “Note 1”
    • ↓
    • YES
  2. For an X.25 application, verify that the File and User attributes are correct. Enter the following command:
    ncl> show x25 access application application-name file, user
    Is the information correct? → NO See the section called “Note 2”
    • ↓
    • YES

  3. Determine whether another application has taken the call. Disable all the applications except the one you want to test.

    Is the call delivered to the application? → NO See the section called “Note 3”
    • ↓
    • YES

    The call was being taken by another application.

Note 1

Enable the application. Enter the following command:
ncl> enable x25 access application application-name

Note 2

Correct the File and User attributes of the APPLICATION entity. Enter the following command:
ncl> set x25 access application application-name -
_ncl> file file-name, user user-name

Note 3

If the system is a Direct Connect system, refer to Section 2.6.

If the system is a Client system, see Section 2.7.

3.5. An Established Incoming X.29 Call Clears Unexpectedly

Use this section if an established X.29 call on a host system suddenly clears.

This section assumes that:

  • X.25 for OpenVMS has loaded and started successfully.

  • Your configuration of X.25 for OpenVMS matches the PSDN subscription.

  • You have enabled event logging at your terminal.

  • The incoming X.29 call has been established; but subsequently clears unexpectedly. If the incoming call cannot be established,refer to Section 3.4.


  1. Has the X.29 user received any response from the PAD? → NO See the section called “Note 1”
    • ↓
    • YES
  2. Has the X.29 user received CLR (call cleared) DER (remote DTE out of order)? → YES See the section called “Note 2”
    • ↓
    • NO
  3. Has the X.29 user received CLR (call cleared) RPE (remote procedure error)? → YES See the section called “Note 3”
    • ↓
    • NO
  4. Has the X.29 user received CLR (call cleared) PAD (invitation to clear) or CLR (call cleared) DTE (remote DTE)? → YES See the section called “Note 4”
    • ↓
    • NO
  5. Has the X.29 user received any other CLR (call cleared) message? → YES See the section called “Note 5”
    • ↓
    • NO

    Continue at step 6.

    Note 1

    If the incoming call is a SET TERMINAL/X29 session from an X.25 for OpenVMS system and the terminal has successfully connected to the host–based PAD, press Ctrl/P to enter PAD command mode, then at the PAD prompt, enter the following command:
    PAD> SHOW ALL

    This shows the status of the PAD. Refer to the X.25 for OpenVMS Utilities for information on interpreting the output.

    Note 2

    Ensure that the DTE that the remote X.29 user is trying to call is working. Refer to the problem solving information in Section 2.4.

    Note 3

    The DTE being used may be wrongly configured for the PSDN. Ensure that the DTEs have been correctly configured. For details on using NCL, refer to the VSI X.25 for OpenVMS Management Guide.

    For details on configuring X.25 for OpenVMS on OpenVMS I64 and OpenVMS Alpha systems, refer to the VSI X.25 for OpenVMS Configuration manual.

    For details on configuring X.25 for OpenVMS on OpenVMS VAX systems, refer to the VSI DECnet-Plus for OpenVMS Installation and Configuration manual.

    Note 4

    This indicates a problem with either the application program or the X.25 for OpenVMS configuration. The X.29 software terminated the call, under a command from the application. Refer to Section 2.11 for details of verifying the user application.

    Note 5

    This is a problem with either the PSDN or the remote DTE.

    Examine the cause and diagnostic codes reported by the PAD, or obtained from tracing with the X29 tracepoint or event logging. If there is a non–zero cause code, there is a problem with the PSDN you are using. Report the problem, including the cause and diagnostic codes, to the relevant PSDN authority.

    If there is a cause code of zero, the problem is with the remote DTE. Contact the system manager for the remote DTE.

  6. Are there any other messages from the PAD? → YES See the section called “Note 6”
    • ↓
    • NO
  7. Enter the DCL command:
    $ SHOW MEMORY/POOL/FULL

    In the display, look at the nonpaged dynamic pool. Refer to the installation manual for details of how much memory you require,and compare this with the display.

    Is there sufficient memory in the nonpaged pool areas? → NO See the section called “Note 7”
    • ↓
    • YES

  8. Use X.25 Accounting to determine the exit status of your process. For details of X.25 Accounting, refer to the X.25 for OpenVMS Accounting manual.

    Does the accounting information indicate the cause of the problem? → YES See the section called “Note 8”
    • ↓
    • NO

  9. Use the Common Trace Facility (CTF) to obtain information on the protocol messages exchanged, by specifying “X29” as the tracepoint. Refer to the DECnet/OSI for OpenVMS Common Trace Facility Use manual for details of how to use CTF. If the trace information does not reveal the problem, contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. For details on how to submit an X.25 for OpenVMS problem, see Appendix D.

Note 6

If you receive any other PAD error messages at the remote X.29 terminal, refer to the technical documentation supplied by your PSDN authority or PAD supplier.

Note 7

Refer to the OpenVMS system documentation for details on tuning your system.

Note 8

Take the appropriate action, as specified in the OpenVMS System Messages and Recovery Procedures Reference Manual.

Appendix A. Loopback Testing

This Appendix describes how to use loopback tests to check the physical link between a DTE and a PSDN.

In a loopback test, the receive and transmit channels of a communications link are connected together at some point. Data is then sent over the link and received back at the point of transmission. When the data is received, it is compared with the data that was sent. If there is a fault on the link, there will be a discrepancy between the returned data and the original data. By varying the point at which the receive and transmit channels are connected, you can isolate the section of the link that is at fault.

Section A.1 describes how to perform loopback tests on the Modem Connect Line.

A.1. Testing the Modem Connect Line

It is possible to place the Modem Connect Line into one or more of the following loopback modes:

  • driver – data is looped within the communication device's driver.

  • device – data is looped within the communications device.

  • connector – data is looped through a passive loopback connector attached to the communications device, which supplies the clock. (Note that the built-in synchronous communications controller (SCC) does not have internal clocking, and so does not support this mode.)

  • local – data is looped through a local modem by asserting the Local Loopback interchange circuit (CCITT 141). This loopback facility is available only if the local modem supports it.

  • remote – data is looped through a remote modem by asserting the Loopback/Maintenance Test interchange circuit (CCITT 140). This loopback facility is available only if both the local and remote modems support it.

  • external – data is looped through a local or remote modem that has been manually set into loopback mode by setting a modem switch.

The subsections that follow provide additional information about the driver, device, local, and remote loopback modes.

Driver Loopback Test

The driver loopback test, shown in Figure A.1, verifies that the driver has been correctly configured into the OpenVMS system, and that it is accessible by means of its software interface.

Figure A.1. Driver Loopback Test
Driver Loopback Test

Device Loopback Test

The device loopback test, shown in Figure A.2 determines whether the driver can communicate with the device itself by means of the device registers and interrupts.

Figure A.2. Device Loopback Test
Device Loopback Test

Local Loopback Test

The local loopback test, shown in Figure A.3, verifies that the device is capable of transmitting and receiving data. The test also confirms that the hardware from the host to the modem (that is the device and cable) is operational.

Figure A.3. Local Loopback Test
Local Loopback Test

Automatic switching of the modem into local loopback requires that both the modem and the device support circuit CCITT 141, Local Loopback Request. If this is not the case, then manual intervention is required. Refer to the documentation accompanying the device for a description of the supported circuits for each device.

This test will fail if no cable is available, or if the modem is not capable of being looped back under the modem control. If the test fails, you should insert a loopback connector and perform a connector loopback test.

Remote Loopback Test

The remote loopback test, shown in Figure A.4, determines whether communications exist between the local and the remote modem.

Figure A.4. Remote Loopback Test
Remote Loopback Test

Automatic switching of the modem into remote loopback requires that both the modem and device support circuit CCITT 140, Remote Loopback. If this is not the case, then manual intervention is required. Refer to the documentation accompanying the device for a description of the supported circuits for each device.

This test will fail if no cable is available, or if the modem is not capable of being looped back under the modem control. If the test fails, you should either insert a loopback connector and perform a connector loopback test or manually switch the remote modem into loopback mode and perform an external loopback test.

A.1.1. Preparing the Line for Loopback Testing

Before testing the Modem Connect Line, it is necessary to disable the LAPB LINK entity that is using the line. In order to determine which LAPB LINK entity is using the Modem Connect Line, enter the following command: 
ncl> show lapb link * physical line
To disable the LAPB LINK entity that is using the line, enter the following command:
ncl> disable lapb link link-name

It should now be possible to loop data to test the Modem Connect Line.

A.1.2. Performing the Loopback Test (OpenVMS I64 and OpenVMS Alpha)

To test the line on an OpenVMS I64 or OpenVMS Alpha system, enter the following command:
$ @sys$startup:x25$loopline line-name mode

If the particular loopback mode is supported by the synchronous hardware and modems and the system is operating correctly, there should be no failures reported from the script. If failures are reported, try a different loopback mode, in order to determine where the problem is occurring.

A.1.3. Performing the Loopback Test (OpenVMS VAX)

To test the line on an OpenVMS VAX system, you must enter a series of NCL commands similar tothe commands in the X25$LOOPLINE.COM file (see Section A.1.5). This file is not supplied with X.25 for OpenVMS VAX.

A.1.4. Returning the Line to Active Service

When loopback testing has been completed, return the system to its previous state with the LAPB link using the Modem Connect Line,by issuing the command:
ncl> enable lapb link link-name

A.1.5. X25$LOOPLINE.COM Source Listing

The following is a modified version of the X25$LOOPLINE.COM file supplied on OpenVMS I64 and OpenVMS Alpha systems. (If you want to see more NCL output, omit the DEFINE/USER commands).
$!++
$! ARGUMENTS:
$!
$! P1 - Modem Connect Line which is to be loopback tested
$! the line must not have any other clients (i.e. users
$! of the line must have been disabled) (instance name only,
$! (i.e., PBXDD-0-1, dte-0)
$!
$! P2 - Loopback mode (e.g. driver, device, connector,
$! local, remote, external)
$!--
$!
$!
$! setup any logical/symbols that we need
$!
$ ncl = "$sys$system:NCL"
$!
$! Set the Modem Connect Line into the appropriate loopback mode
$!
$ define/user sys$output nl:
$ define/user sys$error nl:
$ ncl startloop modem connect line 'P1' mode 'P2'
$!
$! startup MOP if we need to
$!
$ define/user sys$output nl:
$ define/user sys$error nl:
$ show process net$mop
$ if $severity .ne. 1
$ then
$ @sys$system:startup network mop
$ started_mop = 1
$ else
$ started_mop = 0
$ endif
$!
$! Create and enable the HDLC entities which we will use to test the Modem Connect
$! Line.
$!
$ define/user sys$output nl:
$ define/user sys$error nl:
$ ncl
create hdlc
create hdlc link loop
create hdlc link loop logical station loop
exit
$ define/user sys$output nl:
$ define/user sys$error nl:
$ ncl set hdlc link loop physical line modem connect line ’P1’
$ define/user sys$output nl:
$ define/user sys$error nl:
$ ncl
! In case we are running over an SCC restrict the packet size
set hdlc link loop maximum data size 1018, pref maximum data size 1018
enable hdlc link loop
enable hdlc link loop logical station loop
exit
$!
$! Create and enable MOP entities used for testing the line
$!
$ define/user sys$output nl:
$ define/user sys$error nl:
$ ncl
create mop circuit loop type = hdlc
set mop circuit loop link name = hdlc link loop logical station loop
enable mop circuit loop func = { loop requester }
create mop client test
set mop client test circuit = loop, address = {00-11-22-33-44-55}
exit
$!
$! Perform the loopback tests
$!
$ set verify
$ ncl loop mop client test length=1, count=100
$ ncl loop mop client test length=571, count=1
$ set noverify
$!
$! Delete all created HDLC and MOP entities created for the line test
$!
$ define/user sys$output nl:
$ define/user sys$error nl:
$ ncl
delete mop client test
disable mop circuit loop
delete mop circuit loop
disable hdlc link loop logical station loop
disable hdlc link loop
delete hdlc link loop logical station loop
delete hdlc link loop
delete hdlc
exit
$!
$! shutdown mop if we need to
$!
$ if started_mop .eqs. 1
$ then
$ stop net$mop
$ endif
$!
$! set the modem connect line back to normal
$!
$ define/user sys$output nl:
$ define/user sys$error nl:
$ ncl stoploop modem connect line 'P1'

Appendix B. Clear Cause Codes

If a call made to or from an X.25 for OpenVMS system is cleared, one of the Cause Codes listed in Table B.1 maybe displayed. These codes are based on the CCITT X.25 recommendation and the ISO 8208 specification.

Note

The Cause Codes presented in Table B.1 apply only to calls made over public networks; they do not apply to calls made over a private network or over a point-to-point link.

Cause Code 0 indicates that the call was cleared by either the local or the remote DTE. All other Cause Codes indicate that the call was cleared by the network.

If an X.29 PAD is being used, a PAD Cause Code and PAD Cause Message are also displayed when a call is cleared. The PAD Cause Code and PAD Cause Message associated with each Clear Cause Code are shown in Table B.1.
Table B.1. Clear Cause Codes

Clear Cause Code

PAD Cause Code

PAD Cause Message

Description and Action

0

Description: The call has been cleared by either the local or the remote DTE.

Action: Examine the diagnostic code for the reason why the call was cleared. Refer to documentation supplied with the clearing DTE for further details of the diagnostic code.

0

DTE

Remote request

Description: The call has been cleared by the remote DTE.

Action: Examine the diagnostic code for the reason why the call was cleared. Refer to documentation supplied with the remote DTE for further details of the diagnostic code.

1

OCC

Number busy

Description: The called DTE cannot process your call request at this time.

Action: Attempt the call again at a later date.

3

INV

Invalid facility requested

Description: The requested facility is not valid or cannot be used as it has not been subscribed to.

Action: Examine the diagnostic code to determine which facility is in error and then change the appropriate Template attribute accordingly. If the requested facility has not been subscribed to, contact your PSDN.

5

NC

Temporary Network Problem

Description: There is a temporary problem that is not allowing the call to proceed.

Action: Examine the diagnostic code to determine why the call cannot proceed at this time. Refer to the PSDN documentation describing the diagnostic codes. Attempt to make the call again at a later date.

9

DER

Number out of order

Description: The called DTE cannot be contacted as there is a problem at the remote DTE.

Action: Continue problem solving on the remote DTE.

11

NA

Access to this number is barred

Description: The DTE number specified was incorrect or you are not permitted to access the specified DTE.

Action: Verify that the correct DTE number was specified. If the correct number was specified, contact your PSDN to change your subscription details to allow access to the number.

13

NP

Number not assigned

Description: The DTE number specified was incorrect.

Action: Attempt the call again using the correct DTE number.

17

RPE

Network detected remote procedure error

Description: There is a problem with the Call packet, or a problem at the remote DTE has been detected by the network.

Action: Examine the diagnostic code to determine the exact reason why the call was cleared. Refer to the PSDN documentation describing the diagnostic codes.

19

ERR

Network detected local procedure error

Description: There is a problem with the Call packet, or a problem at the local DTE has been detected by the network.

Action: Examine the diagnostic code to determine the exact reason why the call was cleared. Refer to the PSDN documentation describing the diagnostic codes.

21

ROO

Cannot be routed as requested

Description: The called number cannot be contacted via the RPOA specified in the RPOA facility.

Action: Verify that the RPOA Sequence attribute in the template correctly identifies the intended RPOA. If the attribute is correct, examine the diagnostic code for further information about the reason that the RPOA could not forward the call to the destination DTE. If the diagnostic indicates that the error is temporary, attempt the call again at a later date.

25

RNA

Reverse charging refused

Description: The reverse charging facility is not valid in this situation or cannot be used as it has not been subscribed to.

Action: Attempt the call again without specifying reverse charging. If reverse charging has not been subscribed to, contact your PSDN to update your subscription details.

33

ID

Incomplete destination

Description: An incomplete destination has been specified for the call.

Action: Examine the diagnostic code for the reason why the call was cleared. Refer to documentation supplied with the remote DTE for further details of the diagnostic code.

41

FNA

Fast select refused

Description: The fast select facility is not valid in this situation or cannot be used as it has not been subscribed to.

Action: Attempt the call again without specifying fast select. If fast select has not been subscribed to, contact your PSDN to update your subscription details.

57

SA

Ship cannot be contacted

Description: The called DTE cannot be contacted as the ship is currently out of range.

Action: Attempt the call again at a later date.

Appendix C. Diagnostic Codes

The X.25 Diagnostic Codes used by X.25 for OpenVMS are given in Table C.1. These codes are based on the CCITTX.25 recommendation and the ISO 8208 specification.

If the diagnostic was not generated by X.25 for OpenVMS, but by the network or another vendor's DTE, this table may still be helpful. It should be noted however, that vendors may define additional codes and may also place different meanings on the codes listed.
Table C.1. X.25 Diagnostic Codes

Code

Description

0

Non–specific

1

Invalid P (S )

2

Invalid P (R )

16

Packet type invalid

17

Packet type invalid for state R1

18

Packet type invalid for state R2

19

Packet type invalid for state R3

20

Packet type invalid for state P1

21

Packet type invalid for state P2

22

Packet type invalid for state P3

23

Packet type invalid for state P4

24

Packet type invalid for state P5

25

Packet type invalid for state P6

26

Packet type invalid for state P7

27

Packet type invalid for state D1

28

Packet type invalid for state D2

29

Packet type invalid for state D3

33

Unidentifiable packet

34

One way outgoing LCN

36

Unassigned LCN

38

Packet too short

39

Packet too long

40

Invalid GFI

41

Non–zero LCN in RESTART packet

42

Packet incompatible with facility

43

Unexpected Interrupt Confirm received

44

Unexpected Interrupt received

45

Unexpected Reject received

49

Timer expired for CALL

50

Timer expired for CLEAR

51

Timer expired for RESET

52

Timer expired for RESTART

64

General call set–up problem

65

Facility/Registration code not allowed

66

Facility parameter value invalid

67

Invalid called DTE address

68

Invalid calling DTE address

69

Invalid facility length

70

Incoming call barred

71

No logical channel available

72

Call Collision

83

Inconsistent Q–bit setting in M–bit sequence

128?

No application to accept call

145

Interrupt timer expired

163

DTE resource constraint

165

M–bit set on partially full data packet

166

D–bit not supported

Appendix D. Reporting Problems to VSI

D.1. Introduction

If the system fails and you believe that the failure is caused by the X.25 software, contact VSI for information about the variety of service options available to you and the procedures for submitting software problem reports. This appendix describes the information you should include with your report.

D.2. Details of the Software

When you submit a problem report, you must supply details of the software:

  • Specify the full name of the X.25 software product you are using.

  • Specify the software version number.

D.3. Details of the Problem

The more information you provide, the easier and quicker it is to determine the problem. Please include as much detail as possible when entering the requested information.

  1. Clearly define the problem.

    State:

    • Whether or not the problem is consistently reproducible, and if so, how to reproduce the problem.

    • How frequently the problem occurs.

    • Whether there are any factors related to the problem, for example, heavy use of the system, low line-speed, or the use of particular communication devices.

  2. Give the priority of the problem.

    • Priority 1

      Major loss of functions. For example, your X.25 system fails to establish any X.25 connections, or X.25 consistently crashes the system.

    • Priority 2

      Some loss of functions. For example performance degradation, data transfer rate falls by a considerable amount.

    • Priority 3

      Some impact on the user, manual intervention required. For example, you need to use an NCL command when there is a DTE or line failure, to turn the line off and back on again.

    • Priority 4

      Functions can run with no significant impact on the user, problem can easily be worked around. For example, you may only need to alter the order in which certain NCL commands are entered.

    • Priority 5

      No system modifications needed to return to normal functions. For example, you have a suggestion, want some advice, or find a documentation error.

  3. Give additional information:
    • Details of your hardware configuration:

      • Details of CPU type.

      • Details of all the communication devices (revision levels and speeds) on the CPU.

      • CSR and vector addresses of the device you are using.

        These are listed in the Site Management Guide.

    • Details of your software configuration:
      • A listing of the following NCL commands (as appropriate for your system's entities): 
        ncl> show x25 access all
ncl> show x25 access dte class * all
ncl> show x25 protocol all
ncl> show x25 protocol dte * all
ncl> show lapb all
ncl> show lapb link * all
ncl> show modem connect all
ncl> show modem connect line * all
ncl> show llc2 all
ncl> show llc2 sap * all
ncl> show llc2 link * all
ncl> show xot all
ncl> show xot sap * all
ncl> show xot link * all
ncl> show x25 relay all
ncl> show x25 relay client * all
ncl> show x25 server all
ncl> show x25 server client * all

    • Exact details of any event messages and error messages displayed.

    • If the problem occurs each time a particular user program is run, please submit the sources of the program on media.

    • If the problem concerns a line error or a protocol error at Level 2 or Level 3, use CTF to record line traffic, and submit the binary file obtained. If you have a line monitor, you can increase the speed of problem detection by submitting a line monitor trace (either as a listing, or on media), giving details of the type of line monitor used.

    • If the system fails or you need to force a system crash, submit the system dump file with your problem report (not the analyzed output).

      For details of how to force a system crash, please refer to the OpenVMS system documentation.

D.4. Copying System Dump Files

You can use the System Dump Analyzer COPY command to copy the dump file. Use the BACKUP utility to create a backup saveset containing the dump file and any additional information. To backup the saveset on tape, use the following command:
$ BACKUP SYS$SYSTEM:SYSDUMP.DMP[filenames]/IGNORE=BACKUP -
_$ MUA0:name/SAVE/REWIND

where filenames is a list of the files containing any additional information that you are providing, and name is the name you give the saveset.

To backup the saveset on disk, use the following command:
$ BACKUP SYS$SYSTEM:SYSDUMP.DMP[filenames]/IGNORE=BACKUP -
_$ device:name/SAVE/INIT

where filenames is a list of the files containing any additional information that you are providing, and name is the name you give the saveset.

For more information on using BACKUP, refer to the OpenVMS System Management Utilities Reference manual.

1

This code is specific to X.25 for OpenVMS. Its meaning will vary from vendor to vendor.