Troubleshooting ANYNET/MPTN on the System i5

Resolving The Problem

Important Note: Starting in i 7.1, AnyNet (a method used to run SNA communications traffic over IP) is no longer supported. Users of AnyNet are encouraged to migrate to Enterprise Extenders as a replacement. For information about migrating to Enterprise Extenders from AnyNet, see the Migrating from AnyNet to Enterprise Extender topic in the IBM i Information Center.

ANYNET/MPTN is an architected technology for encapsulation of IBM's Systems Network Architecture (SNA) data in UDP/IP; however, it is frequently described as encapsulation of SNA data over TCP. ANYNET is a way to continue the use of legacy SNA applications when the underlying hardware/software will not support native SNA, for example: GB Ethernet cards on the System i.

Function Description

ANYNET/MPTN problems on the iSeries are usually caused by configuration error, even in an ANYNET environment that was previously working (it worked yesterday). The first thing in troubleshooting is to verify that the current configuration is correct. The configuration must be checked on both systems.

Related Jobs/Tasks

To begin verifying the ANYNET configuration, obtain the following information (highlighted in blue) from each system:

DSPNETA

Current system name  . . . . . . . . . . . . . . :   RCHASRS1
  Pending system name  . . . . . . . . . . . . . :            
Local network ID . . . . . . . . . . . . . . . . :   APPN  
Local control point name . . . . . . . . . . . . :   RCHASRS1
Default local location . . . . . . . . . . . . . :   RCHASRS1

and after paging down twice:

Allow ANYNET support . . . . . . . . . . . . . . :   *YES


Run CFGTCP Option 10.

There should be a Host Table entry for the other system with syntax of SystemName.NetID.APPN.SNA.IBM.COM. An entry in the host table on RCHASRS1 to do ANYNET communications to RCHASRS2 would be:

RCHASRS2.APPN.SNA.IBM.COM

Generally, when APPC over TCP is used, the domain suffix of host name is required to be SNA.IBM.COM. If the customer is using something other than SNA.IBM.COM, DSPDTAARA DTAARA(QUSRSYS/QZPAIDOMAN) will show the domain name suffix that should be in the host table.

If the entry is missing from the host table, it must be added to the address of the opposite system. Verify that the IP connectivity is working by pinging (in our example) PING RCHASRS2.APPN.SNA.IBM.COM. If there is no response to the PING, there is an underlying IP problem, and ANYNET will not work. The IP problem must be resolved first.

After verifying that the host table entry exists, is correct, and responds to PINGs, check to see if there is a controller on both systems with a link type of *ANYNW. You may have to do a WRKCTLD *CMN and look at all the controller descriptions that are of type APPC to see if one or more of them have the link type of *ANYNW.

Here is an example of what the controller description on RCHASRS1 might look like to connect to RCHASRS2:

Controller description . . . . . . :   ANYNET  
Option . . . . . . . . . . . . . . :   *BASIC  
Category of controller . . . . . . :   *APPC    
                                               
Link type  . . . . . . . . . . . . :   *ANYNW  
Online at IPL  . . . . . . . . . . :   *YES    
Remote network identifier  . . . . :   *NETATR  
Remote control point . . . . . . . :   ANYNET   
Autocreate device  . . . . . . . . :   *ALL    
System job . . . . . . . . . . . . :   QCMNARB04
Message queue  . . . . . . . . . . :   *SYSVAL  
Current message queue  . . . . . . :   QSYSOPR  
  Library  . . . . . . . . . . . . :     QSYS  
Text . . . . . . . . . . . . . . . :   *BLANK  


You will notice that their is nothing in the above controller description that indicates it would be used to communicate to RCHASRS2. The controller name can be anything. Remote control point can be anything.

WRKCFGL for the QAPPNRMT configuration list is where the configurations get tied together. On RCHASRS1, to communicate to RCHASRS2 with the above controller description, we would see the following entry:

          Remote              Remote    Control          
Remote    Network   Local     Control   Point     Secure
Location  ID        Location  Point     Net ID    Loc    
RCHASRS2  APPN      RCHASRS1  ANYNET    APPN      *NO    

Note that the Remote Location is the other side, the Remote Network ID matches that of RCHASRS2, and that the Remote Control Point name matches that in the ANYNET controller.

After the host table, controller description, and QAPPNRMT configuration have been verified on both systems, vary on the controller descriptions. After varying on the controller descriptions, check to see that there is an ACTIVE QAPPCTCP job running in QSYS. If there is not, there probably is no configuration problem.

NETSTAT OPTION 3 should show the following:

397 003:26:37 Listen
397 000:00:01 *UDP

and we should show one active job with the command WRKJOB QAPPCTCP.

If the configuration has been verified as correct and NETSTAT option 3 does or does not show the port 397 or there is no QAPPCTCP job ACTIVE, ANYNET has a problem.

There is risk that the following procedure may require the customer to IPL and a very rare chance that it could crash the system if Step 1a is not followed; however, if they do not attempt it, the only way to recover the ANYNET connection will be to IPL:

1.	Vary off all APPC and HOST controllers. 1a. Wait 30 minutes (or use "Netstat *cnn" and find any ports used by the application by entering option 8, which shows the job and user name. End the port with option 4. Also verify port 397 (named "APPCoverTCPIP"); in other words, the ANYNET Listen port is ended. )
2.	Issue the CHGNETA command and change Allow ANYNET support . . . . . . *YES to: Allow ANYNET support . . . . . . *NO
3.	Wait 90 seconds.
4.	Issue the CHGNETA command and change Allow ANYNET support . . . . . . *NO to: Allow ANYNET support . . . . . . *YES
5.	Vary the APPC and HOST controllers back on.
6.	NETSTAT OPTION 3 should show the following: 397 003:26:37 Listen 397 000:00:01 *UDP and we should show one active job with the command WRKJOB QAPPCTCP.

If this did not restore the ANYNET connectivity, an IPL will be necessary.