Linux on System z has been an important part of z/VSE’s Protect, Integrate and Extend (PIE) strategy for many years. It:
- Protects customers’ enormous cumulative investment in their core z/VSE applications
- Integrates z/VSE systems and applications into a heterogeneous IT environment
- Extends z/VSE’s capabilities with features and functions provided by Linux on System z or other platforms.
Linux on System z provides many useful functions that z/VSE doesn’t provide. It offers WebSphere, Java, DB2 Universal Database, a rich set of development tools, and a growing selection of packaged applications. On the other hand, z/VSE provides excellent, cost-effective capabilities to run traditional workloads such as CICS transactions or batch jobs.
To allow easy integration of z/VSE with other systems and applications, z/VSE provides a huge set of so-called connectors that allow access to various types of z/VSE data and applications from remote applications and vice versa. Examples for such connectors are the VSE connector server and client, the VSAM redirector, VSE script server, VSE VTAPE, CICS Web support and Web services support, as well as products such as CICS Transaction Gateway, DB2 Server for VSE Client Edition, and WebSphere MQ client and server.
Most of those connectors are based on standard TCP/IP communication. A TCP/IP stack is required on z/VSE and on Linux on System z and a network connection must exist between the two systems. This can be a network cable, a shared OSA adapter, or a HiperSocket network.
Most connectors can be used with various operating systems such as Linux, UNIX, AIX, Windows, etc. However, for best performance, it’s recommended you keep the distance between the two sides as short as possible. It’s certainly a good idea to run the connector solution on Linux on System z right beside the z/VSE systems on the same mainframe server in a separate Logical Partition (LPAR) or z/VM guest, as this shortens the distance between the two sides as much as possible. It also allows the two sides to be interconnected using virtual networks such as HiperSocket, virtual LANs, virtual switches (VSWITCH), etc.
While such virtual networks help reduce network transfer times, latency times, etc., the communication is still based on the TCP and IP protocols. When TCP/IP was designed, the networks were far from being as reliable as today’s networks. So it was designed to allow reliable communication over a non-reliable network. TCP/IP provides mechanisms to handle packet loss, duplicate packets, packet sequence errors, damaged or incomplete packets, etc. To protect against such errors, it uses techniques such as sequence numbers, acknowledgments, and checksums. All those features are required on a real network, but they add a certain amount of processing overhead to the TCP/IP stacks on all involved systems. On z/VSE, the TCP/IP stack runs in a separate partition, so all data sent or received by an application must first be passed (copied) to the TCP/IP stack. This requires some kind of inter-process communication and dispatching, which again adds some overhead. Such processing overhead adds to CPU utilization and can reduce system performance and throughput.
When z/VSE runs side by side with Linux on System z on the same physical mainframe server, the communication between them still works the same way using TCP/IP, including all its processing overhead for checksums, sequence numbers, and acknowledgments. While these things are essential for a real network, why do we have to do all this expensive processing when the two systems run in the same hardware box? Why do we have to go all the way through the TCP/IP stack on the one side, through the (virtual) network and through the TCP/IP stack on the other side, until we reach the target application? Shouldn’t there be a more direct way of communication that doesn’t involve all that expensive processing? The answer is the z/VSE Fast Path to Linux (Linux Fast Path, or LFP) on System z.
Linux Fast Path
LFP is a brand new function provided as part of z/VSE V4.3, which has been generally available since Nov. 26, 2010. It provides for more direct communication (a fast path) between z/VSE applications and applications running on Linux on System z.
Instead of using TCP/IP-based network communication, LFP uses Inter-User Communication Vehicle (IUCV)-based communication. IUCV is a z/VM function that has existed for years and is heavily used by z/VM and other applications. It provides a fast, reliable communication path between z/VM guests running under the same z/VM system. IUCV doesn’t care about checksums, sequence numbers, acknowledgements, packet loss, or damaged packets since it’s just a memory copy from one z/VM guest to another. It causes much less overhead compared to a TCP/IP-based communication.