Pinned topicsplitting up the sections of a compiler listing

‏2012-10-25T21:38:34Z
|Tags:

Answered question
This question has been answered.

Unanswered question
This question has not been answered yet.

Is there a compiler option that will write the various sections of a compiled listing ('Data Division Map', 'Cross-reference of data names', source listing, etc...) into separate output files, or at least put some kind of deliminator between sections so that an automated parser would know when a given section ends?

Re: splitting up the sections of a compiler listing

‏2012-10-25T22:11:30Z

This is the accepted answer.
This is the accepted answer.

There is no such option, directly.

The "heading" for each part of the listing delimits sufficiently (or has done for me).

You other possibility, though I don't think you'd need to resort to it, is to create an "exit" program to process the listing. From there, you could output to seperate files, if that were seen as vital.

I want to accomplish the following: for a given file input into a program, do:
1) list all the fields that make up a record(s) of the input file
2) list the fields that are actually used in the program.

Re: splitting up the sections of a compiler listing

I want to accomplish the following: for a given file input into a program, do:
1) list all the fields that make up a record(s) of the input file
2) list the fields that are actually used in the program.

For the data cross-reference, I search for "Cross-reference of data names:" in the line, then extract everything (exclusive) until the first word on the line is "Context", unless the length of the line is less than eight, in which case it is ignored. Whilst there, I change fullstop/periods to blank (so that the definition and references will be at a fixed "word" position).

For the data division map, I search for "Data Division Map" and extract everything (exclusive) until "PROGRAM GLOBAL TABLE".

I ignore lines where the first word is "Source" or "LineID" and if the length of the line is less than eight, and again change the fullstop/periods to blank for similar reasons.

The extraction of the DATA DIVISION code is simple (exclusive from "DATA DIVISION" to "PROCEDURE DIVISION".

The line-numbers have to be "normalised", as on the data map they are without leading zeros.

The usefulness of the actual line of code is in showing the full definition (for reporting) including, for instance, original level-number, OCCURS and PICture (go for the line number, pick up lines until one ends with a fullstop/period).

Use the line-numbers to link from one content to another. I "drive" with the data map. Note, it is easy with AWK's "associative arrays" to use the line-numbers. Rexx doesn't have a "built-in" method to process the contents of a stem variable no-mattter-what (in AWK I can "for (indexvalue in array)" and get a loop for all entries in an array, no matter what I use for an index) but Rexx can do that with consecutive numerics. OK, you'll get "gaps" (not quite consecutive, due to blank lines (maybe comments if ignored), but not too difficult to handle.

You can decide how to treat comments. If you want them, you have to "assume" how they relate to the code (preceding, or following).

From the cross-reference you can tell the lines on which a field is changed, or just referenced. If you go to the verb cross-reference, you can find out which verb is used on the line (a couple of "gotchas" can await). You can tell what procedure name (if any) contains the code. You can even extract from the Procedure Division the line(s) of code, even the conditional expression, with other contents, and... well, it can be fun. "Mark-up" the final output so you can navigate the output using "links" with your browser, or in any other standard form you like (Rich Text Format to allow standard appearance in a word-processor, in a CSV format, in a "format" of your own devising to aid further parsing, whatever.