× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.