Extract Jobs from Hercules local printer

It is so much easier to look at MVS Job output locally on Linux (taking into account the choices of tools and editors available) than on the TSO, 80 column 3270 terminal. If you specify MSGCLASS=A in your JCL your output gets sent to the Hercules local prt subdirectory. However Hercules just appends each output onto the end of the previous Job. So…I wrote a Python 3 program that reads the Hercules local prt00e.txt & prt00f.txt output on Linux which contains multiple jobs, back to back, and splits each job out to it’s own file. There are more sophisticated ways of doing this on MS-Windows but I was unaware of anything that does this on Linux. It opens the print file, read-only and can run while Hercules is active. There is maybe a likelihood that there could be problems (but not to the Hercules prt files) reading while Hercules is writing. So it’s probably best to run between Job execution.

Extracted files are named “JobNo-JobName (date&time).txt”

I had to add date & time because some Jobs with the same Job Name & Job Number appear multiple times. Such as the “MF1” job that runs on the TK4 system. It can be cancelled BTW! I usually do if I remember.

It’s fast too…
Read a 7+MB file with 80322 lines and wrote (extracted) 42 files (jobs) in less than a second.

parseJob Output

There’s a possibility that I might revisit some work I previously did creating the nostalgic greenbar look. I could combine it with or add a option to this program. It’s certainly not high on my to do list. See this post for an example or search for greenbar for other examples of work I did on this, which also show some bluebar. Still needs much work though!

Lost Ubuntu server password!

