× 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.



Bruce,

You were right it failed on the 257th allocation.

In any case, 4G is a lot more than 16M, and should be sufficient for the majority of applications.

It also appears that the 4G limitation is a job attribute. Once the failure occurred, I could not allocate any more space in the job and had to sign off to release the storage.

This problem went away when I created the program in ACTGRP(*NEW) instead of the DFTACTGRP.

When I used a named activation group, the problem came back but could be cleared by reclaiming the named activation group.

Mel Rothman
Mel Rothman, Inc.

Bruce Vining wrote:




Change your array dimension to 500 and I suspect you'll see a failure around the 257th allocation. Each language runtime could handle storage allocations in different manners, but I would expect most of them to fail in the neighborhood of 4GB.

Bruce



Mel Rothman <mel@xxxxxxxxxxxx To: C400-L@xxxxxxxxxxxx om> cc: Sent by: Subject: [C400-L] Re: Authentication / base64 encoder? c400-l-bounces@mi drange.com 08/29/2003 10:26 AM Please respond to C programming iSeries / AS400




Jon,


I don't know where RPG allocates storage from (you said "from the
default heap which has 1 16M limit"), but I just ran a test that
indicates RPG dynamic storage is not limited to only 1 16 megabyte
piece of storage.

Below is the code and it had no problems allocating 16,000,000 bytes
to each of 50 pointers.

Am I missing or misunderstanding something?

Did you mean to say 16M per pointer?

Mel Rothman
Mel Rothman, Inc.

D ptrs            s               *   dim(50)
D i               s             10i 0
C                   for       i = 1 to %elem(ptrs)
C                   alloc     16000000      ptrs(i)
C                   endfor
C                   eval      *inlr = *on



Jon Paris wrote:

>> But what I'd really like to know - is there any reason for OS/400 to
return NULL after calling for example r = (char *) malloc(1000000) ;

The major reason would be that you've exhausted the heap space (or at

least


there no contiguous space of 1,000,000 bytes available).  I'm not certain
about C, but RPG allocates form the default heap which has 1 16M limit.
Unless you specify that the C code is to use terraspace capability then I
suspect it has the same limit.  If you are using small amounts of memory

I


wouldn't bother about it - if you're using 1,000,000 byte requests then
probably safer to use the CEE APIs and create your own custom heap.

Jon Paris
Partner400
www.Partner400.com

_______________________________________________



_______________________________________________ This is the C programming iSeries / AS400 (C400-L) mailing list To post a message email: C400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/c400-l or email: C400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/c400-l.




_______________________________________________ This is the C programming iSeries / AS400 (C400-L) mailing list To post a message email: C400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/c400-l or email: C400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/c400-l.





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.