The mainframe (Unisys TIP) transaction environment I worked in at NWA had only two ways for F66 programs to generate trace output -- you could stick a CALL DUMPER statement in to dump 1-to-n words of a buffer in octal, or you could stick a CALL DMPFLD statement in to dump 1-to-n words of a buffer in FIELDATA text. There was no CALL PRTADP equivalent (for those familiar with the Unisys USAS environment).
The end result was single 132-column print file containing a bunch of blocks of octal or FIELDATA information (each with at most a 6-character label) sitting in a print file.
Both dumping methods had serious disadvantages. Reading raw octal isn't fun, and neither format would give you relative word offsets (just raw memory addresses) so on long dumps it was hard to figure out where you were in a given buffer without doing a certain amount of math and counting on a 132-column printout, and in general it could be a lot better. It was also hard to read on an 80-column terminal (some viewers would wrap it, others would simply truncate the stuff beyond column 80). So I decided to write a dumper decoder to make things a lot more readable.
One of the nice things about the TIP online transaction environment is the fact that you can write batch programs which aren't really online transactions, but which can connect to TIP anyway and use TIP services.
We had a fairly large library of utility subroutines out there that could decode a word of data in various ways. We had specialized formats for storing a binary date+time (ACCMIN), storing a binary flight+date, and various other special formats, and these routines would decode a word of otherwise obfuscated information and make it nice and easy to read.
I wanted to be able to display those suckers in human-readable decoded format underneath the original octal words if I could detect the presence of a specialized data field, and I also wanted to frame the FIELDATA output from PRTADP statements in such a way that it would be obvious which words you were looking at in the trace.
I also wanted to write a nice front-end for the thing which detected various options on the command line and presented the information in a nice fullscreen viewer on the mainframe.
For this project, I created two parts:
(1) a FIELDATA FORTRAN V batch TIP program which could read the raw trace file containing the trace information to be decoded, which could connect to TIP, which could tap into the nice utility library, and which could generate a nice formatted report to a file.
(2) a CALL macro front-end which could be called from a command prompt, solicit input from the user, interpret options, and effectively drive the above F66 program, then read the resulting output and present it to the user in a nice fullscreen viewer so they could page and/or search through it however they wanted.
The problems:
(1) FORTRAN V programs could only read/write 6-bit FIELDATA. I also didn't know how to create a FORTRAN program that I could call directly from the command line. Oops!
(2) CALL macros were easy to write and were made to be run from the command line, but they could only write 9-bit ASCII files (though they could *read* both ASCII and FIELDATA).
(3) There was no way to directly link the two together (CALL macros are self-contained interpreted macros, and they don't have any way to directly call a program which is written in another language, or even residing in another CALL macro source file!).
The ugly solution: I had the CALL macro write an ASCII COMMAND file, then kick off a breakpointed runstream (whose execution was hidden from the user) which called the ED line editor to convert the command file to FIELDATA so the FORTRAN program could read it. That's roughly the same as piping it to the line editor, I guess, but a lot uglier.:-) Then, it kicked off a second runstream to run the FORTRAN decoding program and sat around waiting for the FORTRAN program to terminate. Again, the execution of the FORTRAN program was breakpointed (output was masked) so the user had no clue what was happening.
The FORTRAN V program read the ED-converted FIELDATA command file, connected to TIP, did its magical decoding stuff, and wrote a report in FIELDATA to an output file. When it was done, it stopped, reactiving the idle CALL program, which would then turn around and feed the name of the resulting output file to a fullscreen file viewer, exit, and kick the viewer off as it's very last step.
The end result: what appeared to be a seamless program which decoded and displayed a trace file, but which had a lot of butt-ugly processing underneath.:-)
The decoding portion of the code (the FORTRAN bits) was actually a lot of fun to write, since it involved dreaming up ways to determine which type of data could be residing in a given 36-bit word based on evaluating the content of a word or portions of a word. It ended up being smart enough to decode a flight information record with all of the flight numbers, timestamps, record keys, and other important fields explicitly decoded which leaving the rest as generic decoded FIELDATA. I was actually proud of that one...
Ugly mainframe hack (dump decoder). :-) (Score:4, Interesting)
The end result was single 132-column print file containing a bunch of blocks of octal or FIELDATA information (each with at most a 6-character label) sitting in a print file.
Both dumping methods had serious disadvantages. Reading raw octal isn't fun, and neither format would give you relative word offsets (just raw memory addresses) so on long dumps it was hard to figure out where you were in a given buffer without doing a certain amount of math and counting on a 132-column printout, and in general it could be a lot better. It was also hard to read on an 80-column terminal (some viewers would wrap it, others would simply truncate the stuff beyond column 80). So I decided to write a dumper decoder to make things a lot more readable.
One of the nice things about the TIP online transaction environment is the fact that you can write batch programs which aren't really online transactions, but which can connect to TIP anyway and use TIP services.
We had a fairly large library of utility subroutines out there that could decode a word of data in various ways. We had specialized formats for storing a binary date+time (ACCMIN), storing a binary flight+date, and various other special formats, and these routines would decode a word of otherwise obfuscated information and make it nice and easy to read.
I wanted to be able to display those suckers in human-readable decoded format underneath the original octal words if I could detect the presence of a specialized data field, and I also wanted to frame the FIELDATA output from PRTADP statements in such a way that it would be obvious which words you were looking at in the trace.
I also wanted to write a nice front-end for the thing which detected various options on the command line and presented the information in a nice fullscreen viewer on the mainframe.
For this project, I created two parts:
(1) a FIELDATA FORTRAN V batch TIP program which could read the raw trace file containing the trace information to be decoded, which could connect to TIP, which could tap into the nice utility library, and which could generate a nice formatted report to a file.
(2) a CALL macro front-end which could be called from a command prompt, solicit input from the user, interpret options, and effectively drive the above F66 program, then read the resulting output and present it to the user in a nice fullscreen viewer so they could page and/or search through it however they wanted.
The problems:
(1) FORTRAN V programs could only read/write 6-bit FIELDATA. I also didn't know how to create a FORTRAN program that I could call directly from the command line. Oops!
(2) CALL macros were easy to write and were made to be run from the command line, but they could only write 9-bit ASCII files (though they could *read* both ASCII and FIELDATA).
(3) There was no way to directly link the two together (CALL macros are self-contained interpreted macros, and they don't have any way to directly call a program which is written in another language, or even residing in another CALL macro source file!).
The ugly solution: I had the CALL macro write an ASCII COMMAND file, then kick off a breakpointed runstream (whose execution was hidden from the user) which called the ED line editor to convert the command file to FIELDATA so the FORTRAN program could read it. That's roughly the same as piping it to the line editor, I guess, but a lot uglier.
The FORTRAN V program read the ED-converted FIELDATA command file, connected to TIP, did its magical decoding stuff, and wrote a report in FIELDATA to an output file. When it was done, it stopped, reactiving the idle CALL program, which would then turn around and feed the name of the resulting output file to a fullscreen file viewer, exit, and kick the viewer off as it's very last step.
The end result: what appeared to be a seamless program which decoded and displayed a trace file, but which had a lot of butt-ugly processing underneath.
The decoding portion of the code (the FORTRAN bits) was actually a lot of fun to write, since it involved dreaming up ways to determine which type of data could be residing in a given 36-bit word based on evaluating the content of a word or portions of a word. It ended up being smart enough to decode a flight information record with all of the flight numbers, timestamps, record keys, and other important fields explicitly decoded which leaving the rest as generic decoded FIELDATA. I was actually proud of that one...