RE: Alternatives to MOVEL - just curious

I'm sorry John, but are you saying that your first step in modernizing
your code is adding new SUBROUTINES? You meant to say subprocedures,
surely?

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Voris, John
Sent: Wednesday, December 11, 2013 2:11 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Alternatives to MOVEL - just curious

message: 2
from: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
subject: Re: Alternatives to MOVEL - just curious

All of which goes to emphasize that a generic approach to a MOVEx

replacement is fraught with problems

and why I recommend the use of custom subprocedures that are named for

the actual function being performed in that specific instance.

I agree. These MOVEL conversions are usually very specific to mapping
the data-formats of two dissimilar fields.

In the effort to modernize the code, I usually first pull these MOVEL
into Subroutines located at the bottom of the program that is now in
/FREE format.
So now the MOVEL's are segregated to their own sections in the code.
And I can add up the effort involved with this "Technical Debt" by
counting the lines of code in this one area at the bottom of the
program.

I often leave them for a future time, but they are identified and ready
to be tackled.
The MOVEL's will continue to work fine with their Global fields, but
they are not scattered throughout the program code

Also at the end of these programs, if there are also old-style CALL to a
programs done in C-specs and not being done in a ProtoTyped CALLP,
These are also moved to the bottom of the program in their own
Subroutines.
It's the first step in getting the program modernized.

- J Voris