Does SNASW local terminated sna packet ？

henrybb · ‎05-30-2005

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 · ‎05-30-2005

SNASw is providing dependant LU requestor services, which does part of the old PU 4 function. Possibly SNASw had a problem correlating the unbind response sent by VTAM with the unbind it had forwarded up. If you still have the SNASw dlctrace please attach it, or perhaps it would be best for you to open a service request so we can track this properly.

You can also check the snasw pdlog to see if there are any related messages to the unbind processing. If SNASw for some reason just discarded the unbind response I would expect it to log a message.

If you need to recreate this to recapture the dlctrace, I would also recommend setting up a snasw ipstrace and dump it. It won't be readable for you, but we have tools to read the binary output and figure out what is going on internally in SNASw when it got the unbind rsp.

Regards,

Bob

henrybb · ‎05-31-2005

thanks for your reply.

I recreate problem to recapture the trace. And there is more information than you need because I have more than one pu.

I had received the reply from 3270 application company. So I don't know whether SNASW just discarded the unbind response because SNASW think the data flow is invalid which 3270 application send. 3270 appl company said(XPNET and ICE is application name):

> data flow is like this:

> 10165 APPL Open

> XPNET opens ICE

> 10167

> APPL Reply

> 10180 APPL WriteR

> XPNET sends OPEN-SESSION to ICE

> 10201 DLC Write NOTIFY Rq ICE sends SLU Enabled to

> host

> 10270 DLC ReadC

> NOTIFY +Rsp

> 10289 DLC Write

> INIT-SEL ICE sends INIT-SELF to host

> 10308 DLC ReadC BIND Host

> sends BIND to ICE

> 10370 DLC

> ReadC INIT-SEL +Rsp

> 10385 DLC Write BIND +Rsp

> 10431 DLC ReadC SDT

> Rq

> 10442 APPL Reply

> OPEN-SESSION response to XPNET

> 10446

> DLC Write SDT +Rsp

> 10461 APPL WriteR XPNET issues

> GET-ATTRIBUTES

> 10464 APPL Reply

>

> 10470 APPL WriteR XPNET

> issues RECEIVE-DATA

>

> 13 seconds

> later ...

>

> 10549 APPL WriteR

> XPNET sends PREPARE-TO-CLOSE

> 10559 DLC Write ICE sends RSHUTD Rq in

> response to PREPARE-TO-CLOSE (10549)

> 10669 DLC ReadC RSHUTD +Rsp

> 10677 APPL Reply PREPARE-TO-CLOSE REPLY

>

> 10680 DLC ReadC Host sends

> UNBIND in response to Request to Shutdown (10559)

> 10693 APPL Reply Reply to rec 10470

> RECEIVE-DATA with RC-SESSION-TERMINATED

> 10707 DLC Write UNBIND +Rsp Respond to 10680

>

> 10715 APPL WriteR XPNET issues

> RECEIVE-DATA

> 10718 APPL Reply

> Reply to 10715 RECEIVE-DATA - RC-SESSION-NOT-ALLOCATED

> 10726 APPL Close XPNET CLOSE

> 10727 APPL Reply REPLY to CLOSE

>

> 10734 APPL Close XPNET backup process

> CLOSE

> 10745 APPL Reply REPLY

> to CLOSE

> 10750 DLC Write

> NOTIFY Rq SLU Disabled

>

> 10811 DLC ReadC BIND from host - WHY? ... what drove

> this?

> 10830 DLC ReadC

> NOTIFY +Rsp

> 10838 DLC

> Write ICE sends UNBIND Rq to host ... *** NO RESPONSE RECEIVED

> ***

>

> 10873 DLC ReadC

> NOTIFY Rq Incoming NOTIFY from host ... WHY???

> 10887 DLC Write NOTIFY +Rsp

>

> 11034 APPL Open XPNET OPENs

> APPL

> 11036 APPL Reply ICE

> REPLY to OPEN

> 11049 APPL WriteR

> XPNET OPEN-SESSION

> 11074 APPL

> Reply ICE REPLY to OPEN-SESSION with RC-SESSION-FAILURE

> 11081 DLC Write NOTIFY Rq ICE sends

> SLU Enabled request to host

> 11144

> APPL Close XPNET CLOSE

> 11145

> APPL Reply ICE REPLY to CLOSE

> 11152 APPL Close XPNET backup CLOSE

