Once upon a time, it was easy. Twenty years ago, there were mainframe computers aimed at either business or scientific computing; there were departmental minicomputers; and there were microcomputers (or PCs) on people’s desktops. Everyone in the IT service organization knew which of these systems was which, which mattered, which needed 24x7 support, and which systems generated phone calls in the middle of the night.
Mainframes were easy to identify. They were expensive, and they were most often built and sold by IBM salespeople dressed in identical dark-blue, power suits. IBM mainframes were kept in secure, climate-controlled computer rooms, built with raised floors that left room underneath for the miles of bulky cables that were used to connect them to their storage and networking peripheral devices. We plugged them into high-voltage, conditioned power sources and bathed them in refrigerated air to keep their high-speed circuitry from overheating. We paid operations personnel to sit and watch them run 24 hours a day. These people were trained to respond to console messages and other requests, such as to refill the paper for the attached printers and mount tapes to feed the nightly batch-processing job streams.
In addition, IBM mainframes were tended to by a dedicated, professional support organization—a priesthood devoted to their ritual care and feeding. I know because I was a novice initiated into that priesthood some 25 years ago. We were called systems programmers—a funny name, given that we were not expected to perform much in the way of actual programming. Our job was to become intimate with the internal workings of the hardware, the operating system (OS) that controlled it, and the major subsystems that supported the applications themselves.
Senior systems programmers became adept in the black art of system management that focused on reliability, stability, and timely delivery of services. For me, it was this focus on professional system management—the reliable and predictable delivery of computing services—that distinguished mainframe systems from the other computing platforms at my installation. Only mainframes had a service and support staff that was on call seven days a week, 24 hours a day to fix problems if any of the key processes on any of the machines failed. That professional attitude continues to characterize mainframe installations today.
Change control is a good example of the system management disciplines we practiced. Change—the antithesis of stability— naturally needs to be rigorously controlled in the mainframe environment where a computer outage might impact the people who rely on data processing in their daily jobs. Planned outages for many high availability applications were limited to no more than a few hours per month. These brief outages—usually scheduled in the early morning over a weekend—needed to be carefully orchestrated so that all critical maintenance activities could be performed in the limited amount of downtime that was available.
Because the applications these machines supported were deemed mission- critical, the professional staff responsible for the timely delivery of computer services was held strictly accountable for their stability. Regular reports on system availability and outages were circulated among senior IT managers. To promote stability, the technical support organization would subject a proposed system change to rigorous peer review regarding both its impact and scope. Testing procedures to verify that the change worked and back-out procedures to restore the system to its previous healthy state were critical aspects of the change request that would be challenged and reviewed. System management professionals in turn held the hardware and software vendors to the same high levels of quality. Regular, weekly meetings were held with our key vendors—including, but not limited to, IBM—to review the status of open problems and schedule vendor diagnostic activities into the change control mix.
Exacting system management disciplines— among them, performance management, problem management, change control, capacity planning and others designed to promote the reliable delivery of service—are the hallmark of mainframe computers.
Over the past 10 years, I have worked increasingly with smaller and considerably less expensive systems, mostly Intel architecture servers and workstations. In the course of my work, it was hard not to notice the steadily increasing power, performance, reliability, and other mainframe- worthy attributes of these systems. I expect that many readers have experienced a similar epiphany upon realizing that the Intel server located in the corner office (or the PC workstation on your desktop) is significantly more powerful than the machines that performed the centralized data processing for a Fortune 50 corporation like the one I worked for back in 1978.
As Unix, Linux, and Windows servers have begun to shoulder more of the computing load associated with mission- critical systems and applications, progressive IT support organizations have successfully applied the same system management disciplines that lent mainframes their stability to these other computing platforms.