TCP/IP supports more than a dozen different types of device attachments to the network. The most significant one is the OSA-Express adapter. There are two statements involved in configuring any adapter for TCP/IP on a z/OS host: a DEVICE statement and a LINK statement.

In Figure 1, there are three different adapters configured, and the first two of them are OSA-Express links.

 DEVICE OSAEDEV1 MPCIPA PRIROUTER
 LINK OSAELNK1 IPAQENET OSAEDEV1
  
 DEVICE OSAEDEV2 MPCIPA PRIROUTER
 LINK OSAELNK2 IPAQENET OSAEDEV2
  
 DEVICE VIPADEV1 VIRTUAL 1
 LINK VIPALNK1 VIRTUAL 1 VIPADEV1
  
 HOME
  201.2.11.9 VIPALNK1
  201.2.11.1 OSAELNK1
  201.2.11.2 OSAELNK2

Because z/OS supports so many different hardware devices, the device and link statements are unique, depending upon the hardware they are defining. However, statements consistently follow a pattern in which the first parameter is the device or link name and the second parameter provides information with respect to that hardware being defined.

For example, the first DEVICE statement has been assigned OSAEDEV1 for a device name, and the device itself is going to be an MPCIPA type device. MPCIPA is the device type used by TCP/IP when the hardware is capable of QDIO-type communication. The subsequent LINK statement, assigned a name of OSAELNK1, further modifies the QDIO definition as IPAQENET. IPAQENET indicates that the link is a real OSA device. By "real," this is to differentiate it from an IQDIO (remember, the I stands for internal) device, which would use a type of IPAIQDIO.

There are a few other options here that warrant special notice. The PRIROUTER parameter is necessary if this link is expected to handle packets destined for other networks or subnetworks. With PRIROUTER coded, the adapter not only accepts datagrams for IP addresses that are defined to the TCP/IP stack, but this parameter also causes the adapter to accept datagrams sent to it that are destined for any IP address. It is up to the TCP/IP stack itself to then decide what to do with the packet.

The next statement of interest in this sample is the HOME statement. The HOME statement's parameters consist of simple IP address and link name pairs. The HOME statement must include an IP address and link name pair for every hard-coded link active in the stack. For example, many z/OS hosts would have a second OSA-Express card defined and its home address would be included in the HOME statement.

An OSA-Express device, as configured in this sample, downloads all IP addresses found in the HOME statement.

This brings us to the VIRTUAL DEVICE and LINK statements. TCP/IP on z/OS supports what is known as a virtual IP Address, or VIPA. Conceptually, VIPA is very simple: a VIPA address is functionally identical to any other IP address defined to the TCP/IP stack except that it is not dependent upon any physical networking hardware. A VIPA link is defined in software only; there is no physical hardware associated with it at all.

Why bother? Well, a VIPA address cannot suffer a hardware or LAN or link failure. It is always available. In our sample above, the user community would not be told to connect to the real links. Instead, clients would connect to 201.2.11.9, the VIPA address. If either of the two OSA links failed, the VIPA address would continue to be available using the adapter that still remained active.

Figure 2. Examples of virtual IP addresses

In Figure 2, there are two different examples of how a VIPA address can be placed within a network (routing) topology. In LPAR 1, the VIPA link uses the same subnetwork as the OSA-Express links. From a network topology perspective, the VIPA address functions as an alias of either OSA card.

In LPAR 2, the VIPA address is on its own unique subnetwork. A router adjacent to this LPAR (in this sample, Router 2) would consider the VIPA address to be two hops away. The next hop for such a router would be to send the packet to one of the OSA-Express cards. The final hop, from the OSA-Express adapter's address (subnetwork) to the VIPA's address (or subnetwork), is completed internally in the z/OS IP stack.

The scenario used for LPAR 2 is the preferred scenario. If the VIPA address is placed in the same network as the physical adapters, then it must always remain part of a TCP/IP stack that has an adapter on that physical network. In other words, the VIPA becomes confined to remaining adjacent to the subnetwork of the physical network that it belongs to. When the VIPA is in its own unique subnet, it can be moved to any TCP/IP stack in the network (and dynamic routing takes care of locating it).