> 11154 APPL Reply ICE reply to XPNET backup

> CLOSE

> 11163 DLC ReadC

> NOTIFY +Rsp received from host

> 11177

> DLC ReadC BIND Rq received from

> host

> 11209 DLC Write ICE

> sends NOTIFY Rq to host - SLU Disabled (because of CLOSE - rec 11144)

>

> 11210 DLC Write ICE sends

> UNBIND 0821 0002 sense code ... *** NO RESPONSE RECEIVED ***

>

> 11234 DLC ReadC Response from

> host to NOTIFY +Rsp

>

> After this,

> XPNET will attempt to OPEN the APPL, and the sequence 11034 - 11234 will be

> repeated.

>

henrybb · ‎05-31-2005

Because message length is limited to 4000 characters,additional information is following,3270 application company said:

> Questions:

>

> - why does the host not respond with a

> +Rsp to the UNBIND sent in rec 10838?

> -

> why does the host send a NOTIFY in record 10873?

>

> the host sends a BIND to ICE when ICE and XPNET are not ready for it. ICE will

> send an INIT-SELF to CICS after OPEN-SESSION if allowed to do so. We suggest

> CMBK disable the sending of BINDS by the host and allow ICE to start

> sessions.

> We suggest that CMBK check

> your VTAM definitions to see if LOGAPPLID has been set on the Tandem host link

> LUs. This setting can cause VTAM to drive CICS to send BINDs to the Tandem

> resulting in the sequence described above. We suggest that this setting be

> changed so that the host will no longer automatically send BINDs to the Tandem,

> at least until the fix in ICE is available (see below).

>

> Fix to ICE:

> Fixes to next ICE 4.1 release - July 2005:

>

> 1. change incorrect response code to BIND from

> code 0821 0002 to 083A 0002

> 0821

> 002

> 0821 Invalid Session Parameters

> (Category: Request Reject)

> 0002 Invalid

> Mode Name at CP: The specified mode name was not recognized by the CP.

>

> 0831 002

> 083A LU Not Enabled - at the time an LU-LU session

> initiation request is received at the SSCP, at least one of the two LUs,

> although having an active session with its SSCP, is not ready to accept CINIT or

> BIND requests.

> 0002 The SLU is not

> enabled.

>

> 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.

>

rclousto · ‎05-31-2005

Hi, we are investigating and will get back to you as soon as we have some information.

Regards,

Bob

henrybb · ‎05-31-2005

thanks.If you need more information,please tell me.

rclousto · ‎05-31-2005

Hi,

We agree that the -rsp BIND would be the correct action for the downstream and we think this should fix the problem.

However, there are some legitimate situations where an UNBIND request would be appropriate, for example if you had another cascaded SNASw router between the router in question and your endpoint, that SNASw router could send an UNBIND rq if its downstream link failed. So, we need to handle this situation. This would give you flexibility on which fix you want to pick up (Cisco or Tandem), assuming we can come up with a good fix. The SNASw problem appears to be that SNASw has not set up addressing in both directions because we expect the BIND rq/rsp to complete before we have to handle UNBIND. We're looking at ways to work around that.

The ipstrace you provided has wrapped and does not contain any tracing of the problem. It only has 16 seconds of output from 13:06:26 to 13:06:42. We would like to try to get a good ipstrace to capture the internal processing, if you're willing to do so. There are two things you can do to help capture the data. One is to make the ipstrace buffer-size larger. The second, and more important, would be to eliminate the failed ReqActPu requests that are filling the logs and traces, by either activating the appropriate VTAM resources or by disabling those downstream devices.

Please capture another dlctrace along with the ipstrace, so that we can correlate the time of the UNBIND rsp we are not forwarding between the traces.

Also, please go ahead and open a service request so that we can keep track of the documentation you're provided, and get all of your contact information, and IOS configuration and version information. Reference this thread and ask that the case be forwarded to our IBM team and mention that you've been working with me. If you post the SR number I can watch for it that way too.

Thanks,

Bob

henrybb · ‎05-31-2005

thanks for your reply.But our company doesn't buy SmartNet services. Maybe it is crazy,but it is.So I can't open a service request.

I will request Tandem application edit their processing flow.

If I have another cascaded SNASw router between the router in question and my endpoint,then 390 send bind request to my endpoint and that cascaded SNASW router downstream link failed. What is right action ? It should send -rsp bind or unbind to 390 ?

thanks!

