The interface to z/OS and the green screen myth

  • Post category:DBAOTM
  • Reading time:4 mins read

In the previous posts I have shown you many modern technologies available on z/OS. But still when you think of the mainframe, you think of black screen with green characters, which looks cool in the Matrix, but not so much in real life. Where does this green screen imago come from? In this section I will talk a little bit about the origins of the green screens in mainframe technology. I will also show you that these green screens have become as uncommon to use as a terminal in Unix or command prompt in Windows. Green screens are for administrators and programmers, not end-users The green screens on the mainframe are user-interfaces. In the early days programmers created their programs on paper, behind their desks. They then entered the programs on punch cards or paper tape. That were the media that were then fed into the computers, using a special reader device. Later, in the 1960s, computers with terminal interfaces were build. With the terminals, users could enter programs and data online. This is the period that the green screens originate from. Each computer type had its own terminal technology. Mainframes had technology indicated with a number: the 3270 terminal. These terminals originally worked with green letters on a black background, and could hold as much as 32 lines of 80 characters (or so). We still refer to these 3270 terminals as green screen. Modern mainframe applications do not use these terminal interfaces anymore. Applications on the mainframe most often do not even have a user-interface anymore. They only expose services, or APIs, exposed to mid-tier or front-end applications. (See modern mainframe application architecture section.) Today therefore, the need for these green screens is limited. Only special system administration tools and application programming tools still have a low level interface. And even these are being replaced by tools with more modern interface. System administrators on Windows use the "DOS" command prompt and Unix techies use the Terminal sessions. Similarly, for mainframe techies there is the “green-screen” 3270 terminal.  Actually, the Unix Terminal and Windows Command Prompt are quite rudimentary, compared to the 3270 interface to z/OS. Green screen application? Technical debt The days where you had green screen applications are long gone. If you still have them, you should get rid of them. Most well-architected green-screen applications can be turned into service-oriented applications. The front-end can then be replaced by a modern front-end application. You may find yourself in the situation where you need to integrate with green-screen applications that have not been so well-designed. I will talk a little bit about that in a separate section Integration with the rest of the world. In section Application architecture for modern mainframe applications, I describe a reference architecture for modern mainframe applications. Now, I will describe what tools typically still needs 3270 screens. TSO What is the functionality of the command prompt for Windows and the Shell function is for Unix, is the TSO tool for z/OS: a command line interface…

Parallel sysplex

One of the most distinguishing features of the z/OS operating system is the way you can cluster z/OS systems in a Parallel Sysplex. Parallel Sysplex, or Sysplex in short, is a feature of z/OS that was built in the 90s that enables extreme scalability and availability. In the previous post we highlighted the z/OS Unix part. Here we will dive into the z/OS Parallel Syplex. A cluster of z/OS instances With Parallel Sysplex you can configure a cluster of z/OS operating system instances. In such a sysplex you can combine the computing power of multiple of z/OS instances on multiple mainframe boxes into a single logical z/OS server. When you run your application on a sysplex, it actually runs on all the instances of the sysplex. If you need more processing power for your applications in a sysplex, you can add CPUs to the instances, but you can also add a new z/OS system to the sysplex. This makes a z/OS infrastructure is extremely scalable. Also, a sysplex isolates your applications from failures of software and hardware components. If a system or component in a Parallel Sysplex fails, the software will signal this. The failed part will be isolated while your application continues processing on the surviving instances in the sysplex. Special sysplex components: the Coupling Facility For a parallel sysplex configuration, a special piece of software is used: a Coupling Facility. This Coupling Facility functions as shared memory and communication vehicle to all the z/OS members forming a sysplex. The z/OS operating system and the middleware can share data in the Coupling Facility. The type of data that is shared are the things that members of a cluster should know about each other since they are action on the same data: status information, lock information about resources that are accessed concurrently by the members, and caching of shared data from databases. A Coupling Facility runs in a dedicated special operating system, in an LPAR of its own, to which even system administrators do not need access. In that sense it is a sort appliance. A sysplex with Coupling Facilities is depicted below. There are multiple Coupling Facilities to avoid a single point of failure. The members in sysplex connect to the Coupling Facilities. I have not included all the required connections in this picture, as that would become a cluttered view. A parallel sysplex Middleware exploits the sysplex functions Middleware components can make use of the sysplex features provided by z/OS, to create clusters of middleware software. Db2 can be clustered into so-called Datasharing Group. In a Datasharing Group you can create a database that can process queries on multiple Db2 for z/OS instances on multiple z/OS systems. Similarly WebSphere MQ can be configured in a Queue Sharing Group, CICS in a CICSPlex, IMS in an IMSPlex and other software like WebSphere Application Server, IDMS, Adabas and other middleware use parallel sysplex functions to build highly available and scalable clusters. This concept is illustrated in Figure 15. Here you…

