In the previous section I explained that green screen interfaces still exist for administrative tasks. But even for these kinds of work there are modern tools with contemporary interfaces. z/OS itself and almost all middleware running on z/OS can be managed with web-based tools, Eclipse-based toolsfor z/OS, or nowadays more and more Visual Studio Code based tools for z/OS. Furthermore almost all administration tasks on z/OS can be invoked from external tools through REST APIs. More and more development and operations functionality will be made available only in this modern kind of tool sets.
The standard Eclipse-based tool for z/OS that you can download for free is called z/OS Explorer. This tool is a desktop client interfacing with z/OS. Many mainframe tools and middleware solutions provide plug-ins for this tool.
Figure – z/OS Explorer
Considering development tools, there are a number of modern options for the mainframe. IBM has developed an Eclipse-based development tool called IBM Developer for z/OS (IDz). The software company Compuware sells a set of tools for mainframe development called Topaz. There are also open source tools and plugins, like the IBM Z Open Editor for Visual Studio.
These modern tools provide a development experience for z/OS applications that is very similar to the experience you have when you develop applications for other platforms, like Java, PHP or Python. Support for developing and debugging mainframe languages such as COBOL and PL/I is supported in the tools, but also Java is supported. As importantly it provides plugins for interacting with middleware such as Db2, MQ, CICS and IMS.
IBM, CA, BMC and other vendors provide many modern tools for the administration of specific middleware in your organization.
Finally, a recent development is the open source project called Zowe. This project is a collaboration of a number of mainframe software vendors and aims to provide an open source software framework for development and operations teams to securely, manage, control, script and develop for z/OS like any other cloud platform.
In separate chapters I will discuss a little bit more on the modern application development and operations architecture tools for z/OS, and on modern monitoring architecture and tools.
The filewatch utility is not a well known utility, that can be very handy. I have used it especially when I needed process a unix file after it has been copied to a certain directory.
This is the documentation about the filewatch utility:
Th job below is submitted and then waiting and activated when there is a change in the input directory /yourdirectory/testfileloc
The job itself moves the files in the input directory to a processing directory, starts the next “watch” job and then the processing job for the files in the processing directory.
The setup is clearly to test the mechanism – and not necessarily a model for a production-like situation. In a production situation you might want to use TWS applications etc, but that is up to your application design of course.
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 with which you can fire off commands to the operating system to get things done on the computer.
Like the DOS command prompt and the Unix shell, this is a very powerful, but clumsy interface. To provide a more user-friendly interface IBM built the tool ISPF on top of TSO.
ISPF
I will no go into the abbreviations here. What you need to know is that ISPF is a standard part of z/OS. This tool gives the user, nowadays mostly system administrators, a very powerful interface to z/OS.
The editor in ISPF and the dataset list utility are probably the mostly used functions is ISPF. With the screen-oriented file editor is you can edit the z/OS datasets. The dataset list utility lets you find the datasets on your z/OS system.
ISPF – Data Set list utilityISPF Editor
ISPF also provides facilities to extend its features through a programming interface. Many tool vendors provide ISPF tools built on these interfaces as part of their tool installation.
SDSF – or equivalent
SDSF is one of the extensions to ISPF that IBM itself provides as a separate product. This product, or one of its equivalents from other vendors, is an essential tool for system administrators of z/OS installations. SDSF allows support staff to operate z/OS and manage the processes running on z/OS, look at output from processes (jobs) and inspect application and system logs. It is somewhat similar to the Task Manager in Windows.
I talk about SDSF here, which is an IBM tool, but there are tools with equivalent functions from other software vendors, such as IOF, SYSVIEW or (E)JES.
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.
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.
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.
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 see a cluster setup of CICS and Db2 in a sysplex. Both CICS and Db2 form one logical middleware instance.
A parallel sysplex cluster with Db2 and CICS
You can see the big benefit of parallel sysplex lies in it’s a generic facilties to build scalable and high available clusters of middleware solutions. You can achieve similar solutions on other operating systems, but every middleware component needs to supply its own clustering features to achieve such a scalable and highly available configuration. This often needs additional components and leads to more complex solutions.
What is unique about a parallel sysplex is that it is a clustering facility that is part of the operating system.
On other platforms you can build cluster of middleware tools as well, but these are always specific solution and technologies for that piece of middleware. The clustering facilities are part of the middleware. With parallel sysplex, clustering is solved in a central facility, in the operating system of z/OS.
An extension to Parallel Sysplex is Geographically Dispersed Parallel Sysplex, GDPS for short. GDPS provides an additional solution to assure your data remains available in case of failures. With GDPS you can make sure that even in the case of a severe hardware failure, or even a whole data centre outage, your data remains available in a secondary datacentre, with minimal to no disruption of the applications running on z/OS.
In a GDPS configuration, your data is mirrored between storage systems in the two data centres. One site has the primary storage system, the storage system in the other data centre receives a copy of all updates. If the primary storage system, or even data centre fails, GDPS automatically makes the secondary storage device the primary, usually without disrupting any running applications.
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.
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.)
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 part of z/OS. You get these options with z/OS.
z/OS Unix applications use the Unix flavour that z/OS provides, which is not Linux.
In z/OS Container Extensions you get the option to run applications with the Linux flavour of Unix, and run these in a containerized setup.
Linux for Z is an operating system that is in no way related to z/OS. Applications running on Linux for Z use the Linux flavour, and in an LPAR or Virtual Machine of its own.
I have tried to put all the Unix variants on z/OS in the picture below. You see z/OS Unix, as part of a z/OS operating systems, you see a z/OS container process running a Linux Docker container, and separate from z/OS there is an LPAR running Linux for Z.
The Unix flavours of z/OS and Linux for Z
What’s next
Now we have seen the basics of z/OS, we can turn to the more specialized and specific parts. In the next post I will discuss the unique clustering feature of z/OS, called parallel sysplex.