SNA only partially working

[Todd Lundstedt]

Doing an upgrade.

Existing system: AIX 5.2, Cloverleaf 5.3, SNA 6.1, prod/test connections listening for data from the mainframe, and prod/test connections calling the mainframe to send data (Siemens Invision).  All SNA connections working as expected.

New system: AIX 5.3, Cloverleaf 5.5, SNA 6.3.

On the mainframe, we have a single VTAM book with all the connections for prod and test in one definition (our test SNA site runs on the prod server… HACMP is involved, it’s a long story).

For testing purposes, we have moved the test connections out of the main VTAM book on the mainframe, and put them into a new book with a different IDNUM.  I cloned the SNA config on the new server from the old server.  I changed the “Node ID” in SNA config to match the new test VTAM book’s IDNUM.

SNA comes up just fine on the new server.  I can receive data just fine on the new server (TIF transactions).  When I attempt to start the threads that send data TO the mainframe (RTIF, and special programs), I get the following error in the Cloverleaf process log:

can’t ALLOCATE to TPN ‘CLNK’: Local TP passed an invalid parameter

The ‘CLNK’ changes depeding on which thread we start, based on the RTPN value in the NetConfig for the appc protocol.

I can verify that we have SNA configured to talk to the mainframe in the following ways:

1. I am receiving TIF transactions from our test CICS region on two threads, and when the Cloverleaf threads start, I can see the connection change from SSCP in the xsnaadmin tool to Active.

2. I can log into the CICS and set the connection for the RTIF threads to Acquired, and I can see the connection turn from SSCP to Active in the xsnaadmin tool.

I believe we have everything working for SNA.  I just can’t get Cloverleaf to activate that connection.

Support thinks we need Implementation a$$i$tance

Is anyone else doing SNA (preferably to an from Invision) on Cloverleaf 5.5?  Do you have any experience that might help?

Topic

[Charlie Bursell]

You need to run an SNA trace to see what is really going.  You might want to trace it from the AIX side and the VTAM as well.

Are you sending the Allocate in EBCDIC?

As for the Implementation a$$i$tance I guess we will offer our time for free the same time you guys start delivering babies for free  😛

Seriously what they are trying to say is that these types of issues can run into many hours of troubleshooting.  That is one of the things I dearly love about SNA espicially RTIF  👿

[Michael Hertel]

Quote:

I cloned the SNA config on the new server from the old server.

This may not be your issue, but when we upgraded SNA on AIX, we copied the SNA configuration from the previous version. That turned out to be a no-no. After walking thru it with IBM $upport, we configured the new SNA using the old information but without using the old files.

[Todd Lundstedt]

Michael..

By cloned, I meant… I rebuilt it from the ground up manually, copying each value over, item by item, value by value.

I didn’t use the migration steps in the SNA manuals.  Reading through the migration steps was taking longer than just going through every panel and making sure the value was entered in on the new systems (plural, in an HA config).

Charlie… Birthing babies only costs cab fare! =).  Just stay in the car until it pops out!

Regarding EBCDIC.. Misc properties on both old test (5.3) and new test (5.5) show EBCDIC Alloc checked.. so.. the answer is yes, I hope.

[Author]

Replies