|
Sorry to say,
there is a very simple K.I.S.S solution to this if you are afraid that big
arrays takes
up to much storage in to many inactive programs:
d ArrayPtr s * Inz( *Null )
d Array s 31 0 Dim( 50000 )
d Based( ArrayPtr )
If ArrayPtr = *null,
Arrayptr = %Alloc(%Size(Array) * 50000);
else;
Arrayptr = %ReAlloc(ArrayPtr:%Size(Array) * 50000);
endif;
// do whatever you wish within the total limit in the array
when you exit the program:
Arrayptr = %ReAlloc(ArrayPtr:1);
return;
On Thu, Mar 9, 2017 at 12:37 AM, Charles Wilt<charles.wilt@xxxxxxxxx>
wrote:
Yes, 80K isn't that big....
But 2MB doesn't seem that big either...
Till you realize there's 11 of those 2MB memory allocations...
giving you 22MB of temporary storage usage...
In a program that ends up in every interactive user's call stack...
And you have 10,000 users...
And your temporary storage usage tops out at 1.4TB...
Needless to say, there's going to be changes...either to the 2MB allocation
breaking up the program a bit so that the 22MB will only be allocated when
needed and only while needed.
So think about your environment, and the life cycle of your memory
allocations.
ILE actually makes it easier to tie up memory as a program remains active
till the activation group ends.
consider ACTGRP(*NEW) if a program is called once and while...
consider actgrp(xxxxx) if a program is called repeatedly for a while, then
is done. As you can then RCLACTGRP...
Charles
On Wed, Mar 8, 2017 at 3:56 PM, Dan<dan27649@xxxxxxxxx> wrote:
O.k., o.k., o.k. I've seen the light. Scott, thank you for reminding mejust
of the context of 80k on today's Power i systems. Of course, this was
an example, but I'm sure most arrays in our production code aren't toofar
off that figure.elements.
Thanks everyone!
- Dan
On Wed, Mar 8, 2017 at 3:20 PM, Scott Klement<rpg400-l@xxxxxxxxxxxxxxxx
wrote:
Dan,have/haven't
The code that makes the dump doesn't know how much memory you
allocated. That information is only known to YOUR code.
So when you say DIM(5000), the dump program tries to list 5000
elements!Again, it doesn't know that you've only reserved memory for 32
runsYou said 5000! So when it tries to read the full 5000 elements, it
thereinto an error -- and therefore prints that the data wasn't addressable.in a
What frustrates me is to see someone using dynamic memory at all for
this! It's only an 80k total size array... believe me, you'll never
zillion years notice that 80k. You are wasting time and creatingheadaches
by keeping tracking of allocation sizes (and from your description,
--are bugs in that) and giving yourself headaches keeping track of it fornuts
WHAT, exactly?
Even if this were megabytes, it might be hard to argue that it's
worthwhile to use dynamic allocation. But for 80k?! Frankly, you're
for using dynamic memory for that.--
And this is coming from someone who LIKES working with pointers!
-SK
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.