Computer Log

Yesterday…completing 2 basic MVS COBOL programs, was very satisfying. I’ve done a fair amount of DOS COBOL, admittedly many years ago, and other than the SELECT statement’s in the ENVIRONMENT DIVISION it’s very similar. After I had 95% convinced myself that IEBGENER was the correct program to load my virtual tape to a MVS DASD dataset, then I only had to concentrate on the JCL and operator messages and not the program. If I had started trying to use MVS COBOL to go tape to disk, if something didn’t work…I would have continuously questioned myself…is the JCL wrong or is the program wrong…or both? Once I was successful with IEBGENER, I basically knew I had the correct JCL and only had to worry about getting COBOL to work with the JCL. And bonus, by using IEBGENER to go tape to disk, I had successfully created 2 different (tape and disk) valid JCL DD definitions. Then I was free to concentrate on the COBOL program!

Wrote my 1st MVS Cobol (see comment about this) below program that successfully read a dasd file and wrote a new dasd file. Then wrote my 2nd MVS Cobol program that successfully read a virtual tape (AWSTAPE) file and wrote a new dasd file.

It should be obvious now, although I admit it wasn’t completely at first, that an AWSTAPE appears to MVS as a regular IBM tape, that doesn’t require some special AWSTAPE utility on MVS to process. I successfully used the IBM utility IEBGENER and a COBOL program to read the tape. Your JCL obviously needs a proper tape DD card just like any normal tape processing does.

I was a little worried that the MVS compiler would have problems with newer DASD (such as anything in the 33xx series) like the DOS compiler did…but it handled 3390’s just fine! I don’t know if that’s because the MVS compiler was patched or simply because it’s a superior compiler? But I do know that the device model isn’t specified in the MVS SELECT/ASSIGN statement as it is in DOS COBOL.

For example:
DOS: SELECT IN-FILE ASSIGN TO SYS010-DA-3380-A-INFILE
MVS: SELECT OUT-FILE ASSIGN TO DA-S-INFILE

Used IEBGENER to load 50,000, 164 byte customer records records to disk. Once I got it working…it was very fast. I basically thought it would just require a new larger (more records) tape. However this brought new problems. Error messages stating that I either hadn’t allocated enough space or there wasn’t enough space available to copy the data to disk.

This IEBGENER loaded data includes a ending character (linux line feed) that isn’t used. Back it the day we would never have wasted a byte like that…50,000 customer records equals 50,000 wasted bytes! You can store an additional 304 customer records in that wasted space. DASD was expensive back then! That’s what caused the Y2K problem…programmers saving 2 bytes per date by only storing ’65’ for ‘the year ‘1965’ and making the assumption of a ’19’ year prefix!

MVS COBOL

Technically it is isn’t MVS COBOL. As it isn’t freely available. In reality it’s a pretty old (but still useful) COBOL version that is freely available. It is IBM COBOL though!

I’ve been trying for a few days, to find a good way to get real looking data records into a MVS dataset from a local Linux file. It’s been fairly tedious and unproductive. So this success was a big morale boost to me. For me this was a major hurdle.

Finally successfully loaded 1000, 141 byte customer records onto Hercules/MVS. As I previously said (see 10/06) I used Jay Moseley’s “maketape” program to create an AWSTAPE. I then used IEBGENER to load that virtual tape to a MVS dataset. I’ve been having a few days of JCL and MVS operator console problems. So I’ve been reading about JCL and realized the VOLSER was always described as being 6 characters, I had assumed up to 6 max. So I finally changed the VOL1 label from ‘VOL1’ to ‘VOL001’ and it worked! I looked up console messages but don’t remember seeing anything specifically about that.

You can see the 142 byte customer record below on Linux. And below that you can see the same records in a TSO 3270 screen in MVS. The 3270 screen needed to be shifted to see all 142 bytes. Click the images to enlarge.

I may try a much larger file, maybe a million records if I get brave and have the DASD space.

Sure enough if I add USER=userid,PASSWORD=password to my job card submitted locally from Linux, I don’t get the RAKF (tk4’s version of RACF) error.

