Connecting networks

When you are planning to connect networks, you should consider the following, and if necessary, discuss these things with the system programmers for the networks that are being connected:

To guarantee uniqueness, know the SSCPIDs and the NetView® domain IDs used in each network, or use a naming convention.
If you own a gateway NCP:
- Obtain the MAXSUBA specification used for any attaching network that contains nonextended subarea addressing nodes so that you can code the MAXSUBA operand on the NETWORK definition statement in the gateway NCP.
- Specify an available subarea number in the attaching network on the SUBAREA operand on the NETWORK definition statement.
- Know how many subarea nodes can communicate with the gateway NCP in the attaching network so that you can code the NUMHSAS operand on the NETWORK definition statement in the gateway NCP.
- Exchange information about explicit route and virtual route structures so that you can code PATH definition statements for nonnative networks in the gateway NCP.
If you plan to code GWPATH definition statements, you need to know the subarea and element addresses of all CDRMs in adjacent networks with which your gateway VTAM® is to establish sessions.
If you are not using network-qualified names, to avoid future name conflicts, decide upon a naming convention for alias names and for real names.
If you want to guarantee that certain application programs can always obtain an alias address, you need to know the real logical unit names of those application programs. These names are required on the GWNAU definition statements that predefine specific resources in the gateway NCP.
Tell system programmers for the other networks the names to be used for logical units. Discuss equivalent COS and logon mode entry names.
Some application programs require a definition for each of their session partners. If these application programs are to have cross-network sessions, define one of the following to the application programs:
- Alias names for session partners in other networks
- LU alias names (on the CDRSC definition statements) for session partners in other networks
- USERVARs that map to the network-qualified names of session partners in other networks
If you code a CDRM operand on a CDRSC definition statement and you specify a NETWORK definition statement for it, use the real SSCP name for the host in the other network.
The real SSCP name is the name specified in the SSCPNAME start option. For any host for which SSCPNAME is not specified, the real SSCP name is the name of the host CDRM for that host. You should use this name on your definition for this CDRM if you code such a definition.
If you code a CDRM definition statement in an adjacent SSCP table, specify the real SSCP name on the label of the CDRM definition statement.
If you code an SSCP name on an LU definition statement for the NetView alias name translation facility, you must specify the real SSCP name.
You must code the real SSCP name on the ADJCDRM operand in an adjacent SSCP table.
Ensure that the COS table named in the COSTAB operand of the BUILD definition statement or a NETWORK definition statement in the gateway NCP is available to the gateway SSCP. You must install it in VTAMLIB. The table specified in the COSTAB operand is used for mapping Class of Service table entries for the routes that originate in the gateway NCP and terminate in the network being defined. If a COS table for the connected network is not supplied, the COS table for your network must include any COS names that can be requested by logical units in other networks.
Ensure that NCP data transfer related operands (such as UNITSZ, TRANSFR, and BFRS) that are coordinated between domains in a multiple-domain network are also coordinated between interconnected networks.
If you use the NetView program, you need to know the NetView suppression characters used in every domain in every network to ensure that the characters are all the same.