By now, most companies have discovered that software constitutes a major expense and a drag on mainframe growth. There are several ways to manage this cost, including delayed hardware
Z/OS and the CBT tape
My search failed to find any open source software for the mainframe operating system, z/OS. One may have better luck in going to a source hosting site, such as SourceForge,net, and conducting a search using the word “mainframe.” The query will produce a list of several contributions, but don’t look for major subsystems, such as transaction processors or database management systems. Most of the results will be niche tools.
Fortunately, mainframe users have a long history of sharing code through the CBT tape. Although the CBT tape is actually closer to being a freeware repository, it is a treasure trove of hundreds of mainframe exits, code fragments and utilities, free for everyone to use. In here, mainframe administrators can find such gems as Partitioned Data Sets (PDS), a veritable Swiss Army knife utility for files, and Queue for reading and manipulating JES2 spool contents. Additional pieces of source can guide a systems programmer with sample exits, control blocks chains or explain where to find valuable system information. Chances are that if a person needs system-level code, it’s already on the CBT tape.
The mainframe user group Share used to hand out CBT tapes at conferences. Now, cbttape.org manages the content and makes it available for download or on CD-ROM. As always, the user assumes any risk for utilizing CBT code. And, just like open source, anyone with a new idea or an improvement to an existing module is free to contribute.
One additional note: Technically, any Java open source application will run on z/OS if one has access to the right level of Java virtual machine. However, running software that hasn’t been tested or tuned for mainframes involves several risks. For example, the Java code may not scale well in a high-volume mainframe environment. It may also have incompatibilities with IBM’s JVM. Lastly, and most significantly, there may be little or no support if it breaks.
Despite the paucity of z/OS open source software, there are some alternatives for emulating mainframe functions on Linux or Windows. I have included a few examples below. However, given IBM’s fierce protection of the mainframe brand, the long-term survival of these projects is questionable.
Hercules is a mainframe processor emulator available under the Q Public License. It claims to support the entire z/Architecture machine instruction set and channel commands, although some features–documented here–are lacking. The catch is that one can’t run modern operating systems on Hercules without an IBM license. To fill the gap, Hercules.org offers downloads of mainframe operating systems that may be considered in the public domain, the latest dating from the early ’80s. However, as the website’s frequently asked questions section suggests, you can always contact your local IBM salesperson for a license to run z/OS on a PC or UNIX machine on top of Hercules.
Another contender, z390.org, offers a suite of free Windows and Linux mainframe emulation software. This presentation from Share’s August 2011 conference outlines the offerings, including an Assembler and COBOL compiler. For program unit testing, z390.org supports a VSAM emulator and a subset of CICS commands. With gaps in the CICS application programming interface (API) and potential source code incompatibilities, this software is not ready to run a production workload, but could be handy for offloading some mainframe development and preliminary testing to a distributed server. It is also a great tool for teaching Assembler to young, budding systems programmers.
Cross-platform open source
The best opportunity for running open source on mainframes still appears to be zLinux. Many open source programs that run on Linux port to zLinux, including JBoss (an application server), MySQL (the database) and HornetQ (messaging). Other types of server software, such as Apache, work as well.
However, there are at least two things to be aware of when dealing with established open source code.The first is a potential lack of experience with mainframes, even when dealing with providers such as Red Hat Inc. Open source contributors may think “write once and run everywhere” is not just a figure of speech and will assume software will work on mainframes without extensive testing. Other contributors may not have access to mainframes, which puts the onus for testing on the first installation that dares to implement the software.
The second setback has to do with open source solutions providers. Often, there is a wide disparity between the licensing models of mainframes and distributed platforms. Distributed software charges usually depend on “cores” and “sockets,” which don’t have exact analogs in the mainframe world. Therefore, what might be a sweet deal on an x86 server may prove to be sour on the mainframe. At that point it will take hard-nosed negotiation, similar to what had to be done for non-open source, to get costs in line.
About the author: Robert Crawford has been a systems programmer for 29 years. While specializing in CICS technical support he has also worked with VSAM, DB2, IMS and assorted other mainframe products. He has programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. The latest phase in his career finds him an operations architect responsible for establishing mainframe strategy and direction for a large Insurance company. He lives and works with his family in south Texas.
This was first published in September 2011