RE: A design philosophy question

> From: Buck Calabro
>
> I started this so many times and have consistently failed to type anything
> sensible.  Continuing in that vein, I glean from your discussion
> with Booth
> that you aren't interested in tinkering how the DDS is laid out; just how
> the RPG is to interact with the chosen DDS.

Personally, I'm having a hard time with this whole thing.  The issue was in
my mind simple and specific, and instead we're jumping off into theory and
system architecture.  Forest and trees kind of stuff.

Maybe I'm just an old dinosaur, but it seems to mee there are situations
where you might want to use the same panel in multiple places.  Three
options:

1. Individual display files for the separate panels
2. Cloned record formats in multiple display files
3. One giant display file for the entire application

I'd love to hear discussion on this, but IMO option one is the best choice.
That then leaves my original three options:

1. Individual programs
2. Modules bound by copy
3. Modules in service programs

I could also probably have multiple display files in a program, but that
scares me too much.  So of the three above, what is suggested?

> I just can't see how
> ILE could
> have an impact on that decision.
>
> Perhaps leaving the display file out of the question would make it easier.
> What problem do you contemplate ILE solving that a dynamic call can't?

Leaving out display files defeats the purpose of the question.  The whole
issue was about display files in modules.  That's all.  That's it.  Simple.
Booth popped turned the discussion to vertical and horizontal
modularization, and the demise of all legacy programming techniques, but all
I wanted to know was: "Are there problems with display files in modules?"

The differences are primarily production oriented.  Multiple programs means
multiple ojbects, and that's the issue.  With dynamic calls, moving an
application from development into production means moving multiple program
objects.  With bound-by-copy modules, there's only one object, while with
service programs you have an intermediate number, depending on how you bind
the modules into the service programs.

Now, while the issue of number of objects is fairly straightforward, I
wanted to know if anyone had addressed the issue of having a display file in
a called module, and whether they'd run into any problems.  How do you open
and close it?  Do you get weird problems with, say, OVERLAY not working as
you expect it?  Or KEEP and ASSUME?  I've seen issues with borders not being
repainted on a popup window (the fields were shown, but the borders
weren't), and was wondering if that's just me.

That's all I was asking.  What are people's experiences, if any, with
display files in modules.  Nothing more, nothing less.

Joe