Re: List API's, Memory Management, and Pointer Math

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]

Ð
Hello David,

You are forgetting one thing -- the single most important feature of the 
AS/400.  
That thing is single level store. All OS/400 objects occupy contiguous storage 
.... in the virtual address space.

When you create an object it gets a block of virtual addresses assigned. It 
used 
to be a 64K (small SID) block for small objects and a 16MB (large SID) block 
for 
large objects.  Teraspace objects have altered the rules slightly.

A user space is initially created with the requested physical size but the 
machine still assigns a block of 16MB virtual addresses to the object.  If you 
attempt to address beyond the physical size you will receive an MCH0601.  You 
can make the space automatically extendable by setting an attribute (use the 
QUSCUSAT API).  The list APIs automatically set this attribute and unset it 
after they've finished.

So when you increment a pointer through the storage you are incrementing 
through 
a contiguous range of virtual addresses.  The machine (i.e., SLIC) translates 
the virual address to a real address which in all likelyhood is not contiguous.

So you as a programmer don't have to worry about the implementation.  The 
QUSPTRUS API is just doing a rslvsp (which takes an object name and type and 
returns a system pointer) followed by a setsppfp (which (generally) takes a 
system pointer and returns a space pointer to the first byte of the associated 
space of the object referenced by the system pointer) and returns that space 
pointer to the caller.

Note that dynamically allocating heap storage is different.  In that case a 
realloc to increase the allocated size is likely to allocate a new, larger, 
chunk of the heap and copy the old contents before returning you a new pointer.

PS. Turn off the HTML mail junk ....

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
Ð-Mailer: Microsoft Outlook Express 5.00.2615.200
Date: Fri, 07 Jul 2000 01:06:04 -0700
From: "David Keck" <dkeck@idt.net>
To: RPG400-L@midrange.com
Reply-To: RPG400-L@midrange.com
Subject: List API's, Memory Management, and Pointer Math
Ðist API's can dynamically extend the size of their associated user spaces.  I 
think it unlikely that that such extensions would always yield a user space 
consisting of a contiguous block of bytes in memory.  I think it more likely 
that extensions would reside in non-contiguous blocks of memory allocated as 
extensions become necessary. 
For Example ...
------------ stuff deleted ---------------------
  4.. Now for simple pointer math to always work, you should be able to have 
the 
driving RPGIV program work its way through the entire *USRSPC one byte at a 
time 
incrementing the address (pointer) by 1 until the end of the structure is 
reached.  But if this always works doesn't that mean that the user space 
extensions always yield a *USRSPC which resides in a contiguous block of memory?