• Configuration members (named CONFIGyy)
• Other members identifying applids, terminals, adjacent networks, and other resources.
When the system is IPL’ed, MVS issues a START NET command to start VTAM. This command will tell VTAM the last two characters of the start-up member (ATCSTRxx). VTAM reads this member and from it determines the options to execute with. The start-up member also contains an operand named CONFIG=yy, which specifies the last two characters of the configuration member. VTAM reads the configuration member, which contains the names of other members that describe the APPLIDs and other resources VTAM is to use. VTAM then reads each of these members, saving the information in tables in memory. VTAM uses these tables to determine whether to accept requests for binds between a terminal and an APPLID.
Much of the security and control is derived from this rule: Within a given MVS image, no terminal or APPLID can communicate over the network unless it’s defined in the SYS1. VTAMLST data set.
Step 2: Let’s assume you have two MVS images, one for test and one for production. Further assume that a terminal defined to VTAM on the test image wants to connect to an APPLID (say a CICS region) defined to the production VTAM. This is possible if each VTAM is defined to the other VTAM, and if each VTAM has the other VTAM’s resources defined as “cross-domain resources.” The other VTAM and the other resources will be defined in members of SYS1.VTAMLST. The resulting connection is called a “cross-domain bind.” The term “domain” here corresponds to one MVS image.
Much of the security and control with cross-domain connections is derived from this second rule: With cross-domain connections, no terminal or APPLID can communicate over the network unless it’s defined in SYS1. VTAMLST on both domains.
Step 3: Our last step is to examine cross-network connections (such as if your SNA network is connected to a business partner’s SNA network). Unlike the previous two steps in which VTAM only allows connections between terminals and APPLIDs defined in its control file, cross-network connections can allow dynamic binding. A terminal in your network can connect to an APPLID defined in your business partner’s network without the APPLID being defined in your SYS1.VTAMLST.
This may be perfectly acceptable if you can trust your partner. However, you will want to know to what other networks your partner’s network is connected. A terminal in your network can connect to an APPLID in some other network as long as that other network is connected to your partner’s network, or to a network connected to your partner’s network, and so on. If this dynamic binding is permitted, then it’s possible for some other network to spoof (assume the identity of) your partner’s network. You will want to make sure you have controls in place to prevent this.
To summarize, follow these steps to evaluate the SNA part of your network:
1. Map your network’s name, its MVS images, terminals, APPLIDs, crossdomain connections, and partner networks. You will get this information from the SYS1.VTAMLST data sets on each MVS image. You may need your VTAM systems programmer’s assistance in interpreting and verifying this information.