[an error occurred while processing this directive]

HP OpenVMS Systems

» 

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here
DIGITAL SNA access server migration guide


[Top] [Prev] [Next] [Index] [Contents] DIGITAL SNA Access Server Migration Guide



Some Common Diagnostics

it is not within the scope of this guide to discuss in any detail the kinds of tests that should be run, or the kinds of errors that might arise. The following discussion briefly reviews some common problems and suggests where to go to resolve them or any other problems that testing reveals.

  • If the access routine is unable to connect to the Server node:
    • Check that the local node, where the access routine is running, knows about the Server node.
    If it does not, update the Node name table to include the Server node.
    • Check to see if other kinds of connections (e.g. set host on a DECnet network or telnet on a TCP/IP network) are able to connect to the Server node.
    If they do not, verify the installation and configuration of the PATHWORKS (DECnet) or TCP/IP environment, and/or verify that the network is routing information successfully between the Access Routine node and the Server node.
    • Check to see if the network object is known on the Server node.
    If it is not, make sure that the Access Server software is up and running on the Server node. Use the NT Event environment and/or SNA logging in the Access Server to determine the source of the problem.
  • If you are unable to access a specific LU or you get an invalid LU name error message:
    • Determine the Access Name (if it is being used), the PU name and session address, or the LU name supplied to/by the access routine. Use this information, along with the Access Server configuration parameters, to determine the local LU name the Access Server attempted to use. Check to see whether this local LU name is known by the SNA Server.
    If it is not, either define the local LU name to the SNA Server, or update the mapping information to use a local LU known to the SNA Server. Check the mapping parameters in both Access Name and Name Mapping.
  • If you are unable to access a specific PLU or you get an invalid PLU name error message:
    • Determine the Access Name (if it is being used) and the PLU information supplied to/by the access routine. Use this information, along with the Access Server configuration parameters, to determine the remote LU name the Access Server attempted to use. Check to see whether this remote LU name is known by the SNA Server.
    If it is not, either define the remote LU name to the SNA Server, or update the information in the Access Name to use a remote LU known to the SNA Server.
  • If you are unable to access a specific logon name or mode or you get an invalid logon name or invalid mode name error message:
    • Determine the Access Name (if it is being used), and the logon name or mode name information supplied to/by the access routine. Use this information, along with the Access Server configuration parameters, to determine the mode name or logon name the Access Server attempted to use. Check to see whether this mode name or logon name is known by the SNA Server.
    If it is not, either define the mode name or logon name to the SNA Server, or update the mapping information to use a mode name or logon name known to the SNA Server.
  • If everything appears to be correct, but a session is not established:
    • Verify that the SNA Server is properly configured and can see the mainframe.
    • Verify that the mainframe is properly configured and can see the SNA Server.

You can use the Windows NT Event Viewer to help diagnose many problems. Both the Application Log and the System Event Log may provide meaningful information about connection and access problems. In particular, the detail information in Pending and Inactive connections may provide specific information about what is wrong. To examine the details of a specific application event, highlight it and then select Detail from the View menu.

For detailed information on using the Event Viewer with the SNA Server, refer to Managing Microsoft SNA Server.

The SNA Server's Performance Monitor is another useful tool for diagnosing problems with the SNA Server itself. See the Microsoft SNA Server Administration Guide for complete details on using the Performance Monitor. Also see the Microsoft SNA Server Planning Guide for detailed troubleshooting procedures for the SNA Server.


[Top] [Prev] [Next] [Index] [Contents] DIGITAL SNA Access Server Migration Guide