Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!PENNDRLS.BITNET!TOM From: TOM@PENNDRLS.BITNET ("Thomas D. Denier") Newsgroups: comp.lang.asm370 Subject: Re: debugging of assembler programs on CMS Message-ID: <9011121958.AA10385@ucbvax.Berkeley.EDU> Date: 12 Nov 90 19:55:36 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: IBM 370 Assembly Programming Discussion List Distribution: inet Organization: The Internet Lines: 17 A long time ago I set up an assembler debugging system to track down a particularly elusive problem with an RSCS modification (it turned out to be due to sloppy coding practices by IBM, which IBM refused to fix). I set up a USERID to run a test version of RSCS, and made my own USERID a secondary user for it. I used IUCVTRAP to catch the console messages from RSCS, processed them with Rexx code, and generated CP commands to be executed on the test RSCS machine. The Rexx code I wrote essentially did two things. It worked its way through RSCS control blocks to find the origin address for the modified line driver. Having done that, it stepped through the code one instruction at a time. As each instruction in the line driver was executed the Rexx code displayed the corresponding line of the LISTING file generated when the line driver was assembled. I managed to find the bug with just these capabilities, but the general approach I used could be extended to provide other capabilities, such as tracking register contents or displaying data areas in their source- code formats.