SNASWITCHING call-out

[msartorel]

SNASWITCHING is able to call-out a remote SNA PU if it receives an order from VTAM Host. VTAM host uses DLCADDR parameters to send orders to SNASW. I am not able to find how to code the DLCADDR parameters in the way SNASW understand them.

Moreno Sartorel IBM Italy

[htranphu]

Here are the config rules:

PATH DLURNAME=NETA.,

DLCADDR=(1,C,TR),

DLCADDR=(2,X,, for example D7D6D9E3F1000000 for PORT1),

DLCADDR=(3,X,04),

DLCADDR=(4,X,)

Regards,

tran

[romney]

One minor correction and one comment ...

PATH DLURNAME=

I believe TR format is the only one supported. You can still connect to downstream Ethernet devices, you just have to specify the address in TR format.

- Ray

[msartorel]

Thanks!! The call-out succeeded, the DLCADDR=(2,name of snasw port) was the parameter that solved the problem... Is this documented somewhere? Thanks a lot again. Moreno

[romney]

Hi Moreno,

no, it is really not documented anywhere that I have found. Probably part of the reason why is that the configuration for this is on the host. Since the DLCADDR=(2,port name) seems to be the most confusing part we could add a comment in the IOS Command Reference and IOS Configuration Guide under the snasw port statement under the name keyword. I'll open a sys-doc ddts to get this done. We might also want to add something in the SNASw Design and Implementation Guide.

- Ray

[msartorel]

Using your suggestions, I succeeded in activating dial-out. When I perform V NET,DIAL from the VTAM, the remote PU become ACTIVE and this is a success! But when the PU become active, the SNASW dowstream link created is the following:

Link Name State Port AdJ CP Node type

139> @U000003 Active DLSW1 --- PU 2.0 1 No

That is, remote PU is recognized from SNASW as PU2.0 and no information about it's CP name is reported.

But, remote PU specifies a CP name, in fact if I display the PU from VTAM after it becomes ACTIVE due to dial-out, i see the following display:

C PRDB DISPLAY NET,ID=PNGCED1P,SCOPE=ALL

PRDB IST097I DISPLAY ACCEPTED

' PRDB

IST075I NAME = PNGCED1P , TYPE = PU_T2.1

IST486I STATUS= ACTIV , DESIRED STATE= ACTIV

IST1043I CP NAME = NORAVV02, CP NETID = IT00CBM , DYNAMIC LU = NO

IST1589I XNETALS = YES

IST1354I DLUR NAME = SESNARM1 MAJNODE = WNGCED1P

IST136I SWITCHED SNA MAJOR NODE = WNGCED1P

IST654I I/O TRACE = OFF, BUFFER TRACE = OFF

IST1500I STATE TRACE = OFF

IST1656I VTAMTOPO = REPORT , NODE REPORTED - YES

IST1657I MAJOR NODE VTAMTOPO = REPORT

IST172I NO LOGICAL

