Hosing z/OS.e and Other Withdrawals

Published: September 25, 2007

by Hesh Wiener

With each new release, IBM adds capabilities to z/OS. This is hardly surprising. IBM touts forthcoming features in its statements of direction and pre-announcements, and offers technical details at the official announcement, well ahead of the delivery date. The same cannot be said of the other side of this coin. New versions of z/OS don't just add capabilities; they also shed features, move functions around, and change how things work. So, while it was hard to miss IBM's decision to kill z/OS.e, less dramatic changes can be invisible--until some legacy workload fails in an updated environment.

IBM isn't trying to give its customers any headaches. On the contrary, it wants the z/OS base to move to the forefront as quickly as possible. But the road to customer support is paved with good intentions. And it has plenty of potholes because IBM doesn't always do what it says as quickly as you'd think.

About five years ago IBM said that it was going to make big changes in the way mainframes manage domain name services. Basically, z/OS uses the industry standard BIND program and for years Version 4.X of this program was included in the bundle called Communications Server. But the industry had moved on and IBM had fallen behind, so it decided to catch up by moving to Version 9 of BIND with z/OS 1.6. It told customers about this in announcement letter 203-266, issued on October 7, 2003 (and still called an "ivory" letter by many because of the off-white color these announcements were printed on back in the days before the Internet). IBM talked about this matter again a few months later in ivory 204-017, issued February 10, 2004. Except that things didn't quite happen as originally planned.

IBM found that some of the load balancing technology provided by the old BIND wouldn't make a five-version leap ahead, so IBM let customers use the old BIND longer if they needed it to help squeeze better performance out of their mainframe systems. IBM explained its mercy in a technical note. This kind of technical note is not the sort of things users always read, but because the note says that IBM was going to not pull the rug out from under the old BIND, the shops that had wrapped their systems around the venerable (if obsolete) functionality of IBM's BIND 4 didn't have to do anything. Their legacy work on load balancing, if left alone, would keep on working well past what was once supposed to be its migrate-by date.

Here it is nearly five years down the road and IBM is still warning users to watch out, reminding them that BIND 4 in z/OS is going away.

Well, there are all kinds of very progressive shops in the mainframe base and a lot of 'em long since figure out that if they want to have their mainframes play ball in the Unix arena, they are often a lot better off doing the Unix type work in a Linux subsystem than wresting with the technically compliant but otherwise Byzantine world of IBM's infusion of Unix APIs and functionality into z/OS. BIND under Linux may or may not provide all the features that IBM got to work with BIND 4 under z/OS, but because BIND is the world standard for name server software and runs on machines as big as mainframes and a small as standalone Windows PCs, there is some advantage is using BIND in a version and an environment where there are a zillion other users. When your enterprise system gets a DNS toothache, it can be handy to know that every kind of help from amateurs with home remedies to the best (and most expensive) DNS dentists in the world have already piled into the Linux and Unix spaces.

In this instance, good systems strategy boils down to a choice between the z/OS way, which IBM does indeed document and support if you are adept at locating the information, or the z/Linux way, which requires an initial investment in new knowledge but provides a link to a vastly larger and more diverse pool of talent.

Any mainframe shop that doesn't have an interest in reworking its network architecture and which is happily running an old (and maybe even unsupported) version of z/OS would be wise to think about the BIND factor when contemplating any migration to current systems software. If that shop simply has no idea if is using BIND functions that might vanish during an upgrade, which may well be the case, the only way to find out about possible pitfalls might be to bring up an entire enterprise under the new z/OS. If BIND 4 isn't there, and the workload needs it, everyone watching the test will find out soon enough.

The BIND example is just one of many. A related situation that doesn't give users the choice between a new version under z/OS or a new version under z/Linux arises when a mainframe is given the job of assigning IP numbers to clients on a corporate network. A DHCP server, a program that, like BIND, also has roots in Unixland, does this job.

IBM used to package a DHCP server with BIND and a bunch of other goodies in its Communications Server for z/OS bundle. But that's going to end, or at least IBM is threatening to kill it off. On August 7, in ivory 207-175, IBM issued a death threat. If you want your mainframe to provide DHCP services, you had better do it under z/Linux, according to the ivory.

Some users will notice this and take it seriously and scoot over to a Linux DHCP server and be done with it. But others will figure IBM is just bluffing, as it did with BIND, and that in the end it will keep a DHCP server in its Communications Server bundle, at least for a few years. If IBM fears that too much change will keep users from adopting new versions of z/OS, it will blink. Shops that don't want to change their DHCP servers will be able to sit tight.

When a mainframe shop delays moving to new software, it's not because it's lazy. There is always risk in changing systems, and changing big systems, like mainframes, means big risk. This is particularly the case when the functions in flux lie at the heart of a company's network architecture.

Pioneers may get all the benefits IBM promises, but they also may be the users who discover any bugs lurking in the new code. By deferring migration, a user can gain from the experience of other shops, and the experience garnered by IBM's support team, too.

Mainframe shops, particularly the ones that have largely consolidated server farms with their core information processing systems, don't have clear choices. If z/OS 1.9 brings with it significant advantages that will boost the efficiency of key applications, the applications teams in an enterprise are going to be in favor of rapid progress, even if there's a bit or risk involved.

At the same time, networking specialists and systems personnel may feel quite differently about that next release. They have to make sure end users inside and outside the corporate campus can connect to systems and applications. Their work at its best is in a sense invisible; it only becomes apparent that there's a networking team when some users can't get to some servers, or some servers can't get to a database. And to make matters even trickier, the infrastructure folk have to deal with issues totally out of the control of IBM and its z/OS team, such as the transition of clients from Windows XP to Vista; the migration of remote cluster support servers to new versions of Windows, Linux, or Unix; and the never-ending effort to maintain security.

As difficult as it might be for users to keep up, it's only going to get tougher. IBM has become very ambitious when it comes to z/OS. The differences between mainframes and other kinds of servers are diminishing, and there's nothing IBM can do about that. The best IBM can do is use firmware and software to maintain distinctions between mainframes and alternatives, distinctions that help IBM justify the premium price of its flagship products. And when it comes to preparing users for the changes that lie ahead, particularly the ones that involve the end of various legacy functions, the best IBM can do is give its customers adequate warning.

RELATED STORIES & RESOURCES

IBM's z/OS Statements of Direction

IBM Previews Future z/OS, z/VM Mainframe Operating Systems

VSE Becomes an Instrument of Strategy

IBM Commits $100 Million to Make Mainframes Easier to Use

IBM Previews z/OS 1.8 for Mainframe Shops

Sunsets on the 31-bitish Empire

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot