|
Simon, Where did you find out about the TERASPACE__ define? Also, what's in your STDLIB include? -Walden ------------ Walden H Leverich III President Tech Software (516)627-3800 x11 WaldenL@TechSoftInc.com http://www.TechSoftInc.com -----Original Message----- From: Simon Coulter [mailto:shc@flybynight.com.au] Sent: Wednesday, December 19, 2001 03:41 To: midrange-l@midrange.com Subject: Re: Teraspace memory allocation Hello Walden, You wrote: >I have a need to allocate more than 16Meg of memory. Teraspace >allocations seem to be the ticket and it looks like I can simply call >_C_TS_malloc, but I'm looking for someone that has used it from RPGLE. >Anyone? Bueller? I have been following this thread and don't really see the problem. Given that the ILE Concepts manual says that teraspace can be addressed from a space pointer, I created the following program using my definitions of the C memory allocation functions including definitions for the _C_TS_xxxxxx teraspace functions. H DFTACTGRP(*NO) BNDDIR('QC2LE') /define TERASPACE__ /copy rpgleinc,stdlib D realPointer S * D based DS BASED(realPointer) D fld1 10 D fld2 10I 0 D fld3 5S 0 C EVAL realPointer = malloc(100) C EVAL realPointer = realloc(realPointer:200) C EVAL based = *BLANKS C EVAL fld1 = 'TESTXYZ' C EVAL fld2 = 1234567890 C EVAL fld3 = 98765 C CALLP free(realPointer) C SETON LR C RETURN This program works on 440 (with latest Cume). Debug shows me that the 'realPointer' is set to 9E580280000810C0 after the malloc (which actually uses _C_TS_malloc). The realloc (which uses _C_TS_realloc) doesn't change the pointer address (normal behaviour in this sequence of events) but does seem to increase the allocation and I can successfully address the teraspace storage. Removing the /define for TERASPACE__ causes the normal malloc/realloc/free functions to be used. The program functions identically but debug shows that 'realPointer' is set to DE636812A30010B0 which is a "normal" space pointer address. Given the difference in addresses in 'realPointer' I presume the teraspace version is actually using teraspace. I tried tracing the function calls but that didn't show anything useful because the IBM service program implementing the memory allocation functions doesn't log trace data. Given that my code seems to do what you require I suggest the problem is in your prototypes. Either that or you are doing something wierd with the pointer addresses after the allocation. In a further attempt to prove that teraspace really was being used (even though the compiler listing indicated it was) I wrote the following code. H DFTACTGRP(*NO) BNDDIR('QC2LE') /define TERASPACE__ /copy rpgleinc,stdlib D realPointer S * D based DS BASED(@based) D fld1 10 D fld2 10I 0 D fld3 5S 0 D $MAX_ALLOC C CONST(2147483408) C EVAL realPointer = malloc($MAX_ALLOC) C EVAL @based = realPointer + C ( $MAX_ALLOC - %SIZE(based) ) C EVAL based = *BLANKS C EVAL fld1 = 'TESTXYZ' C EVAL fld2 = 1234567890 C EVAL fld3 = 98765 C CALLP free(realPointer) C SETON LR C RETURN It took a mucking huge amount of time to complete the malloc. WRKSYSACT also showed the storage management task SMP00001 doing a fair bit of work. WRKSYSSTS showed disk usage going up. So I reckon it worked. A second run of the same program completed the malloc instantly. That is consistent with the ILE Concepts information about there being a single teraspace per process which lasts until the process is terminated thus the second run used the space allocated by the first run. Even though a 2GB allocation indicates teraspace is being used I modified the same program to increase the allocation by the $MAX_ALLOC amount a few times using realloc (just as well I have 12GB of free disk space) until I exceeded the amount I could possibly allocate if I were not using teraspace. Each realloc took quite a while (as one would expect -- copying GB of space must hurt) but they did work. So the net is that teraspace is accessible and addressable from RPG IV. Regards, Simon Coulter. -------------------------------------------------------------------- FlyByNight Software AS/400 Technical Specialists http://www.flybynight.com.au/ Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\ Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au \ / X ASCII Ribbon campaign against HTML E-Mail / \ -------------------------------------------------------------------- _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
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.