This refactoring is intended to be used as part of a legacy code modernization project. It is unlikely to be used on a day-to-day basis.
Although most Progress programmers recognize that NO-UNDO
is important for application performance, it is not unusual to find legacy applications where NO-UNDO
was not consistently added to DEFINE
statements. This refactoring is intended to be run as a single pass through old code, in order to correct those statements.
This NO-UNDO refactoring has a few features which are worthy of note.
These features work nicely with Prolint. If ProRefactor's NO-UNDO Refactoring does not add NO-UNDO to a DEFINE statement, for whatever reason, Prolint will continue to warn about that DEFINE statement until you explicitly tell Prolint that it is intentional with a prolint-nowarn directive. (Or else of course you might review the code and decide to add NO-UNDO by hand.) Here is a snippet of code which is the output from the unit test used for the NO-UNDO refactoring. All of the NO-UNDO options on DEFINE statements were added by the NO-UNDO refactoring, but more interesting is to note where the NO-UNDO refactoring did not add NO-UNDO.
/* n o - u n d o . p * This file contains tests for our N O - U N D O refactoring. * IMPORTANT!! Comments containing "u n d o" (without the spaces) * have an impact on the refactoring's behaviour! */ {&_proparse_ prolint-nowarn(noundo)} DEFINE VARIABLE myInt AS INTEGER. PROCEDURE myProc1: DEFINE INPUT PARAMETER p1 AS LOGICAL NO-UNDO. END. PROCEDURE myProc2 EXTERNAL "whatever.dll": DEFINE INPUT PARAMETER p2 AS LONG. END. /* Test for U N D O statement. */ DEFINE VARIABLE myChar AS CHARACTER. DEFINE VARIABLE myChar2 AS CHARACTER NO-UNDO. DEFINE VARIABLE myChar3 AS CHARACTER NO-UNDO. DO: myChar3 = "". DO: myChar = "". UNDO, LEAVE. myChar2 = "". END. END. /* U N D O statement tests for named block and OUTPUT val */ DEFINE VARIABLE myChar10 AS CHARACTER. DEFINE VARIABLE myChar11 AS CHARACTER. my-block: DO: RUN changeVal(OUTPUT myChar10). DO: RUN changeVal(OUTPUT myChar11). UNDO my-block, LEAVE. END. END. PROCEDURE changeVal: DEFINE OUTPUT PARAMETER changed AS CHARACTER NO-UNDO. END. /* This should remain UNDO */ DEFINE VARIABLE c1 AS CHARACTER. /* This var should be UNDO */ /* with this two line comment. */ DEFINE VARIABLE c2 AS CHARACTER. DEFINE /* UNDOable */ VARIABLE c3 AS CHARACTER. DEFINE VARIABLE c4 AS CHARACTER. /* not no-undo */ /* This comment does not change UNDO for the next define, because of the blank line between the comment and the statement. */ DEFINE VARIABLE c5 AS CHARACTER NO-UNDO. DEFINE VARIABLE c6 AS CHARACTER NO-UNDO. /* Comment on line after does not change UNDO for previous statement. */
Comments
NO-UNDO for Temp-tables
How are temp-tables handled? Also, it does not appear that ProRefactor checks "intent". That is, "should" the variable or temp-table be undone. I'm not sure how it would though. But if this is the case, a comment indicating this might be made.
Re: NO-UNDO for Temp-tables
Hi Jay,
It's been a long time since I last worked with this, and I don't remember it very well. Temp-tables are skipped (see NoundoRefactor.java). They are only briefly examined during analysis (TP03Support.java). It's interesting to note that a TEMP-TABLE definition can have an explicit UNDO. TP03Support.java does the majority of the work. You can see how it is called from the treeparser03.g grammar file. There's no way to know if "undo" was the intent without some consistent coding convention.