Cloverleaf 6.0 with AIX and SNA – version?

[Troy Morton]

Hello,

I was wondering if anyone is using SNA (LU6.2) with Cloverleaf 6.0?

Topic

[Russ Ross]

We ended up running Cloverleaf 6.0 under AIX 6.1 with SNA interfaces with SMS.

I don’t recall off the top of my head which version of SNA we are running without refreshing my memory which I’m not where I can do that right now.

I would choose to go with AIX 7 and even asked our admins to lay it down but they were too busy to do it anytime soon.

We couldn’t wait so we ended up being married to AIX 6.1 for Cloverleaf 6.0.

Russ Ross
RussRoss318@gmail.com

[Russ Ross]

Here is the complete list of our details

Cloverleaf 6.0

AIX 6.1 TL8 SP3

SNA 6.4

I ran this command to determine the version of SNA we are currently running

lslpp -l | grep sna
[code]lslpp -l | grep sna

Russ Ross
RussRoss318@gmail.com

[Troy Morton]

Thanks Russ.  This is very helpful!

[Russ Ross]

By the way we have been running live with what I described since around first of December 2013 so for about close to 4 months at this time.

We have been running TEST Cloverleaf 6.0 on AIX 6.1 TL9 SP1 for a couple of months with same SNA version.

I will be upgrading the OS level in PROD this weekend to match TEST.

Russ Ross
RussRoss318@gmail.com

[Bill Marsch]

we are running cloverleaf 6.0.2 should we be running SNA 6.4 instead of the version verified byt the same command as the user in this posting.  We are having issues with the connection when one side or the other goes down then starts back up.  We are also on Mainframe Invision 27.5 of SMS.

[hci@aixhaserv]:/home/hci> lslpp -l | grep sna                                  

 bos.net.snapp              6.1.6.0  COMMITTED  System Networking Analysis and

 sna.dlcmpc                 6.3.1.0  COMMITTED  MPC Data Link Control          

 sna.gsk_jre                6.3.1.0  COMMITTED  Custom JRE for gskit          

 sna.lu0                    6.3.1.0  COMMITTED  Logical Unit 0 (LU0)          

 sna.msg.en_US.rte          6.3.1.0  COMMITTED  SNA Base Messages – U.S.      

 sna.msg.en_US.snapi        6.3.1.0  COMMITTED  SNAPI TP Development Tool –    

 sna.msg.en_US.wa           6.3.1.0  COMMITTED  SNA Web Admin Tool Messages –  

 sna.msg.en_US.xsna         6.3.1.0  COMMITTED  SNA X Tool Messages – U.S.    

 sna.rte                    6.3.1.0  COMMITTED  Communications Server Base    

 sna.rte64                  6.3.1.0  COMMITTED  64-bit support for            

 sna.snapi                  6.3.1.0  COMMITTED  Communications Server SNAPI TP

 sna.wa                     6.3.1.0  COMMITTED  Web-based Administration for  

 sna.xsna                   6.3.1.0  COMMITTED  X-Windows Management Tool for  

 bos.net.snapp              6.1.6.0  COMMITTED  System Networking Analysis and

 sna.dlcmpc                 6.3.1.0  COMMITTED  MPC Data Link Control          

 sna.lu0                    6.3.1.0  COMMITTED  Logical Unit 0 (LU0)          

 sna.msg.en_US.rte          6.3.1.0  COMMITTED  SNA Base Messages – U.S.      

 sna.msg.en_US.snapi        6.3.1.0  COMMITTED  SNAPI TP Development Tool –    

 sna.msg.en_US.wa           6.3.1.0  COMMITTED  SNA Web Admin Tool Messages –  

 sna.msg.en_US.xsna         6.3.1.0  COMMITTED  SNA X Tool Messages – U.S.    

 sna.rte                    6.3.1.0  COMMITTED  Communications Server Base    

 sna.rte64                  6.3.1.0  COMMITTED  64-bit support for            

 sna.snapi                  6.3.1.0  COMMITTED  Communications Server SNAPI TP

 sna.wa                     6.3.1.0  COMMITTED  Web-based Administration for  

 sna.xsna                   6.3.1.0  COMMITTED  X-Windows Management Tool for  

 sna.docs.Ja_JP.data        6.3.1.0  COMMITTED  SNA PDF documentation –        

 sna.docs.de_DE.data        6.3.1.0  COMMITTED  SNA PDF documentation – German

 sna.docs.en_US.data        6.3.1.0  COMMITTED  SNA PDF documentation – U.S.  

 sna.docs.es_ES.data        6.3.1.0  COMMITTED  SNA PDF documentation –        

 sna.docs.fr_FR.data        6.3.1.0  COMMITTED  SNA PDF documentation – French

 sna.docs.ko_KR.data        6.3.1.0  COMMITTED  SNA PDF documentation – Korean

 sna.docs.pt_BR.data        6.3.1.0  COMMITTED  SNA PDF documentation –        

 sna.docs.zh_CN.data        6.3.1.0  COMMITTED  SNA PDF documentation –        

 sna.docs.zh_TW.data        6.3.1.0  COMMITTED  SNA PDF documentation –        

 sna.ecl.data               6.3.0.0  COMMITTED  Host Access Class Library      

 sna.man.en_US.rte.data     6.3.1.0  COMMITTED  SNA Server Manual Pages – U.S.

 sna.man.en_US.xsna.data    6.3.1.0  COMMITTED  SNA Server X Tool Manual Pages

