Can mainframers and Unix die hards get along?
What are their differences and what can you do to bridge the gap?
OK, we all know that mainframe folks and Unix hackers are completely different breeds. But in addition to listing the whys, it's time we figured out what can we do about it. Every company needs both, so it's important to understand their perspectives in order to get them working together effectively. We'll look at the varying opinions and technical strengths of both sides and consider the possibilities for partnership. (2,300 words)
What is it about mainframers and Unix gurus that causes such a rift? Volumes have been written on the differences between men and women, but the computing analog of Men are from Mars, Women are from Venus does not exist. Instead of continual sniping and misunderstanding, isn't it time that we all tried to reach out?
As the world shifts to client/server and network-centric computing, Unix systems are suddenly moving out of engineering labs and into glass house data centers. Understandably, the folks running the mainframe systems in those centers are perturbed. They don't trust Unix or its evangelists, and they don't understand why we can't happily run mainframes for the next twenty years.
Unix users are similarly confused. Data centers are highly controlled, disciplined places. There are rules, processes, and procedures in a data center that just don't accommodate the Unix mentality. Unix in a data center just isn't much fun.
Like dissimilar heroes in any buddy movie, mainframers and Unix advocates
may have their differences, but they will have to join forces
to fight a common enemy. As both sides will quickly agree, they may
dislike each other, but they both know what happens if we get rid of the
mainframe and stop running Unix, only one choice remains:
NT. Whether you're a Unix geek cracking open your first IBM
Principles of Operation manual or a mainframer trying to figure out
why they call it
ls, nothing could possibly be as
bad as becoming one with the Borg and running NT as your enterprise
In any buddy movie, there comes a time when the overall threat becomes so great that the heroes accept one another, understand their combined strengths, and work together to triumph. It is time for Unix and mainframe systems programmers to find that common ground, and the only way to do it is to see themselves through each other's eyes. If you are in the position of managing a data center housing Unix and mainframe systems, knowing how both camps think will help you join these disparate groups into an effective, unified team.
Unix gurus: Using a mainframe is like watching paint dry
From the Unix perspective, mainframe systems are just plain boring. Unix users are used to personalizing and customizing their systems, viewing Unix as a fabulous toolkit. As soon as they install Unix on a system, they immediately begin tweaking and tuning, replacing a daemon here, modifying a configuration file there. Pulling critical system utilities off the Internet is standard, and their most important tools are most always free.
In contrast, everything on the mainframe is preconfigured and spelled out. With its rigid access and control features, there is little room for creativity and individuality. Unix users are used to having unlimited system access via the root account; the idea that even the most privileged mainframe user is still restricted from parts of the system is incomprehensible.
Perhaps the biggest stumbling block for Unix users is that the
mainframe command line environment is miserably limited. If you are
used to running
tcsh, coupled with
the hundreds of handy Unix utilities, you will be severely cramped
by an environment where hardly anything gets done without building
and submitting a job. A good Unix hacker can do almost anything
with a few pipelines of choice Unix tools. Replacing that
capability with something like CICS is a tough hurdle to leap.
For many Unix hackers, reared with the freedom of the Unix mentality, mainframe computing represents authoritarian control: Big Brother in a blue box, sucking all the fun out of life. In many ways, mainframe computing is perceived as a job, while Unix computing is more of an adventure. The tools that surround mainframe systems serve to build and enforce structure, while the tools that support Unix encourage creativity and change.
It may be that the user interface only furthers this dichotomy. Unix systems almost always sport a high-end graphics display running X Windows, even for the system console. Mainframes come standard with a 24x80 monochrome 3270 tube, which even controls where you can type on the screen. For someone who has been reared with responsive graphics and point-and-click interfaces, a 3270 tube is the ultimate set of blinders. It doesn't even have a control key; how would you use emacs on it?
Finally, any good Unix hacker is also a network hacker. Unix is the system of choice for network computing, and Unix is unparalleled in its ability to provide network services to client systems. E-mail, the Web, DNS, NFS, firewalls, proxy servers, and thin-client computing: This is where Unix earns its keep. Such tools have been ported to mainframes, of course, but these versions cannot match their Unix counterparts.
More importantly, that networking capability lets a lot of Unix systems work together. While a data center usually has one or two big mainframe systems, a large Unix environment will have dozens, even hundreds, of systems. Services are moved among the systems, and applications will routinely spawn tasks across the network to get a job done. This kind of distributed computing doesn't work the same way on mainframe systems, and many Unix folks feel confined on one system. After all, what good is a computer if there is no where to telnet to?
Mainframers: Unix is wimpy, wimpy, wimpy
From the mainframe perspective, Unix systems are little toy computers. Unix may have the best of intentions, but it just doesn't have the muscle to handle real business computing.
The biggest issue mainframe people have with Unix is that it lacks all sorts of features they have grown accustomed to. Things like VSAM file systems and generational data groups have been around forever in the mainframe world, and any good mainframe programmer can't imagine living without them. A variety of file formats with controllable record and block sizes along with built-in indexing and data management make life easier for mainframe programmers. Robust job scheduling is always available, and sophisticated print management is a given.
The I/O capabilities (or lack thereof) in Unix constantly frustrates mainframers. Mainframe systems have tremendous I/O bandwidth, with dozens of channels simultaneously delivering many megabytes of data per second to the CPU. Even the latest SCSI interfaces are puny in comparison, and things like Fibre Channel only begin to approach mainframe channel capacities.
More importantly, you can hook all sorts of things to channels, not just disk systems. Most mainframe systems sport at least four or eight tape drives, and the OS knows how to mount, index, and catalog thousands of tapes. File archiving and sophisticated backup capabilities are built in, as is the ability to cut tapes in a variety of formats. Mainframe programmers don't even blink when asked to dump financial data to a 9-track tape in a bank-specific format, make an archival duplicate, ship the original to the bank, and keep the archive around for seven years. When told that the new Unix system has a tape drive that will let you write a byte stream to it ("but any byte stream you define!", Unix folks claim), your average mainframer feels a heart attack coming on.
If this lack of media sophistication drives mainframers crazy, the lack of security simply terrifies them. The concept of root traipsing over a system, changing anything, anywhere, without an audit trail, is horrifying. Even scarier is the kind of person who wants this kind of access. Experienced systems programmers know that reliability is achieved by locking things down and eliminating the freedom to make mistakes -- a concept that is foreign to Unix hackers.
The security provided by mainframe tools like ACF-2 and RACF is comforting protection, with enough flexibility to accommodate almost any security discipline. It is incomprehensible that anyone would run business-critical applications on a system that cannot be secured from the most dangerous of all people: systems programmers. Unix gurus will claim certification for B2 security, but that doesn't keep a determined systems administrator from wiping out your system. A well-designed mainframe security rule set will prevent any individual from destroying your system.
Perhaps most frustrating to mainframe people is Unix's lack of repeatability. If you run a job on the mainframe, and then run it ten more times, it will perform identically all ten times. Resources used, context switches, I/O counts, you name it: that job is completely predictable. Run a similar task in Unix, and all bets are off, especially if the job spawns multiple threads. Because of this lack of repeatability, accounting and charging for CPU time on a Unix system is almost impossible. Unix claims to have process accounting capabilities, but any mainframe person can tell you it is totally inadequate for real chargeback systems -- to which any Unix person would reply, "So what?"
There is a schism not likely to be healed anytime soon. A well-run mainframe can track resource utilization down to the last byte and cycle and bill every user accordingly. Since most Unix people tend to think that computing should be free anyway, billing for usage is a vague concept that only matters to the bean counters of the world. Mainframe people know that computing is an expensive business, and you had better have a way to recover your costs and prove your worth to the user community. Weaned on emacs and scads of free software on the Internet, Unix people believe that computing should be like air, with plenty to go around for everyone. Billing for computing is just not right -- someone else can pick up the tab.
Can't we all just get along?
You may think that two groups this different have no hope of getting together on anything. But the truth is that there is much common ground between them, and their skills are nicely complementary. Your biggest difficulty will be getting them to realize it. The harsh reality is that everything they say about each other is absolutely true, but all those perceived flaws are actually strengths, waiting to be exploited.
For many mainframe programmers, the freedom and flexibility of a Unix system can be refreshing and liberating. A true computing geek loves any nifty computer, and Unix has enough fun stuff to attract even the stodgiest mainframe advocate. Playing with window systems and network tools is fun for anyone, and learning how to use pipes and Unix utilities will surely be a nice change of pace for someone who has been slinging JCL for fifteen years.
Similarly, Unix admins will respect any powerful system, and the mainframe has enough capability to impress anyone. Mainframes also do things that even Unix people have to respect. Watch a team of mainframe programmers break a system into multiple regions, install a new OS into one of the regions, and cut over to that new OS without ever taking the system down, and you'll have new respect for the mainframe.
When looking to merge these two groups, your best bet is to let them each bring the best of their world to the other side. Let the Unix users install some of their utilities, turn on network services, and enable up-to-date network management protocols on the mainframe. Let the mainframers install real job schedulers and honest-to-gosh print management systems and see how much better your Unix systems will run.
For many shops, a migration from mainframe systems to Unix is inevitable. Mainframe systems programmers are faced with either changing jobs, retiring, or learning a whole new environment. By educating them in the ways of Unix, you'll clear the way for them to bring years of mainframe discipline and management to the unruly world of Unix. Mainframers know the business of computing, they are usually better attuned to customer service issues, and they know how to keep a system up and running for years without failure.
Before you roll those mainframes out the door, make sure your Unix gurus get full exposure to the mainframe discipline that surrounds them. Change management procedures, system upgrade processes, job management, and capacity planning are just a few of the skills your Unix systems administrators will need to run your Unix systems with all the robustness and reliability of a mainframe.
That blend, the flexibility of Unix with the reliability of a mainframe, is the critical systems environment that will carry many companies into the next century. Mainframe systems aren't something to be tossed out, as if they have somehow failed us. Mainframes have been a spectacular success, and there are many lessons to be learned from them. Unix, too, is a spectacular success, and brings much promising technology to the table. The marriage of those features will be the core of tomorrow's data center.
Start working to heal the rift between your Unix admins and your mainframe systems programmers now. They are more alike than they are different, and you want them to realize that as soon as possible. It may seem that they are as incompatible as oil and water, but if you can fortify your data center with the best of both these breeds you will be doing yourself -- and your company -- a great service.
About the author
Chuck Musciano has been running various Web sites, including the HTML Guru Home Page, since early 1994, serving up HTML tips and tricks to hundreds of thousands of visitors each month. He's been a beta tester and contributor to the NCSA httpd project and speaks regularly on the Internet, World Wide Web, and related topics. Chuck is currently CIO at the American Kennel Club. Reach Chuck at email@example.com.
If you have technical problems with this magazine, contact firstname.lastname@example.org