Visara FEP-4600 Planning Guide - Manual (Page 22)

Chapter 2. Support of PU 2.0 Platforms
2-4 707117-003
Local Major Node Gateway Operation
Beginning with IBM’s 3174 Token Ring gateway in the late 1980’s, PU 2.0 Gateways
have been around for several years so the technology is well proven.
The FEP-4600 sits on the ESCON channel appearing as one or more locally attached PU
2.0 platforms (such as a 3174). Each locally attached PU 2.0 image requires a single
subchannel address. Multiple images are supported by using multiple subchannel
addresses. Usually these addresses are grouped consecutively to make the host definitions
simpler, and to conserve CU resources. Each PU 2.0 within the group can be
independently routed through the FEP-4600 onto whichever interface is needed to reach
the destination. By grouping the addresses consecutively, you can use a single
CNTLUNIT macro and a single IODEVICE macro to define multiple remote PU 2.0
platforms. Each CNTLUNIT macro corresponds to a single CU definition in the FEP-
4600.
The FEP-4600 is capable of supporting up to 16 CU definitions per ESCON interface. As
many as 256 PU 2.0 platforms can be supported through a single ESCON interface.
Through EMIF running on the CPU, the FEP-4600 can support connections to multiple
LPARS over the same ESCON connection. Each LPAR that is to own PU 2.0 resources
connected through the FEP-4600 requires a separate CU definition.
Similarly, through use of ESCON directors, the FEP-4600 can communicate with
multiple CPUs through the same ESCON interface.
Running as a gateway, the FEP-4600 spoofs the ESCON PU 2.0 operations and provides
the correct ESCON responses as if the PU 2.0 nodes were actually locally attached
directly to the ESCON connection.
The SECNET=YES parameter (part of the PU definition) is used to inform supervisory
packages such as NetView that the PU is not directly attached to the channel, but is
located on a secondary network.