Needed to recover the admin password in Ubuntu server 18.04.3 LTS. I can’t remember a giant random password, and my password manager’s password file became corrupt. And I didn’t have correct server password on my phone’s password file. In the past you would use the recovery option in the Grub menu to drop to root where you could change your password. Does that work today? Of course not! Now when you select the option to drop to root it asks for…drum roll please…the password. Genius! After googling I found [https://www.howtogeek.com/howto/linux/reset-your-forgotten-ubuntu-password-in-2-minutes-or-less/]…(instruction weren’t an exact match to my grub but close enough where I could accomplish it) now you edit the grub boot procedure to replace the text ‘ro maybe ubiquity’ (the 2nd to the last line) with ‘rw init=/bin/bash’

then boot…then it will drop to root where you can change your password. Of course this meant I needed to disconect video card and keyboard cables from primary computer, move server near said cables on top of my primary computer and connect to server because it’s headless. Then reverse the procedure when finished. Joy!

More Assembler

Got simple Assembler program to run. It did have a error ‘IEW1161 WARNING – NO ENTRY POINT RECEIVED’ that needs fixing. Sounds bad but it was a warning. And it did read my 50 test disk records and wrote all 50 to printer. I need to re-familiarize myself with addressability. Not a terrible beginning. Syntactically, if not logically correct source, JCL that assembles and runs an Assembler program. In short…something I can work with.

Frustrated with Julia!

I had just fixed SQLite errors (requiring dataframes) when version 1.1, I believe, was released.
Now once again my Create customer program that is important to me is getting SQLite errors after the last update to version 1.2
And the error messages are so clear…
Warning: getindex(df::DataFrame, col_ind::ColumnIndex) is deprecated, use df[!, col_ind] instead.
│ caller = top-level scope at CreateCustomer.jl:174
└ @ Core ~/Mystuff/Julia/CreateCustomer/CreateCustomer.jl:174

line 174 looks like…
lmax=ex[1][1]

I’ve written many positive thoughts about Julia in this log, however not feeling very pro Julia right now, so I’m stepping away from the language for now! Never left Python anyway. I should have devoted the time I spent rewriting the Python program in Julia…on improving it! I just wrote a Python program a few days ago.

I changed my Julia YouTube video Julia for General Programming to private, because under the circumstances I don’t feel like touting it. It wasn’t exactly burning up the charts anyway, but had 261 views 7 thumbs up and 0 thumbs down.

As I said SQLite changes that cause problems twice in a version 1 release. I don’t even feel like trying to figure it out…it could just happen again after I fix that. I expect these kind of problems pre-version 1. Also what if I had written 20 SQLite programs? Gotta go back and fix all those after just a point release…I don’t think so. BTW I think the program still ran but I’m not watching Julia spew out these messages on my screen every time I run this just because I updated Julia! I guess that’s a lesson for when I upload programs to github…mention the version you used to write the code, Because there’s a good chance it won’t work, or will spew warning messages at you, by the time the next point release shows up…especially if it’s Julia code!

Also they just closed out a reproducible ‘segfault’ issue (#29213) I had opened on Sep 16, 2018. Which still segfault’s and is still reproducible. Not only that but Jeff Bezanson reduced my code and that’s what still segfault’s. If you don’t want to or can’t fix it…fine. But don’t close it and say it’s not reproducible! I guess that’s one way of trimming down the list of ‘open’ issues…just close them!

My spending time recently working on and learning MVS, probably didn’t help this situation. IBM’s newest OS is still largely compatable with the their 1960’s era OS. I look at z/OS (IBMs current OS) JCL and it looks very much like examples in my SYSTEM/360 JCL book that came out in 1970. The 360 references 1960 . The mainframe is dead…Right? Many fifty year old COBOL programs still work.

COBOL review and a little Assembler

I guess I don’t remember COBOL as well as I thought, because when the below COBOL move statement gives me an error…it’s time for a review.

00032 05 WS-AMOUNT1 PIC 999.99.
00033 05 WS-AMOUNT2 PIC 999.99.
00080 MOVE WS-AMOUNT1 TO WS-AMOUNT2.
80 IKF4052I-E DNM=1-254 (NE) MAY NOT BE TARGET FIELD FOR DNM=1-225 (NE) IN MOVE STATEMENT, AND IS DISCARDED.

Typed one of my Assembler programs from school. The beginning where you set up addressability (spell checker doesn’t like this spelling) and register save areas didn’t look familiar to me. Started with PGENT (program entry?) macro and produced errors. Probably a MVT macro, or perhaps school supplied. I looked at SYS2.JCLLIB(PRIMASM) and borrowed the program initialization start and end setup which did look somewhat familiar. I guess it was similar to how I did it at work in DOS/SP/VS/VSE etc. The addressing should be similar between DOS and MVS. A very simple I/O (from a beginning class) program to read disk and write to printer. Simple is what I need…very rusty at Assembler. Need to start with something small. Typing each instruction brought back some familiarity. This exercise also helped me setup the proper JCL for this. I probably won’t do a lot of Assembly at this stage but it will give me a good starting point for the future. Ended the night with a clean Assembly.

Also installed HLASM extension for VS code which didn’t seem to know proper column areas.

I Broke my MVS!

Spool file got full. because of a tiny little COBOL logic problem and screwed up my MVS…$HASP355 SPOOL VOLUMES ARE FULL. Just because I tried to write 500,000 records to the printer? Well excusseeeee meeeeeeee (: Actually partly because of a logic problem, also because I thought I was working with a much smaller file.

I’m not a MVS systems programmer. So I did what wouldn’t have been possible…back in the day, I simply unzipped a tk4- image I did a few days ago. It didn’t have my new 3350 DASD I recently added. So I copied that DASD from the borked system to the new unzipped system. And made the necessary config changes. However, if I typed in the prefix of the name of a dataset in TSO, it couldn’t find it, but it did if I typed in the VOLID. I don’t know if that was a MVS, TSO or some kind of catalog problem. I just deleted them and reran the local Linux JCL to recreate them. A real MVS system programmer could most likely fixed the problem.

Handy dandy Hercules submit script

Well doesn’t exactly submit, but makes it much easier to do so. Since I prefer to code locally, I wrote Python CLI program ‘toherc’ that takes a file name and depending on file extention (jcl, cob, asm, aws) creates the correct devinit command and automatically places it into the clipboard, ready to paste into the hercules console. So for example if I have a file named LISTVTOC.JCL in the /Mainframe/MVS/ directory I just type toherc LISTVTOC.JCL and it puts “devinit 00c /Mainframe/MVS/LISTVTOC.JCL” in the clipboard. If I have a tape file named CUST-TAPE.aws in the tape/ directory I just type toherc CUST-TAPE.aws and it puts “devinit 480 tapes/CUST-TAPE.aws” in the clipboard. Then you just go to the Hercules console and Paste then press Enter! Wa-la or properly…voilà.

Some may just put everything in Hercules ‘jcl’ sub directory, so this may seem like overkill, however that doesn’t fit my workflow. I like to split things into various random sub-directories, perhaps, COBOL, Assembler, JCL etc. within a mainframe folder and these may also be subdivided especially if you use git. It’s small and I originally just copied it to the directory where my files were but for the reasons I just mentioned, I installed it in to /usr/local/bin/toherc on my system, so it can be run anywhere.

Tip: if you press the up arrow on the Hercules console it will retrieve previous Hercules (Not MVS) commands (devinit is a Hercules command). Therefore if you fix a JCL or program error locally, in Linux and save, then you only need to retrieve the previous command and press Enter to rerun. Easy Peezy.