rclousto · ‎06-01-2005

The SNASw router would send an unbind rq upstream, but it would also immediately clean up the session and not wait for the unbind rsp.

We had some good discussion on this issue among the team this morning. While we believe we are capable of changing our code to get the unbind rsp downstream, we are concerned that the change may affect or break other conditions. Since you have a change coming from Tandem (-BIND rsp instead of UNBIND rq) that should fix the problem, and a possible workaround (remove LOGAPPLID) that may work for you, we're opting not to make any change in SNSAw. Tandem's fix will be available to you before we could get a code change out in a supported IOS version in any case.

I'm going to open an internal defect record to document the issue and the known and possible fixes and workarounds, and then close it without a code change. This acknowledges a possible problem in the SNASw code and our decision not to make a code change at this time.

If you find the Tandem change or LOGAPPLID removal workaround does not solve your problem, please let us know and we can reopen this.

Regards,

Bob

henrybb · ‎06-01-2005

thanks for your reply.

You said:"The SNASw router would send an unbind rq upstream, but it would also immediately clean up the session and not wait for the unbind rsp" .

But if 390 send unbind rsp to the SNASW router. How it should do ? just discard it or does something else?

We define LOGAPPLID like you said. We have four lu which logon to cics-1 and other four lu which logon to cisc-2 . So we defined LOGAPPLID and I can't remove LOGAPPLID because we don't want acq the terminal in the cics manually.

Can u tell me which conditions would result other problem when you said "we are concerned that the change may affect or break other conditions " ?

I found SNA protocol is complicated and attracted . But it is out-of-date. :-(

I will wait for Tandem change to solve problem.

thanks!

rclousto · ‎06-02-2005

When SNASw gets an UNBIND rsp from the 390 it would just discard it, since it would have already cleaned up everything it needed to.

For the LOGAPPL issue, we notice that in frame 5681 the session is initially brought up on an InitSelf from Tandem ICE. So it was started without the benefit of being driven at the host by the LOGAPPL. I'll leave that to you as to what you can or cannot do but this is why we echoed Tandem's advice.

Regarding possible problems a change may cause, it's the one we can't predict that may cause a problem! We try to anticipate all possibilities and design, code and test for them, but the danger is in missing something. What we worry most about is changing our flows such that we would break some other vendor's LU application that is working with our current behaviour. That said, I think it's pretty unlikely that forwarding the UNBIND rsp downstream would cause such a problem.

Which IOS version are you running? Because Tandem is already providing a change to the flow that is causing the problem, we would not fix this in one of our "GD" releases--12.2 and earlier. For 12.3 and 12.4 we would be more likely to make such a change, but we're still reluctant when there appears to be an acceptable solution available.

Let me know if there are still any open questions.

Regards,

Bob

henrybb · ‎06-02-2005

Bob,can u give me a authoritative url which improved client must send bind rsp after it receive bind req ? It can improved thas it is improper if client send unbind req for response bind req.

I need it to satisfy my colleagues.

thanks!

rclousto · ‎06-02-2005

For some reason my replies aren't showing up today. I'm going to split them up and answer these last two posts individually and see if that works better.

The architecture reference we found which best describes our position is http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/D50A5007/6.3.141?DT=20040213113031

"UNBIND is sent to deactivate an active session between the two LUs."

It would seem logical that an "active session" means one that BIND has completed--request and response.

I'll admit this isn't totally conclusive. It does not explicitly preclude an UNBIND from being sent if the session is not completely active, though we interpret this to mean its the only time UNBIND is valid. We've found on more than one occasion the documented SNA architecture is vague and even conflicting in some places.

henrybb · ‎06-03-2005

thanks for your reply.

In your given url

http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/D50A5007/6.3.141?DT=20040213113031

It mentioned "An UNBIND is sent instead of a -RSP(BIND) as a reply to BIND (to reject the BIND) only if the BIND is extended and no errors limit recognition of the BIND as extended. "

So I think it is right when Tandem response UNBIND for bind req from 390 because the bind is extended bind. You can see attached file.(something is wrong with forum,I can't attach file.I will try it later or you can give email address)

Do you think that ios has bug ?

My ios version is c2600-a3js-mz.123-8.T3.bin.

thanks!

henrybb · ‎06-03-2005

try so many times and it success finally.

The attached file is sniffer trace file. I change file format to jpg.You can see the format of bind req which 390 send to Tandem.

thanks!