This topic has been locked.
Pinned topic splitting up the sections of a compiler listing
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?
Updated on 2012-10-27T23:35:44Z at 2012-10-27T23:35:44Z by BillWoodger
BillWoodger 270005Q076123 PostsACCEPTED ANSWER
Re: splitting up the sections of a compiler listing2012-10-25T22:11:30Z in response to SystemAdminThere 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.
Re: splitting up the sections of a compiler listing2012-10-26T03:14:39Z in response to SystemAdminMy first, knee-jerk reaction: Why do you want to do this? What are you trying to accomplish?
Sometimes, an exact answer to the question asked may not get to the solution to the problem you are trying to solve.
Re: splitting up the sections of a compiler listing2012-10-26T16:12:44Z in response to SystemAdminCarl,
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.
1) Input file is BILLING-FILE. File Descriptor is
BLOCK CONTAINS 0 RECORDS
RECORDING MODE IS V
LABEL RECORD IS STANDARD.
MOVE IN-RECORD TO WS-CUST-ACCT-REC
list all the fields that make up a record:
DATA DIVISION MAP:
1 WS-CUST-ACCT-REC . . .
4 COMPANY-CODE. . . . .
4 STATE-CODE. . . . . .
4 LOCATION-CODE . . . .
4 MAILING-ZIP-CD. . . .
4 TYPE-OF-ACCOUNT . . .
2) list the fields of WS-CUST-ACCT-REC that are actually used in the program.
Cross-reference of data names:
581 COMPANY-CODE . . . . . . . . . 12910 12982
582 STATE-CODE . . . . . . . . . . 12912 12984
BillWoodger 270005Q076123 PostsACCEPTED ANSWER
Re: splitting up the sections of a compiler listing2012-10-27T23:35:44Z in response to SystemAdminFor 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.