Such a big task learning MVS. But fun…so far. I don’t mind banging my head against the wall a little bit, but I need some success along the way. As I said before, I’d prefer writing JCL and programs locally on Linux. And I have had some success submitting some jobs there. However some of the JCL I’m submitting from Linux is failing with RAKF (RACF) errors. I suspect it has something to do with permissions to create datasets from an unknown user. I suspect jobs submitted from within TK4 are supplying valid user credentials. At any rate retyping my tape processing JCL within the TK4 environment allowed it to run without those errors. Luckily this JCL is short. Perhaps there is a simple JCL parameter to supply that information. Maybe I’ll figure it out later. As they say…Rome wasn’t built in a day!

So now I must figure out what program I use to load my AWSTAPE into an MVS dataset. IEBCOPY or IEBGENER? Or some other program? How do I define the DD card for the I/O?

I think I have created valid AWSTAPE of 1001, 141 byte customer records to test with. A small file in my fake business.

So far I’m not successfully accessing the tape drives. I get error or operator messages I’m currently unfamiliar with. Then my job is stuck waiting. And I can’t even figure out how to cancel it. Then MVS won’t shut down. So I risk data corruption just quitting. However with my MVS skills severely lacking, my current data recovery plan is just occasionally zip the whole TK4 directory up every now and then. Then restore from that in the event of a catastrophe.

Well an important step has been conquered…submitting jobs [JCL] to MVS 3.8 from my local Linux environment. The next thing important to me, is getting data, perhaps a lot of data into the mainframe. Everyone is different so this might not be as important to someone else. However to me I need to feel that I can run real useful jobs on the mainframe! For me it’s not enough to run a MVS job on 50 records. That wouldn’t be primarily what a MVS mainframe would be used for in its heyday. I myself could manually process 50 records with a calculator. My smallish company, who had millions of customer records couldn’t even afford, or at least justify the expense of MVS and the hardware to run it. I need to know my MVS environment can emulate an actual business. To that end, I need to be able to be able to transfer a lot of data to the mainframe. I’m talking a million records or more. I want to put Hercules/MVS through it’s paces. Obviously the data isn’t actual customers because that would mean I have access to real peoples personal information, and I don’t. However I can generate real looking random data. Currently I can generate a million real looking 164 byte records in about 15 minutes. Another reason is I want to do this is to be able to compare the cool gnuCobol native Linux compiler to a real IBM mainframe COBOL. I assume gnuCOBOL will be faster because it’s not running under emulation. Still, I like doing those comparisons. Also I like seeing what a free COBOL compiler can do against a compiler who’s monthly cost to IBM customers was probably hundred’s or thousand’s of dollars. And that’s just for the compiler, which can’t run without the OS. And for sure the monthly costs for all this software is many thousands of dollars!

Currently this is where I am in this process. It seems to me perhaps a virtual tape (AWSTAPE) might be the best way to transfer large amounts of records to the mainframe. Some years ago Jay Moseley wrote a Basic program to do this. He placed it in the public domain. Concerning the Basic program, he stated that he used “the final release of Microsoft’s Professional Development System which is way beyond the dinky QBASIC that is stuck on all the DOS/Windows systems now” . He further stated “I spent another week writing C equivalents of the original program and getting that to the point it would produce the AWSTAPE image files over under Linux. Even though the compiled BASIC versions ran under DOSEMU, I wanted to have a native version.”

Being familiar with Basic, I took his program and made a few small changes to be able to compile in the very nice IMHO…FreeBasic. The resulting native Linux executable is only 72.6kb. And is fast, IMHO.

It wrote (created the AWSTAPE) 50,000, 164 byte recs in ~10 seconds
It wrote 1 million, 165 byte recs in ~12 seconds

Not too shabby for a Basic program that’s converting every record from ASCII to EBCDIC.

I also tried QB64, which I used for his other tapedump.bas Basic program, because at the time I couldn’t find a way to do the DIR$ function, in FreeBasic. I later found a way to perform this function in FreeBasic. The size of this QB64 executable in Linux was 1.9MB, but only 77.9K in FreeBasic…a big difference! Also the QB64 executable pops open a tacky, non-native looking MS-DOS style Window.

Having said all that. You should use the C version of Jay’s programs. Which are much faster. And the executables provided work out-of-the-box on my system.

Getting there…the next step is loading the AWSTAPE into a MVS dataset, on Hercules!

At the beginning, especially for a new MVS person, I find it easier to write my programs & JCL locally in Linux using the superior full screen editors (almost any!) available. Personally, I like to use the VS Code IDE. So I needed a way to submit these jobs to MVS, found 2 methods, #1 works everytime, #2 worked once…for me!

