Exchange an MVS dataset with Windows

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

I have discussed in another article how you can convert data from one codepage to another. Also I have described a method to copy unix files to MVS datasets. 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: iconv -f 37 -t 1208 /your/unixdir/tst.txt > /your/unixdir/utf8-tst.txt Now you can transfer the file to Windows. Transfer the file in binary mode, otherwise another unwanted code page conversion will happen.

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…

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.