RE: Passing a pointer-based array as a parameter

 <Scott Says>
In other words, don't 
pass an array to the srvpgm, instead call a getElement() subprocedure to

get element #56 from the array.  Or call a getElementByName()
subprocedure 
that does a lookup based on a value in the array.  The calling routines 
shouldn't know or care that you used a dynamic array, pointer logic, etc

to implement it. That's not their problem, it's your service program's 
problem.</Scott Says>

Not to mention that should you have to modify the dynamic array or
pointer logic...it's a one service program fix.  You won't have to
maintain 5000 interactive programs.

On a side note, performance might actually be worse using dynamic
allocation....even if the memory is not overloaded your processing time
will increase due to the overhaed of the program(s) having to figure out
the allocation size, make the allocation & reclaim the allocation.  

Just food for thought.


Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, January 31, 2006 2:14 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Passing a pointer-based array as a parameter


> Would that affect your recommendation?  If it doesn't, I'd still like
to
> know why you advise using dynamic memory allocation.  Is it *that*
messy?

Okay, 20000 elements of 30 bytes each, times 50 users, times 2 (figuring

that's the average number of times it'll be loaded by each user?) would
be 
around 58mb.  Remember, the iSeries will store the stuff that doesn't
get 
much use on disk, and the stuff that's heavily used will be in RAM.  Do 
you think that 58mb where the vast majority is on disk will be a problem

on your system?

The only reason I advise against the dynamic allocation is because it's 
extra work, it's easy to make mistakes that are difficult to debug 
(especially for someone who's new to it) and it's usually unnecessary
when 
working with so few elements.  How much does 64mb of memory cost in 
comparison to the time you'll spend writing, debugging or maintaining
this 
code?

If you think it's necessary because so many people will be running this 
program, then go ahead and do it...  however, I'd suggest that you hide 
the pointer logic in a srvpgm or module so that at least the programs
that 
use it don't need to understand the pointer logic.  In other words,
don't 
pass an array to the srvpgm, instead call a getElement() subprocedure to

get element #56 from the array.  Or call a getElementByName()
subprocedure 
that does a lookup based on a value in the array.  The calling routines 
shouldn't know or care that you used a dynamic array, pointer logic, etc

to implement it. That's not their problem, it's your service program's 
problem.