VTAM reports CPNAME and NETID of remote PU. And these informations comes for sure from SNASW (I didn't specify them on the Sw major node), so I think they are passed to VTAM from SNASW.

The problem is that, because the remote PU is PU2.1 with INDEPENDENT LU, and the session must be started from the HOST, I need to code a SNASW LOCATION on SNASW to make it register the LU to VTAM.

But SNASW LOCATION doesn't work if remote CPNAME is not recognized.

Do you know if SNASW location should work also when the PU is dialled-out from SNASW and not only when the dial is performed from the remote?

Many thanks in advance, Moreno Sartorel

[romney]

Hi Moreno,

snasw should learn the cpname from the xid.

It would be best to capture a dlctrace to see what the xid exchange looks like. You configure snasw dlctrace, then perform the dial out, and as soon as you see the link is active issue snasw stop dlctrace. You can then issue show snasw dlctrace all to find the id numbers of the trace records for the xid exchange, and then issue show snasw dlctrace detail id xxx-yyy to see the detail of all the xids.

I'd also like to see how the downstream port is configured in snaswitch. snasw location only works when the conntype is len.

- Ray

[msartorel]

I Ray, I have taken the DLCTRACE, at the top of the file I added some instructions to help you to position in the right point (PUname, cpname, ...)

The DLC trace was taken before performing the dial-out from VTAM

I confirm you that the DLSW1 SNASw port addresses by the dial-out in conntype LEN

Moreno.

[romney]

Moreno,

thank you for capturing the traces. I also confirmed in my lab that currently snaswitch always assumes downstream dial-out is to a PU 2.0, and therefor we don't learn the cpname (even though we pass it up to VTAM in a CV x'0E' on ACTPU rsp.

I'm sorry, but for the present if your device has independent LUs your only option is to configure the device to initiate the connection rather than having the host initiate the dial out. How many such devices do you have in your network?

We have very few customers that use dial out to begin with, and you are the first that has ever tried to do it to a device with independent LUs. If the above workaround is not acceptable then you can open a TAC service request and we can look at changing this so that the type of XID presented by snaswitch could be controlled by a keyword on the port (conntype or some new keyword yet to be added). I can't promise that such a change would be possible or when it would be available, but we can start the process of evaluation if that's what you need.

- Ray

[msartorel]

Ray, first of all let me congratulate for the usefulness of this forum; you gave me answers (even if not so positive..) in a very short time.

But, I can tell you that my customer is disappointed; he has about 10 remote customers that are now dialed thru VTAM/NCP; he needs to remove the NCP and we sold him SNASW to do that.

If you read SNASW manual, ii says that

"SNASw can receive connect-out instructions from the IBM Communications Server for S/390. This

function allows the system to dynamically connect-out to devices that are configured on the host with

the appropriate connect-out definitions. This feature allows connectivity to SNA devices in the

network that were traditionally configured for connect-out from the host.

Note DLUR connect-out can be performed over any supported data-link type"

No mention about PU2.0 only support. We can open a TAC, but it seems to me that you it will receive a very low priority. But it seems to me that we are not requiring a new functions, but instead we are asking for the solution of a bug.

Which is your opinion about? Do you think that if we open a TAC, it will accepted as a bug, or as a new function requests, so it will take a long time to be developed?

Thanks again, Moreno

[romney]

Moreno,

I'm glad this forum has been useful. I too was surprised that PU 2.0 is assumed on dial out with no other option, and in that respect I wouldn't disagree that this could be considered a bug (or at least a poor design). At the very least the documentation is lacking that detail (as you mentioned). However, your customer's configuration is quite unique ... a PU 2.1 with independent LUs almost always initiates the connection. That is why this has never come up in the 5 years that snaswitch has been in production.

I would not say that we are giving this a low priority ... on the contrary we are meeting today to discuss how a change could be made. But I wanted to be realistic too. Changing 10 devices, even if they are remote customers, will likely take less time than waiting for an IOS image with a fix in it. And there is always the chance that we will find the code change too large or too risky to make.

If your customer wants to pursue this a TAC service request provides a way to open and track a ddts and coordinate further discussions and testing. What kind of timetable do you and your customer have for resolving this?

- Ray

[msartorel]

Ray, yes our configuration is quite unique, but this is how customer was working for a lot of time. It's not so easy to ask remote customers to change the call procedure, because there is not a real workstation, but a software that simulate a PU2.1 and that is contacted by the HOST to send data when they are ready to sent.

I have just talked to my customer and he is intentioned to open a case to TAC.

Our time frame? This is the last type of connectivity we need to migrate in order to free the 3745 communicaton controllers..., so as soon as possible.

Thanks again, Moreno

[rclousto]

Hi Moreno,

I believe Ray is travelling today. Please post the case number when you have it or send it in an email to any or all of us on the development team: romney@cisco.com, rclousto@cisco.com, and htranphu@cisco.com. That way we'll be sure the case is routed to us right away. Meanwhile we'll continue or investigation of what it will take to make this change and identify any potential risks.

Regards,

Bob

[romney]

Hello again Moreno,

has the customer opened the TAC Service Request yet? We really need that ASAP to move this forward. Please have them mention my name in the SR and ask that I be contacted. Thanks!

- Ray

[a.mountouris]

Hello all,

I am involved in a similar situation described on this discussion. Although we have not yet arrived at the point where FEP will be substituted by SNASw routers (this is our second phase, first we use cisco routers as plain x25 switches where all resources plus fep are attached), I would like your opinion if this could be done. In another discussion I have opened investigating the possibility of having x25 (qllc) resources to connect through snasw to ethernet OSA, the result was possitive. This can be done as also described in a snasw example (qllc convertion to ethernet through snasw and vdlc support).

In again another discussion it was pointed out to me (by Rober Clouston) that the 12.1 IOS has two bugs for the connect out dial (when VTAM dials the PU). A circumvention was given there, to use in the DLC argument the name of the snasw port coded with 8 characters (or it should be the snasw vdlc port, the port where the downstream devices are attached to??).

What I want to confirm here is if this dial operation will work even though we have qllc resource attached through x25 serial interface on the router while the VTAM is attached through OSA ethernet card.

Will still I have to use the snasw port name?? (or is it the vdlc port name??)

Or should I code in dlcaddr argument the virtual mac that will be assigned to the incoming call?