I've been playing around, writing programs, to exercise the mush between my ears. These are some of the programs that I've written. First, the file scan programs. But before that, some history.
For file scan, back in the '70s, I wrote a program for my boss who was searching for a string in a large tape file. His program was slow, so I wrote one that used the PARM field to specify one or more strings, and any record that contained one of those strings was written to the output file. A few years later, a guy named Joe Blank, who had worked at Fireman's Fund, and had written a very nice program to do scans came around, and the bank leased his program. He then hired Compuware to do marketing, and agreed that they'd name it FILEAID. Some years later, I believe that Compuware rewrote it themselves, and stopped selling Joe Blank's program. And, of course, they raised the price many times over. I think that The Bank no longer uses FILEAID. Apparently, IBM has something similar, although not having seen an MVS system for a couple decades, I really don't know. Be that as it may, I like the idea of writing a good scan program.
But where to do that? There are 2, somewhat related systems that allow testing IBM mainframe code on a PC. One is Hercules, that provides the virtual system, and the user needs to run an operating system. I suspect that it's often used at trade schools that teach programming. The other is Z390, which is what I use. It combines the virtual environment with it's own operating system, so all a user has to do is write a program and run it. The down side of that is that many functions are done differently in Z390, and other functions are not available at all. That said, the Z390 instruction set is reasonably close to an honest MVS system.
And then, of course, there's the EDITOR. I use SPFlite. SPFlite mimics ISPF pretty well. There was pretty much no learning curve at all. And George, who wrote it, seems a pretty nice guy. (The story he told was that he complained about the lack of a good editor after he retired. His wife said, "You're a programmer, write one." So he did.) Okay, back to file scan programs.
RACHAEL scans a file, looking for a string. There's an OUT file that contains those records. There's also a NOT file that contains all the other records. There is no SYSIN file of control records -- everything is specified in the PARM field.
GOFISH scans a file, looking for multiple strings. The strings, and associated DDNAMES are specified in the PARM field. There isn't a NOT file for records that were not selected. And there isn't a SYSIN file for control cards.
GETFILES is next in the list. I just finished testing it, fixing all my mistakes, and this week, I kind of like it. It scans a file, looking for multiple strings. Those strings can either be in a fixed location (eg record type) or can occur somewhere in the record. (GOFISH and RACHAEL do not look at a fixed location, they both just scan.) The PARM field can be used, but really, input is expected from the SYSIN file. The limitation in GETFILES is that the record-type requests must be in a specific location, and the strings to be scanned for must all be in the same location range. (That range could be 1-9999, or the entire record.) The benefit of using the same range, is that it runs fairly fast, with all the scanned strings being looked for in a single pass, using a TRT instruction to find the least frequently used character from each string for the scan. RACHAEL and GOFISH do the same, but GETFILES is a bit better.
Both EDITFILE, and IFANDOR do not yet work. (Will either ever? I don't know.) I've started several, and dropped them.) But they are intended to be close to Joe Blank's DUMPER program.
A limitation with all these programs is that Z390 does not have a PDS function, and I've never worked with VSAM, so they all, currently at least, only work with sequential files. I'd be more than happy to add the various access method functions, but I think I need access to a real IBM system.
On to other things.
QBR (or GETAT) I wrote to help with the Z390 TEST function. In IBM land, when working on a COBOL or assembler program, or other languages, there is a TEST function that allows you to step through a program, look at registers, look at memory, set BREAK points, etc. In MVS, you set break points by LABEL. In Z390, you set BREAK points by memory address. QBR reads the listing, and creates break points for the LABELs that are specified in the SYSIN file. A break point is set with an AT command. The output of QBR is a file of break points for specified labels, and another file that's a 'narrow' listing, with BREAK points or LIST commands for every instruction.
Today, when I'm testing, using Z390 I have 6 windows open.
- Z390 test console.
- Notepad file containing QBR created BREAK points
4 SPFlite windows, containing
- Source program
- assembly listing
- AT / LIST commands on narrow assembly listing, from QBR
- (often) SYSPRINT listing to see the report. (The Z390 window shows where I am in the PGM)
I had hoped to be able to feed multiple BREAK points into Z390 all at once, but that's unlikely to happen. That limits the usefulness of QBR a fair bit, but I still find it useful.
UTLPRINT - When I stared at the bank, computer input was cards. And the listing came back later, or maybe the next day. If you wanted to see a file, you had to print it, and look at the listing. UTLPRINT had a print-hex function, and a couple other benefits. One day, around here, I just needed a break.
UTLCOMPR - IEBCOMPR is the PITS. Someone at The Bank wrote UTLCOMPR to compare 2 files. Again, having too little to do, I wrote one too. ACTUALLY, the phone company had a really nice compare program that matched records Out Of Order. When there wasn't a match, the 2 records were saved in tables, and when there were more non-matches, the program went through those saved tables. That function would be handy for comparing different versions of source programs, looking for changes. I think I've started it once or twice, but not liked (or couldn't figure out) how it was progressing.
KEYCOMPR - compares files that have, and are sorted on, keys.
IFANDOR - another DUMPER style program that doesn't work (yet???)
There was a guy, trying to use SORT, to insert a new column in the middle of records of an existing file. (Why SORT? I've no clue.) At any rate, I wrote a couple programs to do that.
INSERTIT, ADDACOL, ADSTRING ADDFIELD are some attempts to do that.
The simplest open-exit that I've seen.
OPENX DC 0F'0',X'85',AL3(OPENX+4)
. CLI DCBRECFM-IHADCB(1),0 Q. BLANK DCB?
. BNE 0(14) NO, JUST RETURN.
. BAL 2,16(R15) LOAD A(DCB TO COPY FROM)
. DC A( a dcb ) AND COPY RECFM+LRECL.
. L 2,0(2)
. MVC DCBRECFM-IHADCB(1,1),DCBRECFM-IHADCB(2)
. MVC DCBLRECL-IHADCB(2,1),DCBLRECL-IHADCB(2)
. BR 14
I've posted some of these here, but google messes with the formatting something awful. If you're interested, email works. If you've a good idea where I might post 'em, kind of like google sites, that doesn't mess up the formatting, let me know.