Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
No replies
SystemAdmin
SystemAdmin
403 Posts
ACCEPTED ANSWER

Pinned topic splitting up the sections of a compiler listing

‏2012-10-25T21:38:34Z |
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
    BillWoodger
    126 Posts
    ACCEPTED ANSWER

    Re: splitting up the sections of a compiler listing

    ‏2012-10-25T22:11:30Z  in response to SystemAdmin
    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.
  • SystemAdmin
    SystemAdmin
    403 Posts
    ACCEPTED ANSWER

    Re: splitting up the sections of a compiler listing

    ‏2012-10-26T03:14:39Z  in response to SystemAdmin
    My 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.
    • SystemAdmin
      SystemAdmin
      403 Posts
      ACCEPTED ANSWER

      Re: splitting up the sections of a compiler listing

      ‏2012-10-26T16:12:44Z  in response to SystemAdmin
      Carl,

      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.

      Example:

      1) Input file is BILLING-FILE. File Descriptor is
      FD BILLING-FILE
      BLOCK CONTAINS 0 RECORDS
      RECORDING MODE IS V
      LABEL RECORD IS STANDARD.
      01 IN-RECORD.

      PROCEDURE DIVISION:
      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 . . .
      etc...

      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
      etc...
      • BillWoodger
        BillWoodger
        126 Posts
        ACCEPTED ANSWER

        Re: splitting up the sections of a compiler listing

        ‏2012-10-27T23:35:44Z  in response to SystemAdmin
        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.