MVSFORUMS.com

[papadi]

Cool, time spent learning is a good thing
_________________
All the best,

di

[semigeezer]

If you are feeling adventurous, you can write this type of macro using more detailed compiler output which I think is called SYSADATA or ADATA (??). Using that data instead of a listing gives consistent data that is not dependent on listing options. But it does require either compiling the program from within the macro or having SYSADATA available as part of your compile process (and SYSADATA is really huge). I don't know if SYSADATA would help track down unreachable code, but it might.

A few years ago I was able to write a macro that compiles the program being edited, collects the SYSADATA and then inserts the messages into the editor at the appropriate places using ERR and INFO lines. It is a major pain in the *** to do because the SYSADATA record formats are cryptic and binary and determining the line numbers for errors within nested copybooks is a little convoluted, but it is possible. The SYSADATA record formats are in the COBOL books. Unfortunately I can't share the macro but it was done in Rexx (with a few in-line ISPF panels to set compiler & copybook libraries, options and help).

A word of warning though: This is really an exercise for when you are either hopelessly bored, between assignments, or trying really hard to avoid some other work. I found it very challenging, but fun and it took me a week or two (after hours!) to make it work as I wanted. I'm a big fan of inline error messages (or some other automated way to locate the error location such as the way RDz does it). I'm the poster child for that "lazy developer" you mentioned...except when it comes to writing tools to aid my laziness.
_________________
New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html.

[misi01]

If I have to do something that is convoluted and prone to error, I tend to write a macro (or a script in Reginald rexx on the pc) that will take the work out of the job next time I have to go down the same path.
_________________
Michael

[William Collins]

Me too. I just don't think this example is one of those

Dead code often indicates program-error. OPT spots dead code, whether the whole of a procedure, or just a bit within a procedure. You can't match that unless you mimic the compiler.

OPT(FULL) will identify unused storage, taking REDEFINES into account as well. It is flagged in the data-map.

As far as I can see. the compiler already gives you all that you want (or can, with OPT(FULL)).

If you then want to suck that information into an edit session, fine. I just don't think it happens often enough to make it worthwhile.

If the systems you are working on have old and heavily maintained code, then perhaps the additional step makes sense. Perhaps. But there may be other things that would be useful first..