How to debug Rexx code?

Question

I am working on a code parser that is built on Rexx. It is a single file script with around 5000 lines of code or more. I've never worked on Rexx before. Adding to that, the readability issue is making my life even tougher. So,

Are there are any tools to debug and understand Rexx code?

Answer 1

Use the trace statement? The most simple mode of tracing is 'A'. This causes each instruction to be displayed before it is executed. Your instruction is displayed with a line number and the three characters - preceding it, so that you can identify it as a line in your script.

Answer 2

Wikipedia has a pretty good article on Rexx, which should help you understand Rexx syntax and program structure. And almost any Rexx book will apply to your environment, because Rexx is extremely cross-system (similar in that way to the younger Perl and Python languages). There aren't a lot of online books, because almost everything written about Rexx was written before the web existed, but the reference manual for the Regina implementation is, and it's a particularly good reference work.

Answer 3

The date on this question is old, but I'll share what I have found helpful for the next person who pulls this up. Already mentioned is the TRACE option. I've found this can be overwhelming in a small set of code let alone 5,000 lines or more.
Here are some options I've found useful:

1. Use an "if" to turn the trace on only in certain situations.
   if counter < 25 then trace "A"
   Be sure to turn the trace off with:
   else trace "OFF"
2. Use say followed by pull. What is said will stay on the screen until you hit enter.
3. Add a subroutine:
   AskIt:
parse pull comment
say comment
say 'enter "X" to exit program'
pull continue
if Continue \= "X" then return
exit
   This is invoked with call AskIt "In routine that loops, counter=" counter
   and would display:
   In routine that loops counter='##
enter "X" to exit program
   The tester chooses to return to the code by hitting enter or exit the program with X to edit the source.
   Temporarily inserting return on the line following the routine label will allow you to run the code uninterrupted without removing all the calls.
   
   I have written an edit macro for z/OS which inserts a say *routine name* after every routine label. It inserts the code with a /* comment */ containing a readily identified phrase to simplify cleanup.
   The audience for this would be small, so I'll not include the code here.
   
   Hope this helps someone.