Key mainframe network availability aspects

The extent to which organizations go in order to ensure a high availability z/OS networking environment varies.

Organizations buy mainframes for many reasons, but they generally fall into one or more of the following categories:

Reliability, availability, serviceability (RAS)
Security
Scalability
Continuing compatibility
Evolving architecture

Table 1 looks at these categories from a z/OS networking perspective.

Table 1. z/OS network availability aspects
Category	Examples
RAS	High quality hardware and software components. Software put through rigorous compatibility testing. OSA-E cards provide dynamic failure detection, takeover, and recovery. VIPA (virtual IP address, which is not tied to any physical interface) provide movability and availability of IP addresses, independent of physical network adapters. Many components, adapters, and disk units can be replaced, serviced non-disruptively.
Security	Intrusion detection and control (through TCP/IP). Monitoring and reporting features. Network resource access control. Cryptographic processors, network security protocol support. External security control (through the System Authorization Facility).
Scalability	Can handle very large customer loads and growth. Dynamic non-disruptive expansion. An example of an IBM internal test to show scalability: an environment with 64,000 concurrent Telnet 3270 sessions performing 6,242 transactions per second has been demonstrated successfully.
Continuing compatibility	Compatibility of older applications, device types, and software with the newer releases of networking components is a key feature.
Evolving architecture	The z/OS networking components are continually being developed. Enterprise Extender was designed to assist with transporting SNA over IP networks. Nondisruptive VIPA movement and distribution features assist with making the z/OS environment more robust and available.

Key aspects that you as an mainframe network administrator should look for in terms of RAS might include:

Component failure. Each component should be analyzed for what would happen if this component failed, and it does not have a backup.
Dual and diverse paths. Is there more than one network path that provides an alternative route to a target, should a component fail?
Performance. Can the alternative component handle the load and performance on its own, should a failure occur on the primary component? If load balancing, each component should have the capacity to takeover the load and performance, if required.
Failure process. How transparent would a component failure appear to a client of z/OS? The aim should be that any failure results in a non-disruptive dynamic change, that has minimal impact on the client. This is not always possible, but should be strived for.
Security. What are the client's requirements for securing network access? This requirement might be within the z/OS security team's purview, but you might be required to implement TCP/IP or VTAM features to meet the security policy.

There are many more criteria that could be applied; for example, is the solution scalable and manageable, and will it meet the service level agreements (SLAs) agreed with the business?

Reminder: An SLA is a formal document between a service provider, such as the organization running the mainframe, and its customer, the recipient of the service. Customers of an SLA may be internal to the organization.

Our sample network is designed with a focus on maximum availability. If a component fails, then another component should be able to continue in its place. There are hardware and software components that contribute to availability, as described here.