Code page conversion of a file in a batch job

  • Post category:JCLUtilities
  • Reading time:1 min read

In this post a sample of how to perform a code page conversion of z/OS Unix files in a batch job. The different iconv utility lines show invocation for different code pages. //*                                      //STEP1    EXEC PGM=BPXBATCH    //STDERR   DD SYSOUT=*   //STDPARM  DD   *              SH  iconv -f UTF-8 -t IBM-1140 < inutf8 > outebc  /*                                                      //                SH  iconv -f IBM-1140 -t IBM-1252 < inebc > out1252  //   SH  iconv -f IBM-1252 -t IBM-1140 < in1252 > out1140  //     SH  iconv -f IBM-1140 -t UTF-8 < inebc > oututf8  //                      

Copying Unix files to MVS Datasets

  • Post category:JCLUtilities
  • Reading time:1 min read

As mentioned in the previous post, another sample. This one copies a z/OS unix file to an MVS dataset. Also using OCOPY. //STEP5 EXEC PGM=IKJEFT01 //INUNIX DD PATH='/mydir/infile.txt',PATHOPTS=(ORDONLY) //OUTMVS DD DSN='TEST.MVS.OUTDS',DISP=SHR //* //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * //SYSTSIN DD * OCOPY IND(INUNIX) OUTDD(OUTMVS) TEXT CONVERT(YES) PATHOPTS(USE) /*

Copying MVS Datasets to Unix files

  • Post category:JCLUtilities
  • Reading time:1 min read

Recently I had to get some people started with a few utilities. I thought to share this here. They will be in the next few posts for searchability reasons. There are more ways to Rome, as we say here, so please feel free share you variants in a comment. (I unfortunately need manually curate comments to filter out the spam which is even with this small site overwhelming.) //STEP1 EXEC PGM=IKJEFT01 //INMVS DD DSN=TEST.TRADMVS.DATA, // DISP=SHR //OUTFILE DD FILEDATA=TEXT, // PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHMODE=SIRWXU, // PATH='/mydir/myunixfile.txt’ //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=*//SYSTSIN DD * OCOPY IND(INMVS) OUTDD(OUTFILE) //* Here's a link to the IBM documentation on OCOPY.

Running a MVS or TSO Rexx program from the z/OS Unix environment

  • Post category:Rexx
  • Reading time:1 min read

You probably know that you can use Rexx programs in z/OS Unix. What you may not know is that you can also run a TSO or MVS Rexx program from the z/OS Unix environment. There is a unix command called tso for this. It works as simple as this: tso –t “exec ‘YOUR.MVS.REXXPDS(TESTREXX)’ EXEC” will execute your TESTREXX program. You may want or need to allocate TSO datasets or other datasets in order to execute the Rexx. You can simply allocate these through the export command. export ddname=YOUR.MVS.DATASET You can add these exports to you shell script, or add them to your .profile.

The Unix parts of z/OS