Job submission method #1 [1 step, specify file name on devinit]

After entering the following, the job will be submitted to MVS!
HHC01603I devinit 000C path/SORT.JCL [type on hercules console! Looks in tk4 base dir if no path givin]

Job submission method #2 [2 steps, uses Netcat in Linux, don’t specify file name on devinit]

Type locally in Linux!
bill@billb-MS-7B79 …/Hercules/MVS/TK4/tk4-_v1.00_current $ nc localhost 3505 < SORT.JCL
bill@billb-MS-7B79 …/Hercules/MVS/TK4/tk4-_v1.00_current $

HHC01603I devinit 00c [type on hercules console!]

The task of getting files (especially large data) from Linux to MVS is very important to me. FTP, seemed like it would be a obvious option. YMMV but for me it’s too unreliable! Was easy to retrieve a member using GET in FTP, however using PUT in FTP…failed!

Thinking it could be a permission problem, I created my own PDS. And then FTP allowed me to copy a local file to it.
226 Transfer complete
700 bytes sent in 0.00 secs (26.7029 MB/s) Success!

Problem solved…right? Wrong! I tried to copy something else and failed. Then I deleted the very thing (on MVS) above I had successfully copied and I failed trying to copy it back, again! WTH? The error message is cryptic “550 SORT.jcl: Not opened 13” and doesn’t help.

Also the MVS shutdown didn’t complete…It appears FTP needed to be stopped 1st “/stop ftpd”.

Having fun diving back into MVS. Even though my professional career was with DOS/SP/VSE/ESA bla bla bla. Since I already did the sys programmer thing, there…already scratched that itch, frankly more interested in just using/programming on a IBM mainframe, than administrating/fixing/patching. And the tk4- emulator seems like very a nice/useable MVS 3.8j OS, complete with TSO and a ISPF “like” environment to work in. The DOS emulator environment seems like a lot of work to make really useful/productive. Also I’ve forgotton so much DOS/SP/VSE/ESA that it’s a lot of effort/work to “play” in. So if I’m going to relearn mainframes I might as well concentrate on MVS. Which, by the way, bonus, I’ve been told is still very similar to z/OS, the current IBM flagship OS. Also all my mainframe schooling was in MVT which is the father of MVS. So the JCL is similar. So, I’m sure some of it is buried in the deep recesses of my mind. MVS and now z/OS, is, and has always been the king of IBM mainframe OSs. COBOL programming is largely the same, ASSEMBLER other than the Macros is also largly the same using the S/370 instruction set, with advances.

Ok, so I with the help of a Moshix Youtube video, successfully compiled/executed/viewed my 1st COBOL program. Check out his channel for other helpful Mainframe videos. Pretty much followed his video…except for one thing. I didn’t see my COBOL JOB output on he OUTLIST screen. Then I noticed “(USE ST * FOR ALL JOBS)” at the bottom of the screen. Sure enough I typed that in at the COMMAND prompt…and there it was! Very satisfying to see this. Although I can’t claim to fully understand the whole MVS process right now, it is very reminiscent of what I did on MVT at school in the late 1970s…except more advanced. What I wouldn’t give, back then to code on a full screen editor and submit and view my job right where I sat! However, as old as MVT is, many utilities, such as IEBCOPY IEFBR14, are STILL the same!

Another reason to go MVS rather than DOS…as if it wasn’t enough getting DOS/VS running in VM…which I did and was able to use VM for my interactive environment including submitting JCL to DOS…I couldn’t even successfully compile a COBOL program out of the box because of a DASD issue. Really? There is a solution, however why wasn’t DOS/VS packaged up in a way that common tasks that a programmer would do back then…like say COMPILING A COBOL PROGRAM? No thanks…it’s quite enough to learn how to use a WORKING IBM mainframe OS, without starting off fixing and patching things. Looking at the tk4- config file…DASD devices 3330 and above, such as 3350, 3375, 3380 and 3390 are already recognized by the OS. If you want to learn an IBM mainframe OS then you might as well start with IBMs flagship OS, because DOS/VS, as supplied, is the biggest advertisement for learning MVS 3.8j (as implemented by tk4-). No wonder the MVS guys made the big bucks. The Hercules/tk4- people should be very proud of the work they’ve done!