Re: Removing or replacing *inzsr with Dspecs -- RPG400-L

On Mon, 2014-06-09 at 10:26 -0400, Charles Wilt wrote:

I'm certainly a fan of such refactoring...

But if you want to make such refactoring a standard, I'd recommend taking a
look at tools to do so.

Sadly I'm self teaching at the moment as I've been out of the industry
for a good few years, and I figured re-working an original standardised
template "workwith/create/change/delete" I've managed to re-enter from a
print out (boy did I feel like a kid again, hours spent entering code
from magazines onto a BBC micro and a Commodore PET such was my misspent
youth) would be a good way to both learn the new techniques and language
modifications and wdsc7.

I'm particularly fond of Linoma's RPG Wizard
http://www.linomasoftware.com/products/rpgtoolbox/rpgwizard

Options include:
Target IBM i release . . . . . . *CURRENT
Format of specifications . . . . *FREE2
Examine field attributes . . . . *YES
Expand copy members . . . . . . *NO
Redefine data structures . . . . *YES
Redefine *LIKE DEFN fields . . . *YES
Redefine calc. defined fields . *YES
Convert left hand indicators . . *YES
Convert opcodes to BIFs . . . . *YES
Convert key lists (KLIST) . . . *YES
Insert file I/O BIFs . . . . . . *YES
Convert ADDs/SUBs to EVALs . . . *YES
Convert Z-ADDs/Z-SUBs to EVALs *YES
Convert MULTs to EVALs . . . . . *YES
Convert DIVs to EVALs . . . . . *YES
Convert MOVE(L)s having *BLANK *CLEAR
Convert MOVE(L)s having *ZERO . *CLEAR
Convert MOVEs having data . . . *EVAL
Convert MOVELs having data . . . *EVAL
Convert MOVEA operations . . . . *YES
Convert CASxx operations . . . . *YES
Convert CAT operations . . . . . *YES
Convert DOs to FORs . . . . . . *YES
Convert LOOKUP operations . . . *YES
Convert SCAN operations . . . . *YES
Convert *ENTRY PLIST . . . . . . *YES
Convert Subroutines to Procs . . *NO
Convert CALLs and CALLBs . . . . *YES
Convert GOTO operations . . . . *YES
Compress expressions . . . . . . *YES
Highlight comments . . . . . . . *NO
Fixed-form comment designator . *SLASHES
Comment specification types . . *REMOVE
Comment designator on blanks . . *LEAVE
Case for specification types . . *LOWER
Case for unchanged logic . . . . *LOWER
Case for changed and new logic *LOWER
Case for in-line comments . . . *LEAVE
Case for right-hand comments . . *LEAVE
Free-form indent nested logic . *LEAVE
Document nested logic . . . . . *NO
Source date on converted lines *KEEP

You can download it and try it for free for 10 conversions. The price is
pretty good IMO.

Looking at the options above, it seems as though my thinking of
automation of code changes in my OP does hold some water, although I'm
going to be doing them manually so I can get a real good feel for them
and hopefully put my new knowledge into long term memory.

Arcad has another tool, but it has more functionality and is more $$$.
http://www.arcadsoftware.com/products/arcad-transformer-ibm-i-refactoring-tools/

Charles

On Mon, Jun 9, 2014 at 10:19 AM, Wilson Jonathan <piercing_male@xxxxxxxxxxx>
wrote:

I'm currently working through an old RPG program which was well
structured with small clean(ish) subroutines and a semi Model View
Controller style logic to handle screen control (although with hindsight
its to intermixed with data/program logic, ie SC01SR handles the screen
01, but also dependent on options also calls business logic subroutines
such as updating/adding/deleting a file)

Now when this program was created it had a very large *inzsr, to define
keylists, plists, before/store/etc. fields (b1cust, s1cust, etc.) so
than no fields were defined "in line."

My first question is... is it worth moving and re-coding all the *inzsr
into D specs at the beginning of the program as a first stage of
refactoring the code?

To my mind this makes sense, removing *likes etc from within the code to
the area most suited to having such code, especially as D specs can
perform an equivalent of *like and initial values can be set (I am
assuming a reset will work in the same way as a *inzsr defined field)
also a lot of this change, if not all, could be automated.

My second/third questions are once the above has been done, is it then
worth another refactoring exercise to replace the subroutines with
subprocedures, my gut tells me if it is then this can then be followed
by a third refactoring exercise which would be to move the initially
created global D specs into the subprocedures where appropriate to
isolate fields initially "global" but in reality local to specific
subroutine. (again I could see some of this also capable of automation)

Do these seem like a logical first steps to take, both in terms of
learning but also in a wider context of "best practise" refactoring of
code.

Jon

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.