Having Problems with DLSw+ to SNASw

[bkoryus]

Hi, I’m having trouble getting DLSw to SNASw working and I’m hoping somebody might have came across this type of problem before. Let me first explain the design we have in place:

3174(PU)—s1/1--- 2610–DLSw------telco circuit----------DLSw-7206vxr--SNASw------4503-------OSA/Express

We get our SNA Switch link to come active as a network node, no problems with that function. Our DLSW circuits go connected from the 2610 all the way to the 7206vxr router. Our DLSW circuits get connected to the VDLC999 Port on the 7206vxr router. However, the mainframe sees the Switch Major Nodes as being CONT status, no activation. When we look at the SNASW session the controllers show to be retrying and just stay there. Also when we look at the SNASW DLUS we see the Pipe in an Inactive status. When we look at the PDLOG we are seeing the CPSVRMGR session keeps failing. Any thoughts on what might be going on and why?

Router Configs:

2610

!

dlsw local-peer peer-id 8.42.33.9

dlsw remote-peer 0 tcp 8.42.99.9 lsap-output-list 202

dlsw duplicate-path-bias load-balance

dlsw timer explorer-wait-time 5

!

interface Serial1/1

description ** IBM 3174 PU2.0 CONTROLLER **

bandwidth 19200

no ip address

no ip directed-broadcast

encapsulation sdlc

no ip mroute-cache

no keepalive

sdlc role primary

sdlc vmac 4000.3311.8500

sdlc poll-limit-value 2

sdlc address 13

sdlc xid 13 01757564

sdlc partner 4000.9999.1234 13

sdlc dlsw 13

end

******************************************************************

7206

!

source-bridge ring-group 999

dlsw local-peer peer-id 8.42.99.9

dlsw remote-peer 0 tcp 8.42.33.9 lsap-output-list 202

!

snasw cpname AirLine1.IBM7200

snasw dlus AirLine1.P25

snasw port VDLC vdlc 999 mac 4000.9999.1234 conntype nohpr

snasw port EE hpr-ip Loopback0

snasw link HOSTCMC1 port EE ip-dest 8.42.37.1

!

Thanks,

Bob

[rclousto]

The CPSVRMGR session for the DLUR pipe will come up when SNASw sends the first ReqActPU, and will come down if it fails and there are no other active/pending sessions. So this session going up and down is just a symptom of the PU problem.

If there's nothing in the pdlog about the PU failure, you need to check the VTAM console or take a SNASw dlctrace to see the failure. The sense code will be useful.

Is the Switched Major Node actually Active, and the PUs under them CONCT? If the SwMajNode is not active you need to activate it first, but if VTAM returns a display for the PU, the SwMajNode must be active. Otherwise the problem may be that the 3174 PU name or IDBLK/IDNUM does not match the VTAM definition.

It sounds like both the downstream 3174 link (@I00000x) and HOSTCMC1 link are staying active, right?

If this doesn't help you resolve it, it would probably be best to open a Service Request with the Cisco TAC, and provide what you already have along with the VTAM PU display and definition for the PU, and the snasw dlctrace and pdlog, and relevant config information on the 3174.

Regards,

Bob Clouston

[bkoryus]

Hi Bob,

The SMN is active and the PU under it stays in a CONCT (we have one SMN define for each PU) status.

The HOSTCMC1 and @I0000x goes active. But the @P0000x stays retrying (because Pipe is not going active, if I understand how SNA Switching works).

I've got an open TAC case with Cisco and SNA Switching DE has reviewed the PDLOG and DLCTRACE and didn't find anything on the routers. We had IBM PMR review our Vtam Intenal trace and a Vtam Packet trace, there thoughts are its something with the way the 3174 controller is configured. I just have a hard time understanding what type of configuration might be in a PU2.0 device that wouldn't allow a Req Act to establish a session.

I know if I peer the 3174 to a 3745 FEP with the MAC address define in the Serial Interface on the 2610 router the PU comes active in Vtam.

The sense code we are getting when we try to bind with CPSVRMGR is 0x08A00008.

Thank you for your reply. I've been reading the conversations in this forum and see your probably one of the most knowledge ones in it. Hopefully, you might have run across this problem before and could point me in the right direction.

Thank you,

Bob Koryus

[rclousto]

Hi Bob, I see the case now (SR 601727865), and I've already discussed it with the TAC engineer. This is an odd one as VTAM actually UNBINDs the CPSVRMGR session rather than rejects the ReqActPU. In a "normal" failure we would expect to see the ReqActPU rejected, and then SNASw would unbind the CPSVRMGR session if this were the only PU on it. We were hoping IBM would have some comment on this from the VIT trace.

I'll re-review the logs/traces attached to the case and see if I can come up with anything new. This forum is a good way to see if any other customers have hit and solved this problem, so we'll see if anyone else has ideas here. I'll also look back in our TAC database to see if this has come up before, though I suspect Werner has already done so. I can't recall seeing this before myself.

Regards,

Bob

[bkoryus]

Bob,

Thank you for the reply. I've asked Werner to see if he might be available Monday for a conference call with IBM PMR team, we are discussing this issue with them. We really want to get SNA Switching we want to get all 3745's out before we upgrade to a Cell base MPLS network (which starts up in a couple of weeks). Anyway anything you can do or find would be much appreciated..

Thanks,

Bob K.

[bkoryus]

Bob,

Looks like IBM resolved the problem. They had to change something on the mainframe. I've asked the Sr Vtam person to give me what they changed so I know. When he forward it to me I'll post it. In case somebody else has this type of problem.

Thanks,

Bob

[rclousto]

That's good news! From the case notes it sounds like they had to enable APPN directory searching, it was subarea only and that didn't work with the SNASw DLUR.

Regards,

Bob

[bkoryus]

Bob,

Yes, that was the resolution.

Thank you,

Bob K.