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

Thanks, Jon.  This is quite helpful.  I've always thought my applications
were doing all the memory allocations on the wrong side of the "fence" , and
the modules actually doing the I/O work should be doing it rather than the
calling programs, but just didn't quite know how to get there.

Only my top level procedure is completely generic.  By the time the call
gets all the way down to the real I/O routine (which lives in a
program-generated service program containing all procedures related to a
specific file), it is quite file-specific.  In my current implementation
though, I end up with matching MODS in both the caller and callee and I was
always afraid to define it for more than about 100 records at a time for
performance reasons.  This will eliminate the overhead of one of them, free
up the limitations, plus simplyfy much code.  Thanks again.

Now, before I start revamping everything, I want to try to understand
David's Mediator concept a little better.


> -----Original Message-----
> From: Jon Paris [SMTP:Jon.Paris@Partner400.com]
> Sent: Thursday, April 11, 2002 2:34 PM
> To:   rpg400-l@midrange.com
> Subject:      Separation of Presentation, BL, and I/O Tiers
>
>  > So, even though I never actually allocated any storage in the calling
> program, I could still set the occurrence to different records once I've
> set
> the basing pointer to equal the pointer returned from the I/O module?
>
> You got it.  It is the reverse of passing parameters.  When you pass a
> parm
> you pass only the address (pointer) to storage in the caller.  The callee
> doesn't declare storage - just maps his definition (i.e. "Bases" his
> definition) on that pointer.  When the callee changes memory he is
> changing
> the original callers memory.
>
> In your scenario you are doing the reverse - you are receiving a pointer
> to
> the storage allocated by the callee and using to base your definition -
> but
> the principal is the same.  Don't forget by the way that if the IO routine
> is a subprocedure (which it should be) the pointer that you are returning
> should be declared as STATIC or it will disappear and you will never be
> able
> to free the heap memory allocated to it until EOJ.
>
> 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.
>
> Jon Paris
> Partner400
>
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message.
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer.
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************