Re: Modernising a monolith ile program -- RPG400-L

fwiw, in similar situations I have looked at each maintenance problem as it comes along with this in mind: In the end I want the program broken apart by functions. I also want the business rules and data separated from the user interface.

So, when there is a maintenance problem, I decide which of the functions that is, design the entire function the way I want it, entirely separate from the existing program.

Once done, I either comment the function in the original program, or surround the replaced code with "if oops = 'oops'; endif" and initialize oops with 'OK'. Then add in the new function, and test.

You will be surprised in a couple of years to realize that most of the code in the old program is dead, and finishing the clean-up will be easy-peasy.

Leastways, that is my experience.

On 6/30/2011 10:55 AM, Jeff Young wrote:

Rory,
The program is very difficult to maintain in its present form, and I was
thinking that if there were separate modules for each function, that future
maintenance would be easier.

Jeff Young
Sr. Programmer Analyst

________________________________
From: Rory Hewitt<rory.hewitt@xxxxxxxxx>
To: RPG programming on the IBM i / System i<rpg400-l@xxxxxxxxxxxx>
Sent: Thu, June 30, 2011 11:11:29 AM
Subject: Re: Modernising a monolith ile program

Jeff,

My first question would be "Why are you changing it at all?"...

Is it broken, or is it just that you'd prefer a more modular application
(perhaps for ease of future maintenance) or what?

Unless you NEED to change it, it sounds like an example of a program that
should be left alone.

Just my $0.02, of course.

Rory
On Jun 30, 2011 7:28 AM, "Jeff Young"<cooljeff913@xxxxxxxxx> wrote:

Vern,
This program has 7 possible functions, each distinct from each other based

on

the record in the display file that they are processing. Some of the

functions

are not stand alone but get called from within another routine and depend

on

variables from within that routine. In addition, most of the functions

have a

common function that they execute. How should this be handled?
Is it best to keep those together or separate them into separate modules?
Since each of the routines is accessing a display file format, how do I

handle

that from within a module?
At the present time, there are subprocedures that are common to multiple
functions within the program, but have no revelance outside it. Should I

create

a service program for them?

All suggestions appreciated.

Thanks,

Jeff Young
Sr. Programmer Analyst

________________________________
From: Vern Hamberg<vhamberg@xxxxxxxxxxx>
To: RPG programming on the IBM i / System i<rpg400-l@xxxxxxxxxxxx>
Sent: Thu, June 30, 2011 9:39:07 AM
Subject: Re: Modernising a monolith ile program

Jeff

Seems we'd need to see more in order to reply well, but I'll give you
just one idea.

To pass common data, use parameters - pass only what is needed in the
module - maybe put it all into a data structure, so there is only one
parameter to pass.

Not sure about separating procedures, but if something is called more
than once, maybe it should be put into a service program.

You call this monolithic - that usually means that everything is in one
code source - that doesn't seem to be the case here, right?

Unless the display functionality is used in other programs, I'd keep it
inside this program - reserve service programs for things that are
needed by several programs - or at least more than one!

I'm not even sure I'd move different display stuff into separate modules
- each would need its own F-spec, right? Maybe what is DONE after doing
the EXFMT and all could be separated, but that could get unwieldy, too,
methinks.

HTH
Vern

On 6/30/2011 8:14 AM, Jeff Young wrote:

I have an old ILE RPG program that uses subprocedures and service

programs,

but

performs multiple separate and distinct functions. This program is an
interactive program that uses a display file with multiple formats for

each

function.
What is the best way to separate the separate functions into modules and

then

bind into one program?
Some of the functions depend on common data that is derived from the

initial

parms passed to the program.
Should I split my display file into separate files for each function?
Use the full display file in each module and ignore the formats that are

not

used?
How do I pass the common data needed between modules?

Thanks,

Jeff Young
Sr. Programmer Analyst

--
This is the RPG programming on the IBM i / System i (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.
--
This is the RPG programming on the IBM i / System i (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.