RE: Separation of Presentation, BL, and I/O Tiers

["David Morris" <David.Morris@xxxxxxxxxxxxx>]

Nelson,

I guess it would be easiest to include those answers inline:

>>> NSmith@lincare.com 04/11/02 01:08PM >>>
Interesting questions.  How does the Mediator address these issues,
David?

> -----Original Message-----
> From: Joe Pluta [SMTP:joepluta@PlutaBrothers.com]
> Sent: Thursday, April 11, 2002 3:08 PM
> To:   rpg400-l@midrange.com
> Subject:      RE: Separation of Presentation, BL, and I/O Tiers
>
> > From: Jon Paris
> >
> > Having said all that - given that the routine you call is a
> > generic one used
> > by many different functions, I'm not convinced that dynamic
> > memory is really
> > needed.  Why not just use fixed memory in the callee and map to
that.
> Or
> > for that matter use IMPORT/EXPORT.
>
> Whee!  Now you guys are getting into the FUN stuff!
>
> I need to retrieve dynamic amounts of data, data whose size cannot
be
> determined at compile time.  Do I allocate the maximum amount of
storage,
> or
> dynamically allocate the storage as needed?  Well, that depends on a
whole
> bunch of things.
>
> Let's look at static allocation in the callee.  First off, how many
of
> these
> modules are you going to have?  If you're talking about creating a
nice
> 16MB
> buffer for every file, and you have 100 files, you're talking about
1.6GB
> of
> storage.  For every job.  That's a pretty serious amount of storage.

With a Mediator, you can use one area if you want (I use a user space)

that serves many files. The Mediator maintains information about the
files it is serving and the space where it is loading data.

>
> And what happens when you need to do this recursively?  Let's say you
use
> this procedure to handle a bill of materials.  You call the
subprogram to
> get the parent's components.  You start processing those records, and
the
> first thing you do is go get the components for the first child.
Well,
> since everybody is sharing the same memory (in the callee), then this
call
> is going to wipe out the parent's component list.  Life becomes
totally
> rancid, dude.
>

With a Mediator, you can detect the recursive call (you can store a
stack
level by open file) and allocate another piece of memory.

> On the other hand, how do you manage dynamic memory?  Do I have a big
fat
> buffer that I read everything into, and then allocate a buffer of
the
> correct size when I'm done?  Big waste of memory.  Or, I can allocate
a
> smaller chunk at a time (say 100 records), and then extend the chunk
every
> time I need to.  But this involves copying the old records every time
I
> extend the space.  Thirdly, I could allocate space a chunk at a time,
and
> then paste them all together at the end.  A nice compromise, but not
> particularly intuitive at first glance.
>
> On top of all this, the caller has to remember to release the data.
> Whether
> the caller does the release or calls the subprogram to do the
release,
> this
> is still under the control of the caller.

Mediator does not help much here, The best way to do this is to
register
an exit and a close routine or use a scope message, either one imposes

a new requirement on the caller. Ideally you could call the Mediator to

register the cleanup routine but IBMs APIs and scope messages do
not support a level. The Mediator does simplify the cleanup effort
because all of the allocation is done in a single module.
>
> Whoo hoo!
>
> We're having fun now!
>
> Joe