RE: A design philosophy question

Joe,

I assume that these screens/modules may be called from multiple places.  If
so, then I typically would choose option 2 because it would allow them to be
called individually from a menu if necessary, for example.  Option 4 would
be fine if they don't need to be called as a program individually.  This
would allow simpler packaging for production.  Option 3 should only be used
if each module is only used in a single program and will NEVER be used
anywhere else.  I really hate binding modules by copy if they are used in
more than one place because of the maintenance headaches that causes.

Scott Mildenberger

> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
> Sent: Sunday, September 29, 2002 10:46 AM
> To: rpg400-l@midrange.com
> Subject: A design philosophy question
>
>
> How would you design a complex multi-panel display?
>
> Let's take, for example, an order entry display.  There's a
> screen for the
> ship-to information, a screen for notes, a screen for order header
> information, a screen for order detail, a screen for shipment detail.
>
> It seems to me there are a number of possibilities:
>
> 1. One really big display file handles by one really big program
> 2. Separate programs, each with its own display file, run by a driver
> program
> 3. Separate modules, each with its own display file, called
> using bound
> calls from a driver program
> 4. Separate modules, each with its own display file, in a
> service program,
> called from a driver program
>
> Option one is bad, for all the reasons we've come to know and
> hate over the
> years - maintenance, modularity, and so on.  So that leaves the other
> options.  What are the opros and cons of having a display
> file in a module?
> And what are the tradeoffs between having such a module bound or in a
> service program?
>
> I'm not looking for a definitive "right" answer here; my
> guess is that "it
> depends".  But I'd like to have a little discussion on the
> matter.  I guess
> that's becase I'm at option two today, and very comfortable
> with it, but I
> know that I'd get at least one benefit from a bound approach:
> fewer objects
> to manage, especially in the production environment.  That goes away a
> little if I move to a service program approach, but then
> maintenance is a
> bit easier.
>
> So, please, I'd be interested to hear what you think.  Any
> comments about AG
> usage in this scenario would be appreciated as well.
>
> Joe
>