How can I use Netmaster to help diagnose a problem if the user cannot access the mainframe?
search cancel

How can I use Netmaster to help diagnose a problem if the user cannot access the mainframe?

book

Article ID: 32428

calendar_today

Updated On:

Products

CMDB for z/OS NetSpy Network Performance NetMaster Network Automation SOLVE NetMaster Network Management for SNA NetMaster Network Management for TCP/IP NetMaster File Transfer Management

Issue/Introduction

Introduction:

I have a user who cannot access the mainframe and want to know how I can use Netmaster to help diagnose the problem.  Is this possible?

 

Background: 

If the user has not been able to access the mainframe at all, the stack will never see any inbound packets so Netmaster will be unable to trace what is happening.

However, you can test whether the user's workstation has any connectivity into the mainframe at all.  Some of this can be done using Netmaster, other parts cannot, but below are diagnostic steps that can be utilized to diagnose the problem.

 

 

Environment

Release: SLOPFC00200-12.1-NetMaster-File Transfer Management
Component:

Resolution

Instructions:

  1. Have the user open up a DOS window and enter the command IPCONFIG and hit >enter<

     He should see something like this

     C:\Users\myusers>ipconfig
   Windows IP Configuration

     Ethernet adapter Local Area Connection* 15: 

       Connection-specific DNS Suffix  . : companyx.com
      IPv4 Address. . . . . . . . . . . : 192.0.2.12
      Subnet Mask . . . . . . . . . . . : 255.255.255.255
      Default Gateway . . . . . . . . . : 0.0.0.0

     Wireless LAN adapter Wireless Network Connection 2: 

       Media State . . . . . . . . . . . : Media disconnected
     Connection-specific DNS Suffix  . :

    Wireless LAN adapter Wireless Network Connection:

       Connection-specific DNS Suffix  . : home
       IPv4 Address. . . . . . . . . . . : 192.0.2.1
      Subnet Mask . . . . . . . . . . . : 255.255.255.0
      Default Gateway . . . . . . . . . :

     In this instance, the first IP address is the one known by the mainframe (DNS Suffix companyx.com) and the second is the local home IP address
      of the PC itself.

     Depending on configuration, there may be more than two addresses.

     If the IPCONFIG does not show a second IP address, the VPN session may not be working correctly, but you can still try step 4 with all available
     IP addresses from the display to verify whether there is any possibility of connectivity to the mainframe.

 

  1. In Netmaster, go to /IPDIAG then plug in the IP address of the workstation under Host Name/Addr.

    Try selecting PING and / or Tracert to see if the stack can locate the IP address.

     If not, there is nothing further that can be done from Netmaster.

  1. If the IP address can be located, you can do the following
      -     Go to /SMART
        -      Select A - Add a SmartTrace definition
        -      Select New TCP Trace
        -      Fill out the Name and Description, and add the user's IP address to the Foreign Host field.
        -      You can save and activate the trace there using the PF-Keys PF3 to save, then PF6 to activate,
                     OR
        -      PF3 back to the Packet Tracing Menu and select L - List all Smart Traces and activate from there by selecting the trace definition with A-Activate.
        -      Have the user try again to access the mainframe and review any packets that show up in the trace.

     You can also do this in reverse -

  1. From the DOS prompt, have the user issue

      tracert hostname
      Where the hostname is either the hostname or the IP address of your TCP/IP stack

      The user should try both. 

      Traceroute is better than PING in this case as it will show how far the connection attempt gets before timing out.
      Is it making it into your network at all or just completely timing out? 

      If it fails with the hostname and works with the IP address, there may be DNS problems. 

  1. In that case you can have the user issue this command from DOS:
            ipconfig/flushdns
        And try doing the tracert command again.         

 

   This clears out the DNS CACHE on the PC, removing any names that may have been cached with incorrect values, thus allowing hostnames to be resolved
   correctly.