Mainframe Work, Then and Now
The issues and transitions mainframers faced in the past help us improve today
11/12/2014 5:00:07 AM |
By Gabe Goldberg
It's all too easy as mainframers to answer "What's new?" with "Not much." Or to gripe about the latest bug encountered or fixed, or look forward to installing the (supposedly) latest-and-greatest just-announced whatever from IBM or an ISV.
But taking a longer view is interesting, remembering back five or 20 years or more, focusing on how it's not just technology that's changed, and also the very nature of our work. Today's processors, memory, storage capacities and networks couldn't have been imagined in the early days; paraphrasing a well-known but bogus industry saying, 24-bit addressing was thought to be enough for anybody. And it was, for a while. (Now, of course, we take for granted 64-bit technology, a growing array of opcodes and a massive Principles of Operation that would astonish early mainframers.) Similarly, punch card input and greenbar printed output (and system dumps!) made the world—and the 1403 print train—spin, for a while.
Some things are recalled fondly—on-site support IBMers, frequently visiting IBM sales reps, full source code (for VM, at least)—while others are best forgotten (programming keypunch drum control cards, working night shifts for machine time).
Once dominant batch work—sometimes with turnaround in hours or overnight—is now accompanied or replaced by 24-7 interactive applications.
Remembering the Past
Information was precious and printed. A system programmer's office, recognizable by its multiple manual-filled bookcases, was a challenge to move. And keeping publications—many of them free—updated meant merging technical newsletters to add/replace/delete pages. For some publications (e.g., Principles of Operation, IBM Consultants Manual) this wasn't for the faint hearted.
It was a breakthrough when IBM introduced a product providing a customer-installed database with monthly updates including PTF/APAR records, education descriptions/schedules, publications and more. And spinning multiple tapes and running the update was a less burdensome chore than updating shelves of manuals. The Internet and IBM's Knowledge Center
are quite an improvement over individual manuals' indices and even the helpful VM Master Index.
Software was delivered on round tapes, with cover letters signed by ("bearing the mark of") M Kloomok
Mostly or entirely blue (IBM) installations were common. System programming was typically an "at work" activity, with offices often clustered around the sacred raised-floor, restricted access machine room. Users fought for space in public/shared "terminal rooms." We waged religious wars between VMers/MVSers, only recognizing later that we were really allies on the mainframe team. We dealt with removable DASD volumes (prone to head crashes), managed on some devices with removable address plugs, which we "popped" to notify the system of changes. Tape drive farms were backed by huge tape libraries; volume management/mounting/optimization was a perpetual operator activity and job scheduling challenge.
We suffered with primitive and creaky-slow dial access (calling 56 Kbps broadband) and often had informal or no change control. Having just a few mainstream programming languages simplified user support. Programming was a manual activity with peered code reviews rare. Languages and tools proliferated—usually, but not always, for the better—with, for example, VM evolving from EXEC to EXEC 2 to REXX, and introducing hugely powerful CMS Pipelines. But this required continued learning to maintain skills and marketability, and teams now share their coding work through disciplines such as Agile
Performance and capacity planning, once done by instinct and guess, are much more formalized. Resources such as Cheryl Watson's Tuning Letter
gather, document and distribute z/OS best practices.
As with many technologies and trends, outsourcing goes in and out of favor, along with its black-sheep relative, offshoring. Mainframers have lost jobs to these, or found themselves working for outsource vendors while sitting at their same desk. But some outsourcing has failed, leading to insourcing. Cloud computing might look like outsourcing to just another remote data center but its many variations can present different challenges and opportunities.
Software, Hardware and Billing Are More Complex Than Ever
Once upon a time, billing—from IBM, other hardware vendors and ISVs—was straightforward. Line items were identifiable and software was usually either single payment or monthly lease. And most installations were simple enough that it was clear what software was being used and which could be terminated. When it became more complex, it was worth occasional reviews, comparing bills to system logs to detect abandoned products and save money. But this was still straightforward enough that a system programmer could get it done quickly.
Now, licensing/billing algorithms and terms and conditions require lawyer and accountant skills, and system reporting and analysis tools. Don't ignore billing because it's not technical; don't expect administrative people to grasp IBM's arcane charges. Parallel Sysplex License Charges, Variable Workload License Charges, Advanced Workload License Charges, Advanced Entry Workload License Charges, Entry Workload License Charges and sub-capacity pricing should be in someone technical's vocabulary.
For accurate charging, understand resources such as IBM's Sub-Capacity Reporting Tool
, Mobile Workload Reporting Tool and Tivoli Asset Discovery for z/OS. In the same fashion, hardware configuration management was once simple. It wasn't hard to count disk and tape drives, identifying 3270 terminals and control units and paying maintenance accordingly. Now, hardware asset discovery and management requires sophisticated tools.
Once terminals replaced keypunches, it was only a matter of time before multiple devices on one's desk indicated broad responsibilities. Then the amber multi-session 3290 offered four session viewing, to be replaced by session managers allowing simultaneous access to more systems and applications.
It's always been a system programmer wish for a personal mainframe (with past products XT/370, AT/370 and P/390
satisfying it to varying degrees). Even though we're (mostly) long past midnight hours, and LPARs allow efficient and economical development/test/production separation, a true mainframe sandbox is desirable. Hercules
, an open-source mainframe emulator for diverse personal computer platforms, runs all IBM mainframe operating systems, including ancient versions, which newer mainframes don't support. But, and a continuing irritation to some, IBM doesn't license modern or current systems for use on it and enforces that restriction.
Alternatives that are pricier than Hercules but still much less expensive than big-boy mainframe include IBM's zPDT and Rational RD&T programs that provide small fully functional IBM mainframes. It's always seemed that these systems-—especially those intended for production work—could serve both as lifeboats for orphaned mainframe applications and as mainframe acorns from which mighty systems grow
The Future Is Now
To misuse another quotation, past industry and work evolution don't predict the future. We'll surely see a mix of incremental trends continuing (e.g., telework, mixed-vendor sites, cloud computing), breakthroughs such as Watson wisdom for mainframe information access, and powerful handheld mainframe access or control vastly magnifying today's bring your own device challenges. Applications and systems will support use through smartphones, tablets, all manner of personal computers (Windows, Macintosh, Linux) and devices as yet unimagined.
Increasingly affordable SSD technology may introduce new capabilities, obsolete others (tape, even rotating memory) and alter price/performance decisions. Perhaps Google Glass and in-car telematics will accomplish what once required a 3270 or 029 keypunch. And perhaps IBM's Knowledge Center will apply Watson to dialogues refining search criteria.
As teams are distributed, new collaboration skills are required. Remote desktop viewing/sharing, messaging, video conferencing, social media and reference/information tools such as wikis become critical. Work boundaries change: Some remote workers set fixed hours, while others exploit flexibility to blend/balance on/off-duty time. In times past, people specialized, supporting HASP, CP, CMS performance, or SNA. Now, generalists and (especially) quick learners are in high demand.
Credible competition for the mainframe will increase; some former mainframers already argue convincingly that alternatives offer comparable speed, reliability, scalability and security, perhaps with better price/performance. Compelling reasons for mainframe use— rigorous head-to-head functional comparisons and performance benchmarks—will be needed when "it's a mainframe, it's wonderful" won't always suffice.
In the age of cyber-attacks, even with the mainframe's longstanding innate/inherent security, self- and outsourced audits will be common and valuable. Similarly, businesses handling sensitive information—e.g., health or financial—will increasingly be subject to industry and government regulations. Informal or haphazard change control, access control, system logging, incident response, etc., won't be tolerated.
Technical and procedural standards and increased automation will help transition system programming/administration from specifying detailed implementation to higher-level goal-oriented thinking. Disciplines such as ITIL
will formalize tasks such as change and incident management.
Whether you've been a mainframer for decades or just finished study at an IBM Academic Initiative
institution, opportunities abound to exploit, enjoy and create the mainframe's future. Embrace change as the fuel making the mainframe's next 50 years as rewarding as the first. As you invent the future, remember that change is inevitable and accelerating. IBM has researched how organizational change management has evolved through the years; IT and mainframes must support and enhance business evolution.
Jobs are no longer for life the way they often were. Even careers are more fluid, with people reinventing themselves—voluntarily or of necessity—once or multiple times during their lives. So the most important attribute and skills are being flexible and a quick study; the most important mindset is managing one's own career, because nobody else will.
Finally, consider Eric Sevareid's law: The chief cause of problems is solutions.
Gabe Goldberg has developed, worked with, and written about technology for decades. Email him at firstname.lastname@example.org.