3

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?

Vamsi Emani
  • 10,072
  • 9
  • 44
  • 71
  • 2
    Given how hard Mike Cowlishaw worked on making Rexx readable, I have to ask: What "_readability issue_" are you experiencing? Assuming you read English, a Rexx program pretty much does what the words say. – Ross Patterson May 30 '12 at 09:49
  • @RossPatterson The readability is not w.r.t the language per se. It's got to do more with the 5000+ loc cobbled up into a single script. – Vamsi Emani May 31 '12 at 11:09
  • Depending on who you work for, I may have written that monster :-) – Ross Patterson Jun 01 '12 at 00:49

3 Answers3

9

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.

David Brabant
  • 41,623
  • 16
  • 83
  • 111
  • 2
    Right, `TRACE` is the usual answer. Most especially, `TRACE ?I`, starts what most IDEs would describe as a single-step debugger. When the program pauses and the debugger takes over, you can type any Rexx statement, such as `SAY variableICareAbout`, or `SomeVar = 'A new value'`. – Ross Patterson May 30 '12 at 09:47
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.

Ross Patterson
  • 9,527
  • 33
  • 48
0

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.
Don Hoben
  • 21
  • 4