Not Your Dad's Mainframe: Little Iron
(too old to reply)
Anne & Lynn Wheeler
2006-07-11 01:50:41 UTC
Well I had exposure, access, to an IBM MVT product called TESTTRAN
which was sort of available on our system with assembler F and , if
I remember correctly, Fortran G, both in batch and TSO. One had to
compile/assemble with the TEST option, which produced and kept a
variables symbol table and a statement location table. One could
then set breakpoints, examine program values etc. etc. But it was
very awkward to use, badly documented, and buggy. When I asked I
was told that it wasn't developed because it wasn't used. Which I
considered to be a very much a chicken and egg kind of argument.
I had a little exposure to TEST under our CMS systems. But as we
didn't really support VM/CMS too well at TUCC&UNC I can't comment
much except that I didn't find out much about what it was capable
huge amount of OS/360 TESTRAN was outputing all the (12-2-9) "SYM"
cards as part of assemble/compile ... so that you effectively could
support symbolic debugging. I don't know anybody that actually used it
... I remember having a TESTRAN manual at one point and running with
option to generate SYM cards (just to see what they looked like) ... but
never actually using it.

old post that has mention of "SYM" cards (as well as formats of most of
the other 12-2-9 cards):
http://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers

PER and TRACE command were initially "machine" level stuff ... hex
addresses, hex locations ... etc .. not real symbolic stuff.

I wrote a debug tool in REX(X) called DUMPRX that eventually was
used extensively internally and at one point by nearly all the (vm/cms)
field support people

that had some amount of symbolic capability

this has comment about locate command and symbolics (and testran) ...
from 2001:

I had originally done "pageable" CP kernel function for cp67 3.1 the
summer I did a stint with BCS in Seattle (i was still undergraduate) ...
which didn't get released in product until vm370. Part of the thing that
I did as part of the pageable CP kernel function was to capture the
loader table symbolics (all the external entries) and write it out as
part of the kernel image. this feature including the complete loader
table symbolics as part of the (pageable) kernel image wasn't included
in the pageable kernel that went out in vm370 release 1. As a result,
there were periodic games played with a compiled module frequently
called DMKSYM ... that had symbolics for some amount of kernel external

however, when i got around to doing dumprx, i recreated the capture of
the complete loader table symbolics as part of saving the kernel
image. Then the "locate" command was changed to use all the complete
loader table entries saved out in the pageable kernel (instead of
DMKSYM) ... and other things were enhanced to utilize the actual loader
table entries.

vm/cms postmortem kernel dump processing had facility of importing an
image of the loader printed output. I modified the kernel dump process
to initialize the dump image with a copy of the complete loader table
image (from saving the original kernel image) as part of system startup.


this has title of "A Survey of current debugging concepts"

it looks somewhat like a cms/script document printed on 1403 with TN
train (some of the rendering looks wavy ... which might be scanning
the original, it not, then it isn't likely to have been 1403 output).
It is dated August, 1969 ... and it has section 3-34 "TESTRAN, for IBM

I now some number of gov. installations had cp67 (and cms, and script,
etc) in 69 ... but I don't know if Goddard had one(?).

The above does list TESTRAN reference as:

IBM Corporation. IBM System/360 Operating System TESTRAN.
Systems Reference Library. Form C28-6648-0 File
Number S360-37. February 1967
Anne & Lynn Wheeler
2006-07-18 05:42:26 UTC
DUMPRX was one of the slickest tools available for VM sysprogs in the
'80s. With the overall level of code quality at that time, it was really
needed. I have always thought that the only reason it wasn't included in
the product was the NIH mentality that was common in IBM at that time in
Endicott and Kingston.
http://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron

i may have alienated endicott ... which had a whole group supporting
dumpscan (which was a large program written all in assembler). I had
made a comment that i would implement dumprx in less 3 months elapsed
time only working half time on it. It would have ten times the
function of dumpscan as well as ten times the performance. also since
this was the leading edge of the OCO-wars ... i pointed out that it
would be implemented all in REXX (except for possibly a hundred
assembler instructions) so that the source would have to be shipped.

I got all the basic stuff done early ... and since i had been building
up a knowledge base of failure scenarios ... i started a library of
dumprx/rexx routines that searched for particular classes of failure

it could be run either as cms terminal line-mode ... or as a xedit
rexx macro ... and then have full xedit capability for the dumprx

since they wouldn't ship it, i eventually got approval to give a
detailed implementation dumprx talk at SHARE ... in case anybody else
wanted to implement their own.