Does SNASW local terminated sna packet ？

[henrybb]

My sna session is like this:

cics-390---(EE)--snasw router---(lan)---3270

And there is some problem in sna session. After I look the trace of 390 vtam,I found

1.390 send bind request to 3270 terminal

2.then 3270 terminal send unbind (incorrect parameter) to 390

3.390 send unbind response to 3270. This is the problem. I trace the packet between snasw router and 3270 terminal, but I can't find the unbind response packet.So 3270 terminal is hung.

So where is unbind response gone ?

I am in doubt whether snasw would receive the unbind response packet and for some reason it don't send it to 3270 terminal.

I am in doubt SNASW is just do some protocol translation or it will implement some pu4/PU5 function .

thanks!

[rclousto]

That's a good observation, I didn't read far enough to catch that note. I agree that Tandem is behaving correctly by sending an UNBIND as I see that the BIND is extended.

I think our original code developer read that the UNBIND is a REPLY to the BIND, and expected that the UNBIND sender (Tandem ICE) would therefore clean up all session awareness. Thus, no UNBIND rsp would be needed or expected. SNASw treats the UNBIND rq in this situation exactly the same as a -RSP(BIND).

Unfortunately the SNA architecture doesn't give any further instructions on this situation. I wouldn't call this a bug in either the Tandem ICE or Cisco IOS SNASw implementation. It's a different interpretation of an unclear specification, and this caused you a problem.

We're going to reconsider whether to put in a code change to handle this. It certainly makes some sense to return an UNBIND rsp to an UNBIND req, and the risk of it causing a problem seems low. I will let you know our final decision.

The 12.3T releases have now become 12.4 so if we fix this you'd have to pick it up as a 12.4 version.

I'm curious why you are continuing to push this even though you have a fix coming from Tandem. Are you looking for something sooner, or would you rather upgrade your router, or some other reason?

My email address is rclousto@cisco.com.

Regards,

Bob

[henrybb]

I continue to push the post because Tandem won't fix it because they think that is not their fault. They want me to upgrade IOS version because they think their SNA software(ICE) is doing right thing.

So I need to find the truth.

Router or Tandem ?

If you will put in a code change to handle this, or if you can give me more document about that. please let me know.

thanks!

[rclousto]

I've misunderstood because I thought you said Tandem was making a change in their next release:

> Fix to ICE:

> Fixes to next ICE 4.1 release - July 2005:

>

>

> 2. Change dependent LU

> processing so that if a BIND is received when a session is already allocated,

> ICE will send a negative response to the BIND rather than an UNBIND. This will

> result in the session being deallocated and therefore avoiding the problem being

> experienced by CMBK.

Perhaps you could email me the contact you have at Tandem for this.

[henrybb]

Sorry,I didn't express exactly.

First phase Tandem think there is something wrong with ICE like you saw.

Second phase Tandem request us change SNASW to traditional router(dlsw+cip),and there is no problem when tandem send unbind req.So they change their mind.They think something is wrong with cisco SNASW.So I need to make sure what is the truth.

After read the url which you give, I think that maybe cisco SNASW has bug. Or there is something misunderstand because there is no clearly SNA document about how to do after bind-unbind sequence like you said. I can see 390 send unbind response outbound,so I think that response with unbind rsp is doing right thing because 390 is IBM flagship and SNA implement on 390 is almost right.

thanks for your help!

[rclousto]

We are working on a change to send the UNBIND rsp. I don't have a date for you yet. Please send me an email with your contact information so I can make arrangements to send an image for you to test the change with, assuming we don't hit any unexpected problems with our own testing that we cannot overcome.

Thanks,

Bob

rclousto@cisco.com

[henrybb]

thanks for your help.

my email is:

hantao@cmbchina.com

or

henry07552002@yahoo.com.cn