The past three decades have brought a lot of changes to technology and mainframe jobs. In the ’80s, we brought down CICS at 10 p.m. so we could run batch jobs. Likewise, change management consisted of yelling, “New compiler coming!” over the cubicle wall before submitting the install job. In this tip, I’ll discuss the future of systems programming, which centers on several major themes:
- The growth of Unix on the mainframe
- More planning and outsourcing
- Busier programmers and the loss of systems programming skills
More Unix, less z/OS
Current and future systems programmers will need a working knowledge of Unix to support the mainframe.
According to IBM, Integrated Facility for Linux (IFL) specialty engines continue to gain popularity and now account for 19% of installed System z MIPS. On the z/OS side, major subsystems, such as CICS, continue to add new features, including resource bundles, TCP/IP connections and Service Component Architecture (SCA) that require UNIX System Services (USS). New pieces of the operating system, such as z/OS Management Facility (z/OSMF), are also firmly anchored in USS.
As for the future, zLinux is still expanding, and IBM shows no signs of marketing it less. Last year, we saw the introduction of z/Enterprise, which IBM designed explicitly to bring Linux and z/OS into tighter integration. In addition, the growth in USS-dependent z/OS components points to IBM adding more. In fact, I can foresee a time when most new features will require USS to operate.
Planning requirements will grow
Planning and paperwork will become an increasing part of systems programming jobs in the coming years.
As systems become more complex and uptime requirements approach 100%, the urge for planning and rigor will only become greater. This means planning, documenting and tracking change will demand an even larger percentage of administrators’ time. Some companies will strike the right balance between control and productivity. Others may not be so lucky and future systems programmers will end up spending more time struggling with change control rather than applying maintenance.
Love it or hate it, most companies have at least some outsourcing. Dealing with outside vendors requires careful planning and active management practices to ensure a company gets its money’s worth. Outsourcing also affects systems programmers, as they find themselves writing requirements, work orders and procedures for contractors.
Systems programmer to systems administrators
The drop in college students graduating with a mainframe background is one reason why IBM has invested in graphical user interface (GUI) administration tools, such as z/OSMF and CICS Explorer. These tools provide a more familiar interface, which should help users to be productive faster. More tools of this ilk will surely follow until z/OS and its subsystems can be installed, maintained and operated without any green screens. Along with these wizards, IBM is building more automation as well as self-correction into mainframe software, which means there will be fewer parameters to tweak and fewer resources to manage. Ultimately, the goal is to install and run a mainframe as configured, straight out of the box.
Defining the jobs of outsourcers will generate a measure of tension. Management may turn to outsourcing mundane administrative tasks, as it leaves employees free to do higher-level work and design. However, this may not go as planned for a couple reasons. First, some of the time reserved for higher-level work is taken up with managing the outsourced staff. Second, mundane systems programming tasks often serve to educate newbies in the way of the mainframe. Again, the solution should be a nuanced understanding of who should do what when they’re ready.
With fewer future employees possessing the necessary mainframe education, outsourcing of simple work and less free time will lead, in my opinion, to an overall drop in systems programming skill levels. Fewer people are able to read dumps, write assembler or understand how some of the lower-level processes work. While these skills may not seem necessary, enterprises will find out they really need them in a serious crunch.
The movement toward GUI wizards, simplified system maintenance and knowledge drain will combine to gently transmute the systems programmer into a systems administration role similar to that on the distributed platforms. Like Unix and Windows, future mainframe systems will be installed and run with very few, if any, configuration changes. Maintenance will be applied and moved through the Parallel Sysplex without ever logging onto Time Sharing Option (TSO). Finally, system problems and dumps will be referred to IBM with little analysis or intervention by the customer.
Management and staff may have mixed emotions about this change. While there is something to be gained in productivity and spending less time on system minutiae, it also means some of the deeper skills will not be available the next time the Sysplex hangs or a triple storage overlay brings down CICS. Ultimately, referring those troubleshooting tasks to IBM will only make customers more dependent on IBM.
About the author: Robert Crawford has 30 years of systems programmer experience. While specializing in CICS technical support, he has also worked with VSAM, DB2, IMS and assorted other mainframe products. Crawford has programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. At his latest phase in his career, he is an operations architect in south Texas who is responsible for establishing mainframe strategy and direction for a large insurance company.