× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



It's not actually our code allocating memory...

It's in some vendor's code.

We are working with them to reduce usage...but we'll probably end up
restructuring how we make use of their code.

I'm just throwing the story out there as a cautionary tale.

Yeah 2MB static allocation for something doesn't seem like much...

But sometimes it is.

Charles


On Thu, Mar 9, 2017 at 8:32 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

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
me
of the context of 80k on today's Power i systems. Of course, this was
just
an example, but I'm sure most arrays in our production code aren't too
far
off that figure.

Thanks everyone!
- Dan

On Wed, Mar 8, 2017 at 3:20 PM, Scott Klement <
rpg400-l@xxxxxxxxxxxxxxxx

wrote:

Dan,

The code that makes the dump doesn't know how much memory you
have/haven't
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
elements!
You said 5000! So when it tries to read the full 5000 elements, it
runs
into an error -- and therefore prints that the data wasn't
addressable.

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
in a
zillion years notice that 80k. You are wasting time and creating
headaches
by keeping tracking of allocation sizes (and from your description,
there
are bugs in that) and giving yourself headaches keeping track of it
for
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
nuts
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




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.