XREF Improvements - Community input is requested

Rationalize procedure references

community.progress.com/.../rationalize_procedure_references_in_xref.aspx

Identify which DB table, not just the buffer name.

Actually, my real proposal would not to do an incremental change, but to dump and replace.  I know that goes counter to the core PSC upward compatibility doctrine, but this was not a feature that was well thought out.  There is no reason to have all of the same tags underneath every entry and have most of them go unused and no reason not to have tags which are actually meaningful ... like the DB table for a buffer and whether it is a buffer to a DB or TT table.  There is just ***so*** much more information which is right there in the parse tree that one could dump out and use.   Or, maybe you could dead end XREF and actually do something to dump the parse tree instead???

How about COMPILE LIST as well?

community.progress.com/.../compile_listing.aspx

Having the entire parse tree, and in particular all the symbols (variables, procedures, functions, buffers, strings, etc.) would be quite helpful for searching where a db table is referenced, impact analysis, and finding un-used code paths.

What would be all the better is if the provided information was in a format that could easily be fed into a database for searching and reporting.

I'd suggest looking into John Green's "Programmer's Analyst" - his tools feeds proparse output into a searchable db.

  1) It would definitely be nice to get insight over the bracketing information. For instance, the selected index may look like a good index, but still bracket too wide (e.g. only the first component instead of the first three).

2) Indicate when the lock state of a record changes, what it changes to and why.

Examples:

REPEAT:
    PROMPT-FOR Customer.CustNum.
    FIND Customer EXCLUSIVE-LOCK USING CustNum.
    DISPLAY Customer.Name.
    UPDATE CreditLimit.
    FIND CURRENT-CUSTOMER NO-LOCK.
    FOR EACH Order OF Customer:
        DISPLAY Order.Total - Order.Paid.
    END.
END.

• Line 3: LOCK Customer EXCLUSIVE, Explicit
• Line 7: LOCK Order SHARE, Implicit
• Line 9: RELEASE Order, Implicit
• Line 19: RELEASE Customer, Implicit.

DO TRANSACTION:
    FIND CURRENT Invoice EXCLUSIVE-LOCK.
    UPDATE Invoice.Terms.
END.

1. Line 2: LOCK Invoice EXCLISIVE, Explicit
2. Line 4: LOCK Invoice SHARED, Implicit downgrade

PROMPT-FOR Item.ItemNum.
FIND Item USING ItemNum.
DO TRANSACTION:
    UPDATE OnHand.
    FIND CURRENT Item NO-LOCK.
    DISPLAY Item.OnHand
        Item.BackOrder
        Item.OnOrder.
END.

• Line 2: LOCK Item SHARED, Implicit
• Line 4: LOCK Item EXCLUSIVE, Implicit upgrade
• Line 9: LOCK Item NO-LOCK, Explicit Due to the read on line 5, this is now explicit.

@Tim: Of course, Analyst does a wee bit more than databasing the parse tree, but yes, that is the obvious goal.  I would think dumping the parse tree to XML would be an almost trivial task.

@Mike: The issue with Proparse is its support for syntax past 10.2B.   Looked at your mail lately?

While the output is very bulky, especially the XML one, I'm not inclined to suppress any output since I may not process the output file at the same time that I compile it.  It is easy to skip over things and deceptive if something is not there and one doesn't know to not expect it.

For those not (yet) on the 11.6 ESAP, item 1 from my original post (SEARCH information for local temp-tables) is now available in the new 11.6 ESAP. Please feel free to try it out.

There is no commitment to address the other suggestions from this thread in 11.6, but I appreciate the dialog.

in 1998, I asked my tech support, (at the time techsup  was regional, so I contacted Mexico office) if there would be a listing or something about database plan, and got no for an answer..

Hopefully we can get an explain plan/bracketing information in 11.7 :)