iSeries SNA/APPC connectivity

I had 2 iSeries (AS/400s) in the same data center which were connected via Ethernet, and at the same time supported SNA communications between the 2 systems. This supports QSNADS file distribution between the 2 systems. This was configured and working successfully in the same datacenter, but when 1 of the machines was relocated to a datacenter in a remote building, the appc controllers and respective  appc devices (representing the 2 systems) cannot be varied on to support the SNA connectivity. They stay on a 'vary on pending' status. The AS/400 in the remote location had a change with it's IP and default route. while the host table entry for the local system had it's IP entry for the remote system changed accordingly; Ethernet connectivity between the 2 systems is successful. It's just the appc / sna connectivity that got clobbered, What did I miss?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Gary PattersonVP Technology / Senior Consultant Commented:
Hard to diagnose at a distance without more information on your environment.

1) What OS version are you running o each machine?

2) SNADS relies on APPN networking.  Are you using AnyNet support (SNA over IP), or are you trying to use native APPN?  Native APPN requires special support by intermediate routers.

3) Suggest you post the relevant configuration objects from each system.

4) Do you have a QAPPCTCP job running on both systems?

5) When you do WRKTCPSTS OPTION(*CNN) on each system, do you see the APPCove... jobs in the correct status on both systems?

6) Are there firewalls between the two systems that might be filtering traffic?

7) Once you have verified that you have APPN connectivity, follow the SNADS troubleshooter and post any relevant information if you need help:

Finally, here is a pretty detailed guide for setting up SNADS over Anynet (SNADS over IP):

- Gary Patterson

Check out my Experts-Exchange profile:

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
amersportsAuthor Commented:
Thanks for the links, the first of which REALLY helped. I can now strpasthr between both systems (validating successful SNA connectivity between both), and I can now send distributions from the remote system to the local system. However, I cannot get files from the local system to the remote.
Local system is v5r3, remote system (wsgsys09) is v5r4
When I start qsnads on the local system, the results are as follows:

     Job 169789/QSNADS/WSGSYS09 started on 01/08/14 at 13:47:03 in subsystem
  QSNADS in QSYS. Job entered system on 01/08/14 at 13:47:03.          
Job 169789/QSNADS/WSGSYS09 submitted.                                  
Remote system abnormally ended transaction for file QCSNADSC in library
  QSYS for device ZDPGMDEV.                                            
Alert created.                                                        
Starting recovery for SNADS sender 169789/QSNADS/WSGSYS09, serving *SNA
  distribution queue WSGSYS09                                    
The queue on the source system looks as follows

 Queue                       Queue                              Queue Depth
 Name                        Priority                          Send        Current           Status
 WSGSYS09                Normal                              1              8                Rty-Fail
 WSGSYS09                High                                   1              8                Rty-Fail
Gary PattersonVP Technology / Senior Consultant Commented:
Sounds much better.  Just need a little more info to troubleshoot this last bit:

1) Please pull up second level help text for message and post here:

Remote system abnormally ended transaction for file QCSNADSC in library
  QSYS for device ZDPGMDEV.      

2) Please pull up job log for job 169789/QSNADS/WSGSYS09 and post.

3) Please pull up distribution log on both systems and post.  See SNADS troubleshooting link above for instructions.
Exploring SharePoint 2016

Explore SharePoint 2016, the web-based, collaborative platform that integrates with Microsoft Office to provide intranets, secure document management, and collaboration so you can develop your online and offline capabilities.

amersportsAuthor Commented:
Hi Gary
Please see attached. If I can provide anything additional please let me know.
It seems I am so close......
Gary PattersonVP Technology / Senior Consultant Commented:
OK, so the problem occurs when the transaction initiates from system WSGSYS06 to wsgsys09.

SNA error code X'08640000':

Premature conversation termination. The conversation terminates abnormally; for example, the transaction program might issue a DEALLOCATE_ABEND verb, or the application program might terminate (normally or abnormally) without explicitly terminating the conversation.

Looks like you need to diagnose the problem on wsgsys09.  

Make sure QAUTOCFG system value is set to '1'  on wsgsys09 to allow any required appc devices to be created.  IF it is normally set to '0', you can set it back once everything is up and running.

- Gary
amersportsAuthor Commented:
'PGMEVOKE' is a routing entry in subsystem QCMN on both systems

                            Display Routing Entries                            
                                                             System:   WSGSYS06
 Subsystem description:   QCMN           Status:   ACTIVE                      
 Type options, press Enter.                                                    
   5=Display details                                                            
 Opt    Seq Nbr    Program       Library       Compare Value               Pos  
          240      *RTGDTA                     'QLZPSERV'                  37  
          250      *RTGDTA                     'QCNPCSUP'                  37  
          260      *RTGDTA                     'QOCEVOKE'                  37  
          290      *RTGDTA                     'QPCSUPP'                    1  
          295      *RTGDTA                     'QCASERVR'                   1  
          299      *RTGDTA                     '#INTER'                     1  
          300      *RTGDTA                     'PGMEVOKE'                  29
amersportsAuthor Commented:
Update (1/9 11:44)
This is a nasty one!
qautocfg on wsgsys09 (local) was indeed off; it is now enabled, I IPLd wsgsys09, [re]started qsnads on wsgsys06 (remote):  same error was encountered on the joblog previously provided.
I was told that the remote site contains an Ethernet handoff with no firewall in between. Is there any setting(s) on the intermediate routers that could be interferring with traffic for port 397? Again, strpasthr is successful between both systems both ways; Would this fact rule out the possibility that the port is being blocked? Is there a test I can do to confirm?
It's really puzzling that strpasthr works between both systems, and that I can send from local to remote, but not the other way around. I hope the additional information helps.
Gary PattersonVP Technology / Senior Consultant Commented:
So no NAT, no firewall. Strpasthr working in both directions indicates this is probably not a network issue.


1) Make sure you are running the latest cume/hiper/group PTFs on both systems.

2) Run a communications trace at both ends to see exactly what is happening between the two systems.

3) The SNA error code X'08640000' indicates that a conversation IS being initiated, but that it is ending abnormally.  You probably want to look at the job log from the receiving job and the QSYSOPR message queue to see if there are any useful messages.  Also check the system problem log (WRKPRB) on the receiving system, and see if you can find any more  detailed problem information.
amersportsAuthor Commented:
Thanks for your help, Gary. There were some old device configurations that were causing a conflict.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking Protocols

From novice to tech pro — start learning today.