Mainframe network concepts and functions
In this chapter, we introduce mainframe network concepts and the latest networking technologies. We start with an overview of the network architecture and the various communication protocols, and then introduce the IBM z/OS Communication Server and its components. We also describe how the networking technology has evolved over the past years.
We take a look at the IBM Systems Network Architecture (SNA), including basic and Advanced Peer-to-Peer Networking (APPN). We then explain the TCP/IP implementation on z/OS and examine the SNA/IP implementation with a focus on the Enterprise Extender technology. We explain the TN3270 Enhanced protocol, its evolution, and provide a brief overview on the implementation. We also describe RDMA connectivity, which is a method of network connectivity added in version 2.1. Next, we cover the hardware connectivity on the mainframe and focus on the different types of connectivity. We include network software functions, such as FTP, SFTP, and SMTP. We conclude the chapter with information about the network management and network monitoring products that are available, with short descriptions of their functions.
 
Note: IBM z Systems platforms were previously called IBM System z platforms. Therefore, any text or labels in figures that say "System z" are valid for z Systems.
This chapter includes the following sections:
1.1 Introduction to mainframe networks
The z/OS network capability includes a full-featured Communications Server with integration of SNA and TCP/IP and RDMA protocols. This enables the mainframe to serve a large number of worldwide clients and applications simultaneously. The z/OS Communications Server provides a set of communications protocols, SNA, TCP/IP and RDMA, that allow these clients and applications to send and receive data using both local and wide-area networks (WANs).
This section covers the following aspects:
1.1.1 Technical overview
The z/OS Communications Server provides a set of communications protocols that support peer-to-peer connectivity functions for both local and wide-area networks, including the most popular wide-area network, the Internet. z/OS Communications Server is the IBM implementation of SNA and standard TCP/IP protocol suites on the IBM System z platform and also includes support for RDMA.
SNA is an IBM proprietary networking protocol, whereas TCP/IP is a component product of the z/OS Communications Server that provides a multitude of technologies that collectively provide an Open Systems environment for the development, establishment, and maintenance of applications and systems. RDMA is a high-speed, low latency, low CPU method of connecting servers that share a common LAN segment. RDMA is supported on z/OS using the Shared Memory Communications over RDMA (SMC-R) protocol that was first implemented in z/OS version 2.1 (V2R1).
z/OS Communications Server is a base element, meaning that it is part of the z/OS operating system. It provides both SNA and TCP/IP networking protocols for z/OS. The SNA protocols are provided by VTAM and include Subarea, Advanced Peer-to-Peer Networking, and High Performance Routing (HPR) protocols. SMC-R is provided in the TCP/IP stack.
As Figure 1-1 on page 3 show, z/OS Communications Server includes three major components:
•The TCP/IP and RDMA (SMC-R) protocol stack.
•The SNA protocol stack contained in Virtual Telecommunications Access Method (VTAM).
•The Communications Storage Manager (CSM), which provides a shared I/O buffer area for both TCP/IP and VTAM data flow. The CSM function allows authorized host applications to share data without having to physically move the data.
Figure 1-1 z/OS Communications Server
TCP, UDP, RAW protocols
The transport layer provides the support for the TCP, UDP, and RAW protocols. All three protocols use IPv4 or IPv6 as the network layer. The TCP protocol provides a connection-oriented, reliable transport layer, whereas UDP provides a simpler, connectionless and unreliable transport layer. The RAW transport layer provides for a more direct interface to the IP layer, which is primarily used by system management type applications.
TCP/IP protocol
TCP/IP is the set of communications protocols used both for the Internet and other similar networks. It is named for two of the most important protocols, which were the first two networking protocols defined in this standard:
•Transmission Control Protocol (TCP)
TCP is a transport layer protocol used by applications that require guaranteed delivery. TCP establishes a full duplex virtual connection between two endpoints. Each endpoint is defined by an IP address and a TCP port number. A byte stream is transferred in segments.
•Internet Protocol (IP)
IP routing is a set of protocols that determine the path that data follows to travel across multiple networks from its source to its destination. Data is routed from its source to its destination through a series of routers, and across multiple networks.
UDP protocol
As defined in RFC 768 the User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the Internet Protocol (IP) is used as the underlying protocol.
This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction-oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP).
ICMP protocol
As defined in RFC 792, the Internet Protocol (IP) is used for host-to-host datagram service in a system of interconnected networks. The network-connecting devices are called gateways. These gateways communicate for control purposes via a Gateway-to- Gateway Protocol (GGP). Occasionally, a gateway or destination host communicates with a source host, for example, to report an error in datagram processing. For such purposes, the Internet Control Message Protocol (ICMP) protocol is used. ICMP uses the basic support of IP as though it is a higher-level protocol; however, ICMP is actually an integral part of IP and must be implemented by every IP module.
ICMP messages can be sent in several situations:
•When a datagram cannot reach its destination
•When the gateway does not have the buffering capacity to forward a datagram
•When the gateway can direct the host to send traffic on a shorter route
IP is not designed to be absolutely reliable. The purpose of these control messages is to provide feedback about problems in the communication environment, not to make IP reliable. There are still no guarantees that a datagram will be delivered or a control message will be returned. Some datagrams might still be undelivered without any report of their loss. The higher-level protocols that use IP must implement their own reliability procedures if reliable communication is required.
SMC-R protocol
The SMC-R protocol is a low latency, low CPU, high-speed method of connecting servers across a common network. SMC-R is implemented within the TCP/IP stack so that it can be transparently used by TCP/IP sockets applications, however it bypasses most of the TCP and IP processing to move data directly between hosts using Remote Direct Memory Access (RDMA).
SMC-R uses the RDMA over Converged Ethernet (RoCE) standard and requires the
IBM 10GbE RoCE Express feature to perform RDMA operations over your existing Ethernet fabric. The SMC-R protocol stack is under the sockets layer alongside the TCP/IP stack to facilitate transparent exploitation by TCP sockets-based applications.
SMC-R operates by registering memory regions called Remote Memory Buffer Elements (RMBEs) in each partner host with the RoCE Express feature. Data is transferred by moving it into an RMBE on the sending side and then signaling the RoCE Express feature to communicate with the peer RoCE Express feature to move the data into the receiver’s RMBE. In this manner, the data transfer is performed by the RoCE Express features without using the general-purpose CPU for networking protocol management.
SMC-R is a hybrid protocol. Peers first create a TCP connection by using existing logic, and then they negotiate use of SMC-R over that connection. If both peers support SMC-R and the configuration is suitable, the connection data is moved out of band by the RoCE Express features by using RDMA while the TCP connection remains up and idle. The TCP connection controls the SMC-R connection. For example, if the TCP connection is reset, the corresponding SMC-R connection is terminated.
SNA protocols and VTAM
Systems Network Architecture (SNA) is a data communication architecture established by IBM to specify common conventions for communication among the wide array of IBM hardware and software data communication products and other platforms. Virtual Telecommunications Access Method (VTAM) controls the network and maintains a table of all the machines and phone links in the network. It selects the routes and the alternate paths that messages can take between different NCP nodes. A subarea is the collection of terminals, workstations, and phone lines managed by an NCP. Generally, the NCP is responsible for managing ordinary traffic flow within the subarea, and VTAM manages the connections and links between subareas. Any subarea network must have a mainframe.
Communications Storage Manager
The Communications Storage Manager (CSM) is a VTAM component that allows authorized host applications to share data with VTAM and other CSM users without the need to physically copy the data. CSM includes an API that provides a way to obtain and return CSM buffers, change ownership of buffers, copy buffers, and manage CSM buffers.
High-Performance Routing
The HPR protocol is based on two key components: Rapid-Transport Protocol (RTP) and Automatic Network Routing (ANR). RTP is a reliable, connection-oriented protocol that ensures delivery and manages end-to-end network error and flow control. RTP creates new routes following a network failure. ANR is a connectionless service that is responsible for node-to-node source-routed service.
The RTP layer is invoked only at the edges of an APPN network. In intermediate nodes, only the ANR layer is invoked. RTP nodes establish RTP connections to carry session data. All traffic for a single session flows over the same RTP-to-RTP connection and is multiplexed with traffic from other sessions using the same connection.
For a more detailed overview, see the “High Performance Routing” section on the IBM Systems Network Architecture Routing page on Cisco.com:
Peer-to-peer networking
Earlier releases of VTAM support type 2.1 casual connections, a way of connecting two VTAMs in a peer-to-peer relationship using low-entry networking (LEN). Although type 2.1 casual connection is still supported, IBM recommends that you use APPN to connect two VTAMs in a peer-to-peer relationship.
z/OS UNIX System Services
z/OS UNIX System Services is the z/OS Communications Server implementation of UNIX as defined by X/Open in XPG 4.2. z/OS UNIX System Services coexists with traditional
IBM MVS™ functions and traditional MVS file types (partitioned data sets, sequential files, and so on). It concurrently allows access to z/OS UNIX file system files and to z/OS UNIX utilities and commands by means of application programming interfaces and the interactive shell environment. z/OS Communications Server components run on UNIX System Services as processes that use other system services through z/OS.
Enterprise Extender
The Enterprise Extender (EE) is used in conjunction with the APPN extended border node function can replace SNA Network Interconnection (SNI) functions in a way that does not require SNA mature hardware, such as the IBM 3745 communication controller. High performance routing is an addition to APPN that improves reliability, increases network performance, and was designed to use higher link speed technologies.
1.1.2 Communications Server features and benefits
z/OS Communications Server provides application programming interfaces (APIs) and networking protocol support to enable SNA and TCP/IP applications running on z/OS to communicate with partner applications or users on the same system, other systems within a single data center, or in remote locations.
High-speed connectivity
Communications Server provides support for high bandwidth and high-speed networking technologies through the following features:
•Gigabit Ethernet with OSA Express QDIO for TCP/IP
•High-speed communication between TCP/IP stacks running in a z/OS logical partition (LPAR) using IBM HiperSockets™
•IBM FICON® connectivity, a third high-speed connectivity option
•The Shared Memory Communications over RDMA (SMC-R) protocol that uses the RDMA (Remote Direct Memory Access) over Converged Ethernet (RoCE) standard, which is implemented by the RoCE Express feature
High availability
Communications Server provides high availability to z/OS applications over both SNA and TCP/IP networks. IBM Parallel Sysplex® technology is used to enable high availability application support through the following functions:
•APPN High Performance Routing (HPR) provides end-to-end session continuity by supporting nondisruptive path switch around failed network components.
•The SNA Generic Resources function provides workload balancing for multi-instance applications within a parallel sysplex to maximize availability and efficiency of application data sharing.
•Multi-node Persistent Sessions provides session recovery for SNA applications.
•Dynamic VIPA (Virtual IP address) provides TCP/IP application availability across z/OS systems in a sysplex and allows participating TCP/IP stacks on z/OS to provide backup and recovery for each other for both planned and unplanned TCP/IP outages.
•Sysplex Distributor provides intelligent load balancing for TCP/IP application servers in a Sysplex and, along with Dynamic VIPA, provides a single system image for client applications connecting to these servers.
Enterprise connectivity
Communications Server has many features that support enterprise connectivity, including:
•TN3270 Server provides workstation connectivity over TCP/IP networks to access z/OS and enterprise SNA applications.
•Enterprise Extender allows SNA enterprise applications to communicate reliably over an IP network using SNA HPR and UDP transport layer protocols.
•APPN Extended Border Node (EBN) enables two or more SNA NetIDs to communicate via APPN protocols using VTAM. It can be used as a replacement for 3745/NCP-based SNA Network Interconnect (SNI).
System and data security
No network infrastructure these days can operate without proper security measures in place. Network security has to protect sensitive data and the operation of the TCP/IP stack on z/OS, as follows:
•z/OS provides robust TLS/SSL implementations and z/OS Communications Server provides a policy-based mechanism to apply that protection to z/OS applications transparently. Many key middleware products like IBM DB2®, IBM IMS™ Connect, IBM CICS®, IBM MQ, and IBM WebSphere® Application Server support TLS/SSL through one or more of these mechanisms as do numerous other z/OS components, such as these:
 – FTP client and server
 – RACF
 – JES
 – CSSMTP
 – TN3270 server
