Several decades ago, it was common for a mainframe shop to have at least five dedicated systems programmers plus two per additional image. Today, only the largest sites can boast five dedicated systems programmers.
Raise your hand if your shop fits that classic five-person profile. Are you counting the DB2 database administrator, the network administrator who keeps your TCP/IP profile up to snuff, or the security specialist who also spends time with the active directory? Then put your hand back down. The fact is, many small shops can’t claim a single, dedicated operating systems programmer, much less five of them.
How are small and mid-size mainframe installations coping with the shortage of support skills? One emerging trend is the use of remote managed support. A remote team can take full responsibility for the operating system, or it can augment the on-site staff, providing depth, breadth, and continuity.
To better understand the appeal of alternative support strategies—such as remote managed support—let’s consider some of the long-term trends in tech support. The mix of the activities being performed and the skills required have both changed substantially.
What Happened to the JES2 Group?
You may recall the days of specialization in the tech support department. Dedicated teams within the department could focus on individual operating system components or subsystems: the JES2 group, the CICS group, the VTAM/ NCP team. These specialized teams have disappeared from most shops, and smaller tech support groups are being stretched to cover the entire system. What has changed in the IT environment to make this feasible?
For starters, we were installing and maintaining vendor software with tools such as SMP, which were less effective than they are today. The systems programmer spent a lot of time analyzing and resolving conflicts that arose in the installation of products and maintenance. Today, improvements in the tools, primarily SMP/E, and in the packaging have reduced this workload. In addition, most shops now install major upgrades less frequently, typically once every few years. Today, the operating system is packaged with many of the popular products (e.g., ISPF, RMF) that, in the past, may have required separate installation processes.
Finally, we’ve significantly reduced our use of exits, source changes and superzaps to modify vendor products. To paraphrase Henry Ford, pick any flavor you like as long as it’s vanilla. As a result, we don’t need to know as much about product internals.
The systems programmer has become, in many ways, the system integrator. We connect components to one another; we connect the mainframe to other platforms; and we build procedures and jobs that manage the day-today needs of the system. We’re focused more on the business needs of our enterprise and less on the internal technology of the mainframe operating system. And we’re not alone in this trend: Your company’s Unix team probably isn’t writing their own device drivers, either.
Build or Buy?