opinion: What Old Skills Don't z/OS Systems Programmer Need to Know?

z/OS administrators are called 'systems programmers.' And this is no accident: in the old days, systems administrators had to be programmers working with the system. z/OS was configured by coding assembler macros and assembling them (systems generation). Every site coded its own assembler exits and routines to get z/OS to do what they wanted. And documentation wasn't great, so some hardy individuals looked at the source code (yes, the source code used to be supplied) to find out what was going on.

Today, z/OS administration is similar to other operating systems like UNIX. So, some of those skills that used to be needed are now no longer required for most z/OS systems programmers. Let's look at some of these skills.

Programming

Assembler used to be an essential skill for any systems programmer. Although it's handy today, most z/OS systems programmers will never use it. IBM and other software vendors have been slowly reducing the need for exits, providing parameters and other features that can be used instead. In most of the sites I see, exits are never touched, and just keep working.

Some sites will still have one veteran with assembler skills to maintain any legacy exits and programs. Others won't.

This also removes the need to understand internal z/OS macros and APIs that assembler programs and exits use. No need to understand what a 'GETMAIN' is, or what the ESTAE macro will do.

ISPF development also used to be a core skill as sites happily created their own ISPF panels. Today, few sites do this, and just work with what's there. So ISPF dialog development skills aren't often used.

CLIST used to be another key skill, used for ISPF development and other utilities. Today, REXX has replaced it.

Internals

Because few systems programmers will need assembler, it follows that today, they won't need to have as deep an understanding of the internal structure and functioning of z/OS. Many z/OS systems programmers will never look at control blocks or exits. Most will never need to understand what a TCB is, or know the difference between the ASCB and ASXB.

Even dump analysis is rarely used today. Most sites will have tools like IBM Fault Analyzer or BMC Compuware AbendAid to help format and understand dumps. z/OS messages are far better, and often provide all the information needed to determine why a program abended. Few will ever start IPCS to analyse dumps.

z/OS has become a lot more stable, so many tools are no longer required, nor the information needed to use them. For example, in the past it was sometimes necessary to zap the VTOC of a DASD device. Today, most systems programmers won't even know what zap is, or much about the VTOC.

The reality is that IBM and other vendors have been making it harder to understand the internal workings. CICS control blocks are no longer documented. IBM no longer offers courses to understand the internal workings of z/OS, and existing documentation is vague.

Hardware and IPLs

As a young systems programmer, I would regularly go into the machine room and work on the mainframe hardware console: looking at screens, performing standalone dumps, and even IPLing a system (sometimes over the top of a sick MVS). Today, most systems programmers will never have seen an HMC, or how operators IPL. Few will know how to do a standalone dump (in many cases, this is done automatically from the AUTOIPL policy), far less analyse one. Even knowing the commands to start and stop subsystems is less important as automation products take charge.

Similarly, few systems programmers will know there's such a thing as standalone ICKDSF or DFSMSdss, far less be able to use them. Most sites have replication, and rely on this for system level backup and recovery. Applications and DBAs will perform dataset/database level backups, maybe using HSM features as well.

More to Learn

If you've made it to this part of the article, you're probably thinking that z/OS systems programming has become easier over the years, as many legacy skills are no longer needed. But this isn't true: there are new skills that z/OS systems programmers need to know.

For example, z/OS systems programmers are also UNIX administrators, as z/OS UNIX has become essential. They need to understand TCP/IP and the Network File Server (NFS), and have a basic understanding of Java.

Websphere Application Server (WASz) has become a core component of z/OS as it is used to create web portals into z/OS systems. Other base features to be learned include CIM, Apache HTTP server, and Tivoli Directory Server.

Encryption has become essential for z/OS system, so a knowledge of ICSF, OpenSSH, and other encryption features is required.

z/OSMF is designed to make z/OS administration easier, but it is another subsystem that must be installed and maintained. Other tools like the open source ZOWE also add to the knowledge needed: they still need to be installed, configured and maintained.

More Breadth, Less Depth

Today's z/OS systems programmer need to know less about more. A deep understanding of z/OS is no longer required, but an understanding of a lot more subsystems and technologies is. So, although the job of a z/OS systems programmer is changing, it isn't becoming easier.

David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.