•Kerberos 5 and GSSAPI support is provided for the following applications:
 – FTP client and server
 – UNIX rshd server
 – UNIX System Services telnet server (supports only Kerberos 5)
•IPSec VPN functions enable the secure transfer of data over an IP network using standards for encryption, authentication, and data integrity.
•Intrusion Detection Services (IDS) provide mechanisms that detect a wide variety of potential attacks. The specific events to detect attacks and the actions to take (for example, logging, dropping packets, terminating connections, and such) are defined in IDS policy.
•z/OS Communications Server also provides SAF-based access controls to protect a wide variety of networking-related resources.
Network management
Network management support collects network topology, status, and performance information, and makes it available to network management tools.
•VTAM supports the traditional Common Management Information Protocol (CMIP) network management protocol for managing SNA network topology and providing other management interfaces for performance monitoring.
•Managing TCP/IP, the SNMPv3 protocol is supported.
•Communications Server provides support for standard SNMP applications and IETF standard TCP/IP protocol management information bases (MIB).
•Additional MIB support is provided by the IBM MVS TCP/IP enterprise-specific MIB, which supports management data for Communications Server TCP/IP stack-specific functions.
1.1.3 Who supports the network
Network communication functions have both a software and a hardware aspect, and a separation of software and hardware administrative duties is common in large organizations. However, the network administrator, who is a skilled software data communication expert, needs to understand both aspects.
The network administrator must bring a thorough understanding of the operating system’s communications interfaces to any project that involves working with the organization’s network. Although network hardware technicians have specific skills and tools for supporting the physical network, their expertise often does not extend to the operating system’s communications interfaces. For example, when a nationwide retail chain opens a new store, the network administrators and network hardware technicians must coordinate their efforts to open the new store.
The following tasks are among the responsibilities of a z/OS network administrator:
•Defining, maintaining, and modifying an existing mainframe network
•Providing technical guidance to application development and business unit projects
•Determining, isolating, and correcting problems
•Tuning performance
•Making planning recommendations for capacity
•Developing operational procedures
•Training network operators
•Maintaining an awareness of emerging network technologies
•Recommending and implementing new network technologies
1.2 History of mainframe networks
Established in 1969, the Transmission Control Protocol/Internet Protocol (TCP/IP) is actually five years older than the System Network Architecture (SNA). However, SNA was immediately made available to the public, but TCP/IP was limited at first to military and research institutions, for use in the interconnected networks that formed the precursors to the Internet.
In 1974, IBM introduced its Systems Network Architecture (SNA), which is a set of protocols and services enabling communication between host computers (IBM mainframes) and peripheral nodes, such as IBM dedicated hardware offerings, like the IBM 3174 controller for IBM 3270 type displays and printers, controllers for the retail and finance industry, and more. The mainframe subsystem that implements SNA was named Virtual Telecommunication Access Method (VTAM). The robustness of the SNA protocol, the IBM hardware, and the transaction management infrastructure software supplied by IBM (CICS and IMS) made SNA the dominant protocol in the Fortune 1000 companies. In addition, SNA was designed to include network management controls not originally in TCP/IP through the Synchronous Data Link Control (SDLC) protocol.
In the 1980s, SNA was widely implemented by large corporations because it allowed their IT organizations to extend central computing capability worldwide with reasonable response times and reliability. For example, widespread use of SNA allowed the retail industry to offer new company credit card accounts to customers at the point of sale.
In 1983, TCP/IP entered the public domain in Berkeley BSD UNIX. TCP/IP maturity, applications, and acceptance advanced through an open standards committee, the Internet Engineering Task Force (IETF), using the Request For Comment (RFC) mechanism.
 
