Enterprises running an IBM z/OS mainframe will be familiar with the need for a z/OS systems programmer. In this third part of our series on mainframe-related IT roles, we'll take a look at what a systems programmer does, what education/skills are necessary to become a systems programmer, and how the role has evolved over time.
Who Are Systems Programmers and What Do They Do?
The role of a systems programmer entails installing, customizing, and ensuring the operation of an enterprise's operating system. These programmers maintain mainframe hardware configurations, install and customize the operating system, ensure the system and its services are operating in compliance with service level agreements, and plan for minimal system disruptions. Additionally, these programmers provide mainframe technical support for developers.
Steve Gear, a 30-year veteran z/OS systems programmer, says he takes responsibility for keeping the mainframe up and running. "That means 99.999% uptime and no unexpected outages," he explains. "You also need to plan, test, document, backup, and communicate all that you do." Gear advises those interested his line of work read Dave Elder-Vass's "MVS Systems Programming," particularly the first chapter, because much of it is still relevant today.
Additionally, systems programmers are engaged in the performance and tuning process for the mainframe system, installing and maintaining third-party products, updating documentation, and being the resource for mainframe-related questions for the company.
With regard to application maintenance and upgrades within the software portfolio, Gear advises programmers familiarize themselves with IBM's SMP/E, if available. "It's a key tool for the systems programmer as it does many things to maintain the software installation," he adds. "Any time devoted to learning how it works, how to maintain the SMP environment, and how it should be used will be time well spent."
Gear indicates his day-to-day can include:
- Monitoring the performance of workloads,
- Reviewing and resolving any issues in the system display and search facility (SDSF)
- Working on incident tickets opened for the mainframe team
- Running batch reports from tape or direct access storage devices (DASD) to ensure that hardware is working properly
- Researching any available maintenance for third-party products or z/OS
- Working on the maintenance timeline and checklist
Above all, he also keeps up-to-date on the latest z/OS updates and maintains any relevant documentation to reflect changes or upgrades.
Systems Programmer Skills Requirements
Gear points out that programmers today are encouraged to have a computer science or management information systems (MIS) degree, though he laments that most colleges and universities still do not have specific mainframe tracks. He adds, "If I were 20 years old, I would definitely take all of the Marist College certifications."
Additionally, systems programmers can up their skills through SHARE education programs and through IBM. "When I started as a programmer," Gear says, "I studied every IBM manual I could get my hands on, plus every Multiple Virtual Storage (MVS) book that was published." He reminds new systems programmers that "you are never finished learning."
Role of Systems Programmer During Migration
Gear says that before a typical operating system or product migration, systems programmers need to audit the current system's utilization for both hardware and software. With that, programmers need to research what the driving system requirements are and possibly update that driving system to meet the new product's needs, while ensuring the current production can still function. Once a new version is identified, programmers need to review the features and functions of both the software and hardware, as well as any prerequisites z/OS needs to meet.
Gear says this is when systems programmers work with the vendor to build the product to order, while simultaneously creating project plans to build the driving system; a new version in the test system, including an install checklist and testing plan; and deploy production plans. "Don't forget to communicate all these plans to affected parties within each department at the company and their teams," says Gear. "Have as many change management meetings as it takes to get everyone up to speed."
Evolution of Systems Programming
Gear, who has a Bachelor of Science degree in geography and geology, was hired as a programmer in the 1980s, sidelining his initial plans to attend college for an MIS degree. Once hired, he volunteered to install third-party products because no one else at the company stepped up. "I remember after being on the job for a week, I was hooked," he recalls. "You will never be bored. I always thought of myself like Scotty on 'Star Trek'. I never wanted to be Captain Kirk."
By the end of that decade, he was hired for a systems programmer position at another firm where he was trained in operating system maintenance, a field he has worked in ever since. Over the years, he says the role hasn't changed much, but how the job is done has changed.
When installing z/OS in the 1980s, orders would be submitted to IBM and a pallet with 10 to 20 boxes would arrive a week or two later, 10 filled with tapes and 10 filled with manuals. Programmers would need to add those tapes to the library, add Resource Access Control Facility (RACF) definitions, and let operators know that they need to submit a bunch of jobs, among other tasks.
Gear says, "Now, after the product is ordered and built on a website, it is downloaded to the company system. The product target environment is built within a day or two. No tapes. No cabinets, filled with manuals. All documentation manuals are available online."
Another aspect of the job that has changed is how much of a building is taken up by stored data and hardware. "In the 1980s and 1990s, companies often had two central electronic complexes (CECs), with DASD and tapes, which filled up an entire wing of an office building, but all that is now stored in a rack the size of a couple refrigerators," he explains. At that time, to run a second logical partition (LPAR) on a CEC would have been difficult with all the required configuration changes. "Now, running many LPARS in a CEC is a ‘business as usual’ thing to do," says Gear.
In terms of workload performance, Gear says programmers had to hard code the system resources manager (SRM) parameters in the 1980s and 1990s. Once coded, systems programmers had to wait for someone to call in with a response time issue and then manually make SRM parameter changes to resolve it. "Now, we code the workload management goals and the workload manager takes care of the internal system changes (eg. dispatching priority, storage, etc.)," he says.
The job of systems programmer is never boring, requiring consistent vigilance and a desire to always learn. In mainframe, systems programmers are system stewards, ensuring the efficiency and strength of the system to perform as expected more than 99% of the time.
Check out past articles from our mainframe-related IT roles series: