This article summarizes a method to copy an MVS dataset to Windows, while keeping records and converting from ebcdic to the utf8 codepage.
This job copies the MVS dataset to a UNIX files, indicating to keep record indicators with the Windows CR character (UNIX uses the CRLF typically as record / line separators). The dataset below ‘YOUR.TEST.PS’ should be a PS – physical sequential – dataset or a PDS(E) member.
//STEP1 EXEC PGM=BPXBATCH
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDIN DD DUMMY
//* Values in STDENV below are kept but have no meaning for this function
//STDENV DD *
JAVA_HOME=/usr/lpp/java/J8.0_64
PATH=/usr/lpp/mqm/web/bin:/bin:/usr/sbin
LIBPATH=/usr/lpp/mqm/java/lib
//STDPARM DD *
SH cp -v -F cr "//'YOUR.TEST.PS'" /your/unixdir/tst.txt
You can now convert the EBCDIC data to UTF-8 as follows:
When most people think of mainframes, they picture green characters on a black screen. The kind you see in old movies or The Matrix. It’s one of the most persistent myths in enterprise IT. Where does this image come from, and how much truth is there to it?
In this article 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 utilityExample of the ISPF 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.
What modern mainframe developers actually use
The green screen is the exception, not the rule. Modern mainframe development looks like this:
VS Code with z/OS extensions for editing and debugging
Git for source control
Jenkins or Azure DevOps for CI/CD pipelines
Slack and Jira for collaboration
Grafana and Prometheus for monitoring
This is the same toolset used on any modern platform. The mainframe has moved on—and so should the narrative.
The green screen myth: busted
The green screen narrative is one of the most persistent myths about mainframe technology. It keeps talented developers away and gives executives the wrong impression about what modern mainframe work actually looks like.
Today’s mainframe developers use VS Code, Git, Jenkins, and modern IDEs—the same tools used on any other platform. The 3270 terminal exists, just as the Windows Command Prompt does. But neither defines the modern experience of working with the platform.
Want to understand what modern mainframe technology really looks like, beyond the myths? My book Don’t Be Afraid of the Mainframe cuts through decades of misconceptions and gives IT leaders and professionals the honest introduction they never received.
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.
A common task in z/OS environments is moving data between the Unix file system and traditional MVS datasets. Here is how to do it using the OCOPY utility in a JCL batch job.
As mentioned in the previous post, another sample. This one copies a z/OS unix file to an MVS dataset. Also using OCOPY.
When working with z/OS, you often need to move data between the Unix file system (zFS) and traditional MVS datasets. This is a common task for system administrators and developers integrating Unix-based tools with mainframe applications.
The OCOPY utility is the standard tool for this. It handles character set conversion between ASCII (Unix) and EBCDIC (MVS) automatically when you specify TEXT and CONVERT(YES).
INUNIX: The Unix input file (ORDONLY = open for read only)
OUTMVS: The target MVS dataset
TEXT: Tells OCOPY this is text data (triggers EBCDIC conversion)
CONVERT(YES): Enables ASCII to EBCDIC conversion
PATHOPTS(USE): Uses the PATHOPTS specified on the DD statement
The reverse: copying MVS to Unix
To copy in the other direction (MVS dataset to Unix file), simply swap the IND and OUTDD parameters and adjust the DD statements accordingly. See: Copying MVS Datasets to Unix files
Working with both Unix and MVS on z/OS is a perfect example of how modern the mainframe platform really is. Want to understand the full picture of modern mainframe capabilities? My book Don’t Be Afraid of the Mainframe covers the Unix side of z/OS, integration patterns, and much more.
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.)
