An APPN virtual controller is a controller description that Advanced Peer-to-Peer Networking® (APPN) can use, and that high-performance routing (HPR) support uses. It can be used to attach and manage advanced program-to-program communications (APPC) device descriptions. This type of controller does not represent a connection to a remote system. On iSeries™, local applications that need to establish LU 6.2 sessions to other locations in the APPN network require an APPC device description that specifies APPN(*YES). For simplicity, these devices are referred to as APPN devices.
The Allow APPN virtual support (ALWVRTAPPN) parameter is on the Change Network Attributes (CHGNETA) command. If the ALWVRTAPPN parameter is *YES, any existing APPN devices that are attached to the real APPN controller description will not be allowed to vary on. Message CPDB157 will be issued. If migrating to this new APPN object model, you may want to delete any existing APPN devices because they will no longer be used. You may also want to delete the devices if you have no intention of resetting the ALWVRTAPPN parameter to *NO.
APPN virtual controllers provide the following:
Prior to supporting APPN virtual controllers, multiple APPN device descriptions can be created and used simultaneously to communicate between the same local location and remote location pair. This situation was possible because alternate paths exist through the network. The first hop out of the local system (that is represented by a controller description) can be different for the two paths. After a session is established, the same APPN device description is used for the life of that session. With APPN virtual controller support, you can accomplish all communications between the same local location and remote location pair using a single device description. This single device description can be used, even if multiple paths to that remote location exist in the network.
iSeries allows a maximum of 254 devices to attach to a controller description. In some environments, there may be a requirement to access more than 254 different locations (that are each represented by devices) through a single system. For example, an iSeries may attach to a System/390®, connected to hundreds of systems that the local iSeries would like to communicate with (through System/390). Without APPN virtual controller support, this communication requires the definition of parallel transmission groups (multiple controller descriptions) between the local system and System/390. Using multiple real controller descriptions can be costly in regards to both the line costs and managing multiple connections. With APPN virtual controller support, you use one real controller description, but attach more than 254 devices that are spread across more than one virtual controller.
APPN virtual controller descriptions do not associate with any communication lines or adjacent system. Thus, there are no communication failures to associate with these controller descriptions. This situation highlights some key points regarding error recovery:
When APPN virtual controller descriptions are not used, device descriptions attach to APPN controller descriptions that represent connections to adjacent systems. When communication failures occur, applications that are affected by the session outages must be notified. The system also performs error recovery on the controller description and all of the attached device descriptions. In some large environments, device error recovery can take a lot of time.
When APPN virtual controller descriptions are used, the APPN controller descriptions that represent connections to adjacent systems do not have device descriptions attached. When communication fails (for example, a line failure), the applications affected by the session outages are notified. The system recovers errors on the controller description. No error recovery is required on the device descriptions if each of the following are true:
Eliminating error recovery at the device level can help decrease the amount of time iSeries requires to recover errors after some communication failures.
For more information about getting optimal performance from your network, see the page Designing an APPN and HPR network.