Note: The term internet is used as a generic term for a TCP/IP network and should not be confused with the Internet, which consists of the large international backbone networks connecting all TCP/IP hosts that have links to the Internet backbone.
TCP/IP was designed for interconnected networks (an internet) and seemed to be easier to set up, but SNA design was hierarchical with the centralized mainframe being at the top of the hierarchy. The SNA design included network management, data flow control, and the ability to assign class of service priorities to specific data workloads. Communication between autonomous SNA networks became available in 1983. Before that, SNA networks could not talk to each other easily. The ability of independent SNA networks to share business application and network resources is called SNA Network Interconnect (SNI). During the 20-year period when SNA was the primary networking method, many CICS and IMS application programs were developed and put in place. The application programming interfaces (API) of these application programs are heavily dependent on the underlying protocol, SNA.
It is apparent that TCP/IP is the dominant networking protocol now and for the foreseeable future. Today, new applications use state-of-the-art programming techniques, like Java and HTTP, but it will take many years until all SNA applications disappear. Why is that so?
A networking application is dependent on the communication protocol it uses. Every protocol provides an application programming interface (API). TCP/IP’s API is called socket programming and SNA has its own API. Migrating a networking application from one protocol to another (that is, from SNA to TCP/IP) requires replacing the calls to the API. Business managers are reluctant to invest in protocol conversion only for the sake of changing the underlying protocol without introducing new functions and improvements. More importantly, organizations have invested a tremendous amount of labor and money in developing SNA applications. Considering the investments in SNA applications, these programs will be used for many years to come. To recode these applications as TCP socket applications is often impractical and cost-prohibitive. Besides, alternatives exist.
IBM introduced new technologies to help organizations preserve the investment in SNA and use IP as the protocol for connecting SNA computers. The technology is known as SNA/IP (SNA over IP) integration. The two endpoints, the SNA application in the mainframe and the SNA application in the remote location (branch, store), remain unchanged, thereby preserving the investment in SNA. SNA is stable, trusted, and relied upon for mission-critical business applications worldwide. A significant amount of the world’s corporate data is handled by z/OS-resident SNA applications. A distinctive strength of SNA is that it is connection-oriented with many timers and control mechanisms to ensure reliable and secure delivery of data.
Mainframe IT organizations are often reluctant and skeptical about moving away from SNA, despite the allure of TCP/IP and web-based commerce. This reluctance is often justified. Rewriting stable, well-tuned business applications to change from SNA program interfaces to TCP/IP sockets can be costly and time consuming. Many organizations choose to use web-enabling technologies to make the vast amount of centralized data available to the TCP/IP-based web environment, while maintaining the SNA APIs. This best of both worlds approach ensures that SNA and VTAM will be around well into the future. Because SNA applications will exist for years to come, someone has to care for SNA definitions, problem determination, recovery, business continuity procedures, and many other tasks. These tasks are the responsibility of the mainframe networking systems programmer who needs to know in depth the architecture and how to implement SNA on various hardware and software platforms.
1.3 Mainframe network architecture
Basic elements of a computer network include hardware, software, and communication protocols. The inter-relationship of these basic elements constitutes the infrastructure of the network. If we think of a network as roads, highways, rails, and other means of transport, the network protocols are the traffic rules.
Connectivity is the pipeline through which data is exchanged between clients and servers via physical and logical communication interfaces and the network. The IBM System z provides a wide range of interface options for connecting your z/OS system to an IP network or to another IP host. Some interfaces offer point-to-point or point-to-multipoint connectivity, but others support local area network connectivity. The physical network interface is enabled through z/OS Communications Server (TCP/IP) definitions.
There are several ways to establish network connections with the mainframe. The IBM Open Systems Adapter-Express 5S (OSA-Express5S) and Open Systems Adapter-Express4S (OSA-Express4S) features that are available for an IBM System z mainframe computer connect to other servers and clients in 1000BASE-T Ethernet (10, 100, and 1000 Mbps), Gigabit Ethernet (GbE), and 10 Gigabit Ethernet environments. They provide redundancy capability and throughput improvements when running in Queued Direct I/O (QDIO) mode. QDIO mode allows direct access to central memory. QDIO mode can be emulated within a central processor complex (CPC) by allowing memory-to-memory data transfer among LPARs running IBM z/VM®, Linux, or z/OS.
The 10Gb IBM RoCE Express feature provides RDMA connectivity between hosts over a shared network segment using the SMC-R protocol.
z/OS Communications Server provides the data transportation corridor between the external network and the business applications running on z/OS. z/OS Communications Server provides a set of communications protocols that support peer-to-peer connectivity functions for both local and wide-area networks, including the most popular wide area network, the Internet. z/OS Communications Server also provides performance enhancements that can benefit a variety of TCP/IP applications and includes several commonly used applications.
TCP/IP and SNA are both layered network models. Each can indirectly map to the international Open Systems Interconnect (OSI) network model, as shown in Figure 1-2.
Figure 1-2 Open Systems Interconnect (OSI) network model
The OSI network model depicts the organization of the individual elements of technology involved with end-to-end data communication. As shown in Figure 1-2, the OSI network model provides some common ground for both SNA and TCP/IP. Although neither technology maps directly into the OSI network model (TCP/IP and SNA existed before the OSI network model was formalized), common ground still exists due to the defined model layers. The OSI network model is divided into seven layers. OSI layer 7 (Application) indirectly maps into the top layers of the SNA and TCP/IP stacks. OSI layer 1 (Physical) and layer 2 (Data Link) map into the bottom layers of SNA and TCP/IP stacks.
The z/OS Communications Server includes several sophisticated products and functions, including these major services:
•IP, using Transmission Control Protocol/Internet Protocol (TCP/IP).
•RDMA, using the SMC-R protocol over RoCE Express features, which is integrated with TCP/IP to provide seamless exploitation for TCP sockets applications.
•Systems Network Architecture (SNA), using Virtual Telecommunication Access Method (VTAM).
The Communications Storage Manager (CSM) component provides a shared I/O buffer for data flow. The CSM function allows authorized host applications to share data without having to physically move the data.
Figure 1-3 depicts the overall architecture of the z/OS Communications Server.
Figure 1-3 The z/OS Communications Server architecture
A resource in an SNA network is a network accessible unit (NAU), which is either an origin or a destination of information transmitted by the transport network (the data link control and path control layers). SNA consists of network accessible units such as system services control points, physical and logical units.
Physical units are components that manage and monitor resources, such as attached links and adjacent link stations, that are associated with a node. System services control points (SSCPs) indirectly manage these resources through physical units. A physical unit receives and acts upon requests from the SSCP, such as activating and deactivating links to adjacent nodes. It also manages links and link stations and accounts for the unique aspects of different link types.
Users and applications access SNA networks through logical units (LUs), which are the entry point through which users and applications access the SNA network. Logical units manage the exchange of data between end users and applications and application-to-application, acting as intermediaries between the two session partners on the two endpoint LUs.
Because SNA is a connection-oriented protocol, before transferring data the respective logical units must be connected in a session. In SNA hierarchical networks, logical units require assistance from SSCPs to activate a session with another logical unit. A session between a logical unit (LU) and an SSCP is called SSCP-LU session. Control information flows from the SSCP to LU session. A session between two logical units either in the same node or in two different nodes is called an LU-LU session. The session between two LUs is used for application data flows. All node types can contain logical units. The control point assists in establishing the session between the two LUs and does not take part in the data transfer between the two LUs.
1.4 Networking hardware
Connectivity is the pipeline through which data is exchanged between clients and servers via physical and logical communication interfaces and the network. The IBM System z servers provide a wide range of interface options for connecting your z/OS system to an IP network or to another IP host, depicted in Figure 1-4. Some interfaces offer point-to-point or point-to-multipoint connectivity, and others support local area network (LAN) connectivity. This flow diagram depicts the physical interfaces (and device types) provided by System z servers. The physical network interfaces are enabled through z/OS Communications Server (TCP/IP) definitions.
Figure 1-4 System z physical interfaces with Communications Server
Ethernet is a family of frame-based computer networking technologies for local area networks (LANs). It defines several wiring and signaling standards for the physical layer of the OSI networking model. Ethernet is standardized as IEEE 802.3. The combination of the twisted-pair versions of Ethernet for connecting end systems to the network, along with the fiber optic versions for site backbones, is the most widespread wired LAN technology. It has been in use since 1980, largely replacing competing LAN standards such as token ring, FDDI, and ARCNET.
Ethernet can support multiple networking protocols, including TCP/IP and RDMA over Converged Ethernet (RoCE).
ATM is a switching technology that provides fast, reliable, simultaneous transfer of data, voice, and video. VTAM supports ATM technology by enabling communication across ATM networks – both public (wide area networks, or WANs) and private (campus networks) – that are accessed through LAN emulation and native connections
Token ring local area network technology is a local area network protocol that resides at the data link layer (DLL) of the OSI model. It uses a special three-byte frame called a token that travels around the ring. Token ring frames travel completely around the loop.
IBM FICON provides all of the strengths of ESCON, plus more. The link data rate is 4 Gbps, with an expected effective data transfer rate of up to 350 MBps (full-duplex data transfer and large sequential read/write mix). The System z servers build on this I/O architecture by offering high-speed FICON connectivity.
The Enterprise Systems Connection (ESCON) channel is a high-bandwidth host attachment facility that can be used to connect SNA and non-SNA 3174 controllers, 3172 Nways interconnect controllers, 3746-900 controllers, and channel-attached hosts to VTAM running on MVS/ESA. ESCON provides bidirectional serial bit transmission, in which the communication protocol is implemented through sequences of special control characters and through formatted frames of characters. ESCON uses fiber optic cables for data transmission. The ESCON link data rate is 200 megabits per second (Mbps), which results in a maximum aggregate data rate of up to 17 megabytes per second (MBps). The maximum unrepeated distance of an ESCON link using multimode fiber optic cables is 3 km (1.86 miles) when using 62.5 micron fiber.
1.4.1 Network connections
Network connections can be made in several different fashions. The mainframe originally relied upon the channel subsystem to offload I/O processing to channel programs. Disk storage is still accessed using ESCON channels in some places as most of them are migrating to faster FICON channels. But, for networking connectivity, OSA-Express cards offer better performance and availability. Connectivity is the pipeline through which data is exchanged between clients and servers via physical and logical communication interfaces and the network. The IBM System z servers provide a wide range of interface options for connecting your z/OS system to an IP network or to another IP host. Some interfaces offer point-to-point or point-to-multipoint connectivity, but others support local area network (LAN) connectivity.
The Open Systems Adapter is actually a network controller that you can install in a mainframe I/O cage. The adapter integrates several hardware features and supports many networking transport protocols. The OSA card is the strategic communications device for the mainframe architecture. It has several key features that distinguish it from CCW-based communications. The IBM Open Systems Adapter-Express 5S (OSA-Express5S) and Open Systems Adapter-Express4S (OSA-Express4S) features that are available on an IBM System z mainframe computer connect to other servers and clients in 1000BASE-T Ethernet (10, 100, and 1000 Mbps), Gigabit Ethernet (GbE), and 10 Gigabit Ethernet environments. They provide redundancy capability and throughput improvements when running in QDIO mode. QDIO mode allows direct access to central memory. QDIO mode can be emulated within a CPC by allowing memory-to-memory data transfer among LPARs running z/VM, Linux, or z/OS.
A new type of OSA, the OSN channel type, is only available with OSA-Express2 and later and requires an IBM z9® mainframe or later model. The primary intention of this type is to free organizations from the constraints of obsolete hardware: device types 3745 and 3746. The 374x device types, as they are called, are no longer manufactured or sold by IBM. A 374x host is required to run the Network Control Program (NCP). NCP is a significant functional component of subarea type SNA networks. The OSN channel type allows an Open Systems Adapter to communicate with an NCP using Channel Data Link Control protocol (CDLC). CDLC cannot be used over an OSD or OSE channel type, and even with channel type OSN it can only communicate to other LPARs within the CPC. Historically, 374x devices were often connected to parallel or ESCON channels, which support CDLC. In this case, NCP will run on a software program called Communications Controller for Linux (CCL). And, as mentioned, both LPARs must be within the same CPC, because the data flows do not enter the network. In many cases, CCL provides the easiest way to migrate from older SNA-based network controllers to modern network devices.
The RoCE Express feature is supported on zEC12/zBC12 and newer hardware. It is a PCIe adapter that implements RDMA over converged Ethernet (RoCE), supporting the SMC-R protocol. Because SMC-R was designed for compatibility, you generally do not need to update or change your network switches to use SMC-R. The only advanced switch feature that SMC-R requires is the Global Pause frame described in the IEEE 802.3x standard.
1.5 Network protocols
In this section we take a closer look at both TCP/IP and SNA. More detailed information about security-related topics can be found in the individual chapters Chapter 3, “TCP/IP security” on page 89 and Chapter 4, “SNA security” on page 131.
1.5.1 TCP/IP
The single entity that handles, and is required for, all IP-based communications in a z/OS environment is the TCP/IP daemon itself. The TCP/IP daemon implements the IP protocol stack and runs a large number of IP applications to the same specifications as any other operating system might do. That’s the beauty of TCP/IP. TCP/IP connectivity and gateway functions handle the physical interfaces and the routing of IP data packets called datagrams.
The network protocol layer provides the support for the IP protocol. All TCP and User Datagram Protocol (UDP) data goes through the IP layer when entering and leaving the host. TCP and UDP use the IPv4 routing layer or the IPv6 routing layer. The network layer also provides support for the Internet Control Message Protocol (ICMP) and ICMPv6. This is used by the IP layer to exchange information and error messages with IP layers on other hosts and routers. ICMP is used for the IPv4 protocol and ICMPv6 is used for the IPv6 protocol. The transport layer provides the support for the TCP, UDP, and RAW protocols. All three protocols use IPv4 or IPv6 as the network layer. The TCP protocol provides a connection-oriented, reliable transport layer, whereas UDP provides a simpler, connectionless and unreliable transport layer. The RAW transport layer provides for a more direct interface to the IP layer, which is primarily used by system-management type applications.
The file system layer provides the main interface between the application programming interfaces (APIs) and the transport layers. The first component of the file system layer is the z/OS UNIX logical file system (LFS). The LFS provides the API layer with a common interface to access files and sockets.
Each of the application programming interfaces (APIs) can be used to interface with the TCP/IP Services protocol stack provided by z/OS Communications Server. Like most networking software, TCP/IP is modeled in layers. This layered representation leads to the term protocol stack, which refers to the stack of layers in the protocol suite. It can be used for positioning (but not for functionally comparing) the TCP/IP protocol suite against others, such as Systems Network Architecture (SNA) and the Open System Interconnection (OSI) model. Functional comparisons cannot easily be extracted from this, because there are basic differences in the layered models used by the different protocol suites. By dividing the communication software into layers, the protocol stack allows for division of labor, ease of implementation and code testing, and the ability to develop alternative layer implementations. Layers communicate with those above and below via concise interfaces. In this regard, a layer provides a service for the layer directly above it and uses services provided by the layer directly below it. For example, the IP layer provides the ability to transfer data from one host to another without any guarantee of reliable delivery or duplicate suppression. Transport protocols such as TCP make use of this service to provide applications with reliable, in-order data stream delivery.
TCP/IP stack
The TCP/IP address space is where the TCP/IP protocol suite is implemented for the z/OS Communications Server. The TCP/IP address space is commonly referred to as a stack. In earlier versions Open Edition (OE) TCP/IP could run either as a stand-alone or in parallel with the TCP/IP for MVS. This was often necessary because the OE stack did not support all the functions and network connections available with TCP/IP for MVS.
z/OS Communications Server IP now has a highly efficient direct communication between the UNIX System Services address space (OMVS) and a TCP/IP stack that was integrated in UNIX System Services. This communication path includes the UNIX System Services Physical File System (PFS) component for AF_INET and AF_INET6 (Addressing Family-Internet) sockets communication. Two configuration files are used by the TCP/IP stack, PROFILE.TCPIP and TCPIP.DATA. PROFILE.TCPIP is used only for the configuration of the TCP/IP stack. TCPIP.DATA is used during configuration of both the TCP/IP stack and applications.
The z/OS Communications Server allows a single TCP/IP address space to drive multiple instances of any supported device. To configure your devices, add the appropriate DEVICE and LINK statements to the configuration data set. The LINK statements show how to define a network interface link associated with the device and are included with the DEVICE statement for that device type. The new alternative to coding a DEVICE and a LINK statement is the INTERFACE statement to define network connectivity for the TCP/IP stack.
The TCP/IP address space operates as a transport provider for the INET physical file system. For this to occur, the TCP/IP system address space must connect to z/OS UNIX and become a z/OS UNIX process. Therefore, the started task UID that is assigned to the TCP/IP system address space must have a valid OMVS segment. As a transport provider, the TCP/IP address space requires superuser privileges in z/OS UNIX.
1.5.2 SMC-R
Remote Direct Memory Access (RDMA) is a communications technology that enables a host to make a subset of its memory directly available to a remote host. By doing so, data can be transferred between hosts efficiently and without any help from the CPU on the source or target host. Historically, RDMA has been confined to high-performance computing environments where the cost of maintaining RDMA-capable network fabrics such as InfiniBand was justified given the emphasis of performance over cost. However, RDMA is now available on standard Ethernet-based networks by using the industry (InfiniBand Trade Association) standard referred to as RDMA over Converged Ethernet (RoCE). With RoCE, the cost of adopting RDMA is lower because it can flow over the Ethernet fabrics that are already in place to carry IP network communications. Both standard TCP/IP and RDMA traffic can flow over the same physical LAN fabric at the same time, but RDMA network interface cards (RNICs, also referred to as RoCE host channel adapters (HCAs)), are required to do so. On System z, the 10Gb RoCE Express adapter serves as the RNIC.
z/OS Communications Server 2.1 introduced a new capability that combines the performance benefits of RDMA with the widely-used TCP/IP sockets programming interface. This function, called Shared Memory Communication - RDMA (SMC-R), allows your TCP sockets applications to benefit from direct, high-speed, low-latency, memory-to-memory (peer-to-peer) communications over RDMA transparently - no changes are required in your application programs.
SMC-R provides an enterprise class of services for RDMA that are designed for enterprise class data center networks. Communicating peers (the z/OS TCP/IP stacks) dynamically learn about the shared memory capability by using traditional TCP/IP connection establishment flows. With this awareness, the TCP/IP stacks can switch from TCP network flows to more efficient direct memory access flows that use RDMA. The application programs are unaware of the switch to shared memory communications.
1.5.3 SNA
Systems Network Architecture (SNA) is a data communication architecture established by IBM to specify common conventions for communication among the wide array of IBM hardware and software data communication products and other platforms. Among the platforms that implement SNA in addition to mainframes are the IBM Communications Server on Windows, AIX, and Linux, Microsoft Host Integration Server (HIS) for Windows, and many more. The way in which products internally implement these common conventions can differ from one product to another, but because the external interface of each implementation is compatible, different products can communicate without the need to distinguish among the many possible product implementations.
SNA products recognize and recover from loss of data during transmission, use flow control procedures to prevent data overrun and avoid network congestion, identify failures quickly, and recover from many errors with minimal involvement of network users. SNA products also increase network availability through options such as the extended recovery facility, backup host, alternative routing capability, and maintenance and recovery procedures integrated into workstations, modems, and controllers.
A networking application is dependent on the communication protocol it uses. Every protocol provides an application programming interface (API). TCP/IP’s API is called socket programming and SNA has its own API. Migrating a networking application from one protocol to another (that is, from SNA to TCP/IP) requires replacing the calls to the API. Business managers are reluctant to invest in protocol conversion only for the sake of changing the underlying protocol without introducing new functions and improvements.
IBM introduced new technologies to help businesses preserve the investment in SNA and use IP as the protocol for connecting SNA computers. The technology is known as SNA/IP (“SNA over IP”) integration. The two endpoints, the SNA application in the mainframe and the SNA application in the remote location (branch, store), remain unchanged, thereby preserving the investment in SNA. There are two implementations of SNA - Subarea networking and Advanced Peer-to-Peer Networking (APPN).
Subarea networking
Subarea networking was the initial implementation of SNA that defined mainframe-based hierarchical networks in which every resource and SNA route had to be predefined. In the initial implementation of SNA, adding resources or changing SNA routes necessitated the shutdown of parts of the network.
The initial implementation by IBM was the SNA subarea network. This network is a hierarchical network implemented by the Virtual Telecommunications Access Method (VTAM) in the mainframe. VTAM is the software that controls communication and data flow in an IBM mainframe SNA network. VTAM resides in the mainframe and supports a wide variety of network protocols, like SDLC and LAN.
VTAM controls data transfer between channels and OSA LAN-attached devices and performs SNA routing functions. VTAM provides an application programming interface (API) that enables the development of application programs that communicate using SNA with remote application programs or devices. Currently, VTAM is part of the z/OS Communications Server and is called SNA services. You’ll find more information about VTAM in 1.6.1, “VTAM” on page 21.
SNA nodes
A data communication network can be described as a configuration of nodes and links. Nodes are the network components that send data over, and receive data from the network. Node implementations include processors, controllers, and workstations. Links are the network components that connect adjacent nodes. Nodes and links work together in transferring data through a network. An SNA node is a set of hardware and associated software components that implement network functions. Nodes differ based on the architectural components and the set of functional capabilities they implement. Nodes with different architectural components represent different node types.
•A T5 node is located only in the mainframe. The software that implements the T5 node is the SNA component of the Communications Server. The SNA component in z/OS is also referred to as VTAM (Virtual Telecommunications Access Method).
•A T4 node is a communication controller attached to peripheral nodes through communication lines or a LAN either to another communication controller through communication lines or to a mainframe through an ESCON or a parallel channel. IBM uses special hardware and software to implement the T4 Node. The software is the IBM network control program (NCP), and the hardware is the IBM 3745 or 3746 device. The Communication Controller of Linux (CCL) is a software package that replaces the 3745 or 3746.
•A T2.0 is a peripheral node that attaches to the communication controller or the mainframe. T2.0 is an alias for the IBM 3174 display controller, which attaches 3270 displays and printers and is connected through a communication line to the T4 node or through a channel to the T5 node. Additional devices that implement T2.0 node are banking branch controllers and retail store controllers.
•A T2.1 is a peer-oriented peripheral node that attaches to a mainframe, a communication controller, or another peripheral node. A T2.1 node is called a low entry networking (LEN) node.
Many of the SNA node types have been replaced by up-to-date hardware and software. The T2 node was replaced by a workstation (Windows or UNIX) that implements software called 3270 emulation and the banking and retail controller by Windows, UNIX, or Linux-based servers. The 3745 and 3746 hardware is nearing its end of life. The migration to TCP/IP in the backbone reduces the number of lines in the 3745 and 3746. The OSA and the routers can implement most of the functions of the 3745 and 3746 at much lower cost. One of the alternatives to the 3745/3746 hardware is the IBM Communication Controller of Linux (CCL) software package implemented on the mainframe. CCL uses OSA for NCP (OSN) or an OSA port operating in LCS mode and routers.
System services control point (SSCP)
A type 5 subarea node contains a system services control point (SSCP). An SSCP activates, controls, and deactivates network resources in a subarea network. To control and provide services for its subordinate nodes, an SSCP establishes sessions with components in the network.
Advanced Peer-to-Peer Networking network topology
To address the deficiency of the static nature of subarea SNA, IBM introduced an SNA-based peer network, with no hierarchical relations, and with dynamic definition of resources. At a later stage, APPN was enhanced with the introduction of High Performance Routing (HPR) and Enterprise Extender (SNA/IP), which, as its name implies, is a high performance routing protocol that can be optionally used by APPN.
Hierarchical systems are organized in the shape of pyramid, with each row of objects linked directly to objects beneath it. SNA subarea, besides implementing the model of a hierarchical system, is centrally managed from the top of the pyramid. Network resources in SNA are managed (that is, known and operated) from a central point of control that is aware of all the activity in the network, whether a resource is operational, and the connectivity status of the resource. The resources can send reports on their status to the control point. Based on networking and organizational requirements, a hierarchical network can be divided into subnetworks, where every subnetwork has a control point with its controlled resources.
Advanced Peer-to-Peer Networking (APPN) is a type of data communications support that routes data in a network between two or more systems that do not need to be directly connected. APPN topology does not have a subarea number or have exclusive ownership of the SNA resources. Each APPN-participating VTAM is included in a geographically dispersed collection of shared SNA resources, eliminating the need for a cross-domain resource manager to establish sessions. APPN includes a high-performance routing (HPR) method of sending SNA application data through existing TCP/IP network equipment. APPN includes a function called Enterprise Extender (EE), sometimes referred to as HPR/IP. EE ensures that SNA applications can be served by state-of-the-art IP networking technology.
HPR is not limited exclusively to SNA/APPN over TCP/IP networks. Rather, HPR is the APPN function that provides high-performance delivery of data through an APPN network, combined with the high-availability feature of dynamic rerouting of sessions around failures in the network. But HPR is supported over most types of APPN connections (not just APPN over TCP/IP). Enterprise Extender (EE) is the APPN/HPR function that allows SNA sessions and other APPN functions (like HPR) to work over a TCP/IP network (rather than a native SNA network).
Depending on the software that implements APPN in T2.1 nodes, the node can be configured in the APPN networks with varying complexity, from the simplest case of an isolated pair of low-entry networking nodes to a large APPN network. Using low-entry networking or APPN protocols, any node can control the establishment and termination of sessions.
The following node types can be implemented by T2.1 nodes:
•Low-entry networking (LEN)
•APPN end node (EN)
•APPN network node (NN)
To ease the migration from subarea networking to APPN in the mainframe, the following nodes types can be implemented in a mainframe:
•Interchange node (ICN)
•Migration node
T5 and T4 nodes also support low-entry networking and APPN protocols, and are fully compatible with T2.1 nodes in these contexts. They also introduce product features of their own, related to enhanced subarea-APPN interchanges. When a subarea node implements either APPN or low-entry networking protocols, it acts as a T2.1 node and can still implement, depending on VTAM’s definitions, the subarea T5 and T4 functions.
Architectural components of the SNA network
A resource in an SNA network is a network accessible unit, which is either an origin or a destination of information transmitted by the transport network (the data link control and path control layers). You already read about control points and system services control points, which are network accessible units. Other network accessible units are:
Physical units
Physical units are components that manage and monitor resources such as attached links and adjacent link stations associated with a node. SSCPs indirectly manage these resources through physical units. Physical units (PUs) exist in subarea and type 2.0 nodes. (In type 2.1 peripheral nodes, the control point performs the functions of a PU.) The PU supports sessions with control points in type 5 nodes and also interacts with the control point in its own node.
A physical unit provides the following functions:
•Receives and acts upon requests from the system services control point (SSCP), such as activating and deactivating links to adjacent nodes
•Manages links and link stations and accounts for the unique aspects of different link types
Logical units
Users and applications access SNA networks through logical units (LUs), which are the entry point through which users and applications access the SNA network. Logical units manage the exchange of data between users to applications and application to application, acting as intermediaries between the two session partners on the two endpoint LUs. Because SNA is a connection-oriented protocol, before transferring data the respective logical units must be connected in a session. In SNA hierarchical networks, logical units require assistance from system services control points (SSCPs), which exist in type 5 nodes, to activate a session with another logical unit.
A session between a logical unit (LU) and an SSCP is called and SSCP-LU session. Control information flows from the SSCP to LU session. A session between two logical units either in the same node or in two different nodes is called an LU-LU session. The session between two LUs is used for application data flows. All node types can contain logical units. In SNA hierarchical networks, the logical unit has sessions with only one control point in type 5 nodes and with logical units in other nodes. A control point assists in establishing a session between its managed LU and an LU. It does not manage in a different node.
SNA defines different kinds of logical units called LU types. LU types identify sets of SNA functions that support user communication. LU-LU sessions can exist only between logical units of the same LU type. For example, an LU type 2 can communicate only with another LU type 2; it cannot communicate with an LU type 3. The following list explains the LU types that SNA defines, the kind of configuration or application that each type represents, and the hardware or software products that typically use each type of logical unit:
•LU type 1
This is for application programs and single-device or multiple-device data processing workstations communicating in an interactive or batch data transfer. An example of the use of LU type 1 is an application program running under IMS/VS and communicating with a 3270 printer.
•LU type 2
This is for application programs and display workstations communicating in an interactive environment using the SNA 3270 data stream. An example of the use of LU type 2 is an application program running under IMS/VS and communicating with an IBM 3270 display station at which an user is creating and sending data to the application program.
•LU type 3
This is for application programs and printers using the SNA 3270 data stream. An example of the use of LU type 3 is an application program thar runs under IBM Customer Information Control System/Virtual Storage (CICS/VS) and sends data to a 3270 printer.
•LU type 6.2
This is for transaction programs communicating in a client/server data processing environment. The type 6.2 LU supports multiple concurrent sessions. LU 6.2 can be used for communication between two type 5 nodes, a type 5 node and a type 2.1 node, or two type 2.1 nodes. Examples of the use of LU type 6.2 are:
 – An application program running under CICS in a z/OS system communicating with another application program running under CICS in another z/OS system.
 – An application program in a Microsoft Host Integration Server (HIS) or IBM AIX Communications Server communicating with a CICS in a z/OS system.