In the previous DBAOTM post I have introduced you to the z/OS operating system, the flagship operating system for the mainframe. In this post I will introduce you into the Unix side that z/OS has been equipped with over the past two decades. Since the 1990s IBM has added Unix functionality to z/OS. The first extension was z/OS Unix System Services – z/OS Unix in short - and recently we IBM have added z/OS Container Extensions. z/OS Unix The Unix part of z/OS is a runtime environment that is an integral part of the z/OS operating system. z/OS Unix is fully Unix (Posix) compliant. z/OS Unix provides an interactive command interface that is called a shell in Unix terminology. IBM has developed this part in the 1990s to make it easier to port applications from other platforms to z/OS. Many off-the-self and open source middleware and application packages that are available on z/OS make use of z/OS Unix. Examples are IBM’s own WebSphere Application Server and IBM Integration Bus, the banking product BASE24-eps from ACI, and open source tools like PHP and Git. z/OS Unix has regular files the same as other Unix systems. In the z/OS Unix shell you can use normal Unix commands like ls, cd, more and many more of the standard Unix commands. You can set up a telnet or SSH session with z/OS Unix and do many more things you can also do with other Unix environments. z/OS Container Extensions A very recent development on z/OS (it came with z/OS 2.4, end 2019) is the possibility to run Linux Docker Containers on z/OS. Docker containers are a hardware independent and lightweight manner to run many applications in a virtualized configuration. The Docker technology has been available on x86 platforms for a long time. With Docker containers you get a virtualization solution that does not need a complete virtual machine with an operating system running in it for every application. Instead your application is running in a small container that provides only a limited set of virtualization facilities. Just the things that the application needs. You can run many Docker containers – so applications – on a single real operating system image. The interesting thing is that in a conceptual way Docker is a quite like z/OS as we have seen it in section Address Spaces are processes. On a z/OS operating system you can run many applications in “Address Spaces”. With Docker you run many container processes on a single real operating system image. I will talk a bit more about Docker in section Linux in z/OS Container Extensions. z/OS Address Spaces versus Docker containers All Unix variants A small elaboration, as you may already get confused with the Unix on the mainframe. I mentioned Linux for the mainframe, now I talk about z/OS Unix and Linux in Containers. It is important to understand the difference between z/OS Unix, z/OS Container Extensions and Linux for Z. z/OS Unix and z/OS Container Extensions are an integral…

z/OS Container Extensions Live demo

On 2 December, in a session organized by the Dutch GSE, the IBM User Group, specialists from the IBM Garage in Montpellier performed a presentation and live demonstration of running Linux containers in a z/OS Container Extension (zCX). After the session there was a short discussion about use cases for z/OS Container Extensions, introduced by a view on this topic by Rabobank. You can find the presentation in the GSE Google Drive: Link to the presentationAnd we've also recorded the whole event, so you can watch it on the GSE NL YouTube channel: https://www.youtube.com/watch?v=sY_utVaq9Uk&feature=youtu.be

DBAOTM – z/OS – the mainframe flagship operating system

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…

DBAOTM Operating systems for the big mainframe box

In the previous posts I have given an overview of the most important mainframe hardware components. In this article I will summarize what operating systems you can run on this hardware. But first… This post appears as part of a number of articles in the category “Don’t Be Afraid Of The Mainframe”. What is actually a mainframe A little late to answer this question, but I thought it was good to address this here. A mainframe is a large computer that is designed to run many different computing tasks at the same time. A mainframe stems from the time where hardware was expensive, and a single central solution for computing was the only way to economically run computing tasks. A lot of characteristics of that design point are still prevalent today. Hence it is good to understand this background. z/OS and Linux, and then some… A number of operating systems can run on the mainframe. I will give a short description here of the operating systems you can run on a mainframe. For the rest of the series of articles I will focus on the two most important ones today. z/OS is the most important mainframe operating system, but also the most different from today’s mainstream operating systems. I will discuss z/OS most extensively.  Linux for the mainframe is the second most important operating system and has gained popularity over the past decade. I will discuss Linux for the mainframe in a separate chapter Linux for the mainframe. z/OS IBM often calls z/OS their flagship mainframe operating system. The roots of z/OS date back to 1964, when the operating system OS/360 was designed for the System/360 computer, the predecessor of IBM’s modern mainframe computers. In the early 70s the successor of the OS/360 operating system was developed, and named MVS (it stands for Multiple Virtual Storage, but you can forget that immediately). MVS has evolved further into OS/390 and now it is called z/OS. The name changes may suggest fundamental different systems, but these are in fact only marketing-driven name changes for MVS and the technology base is still the same, although it has very significantly evolved. z/VM, the mother of all hypervisors z/VM, or VM (VM stands for Virtual Machine) as it was originally named, used to be a full-fledged operating system that was design to run business applications. The operating system included a unique technology that allowed users to virtualize the mainframe hardware and split it up into small virtual machines. Nowadays we have VMWare, KVM, Xen, Hyper-V and others that do the same for x86 and other platforms. But the technology in VM was developed in the 1960s. It was far ahead of it’s time. z/VM can be considered the mother of all hypervisors. z/VM is nowadays it is only still used as a hypervisor for the mainframe, and is no longer as an operating system for business applications. z/VSE The z/VSE operating system is the small brother of z/OS. It was developed in parallel to MVS,…