In the previous DBAOTM post I have described the operating systems available for the IBM mainframe and seen z/OS is the flagship in this category. In this post I will introduce you into the z/OS operating system concepts and terminology. The goal of this piece is to give you a good idea what is special about z/OS are and how the peculiarities relate to more commonly known concepts in Unix and Windows operating systems. z/OS: MVS and Unix combined I will describe the z/OS operating system into two parts, and discuss these separately. The traditional part is MVS and this part deviates most from what we know from Windows and Unix. The second part is z/OS Unix, an extension that can run Unix applications, very much similar to other Unix flavours. Next in my discussion, in upcoming posts about z/OS, I will talk about the unique clustering facility that z/OS brings, called parallel sysplex. Finally I will cover the green screens that the mainframe is often associated with, and discuss where this is still used. I will discuss modern tools and IDE’s for z/OS that come with modern user interfaces, replacing the old green-screen based tools. The MVS part of z/OS The MVS side of z/OS is the traditional mainframe side. This is the part that has its roots in the 1960s. MVS and its predecessors were built in the era in which batch processing with punch cards was the basic way of interacting with the mainframe. In MVS we find the features that today look a bit awkward. Basic operation of the MVS part with batch and JCL First let’s have a look at he basic operation of a batch process in z/OS. The batch process is core to the MVS part of z/OS. In essence, today it still works in the same way as it was when designed in the 1960. To run a program on z/OS you need to have a means to tell it what to do. You do this by creating a script, which is usually quite small. The language for this script is called JCL – Job Control Language. With the JCL script you tell the computer which program to run, and for that, what the input is for that program and where the output must be written to. This looks like a piece of code like this: //RUNPROG  EXEC PGM=PROGRAM1 //INPUT    DD DISP=SHR,DSN=MY.INPUT.DATA //OUTPUT   DD DISP=NEW,MY.OUTPUT.DATA This code looks awful of course, despite its simplicity. This is because the language was designed for punch cards. Punch cards can carry 80 characters per line, and every line also needed some special positions to control the operation of the punch card reader. Also, to make things as simple as possible for the punch card reader, everything is in uppercase. All in all, JCL is probably easily readable for a punchcard reader device, but from an aesthetical and ergonomic perspective it is horrendous. Anyway, with the above snippet of JCL you tell the computer to run…