One of the main reasons for networks to migrate to APPN is the implementation of a sysplex. A sysplex environment provides some unique advantages to the VTAM installation, namely generic resources (GR) and multinode persistent sessions (MNPS). With the latest emphasis on IP application load balancing within the sysplex through the use of Sysplex Distributor, and SNA application load balancing within the sysplex through the use of generic resources, migrating to an HPR/IP (EE) infrastructure has become a natural step toward supporting SNA applications through native IP connectivity to the mainframe. HPR/IP accommodates the presence of SNA data within the IP packet, and uses the dynamic routing capabilities of both HPR and IP.
APPN/HPR improves the availability of sysplex resources. Generic resources enable multiple application copies within a sysplex to present a single image to the user, resulting in better performance through load balancing and improved availability. The multinode persistent sessions function enables sessions to survive the failure of a VTAM, or a z/OS system, or even a processor, without disruption. You can use an IP network for SNA sessions with Enterprise Extender, which provides enablement of IP applications and convergence on a single network transport and preserves SNA application and endpoint investment. An EE connection is a logical connection that represents IP connectivity from a host to a specified IP address or host name. Conceptually, an IP network looks like an APPN/HPR transmission group (TG) in a session route.
1.6 Additional network components
This section describes additional components within the z/OS Communications Server.
1.6.1 VTAM
In z/OS, VTAM provides the SNA layer network communication stack to transport data between applications and the user. VTAM manages the SNA-defined resources, establishes sessions between these resources, and tracks session activity.
VTAM performs several tasks in a network, for example:
•It monitors and controls the activation and connection of resources.
•It establishes connections and manages the flow and pacing of sessions.
•It provides application programming interfaces (for example, an APPC API for LU 6.2 programming) that allow access to the network by user-written application programs and IBM-provided subsystems.
•It provides interactive terminal support for the Time Sharing Option (TSO).
•It provides support for both locally and remotely attached resources.
z/OS runs only one VTAM address space. Each application that uses VTAM, such as CICS/TS, requires a VTAM definition. The application and VTAM use this definition to establish connections to other applications or users.
What HTML is to a web application and browser, the 3270 data stream is to an SNA application and device in an LU-LU session. Specialized commands are embedded in the data of panel devices and printers. The 3270 data stream is data with these embedded instructions and data field descriptors. The 3270 data stream commands are created and read by SNA applications, such as Physical Unit (PU) controllers managing the displays, printers, and TN3270 emulators available in AIX and PC operating systems.
Each endpoint of an SNA session is known as a logical unit (LU). An LU is a device or program by which a user (application program, a terminal operator, or an input/output mechanism) gains access to the SNA network. VTAM-established sessions are known as LU-to-LU sessions. In an SNA network, CICS/TS, for example, is considered an LU and typically has many sessions with other LUs, such as displays, printers, POS devices, and other remote CICS/TS regions. Each LU is assigned a unique network addressable unit (NAU) to facilitate communication.
A physical unit (PU) controls one or more LUs. A PU is not literally a physical device in the network. Rather, it is a portion of a device (usually programming or circuitry, or both) that performs control functions for the device in which it is located and, in some cases, for other devices that are attached to the PU-containing device.
A PU exists in each node of an SNA network to manage and monitor the resources (such as attached links and adjacent link stations) of the node. The PU exists either within the device or within an attached controlling device. VTAM must activate the PU before it can activate and own each LU attached to the PU.
Although TCP/IP is by far the most common way to communicate over a network with a z/OS host, some environments still use native SNA, and many environments now carry (encapsulate) SNA traffic over UDP/IP. The hierarchical design of SNA serves the centralized data processing needs of large enterprises.
At the top of this hierarchy is VTAM. VTAM serves the following types of network topologies:
•Subarea
•Advanced Peer-to-Peer Networking (APPN)
•Subarea/APPN mixed
The part of VTAM that manages a subarea topology is called the System Services Control Point (SSCP). The part of VTAM that manages APPN topology is called the Control Point (CP).
Virtual Telecommunications Access Method (VTAM) controls the network and maintains a table of all the machines and phone links in the network. It selects the routes and the alternate paths that messages can take between different NCP nodes. A subarea is the collection of terminals, workstations, and phone lines managed by an NCP. Generally, the NCP is responsible for managing ordinary traffic flow within the subarea, and VTAM manages the connections and links between subareas. Any subarea network must have a mainframe. The SNA protocols are provided by VTAM and include Subarea, Advanced Peer-to-Peer Networking, and High Performance Routing protocols.
The communications storage manager (CSM) is a VTAM component that allows authorized host applications to share data with VTAM and other CSM users without the need to physically copy the data. CSM includes an API that provides a way to obtain and return CSM buffers, change ownership of buffers, copy buffers, and manage CSM buffers. VTAM supports the attachment of a sysplex to a network. Sessions into the sysplex can be established from either subarea nodes or APPN nodes. Several VTAM functions are available only in a sysplex environment. If a coupling facility and an APPN or mixed APPN and subarea environment exists in the sysplex, the user can take advantage of the VTAM functions. VTAM also provides support for TCP/IP functions that need access to a coupling facility.
VTAM supports the following types of LANs through the IBM Open Systems Adapter (configured in SNA mode):
•Ethernet or Ethernet-type LAN
•Token-ring network
•Fiber distributed data interface (FDDI)
Resources in a VTAM network are classified under major and minor nodes. Each major node can contain one or more minor nodes. To define the attachment of any device, set of devices, various tables, or search order of resources to VTAM, you need to code major node members and store them in the VTAMLST partitioned data set.
The start options are stored in the SYS1.VTAMLST partitioned data set (PDS) or any other PDS concatenated to the VTAMLST DD statement. The member name is ATCSTRxx, where xx specifies the identifier of the start option file. Start options provide information about the conditions under which VTAM runs. They also enable you to tailor VTAM to meet your needs each time VTAM is started. Many operands can have defaults specified as start options, thus reducing the amount of coding required. Many start options can be dynamically modified and also displayed. The ATCSTRxx member contains VTAM start parameters that define the VTAM’s identity in the network, plus tuning options and a pointer to the major node startup list, ATCCONxx. A configuration list specifies the resources that are to be activated when VTAM is started. The member names of the resources you want to have activated when VTAM starts are stored in the ATCCONxx member in the VTAM definition library, where xx is any two alphanumeric characters.
1.6.2 TCP/IP stack and functions
The highest level protocols within the TCP/IP protocol stack are application protocols. They communicate with applications on other internet hosts and are the user-visible interface to the TCP/IP protocol suite. All application protocols have some characteristics in common. They can be user-written applications or applications standardized and shipped with the TCP/IP product. The TCP/IP protocol suite includes application protocols such as:
•Telnet for interactive terminal access to remote internet hosts
•File Transfer Protocol (FTP) for high-speed disk-to-disk file transfers
•Simple Mail Transfer Protocol (SMTP) as an internet mailing system
These are some of the most widely implemented application protocols, but many others exist. Each particular TCP/IP implementation will include a lesser or greater set of application protocols.
Telnet
Telnet is a terminal emulation protocol. With Telnet, users can log on to remote host applications as though they were directly attached to that host. Telnet protocol requires that the user have a Telnet client that emulates a type of terminal that the host application can understand. The client connects to a Telnet server, which communicates with the host application. The Telnet server acts as an interface between the client and host application. A PC can support several clients simultaneously, each with its own connection to any Telnet server.
The original basic Telnet protocol was defined in RFC 854. This RFC effectively defined all that was needed to support the 3270 data stream, because the 3270 data stream is just part of the Telnet data payload. In other words, the 3270 portion was implemented outside of (above) the Telnet protocol. Specific options could be negotiated (beyond basic Telnet) using the Telnet option standard of RFC 855. Option negotiation in turn allowed for device type negotiations (later formally defined in RFC 1091) to be completed as part of the Telnet session setup.
There are two types of Telnet servers:
•TN3270E Telnet server
This type provides access to z/OS VTAM SNA applications on the MVS host by using Telnet TN3270E, TN3270, or Linemode protocol. A TN3270E client uses the TN3270E protocol to access the resources on a TN3270E server. However, the TN3270E client cannot complete the connection all the way to the target application because the TN3270E client communicates according to the TN3270E protocol but the target application expects communication to be SNA protocol.
•z/OS UNIX Telnet server
This type provides access to z/OS UNIX shell applications on the MVShost by using Telnet Linemode protocol.
File Transfer Protocol (FTP)
The File Transfer Protocol (FTP) allows a user to copy files from one machine to another. The protocol allows for data transfer between the client (the user) and the server in either direction. In addition to copying files, the client can issue FTP commands to the server to manipulate the underlying file system of the server (for example, to create or delete directories, delete files, rename existing files, and so on). FTP is the most frequently used TCP/IP application for moving files between computers. FTP is built on a client/server architecture and uses separate control and data connections between the client and server.
From an FTP user's point of view, the link is connection-oriented. FTP uses TCP as a transport protocol to provide reliable end-to-end connections. Both hosts must run TCP/IP to establish file transfer. FTP is used to transfer files between TCP/IP hosts. The FTP client is the TCP/IP host that initiates the FTP session; the FTP server is the TCP/IP host to which the client connects.
The z/OS model for the FTP server includes a daemon process and a server process. The daemon process starts when you start your cataloged procedure (for example, START FTPD), and it listens for connection requests on a specific port. When the daemon accepts an incoming connection, it creates a new process (server's address space) for the FTP server, which handles the connection for the rest of the FTP login session. Each login session has its own server process.
z/OS UNIX sockets
Sockets are used for local (intrahost) and remote (interhost or network) communication between UNIX processes. Simply consider the concept of an API as being the set of C library service calls used to work with a particular resource. Although sockets and HFS files are both streams, the complexity of socket handling requires more powerful syntax and options for handling socket data. This is relevant in a later discussion where you’ll see that z/OS has perhaps eight different socket APIs. A powerful design principle was used in UNIX data processing: Any type of data manipulated by a process can be represented by a standard file/stream structure. Also, a single set of program calls is used to open streams, read and update data, and close streams to insulate the program from dealing with the physical origin of stream data.
The Resolver
The resolver acts on behalf of programs as a client that accesses name servers for name-to-address or address-to-name resolution. The resolver can also be used to provide protocol and services information. To resolve the query for the requesting program, the resolver can use information obtained from any of the following sources:
•Available name servers
•Its system-wide resolver cache of name server data
•Local definitions, such as /etc/resolv.conf, /etc/hosts, /etc/ipnodes, HOSTS.SITEINFO, HOSTS.ADDRINFO, or ETC.IPNODES
Whether the resolver uses name servers, and how, is controlled by TCPIP.DATA statements (resolver directives). When system-wide caching is enabled, the resolver can also use DNS response information that has been cached locally.
Resolver flows show the information request and response flows as the resolver gets a request, and based on its own configuration file either looks at a local hosts file or sends a request to a DNS server. After the relationship between the host name and IP address is established, the Resolver returns the response to the application. In a z/OS system, this task is more complex, because the applications can be built using one of three main groups of sockets API environments:
•Native TCP/IP sockets
•UNIX System Services callable sockets (BPX1xxxx calls)
•IBM Language Environment® C/C++ sockets
To initiate a request to the resolver in z/OS, an application executes a set of commands based on the Sockets API Library the application used to generate the socket to connect to the TCP/IP stack.
1.6.3 Enterprise Extender
Enterprise Extender (EE) has provided a useful solution to the dilemma of running SNA applications over IP networks. The Enterprise Extender (EE) technology was implemented on most IBM networking platforms during 1998. Its main objective is to provide SNA-over-IP integration that is significantly superior to its predecessors, such as data link switching (DLSw) and IBM AnyNet®. AnyNet is no longer supported in the z/OS Communications Server V1R8 and later. Enterprise Extender has provided a useful solution to the dilemma of running SNA applications over IP networks. “Extending the enterprise” is an appropriate description. Enterprise Extender is a standard created by the Internet Engineering Task Force (IETF) and APPN Implementers’ Workshop (AIW). It is documented in RFC 2353.
Because of its design, the EE architecture is extremely flexible. It can be used in all networks from the smallest to the largest, and provides the network architect with a wide choice of locations within the network to place the SNA/IP boundary. EE uses all the latest routing performance enhancements provided by APPN/HPR.
Figure 1-5 Enterprise Extender
EE uses APPN’s High-Performance Routing (HPR) technology to provide encapsulation of SNA application traffic within UDP frames by HPR-capable devices at the edges of an IP network. These edge devices are called endpoints. This is illustrated in Figure 1-5. To the IP network, the SNA traffic is UDP datagrams that get routed without hardware or software changes to the IP network. To the SNA application, the session is normal SNA with predictable performance and high availability. By wrapping the SNA application in this way, EE enables SNA data to be carried over an IP network without changing either the SNA applications or the IP hardware.
EE architecture
The Enterprise Extender architecture carries the SNA High-Performance Routing (HPR) traffic of any logical unit type over an IP infrastructure without requiring changes to that infrastructure. It treats the IP network as a particular type of SNA logical connection. In this manner, the SNA protocols act as transport protocols on top of IP, as does any other transport protocol such as Transmission Control Protocol. An important aspect of Enterprise Extender is the ability to view the IP network as an APPN connection network. In this case, the benefit comes from the ability to establish dynamically a single one-hop HPR link to any host to which IP connectivity is enabled, provided that the host implements Enterprise Extender. In general, this allows the routing function to be handled entirely within IP. IP routers serve as the only routing nodes (hosts) in the network.
The implementation of EE in z/OS involves data transfer between the VTAM and the TCP/IP address spaces. A special connection type called IUTSAMEH is used to move data from VTAM to TCP/IP and vice versa. This connection type is used to connect two or more Communications Server for z/OS IP stacks running on the same MVS image. In addition, it is used to connect the z/OS Communications Server IP stacks to z/OS VTAM for use by Enterprise Extender. For Enterprise Extender, z/OS Communications Server implements a separate UDP layer called “Fast UDP” that is optimized for Enterprise Extender communication. Fast UDP, communicates with Enterprise Extender (the APPN over UDP component in VTAM through the IUTSAMEH device.
1.6.4 TN3270/E
During the last several decades, before the Internet Protocol’s rise in popularity, large organizations established their own SNA networks. These SNA networks were used to communicate between remote users and the centralized mainframe. The display management protocol used to facilitate this communication within an SNA environment was called the 3270 data stream. At the user’s location in an SNA network was a device referred to as a 3270 terminal.
A 3270 terminal was a non-programmable (sometimes called “dumb”) workstation. Stated more simply, it was a monitor with a keyboard attached. The 3270 terminal had only rudimentary communications capabilities and was text-based. One of the earliest model 3270 terminal displays (3278 model 1) consisted of 12 rows and 80 columns of text characters, no more and no less. Eventually, a 24 x 80 screen size became the standard, with some alternate sizes available.
Today, a single instance of the TN3270E server can support up to 128 000 emulated 3270 display terminals. Display terminals are emulated in software called TN3270E clients, which can run on a standard personal computer or workstation. In the world of genuine 3270 display terminals, 128,000 users would require an enormous amount of dedicated, limited function keyboard and display devices, not to mention 2000 dedicated 3174 control units. As network use exploded, the SNA 3270 method of communicating with a mainframe became untenable. The solution came in the form of the Internet Protocol (IP).
A TN3270E client uses the TN3270E protocol to access the resources on a TN3270E server. However, the TN3270E client cannot complete the connection all the way to the target application because the TN3270E client communicates according to the TN3270E protocol, but the target application expects communication to be SNA protocol. In effect, the TN3270E server is nothing more than a protocol converter: on one side it maintains an RFC 2355-compliant TN3270E session; on the other side, it emulates a 3270 data stream terminal (including the 3174 control unit) to VTAM. The target application cannot tell the difference between a genuine 3270-attached terminal and a TN3270E server-emulated terminal. Among the many capabilities of TN3270E, one is the ability of the TN3270E client specifically to request an LU to be used as the terminal LU. This level of control allows more control, from an SNA point of view.
1.6.5 Special features
The IBM z/OS Communications Server provides some special functions to enable high availability, load balancing and performance. This section describes some of those functions.
Virtual IP Address (VIPA)
A VIPA is a generic term that refers to an internet address on a z/OS host that is not associated with a physical adapter. There are two types of VIPAs:
•A static VIPA cannot be changed except through an operatorcommand.
•A dynamic VIPA (DVIPA) can move to other TCP/IP stack members in a sysplex or it can be activated by an application program or by a supplied utility. Dynamic VIPAs are used to implement sysplex distributor.
The virtual IP address (VIPA) removes the adapter as a single point of failure by providing an IP address that is associated with a stack without associating it with a specific physical network attachment. Because the virtual device exists only in software, it is always active and never experiences a physical failure. A VIPA has no single physical network attachment associated with it. Also, the TCP/IP stack does not maintain interface counters for VIPA interfaces (virtual links).
Dynamic Virtual IP Address (DVIPA)
DVIPA is part of the evolution of the VIPA feature that we described. The VIPA mentioned in the previous section was static. It is defined through a DEVICE and LINK statement pair and remains unchanged unless explicitly removed by changing the active configuration statements. By contrast, a dynamic VIPA would normally be activated in one of two ways:
•An application explicitly issuing a bind() function call to the IP address. This is called unique application-instance DVIPA.
•A TCP/IP stack dynamically activating the address. This is called multiple application-instance DVIPA.
In order for TCP/IP to communicate DVIPA status among LPARs, TCP/IP uses an XCF group called EZBTCPCS. DVIPA is beneficial, from a network perspective due to following reasons:
•DVIPAs allow servers to be made available independently of hardware or software failures. This can be done dynamically by TCP/IP or even by a system automation product.
•DVIPA allows multiple LPARs to appear to be a single, highly available network host.
•Because DVIPA movement is automatic, users and clients might never know a DVIPA address movement has occurred.
•With DVIPA, applications can be seamlessly moved from one LPAR to another, allowing a virtualization of the application itself.
A distributed DVIPA, which is a special type of DVIPA, can distribute connections within a sysplex. Dynamic VIPAs are designed to interoperate with a dynamic routing daemon. Therefore, it is highly recommended that a dynamic routing daemon (such as OSPF) be used on a z/OS host that uses VIPAs.
Sysplex Distributor
The Sysplex Distributor can be viewed as an evolution of connectivityimprovements. It is a combination of the high availability features of DVIPA and the workload optimization capabilities of WLM. The implementation has one significant difference: Rather than all participating hosts being effectively equal, LPARs can be given specific roles to play. When combined with WLM, the overall effect on availability is exceptional. Another change with sysplex distributor is that the distribution is possible only with TCP connections. Other Layer 4 protocols are not supported.
VMAC
Before the introduction of the virtual MAC function, an OSA interface only had one MAC address. This restriction caused problems when using load balancing technologies in conjunction with TCP/IP stacks that share OSA interfaces. The single MAC address of the OSA also causes a problem when using TCP/IP stacks as a forwarding router for packets destined to unregistered IP addresses.
VMAC support enables an OSA interface to have not only a physical MAC address, but also many distinct virtual MAC addresses for each device or interface in a stack. That is, each stack can define up to eight VMACs per protocol (IPv4 or IPv6) for each OSA interface. With the use of VMACs, forwarding decisions in the OSA can be made without having to involve OSI Layer 3 level (network layer/IP layer). From a LAN perspective, the OSA interface with a VMAC appears as a dedicated device or interface to a TCP/IP stack. Packets destined for a TCP/IP stack are identified by an assigned VMAC address and packets sent to the LAN from the stack use the VMAC address as the source MAC address. This means that all IP addresses associated with a TCP/IP stack are accessible using their own VMAC address, rather than sharing a single physical MAC address of an OSA interface.
QDIO
QDIO is a highly efficient data transfer mechanism that is designed to dramatically reduce system overhead and improve throughput by using system memory queues and a signaling protocol to directly exchange data between the OSA microprocessor and network software. QDIO is the interface between the operating system and the OSA hardware. The components that make up QDIO are DMA, data router, priorityqueuing, dynamic OSA Address Table building, LPAR-to-LPAR communication, and Internet Protocol (IP) Assist functions. QDIO supports both IP and non-IP traffic.
HiperSockets
HiperSockets implementation is based on the OSA-Express Queued Direct Input/Output(QDIO) protocol, hence HiperSockets is called internal QDIO (iQDIO). The Licensed Internal Code (LIC) emulates the link control layer of an OSA-Express QDIO interface. Typically, before you can transport a packet on an external LAN, you have to build a LAN frame, and insert the MAC address of the destination host or router on that LAN into the frame. HiperSockets do not use LAN frames, destination hosts, or routers. TCP/IP stacks are addressed by inbound data queue addresses rather than MAC addresses.
The System z LIC maintains a lookup table of IP addresses for each HiperSocket. This table represents an internal LAN. When a TCP/IP stack starts a HiperSockets device, the device is registered in the IP address lookup table with its IP address, and its input and output data queue pointers. If a TCP/IP device is stopped, the entry for this device is deleted from the IP address lookup table. HiperSockets copy data synchronously from the output queue of the sending TCP/IP device to the input queue of the receiving TCP/IP device by using the memory bus to copy the data through an I/O instruction.
The controlling operating system that performs I/O processing is identical to OSA-Express in QDIO mode. The data transfer time is similar to a cross-address space memory move, with latency close to zero. To get a data move total elapsed time, you have to add the operating system I/O processing time to the LIC data move time.
HiperSockets operations are executed on the central processor (CP) where the I/O request is initiated. HiperSockets starts read or write operations. The completion of a data move is indicated by the sending side to the receiving side with a Signal Adapter (SIGA) instruction. Optionally, the receiving side can use dispatcher polling rather than handling SIGA interrupts. The I/O processing is performed reducing demand on the System Assist Processor (SAP). This new implementation is also called thin interrupt.
Open Systems Adapter Support Facility (OSA/SF)
The TCP/IP subagent can retrieve SNMP management data from the Open Systems Adapter Support Facility (OSA/SF) for several OSA adapters. The OSA product also provides an SNMP subagent, the OSA-Express Direct subagent, which supports management data for OSA-Express adapters. The OSA-Express Direct subagent can be used with Communications Server SNMP support to retrieve the management data. Use the OSA-Express Direct subagent for OSA management data, rather than the TCP/IP subagent, because the OSA-Express Direct subagent communicates directly with the OSA-Express adapters and does not require the OSA/SF and IOASNMP applications.
OSA/SF includes a Java-based graphical user interface (GUI) in support of the client application. The Java GUI is independent of any operating system or server (transparent to the operating system), and is expected to operate wherever the current Java runtimes are available. Use of the GUI is optional. A REXX command interface is also included with OSA/SF. OSA/SF is not required to set up the OSA features in QDIO mode (CHPID type OSD), but it can be used for monitoring and controlling ports. OSA/SF has been, and continues to be, integrated in z/OS, z/VM, and IBM z/VSE®, and runs as a host application. For OSA/SF, Java GUI communication is supported via TCP/IP only. In the past, communication was supported via EHLLAPI (3270), APPC, and TCP/IP. This integrated version of OSA/SF is a complete replacement for the currently integrated versions in z/OS, z/VM, and z/VSE. This version of OSA/SF is not being offered as a separately orderable program product.
The OSA/SF is used primarily for the following functions:
•Manage all OSA ports.
•Configure all OSA non-QDIO ports.
•Configure local MAC.
•Display registered IPv4 addresses (in use and not in use). It is supported on System z servers for QDIO ports.
•Display registered IPv4 or IPv6 Virtual MAC and VLAN ID associated with all OSA Ethernet features configured as QDIO Layer 2.
•Provide status information about an OSA port (shared or exclusive use state). This support is applicable to all OSA features on System z servers. With z/OS, a second interface using a set of REXX EXECs through the Time Sharing Option Extensions (TSO/E) can be used to control the OSA features defined to System z servers on which the TSO/E is running.
1.7 Network tools and products
With such a complex architecture that provides a variety of functions to communicate with the System z and z/OS, the mainframe networking has a wide range of licensed programs to simplify tasks and provide ease of management and administration. These products provide session management functions, network monitoring, performance management and diagnosis tools. There are products from IBM and third-party vendors that provide similar or exclusive functions.
1.7.1 NetView Performance Monitor
The IBM Tivoli® NetView® Performance Monitor (NPM) aids network support personnel in managing VTAM-based communications networks. It collects and reports on data on the host and NCP. NPM data can be used for the following purposes:
•Identify network traffic bottlenecks
•Display screens showing volume and response times for various resources
•Generate color graphs of real-time and historical data
•Alert users to response time threshold exceptions
NPM performance data can also help in several ways:
•Determine the performance characteristics of a network and its components
•Identify network performance problems
•Tune communications networks for better performance and verify the effects of problem resolutions
•Gauge unused capacity when planning for current network changes
•Produce timely and meaningful reports on network status for multiple levels of management.
1.7.2 OMEGAMON XE for Mainframe Networks
IBM Tivoli OMEGAMON® XE for Mainframe Networks collects network performance data across z/OS systems. The following list includes several other functions and benefits of Omegamon XE for Mainframe Networks:
•Immediately sense poor or unstable network connections that hamper application performance, and allows you to quickly pinpoint root causes to ensure high availability of services and improve user productivity
•Enables the management of multiple z/OS and network stacks from a single interface to improve user productivity and operational scalability
•Improves your ability to standardize event, incident, problem, and availability management across domains and platforms through extensive integration with Tivoli NetView for z/OS, Tivoli Enterprise Portal and the entire OMEGAMON suite, Tivoli Netcool/OMNIbus, and Tivoli System Automation for z/OS to achieve operational excellence
•Real-time reporting and alert monitoring on Enterprise Extender (EE) and High Performance Router (HPR) connections
•The first monitor for IP Security (IPSec) and capability to detect intrusions and identify the culprit
•Monitors OSA Adapter performance and detect IP congestion which might slow down transaction response time
•Monitors FTP job status and performance throughput with alert notification and automated actions to correct problems
1.7.3 Session Manager for z/OS
IBM Session Manager for z/OS allows access to multiple z/OS applications from a single 3270 terminal, helping users manage their workload more efficiently and productively. Users can switch between applications with a single key stroke or command. This secure single menu gives users access to applications running on any z/OS machine in the network. Session manager provides following features and functions:
•Provides secure, intuitive access to multiple z/OS systems from a single 3270 terminal.
•Session recovery provides greater resilience and flexibility after a planned or unplanned outage.
•Cost and effort of network administration is reduced with further benefits to help desk and operations personnel.
•Centralized user ID administration allows the ability to broadcast messages to users.
•Batch administration eases the potential administration overhead for mass updates for large sites.
•Dynamic menus allow users and applications to be administered using External Security Manager definitions.
1.7.4 Solve: Access Session Management
CA SOLVE:Access Session Management improves user productivity, reduces training costs and simplifies the process of logging client programs into centralized applications. It reduces the time and cost of network administration and enhances the support the Service Desk provides to users through centralized user ID administration, enhanced visibility of user problems and more. CA SOLVE:Access simplifies user access and network administration, and enhances security. In addition, the product integrates with CA NetMaster Network Management for TCP/IP, which helps you improve correlation between users and connections, and provides CA SOLVE:Access with IP addresses for display. It includes the following key features:
•Simplified mainframe application access
•Scripted logon to applications
•Reduced network administration time and cost
•Enhanced network security
•Improved customization and configuration
•Modern network infrastructure support
1.8 Operations and administration
In this section, we describe the tasks, roles, and responsibilities involved in managing and administering a mainframe network environment.
1.8.1 Operational tasks
The role of a z/OS network administrator can span a wide area. In some organizations you might be a generalist, looking after all z/OS networking components, printer subsystems, and even some of the hardware. However, it is more likely that you will specialize in one or two particular areas, such as VTAM and TCP/IP.
This chapter remains at a high level, and attempts to give you a general understanding of the role. Within z/OS networking components on the mainframe, these are some of the common tasks that you are expected to perform:
•Correct z/OS network-related faults.
•Change and configure network components.
•Monitor and control network components.
•Provide network performance and usage statistics.
•Work with other groups on projects, tasks and problems. These groups might include operations, the WAN network team, z/OS systems programmers, change control, business users, and testers.
“Monitoring” means watching and observing, normally to see something change. This does not imply that you sit there all day watching a screen. There are network management tools installed on z/OS to capture alert and monitor messages and events. There are also network operations staff members who normally are the first-level filters for problems.
1.8.2 z/OS network administrator tasks
Network administrator tasks can be varied and are, one way or another, derived from the needs of the organization within which the network administrator functions. In an environment other than z/OS, a network administrator might have a role that encompasses many platforms and hardware areas. However, z/OS network administrators tend to have a more narrow focus. One reason for this is complexity: network administration on z/OS requires a good working knowledge of z/OS itself. It also requires a good knowledge of networking hardware. When you combine this with the actual VTAM, TCP/IP, LAN, and WAN knowledge required, the z/OS network administrator is unlikely to have the opportunity to include other platforms.
So what are some of the tasks a z/OS a network administrator might undertake? A sampling is described in Table 1-1.
Table 1-1 Network administrator tasks
Task
Description
Problem source identification
When something does not function as expected, the network administrator is one of the first persons to work towards resolution.
Network control
VTAM, TCP/IP, and their associated applications must be started, stopped, monitored, and maintained as required.
Planning
Planning includes network architecture decisions, such as what role z/OS plays in the network and how z/OS should be situated in the network.
Change control
In a z/OS network environment, all changes are part of a planned and controlled process. The z/OS network administrator would work with other network administrators.
Hardware evaluation
If a new feature is to be added to the z/OS host or to the network used by the z/OS host, then an evaluation of the impact of the feature must be assessed.
Software evaluation
In the TCP/IP world, new networking applications and updated existing ones are literally a daily phenomenon.
Installation of hardware and software
After the decision is made, the actual software or hardware must be implemented.
Capacity planning
Network capacity requirements are always changing.
Paperwork
Documentation of the environment, changes, and procedures are all part of the network administrator’s role.
For problem determination, the network administrator should first determine the general cause of the problem by reading error messages, checking for system memory dumps, checking to see whether software or hardware has changed, and reading the system log. After determining the general cause of the problem, the network administrator should use the tools and diagnostic aids available to determine the specific cause of the problem. Lastly, tuning tasks should be carried out to ensure good network performance.
z/OS has diagnostic aids that the network administrator can use: abend dumps, stand-alone dumps, and supervisor call (SVC) dumps, which the Interactive Problem Control System can format for easier reading. VTAM also has specific aids, such as IBM First Failure Support Technology™, CSDUMPs, network traces, sense codes, VTAM traces, and commands that display the state of VTAM components and resources. TCP/IP has component traces and diagnostic commands (such as the NETSTAT command) that help determine problems in the IP network.
Communications Storage Manager (CSM) problems generally manifest as central storage problems. The network administrator can display CSM’s use of storage, activate CSM VTAM traces, and dump CSM storage for analysis.
1.9 Securing mainframe networks
The security objectives in networking aim to achieve data integrity and privacy despite all the threats that networks are exposed to in today’s computing environment. This would not be a complex challenge if communication between two applications were given a physically isolated and dedicated wire link for each conversation. However, physical networks share resources among numerous users. Furthermore, technologies such as TCP/IP and the Internet have been designed to make this sharing flexible and easy. Therefore, network security is an area that needs to be addressed.
With respect to the mainframe, the complexity of the hardware components, various protocols and advanced features pose more challenges in ensuring security and isolation, even within a single central processing complex that hosts multiple logical partitions.
From the hardware perspective, System z does have integrated hardware network adapters, and the counter-measures to the security threats are left to the software running in the system. However, there are other needs for security at the hardware level, because these adapters are also resources that must be sharable between logical partitions and even, in the case of VLANs, between networks. Another consideration regarding network security with System z is that, in some System z configurations, the TCP/IP protocol can be transported by IBM proprietary technologies and is less exposed to the classical networking threats.
Thus, as mentioned, data security and isolation demanded is much higher and complex on System z due to the virtualization it provides at various levels. Technologies such as HiperSockets or RoCE makes it evident to prove the customers that the data belonging to a particular transaction is secure, and which is traceable throughout its lifecycle. Also, with SNA not being popular as TCP/IP due to its restricted use with only mainframe applications, any incorrect configuration or practice might expose it to a serious security threat. As the technology now allows SNA over IP communication, such threats might propagate to a wider scope endangering a larger part of the business.
Therefore, there is a need to protect mainframe network resources appropriately to secure the applications that use the functions of System z and IBM Communications Server components and protocols.
In the remainder of this book, we focus on network security for the following integrated System z components:
The mainframe, like any other IT component in a complex deployment, does not stand-alone. It is crucial for every organization to define and apply an enterprise-wide security architecture that regards the resources on a mainframe as part of the overall solution. Policies, access control, log file collections, and more must be consolidated at a centralized security office. To further investigate this integration, read the related IBM Redbooks publication titled Security on the IBM Mainframe: Volume 1 A Holistic Approach to Reduce Risk and Improve Security, SG24-7803.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset