Is it possible to have a DLU Requester downstrwam of SNASw BrNN ?

[j.verboom]

Microsoft Host Integration Server 2003 lacks APPN

Virtual Node (aka Connection Network) functionality.

When LPAR1 is the Primary Network Node Server for HIS.

ALL sessions orginating or terminating in the HIS Server

will pass through Intermediate Routing Node LPAR1.

This solution will cause a lot of unnecessary Mainframe I/O

and usage cpu cycles. This APPN Network consist of some 30

APPN nodes as well as some 25000 sessions in prime time.

+------+ +-------+ +-------+

| | | | | |

| HIS | | LPAR1 | | LPAR2 |

| EN | <- EE -> | NN | <- EE -> | NN |

| DLUR | | DLUS | | |

| | | CDS | | |

+------+ +-------+ +-------+

To eliminate this perceived problem we propose to use the

SNASw Virtual Node capability. If this works no sessions

will run through LPAR1 between the HIS and LPAR2.

<------ Downlink ------> <------ Uplink ------>

VN

+------+ +--------------+ +-------+

| | | | | |

| HIS | | SNASw | | LPAR1 |

| EN | <- EE -> |.......+......| <- EE -> | NN |

| DLUR | | BrNN | EN | | DLUS |

| | | | DLUR | <- | CDS |

+------+ +--------------+ \ +-------+

\

EE +-------+

\ | |

\ | LPAR2 |

-> | NN |

| |

| |

+-------+

The above scheme results in the following

- All PU and LU of the HIS Server are registered with the

SNASw directory database.

- A APING from the Mainframe LPAR1/2 to the HIS Control

Point name will show a route containing the SNASw & HIS

nodes. Sometimes however the route will end with the SNASw.

- Session requests for 3270 LU (DLUR) always seem to arrive

at the destination LPAR, but the reversed path runs into

trouble with sense codes like 08060031, 08900037

AIW document :

APPN Branch Extender Archtecture Reference

6.8 Local Independent LUs and DLUR Support on BrNN

explicity states :

Support for DLUR is optional on a BrN, but DLUR is so

important that we can't imagine any Branch Extender product

leaving it out

The footnote on the same page states :

Without option sets 1116, 1122 and 1123, a DLUR downstream of

BrNN would be broken because the BrNN represents itself as the

ENCP owning all domain resources; therefore searches involving

a downlink DLUR with the Owning-CP-Respond indicator set would

not work right.

[romney · Accepted solution]

Hello Jan,

the answer is NO. The option sets you referenced were an attempt to make this work, and snaswitch did indeed implement them, but subsequent testing by IBM, Cisco, and other vendors (back in 1999) found that the architecture as it now stands is broken. Here is an excerpt from an e-mail on this topic ...

The following is being forwarded to the aiw-appn-reference mailing list.

Message originally sent on July 15, 1999 by brabson@raleigh.ibm.com

---------------------------------------------------------------------------

There seems to be renewed interest in Downstream DLUR support from a

Branch Extender (BEX) and problems various products are having in

implementing the function. I've talked with several folks in VTAM

regarding these problems and the consensus of the group is that we do

not believe it can be made to work given the current architecture. It

does not matter if the DLUR is downstream from a BEX node with or

without DLUR support. In both cases, there are problems which creep

into the equation which will likely cause failures at some point in

time.

To help everyone understand why we feel this does not work, I'm going to

describe a few of the issues which we discussed. I'm quite certain that

if we had spent more time talking we would have found additional

problems. However, the set below were sufficient enough to convince

everyone in the meeting that the function does not work, and cannot be

made to work without additional architecture work and changes to VTAM.

That part of the architecture (including these option sets) would need to be rewritten by IBM (who own it), and then all the products involved would need to make the necessary changes. Thus far there has not been enough customer demand for this function to make this happen. We are asking IBM to at least update the Branch Extender architecture to acknowledge that it is broken.

If this function is something that you truly need please open a dialog with IBM and copy me (romney@cisco.com). In the meantime, have you tried configuring the HIS so that it is not the DLUR, but instead use an LLC connection to SNASw where it can then act as DLUR?

- Ray

[j.verboom]

HIS is now configured to use LLC, which works fine.

[romney]

I'm glad to hear it! Thanks for the feedback.