[hci@aixhaserv]:/home/hci>

[Russ Ross]

With all versions of SNA spanning at least 17 years the connections have acted undesirably consistant for us.

When stopping the sender on the mainframe the connection on cloverleaf hangs in UP state, to reconnect to mainframe requires the cloverleaf listener be recycled sometimes more than once, then once the listener is in an opening state then start the SNA/TIF sender on the mainframe.

When cycling the interface on the cloverleaf side without shutting down the mainframe side first, sometimes will loose one message, and if the cloverleaf side is restarted it will eventually reconnect with mainframe and resume message flow but does not reconnect right away.

I treat the SNA/TIF interfaces from the mainframe to cloverleaf as not persistant and when possible on shutdown will stop the sender on the mainframe first to prevent one message from being sometimes lost.

Then when I start them up I must start the cloverleaf listener first and make sure it is in opening state before starting the SNA/TIF sender then it will reconnect right away.

Unfortuantely, this means our SNA/TIF interface require more than thier fair share of manual on-call support.

I will be glad when they are gone and replaced, which could happen if our EPIC project we just started succeeds

Russ Ross
RussRoss318@gmail.com

[Russ Ross]

My team member (Jim Kosloskey) shared this with me:

Code:

From: Kosloskey,Jim
Sent: Thursday, May 22, 2014 11:19 AM
To: Ross,Russ
Subject: clovertech post SNA

Russ,

I saw your Clovertech post re SNA.

It is not SNA that causes the behavior we experience with Invision. It is primarily due to the way SMS/Siemens had the Invision Communication Handler written.

Properly written SNA programs do not behave that way.

Jim Kosloskey
UT M. D. Anderson Cancer Center
Enterprise Development and Integration

Jim’s point is well taken because looking at SNA as the cause of the undesirable behavior very well might be fruitless if in fact it is the Invision Communication Handler that is the culprit.

Russ Ross
RussRoss318@gmail.com

[Peter Heggie]

That explains a lot. We upgraded CICS last fall, and a little after that we upgraded z/os, and ever since, the SNA/TIF connections have been inconsistent in reconnecting. So it looks like the poorly-written communications handler is failing farther behind in compatability with CICS and SNA.

Our CICS regions cycle at 1am. We have three different regions, and each has some TIF and RTIF connections (using SNA). I’ve split up our Cloverleaf processes to match the CICS regions. At 1am I begin to parse the process logs, looking for the ‘communication lost’ messages, indicating SNA has gone away. At that point, the Cloverleaf SNA threads are recycled, and wait for the region to come back up and SNA to reconnect. This works automatically about 75% of the time. The other 25% requires Operations to manually disconnect and acquire the SNA connection using CICS CEMT i Conn commands.

Do you think it would help if the restarting of the Cloverleaf processes were to run twice instead of once? Or to continually restart & wait until a certain status is seen on the Cloverleaf SNA thread? The recycle cron script does not examine the status of the Cloverleaf thread after the restart command is issued; it just waits for the hci command to complete successfully.

Pete

Peter Heggie

[Russ Ross]

I have regular SMS/Care maintenance windows and I think for at least the RTIF interfaces before downtime starts and then restart them when over via cron.

Just like you our SNA reconnects after downtime don’t always work, so I have a cloverleaf alert check the TIF/RTIF interfaces on cloverleaf later on after the down time.

I think my RTIF will actually be in and ERROR state if memory serves and since TIF interface constantly changes states (open,up,down) I check for nothing received in a couple of hours during the night and weekends and whithin 5 minutes during the weekdays.

Of course your alerts would need to be tailored for you circumstance but you get the idea of using an alert to help get more sleep and only deal with the 25% of the time you need to be awake.

In the early days I also tried to have the computer operators set things right.

I eventually gave up on taking that approach but would go that way first to see if your computer operations can handle the task.

Unfortuantely, we had too many issues going that way here but I know other places have been able to get computer operations to help instead of making it worse.

This way the ones already awake fix the problem and those sleeping can get more rest.

Russ Ross
RussRoss318@gmail.com

[Troy Morton]

Hi Everyone,

We ended up going with AIX 7.1; SNA v6.4.  We have been running this since April with no major issues.  We did have to change the thread configs to use “binary” encoding instead of “ASCII”, however.

We tried AIX 7.1 and SNA 7.0 and it DID NOT work with Cloverleaf 6.0 because the APIs have been changed in SNA 7.0.

Thanks,

[Author]

Replies