Re: why the 16meg space size limit?

["Mark S. Waterbury" <mark_s_waterbury@xxxxxxxxx>]

Hello, all:

I just have to add my "two cents".  First of all, teraspaces are "fine" if
you really
need access to a very large "contiguous" chunk of memory, so that you can do
some (rather dumb) things like increment a pointer to walk through the
contents of
some vast data structure, array, etc., like many typical C or C++ programs
do,
usually on some Unix box or PC. So, IBM wanted to make it "easier" to "port"
the
(dumb) C programs to AS/400 and iSeries, and so, now we have "teraspaces".
;-)

However, if you are using any decent language with reasonable data
structuring
facilities, such as the ability to use pointers to create trees, linked
lists, etc., then,
why on Earth would you "need" to have a "contiguous" chunk of memory that
big,
in the first place??? (Let me explain...)

It is very easy to get chunks of memory, sub-allocated from within a
*USRSPC, or
from within an ILE heap space, and "chain" these together, in all sorts of
ways, to
create whatever larger data structures you want. You can even create
dynamically
sized, dynamically dimensioned "arrays" in this way, using linked list
structures.

Now, if you need to have a "persistent heap", then you would want to use
*USRSPC
objects, because they are permanent, unless you create them in QTEMP. If you
want
a "heap" that is automatically disposed of and "cleaned up" automatically at
"end of job"
then you can use the ILE heap. In fact, you can allocate multiple "heaps" of
up to 16 Mb
each, and yes, you can still chain together the little bits and pieces of
whatever it is that
you are "allocating" within these spaces.

If you are wanting to create a "persistent heap", then I advise against
storing actual
MI pointers within the data structures themselves. In this case, it would be
far better
to store some type of (segment, offset) tuple that represents the target
address, which
identifies which *USRSPC (space object) is to be used (segment #) and the
offset
within that space, because, that way, you can actually use SAVOBJ and RSTOBJ
to
save and restore all of the "component" *USRSPC objects, and of course,
after you
restore these objects (possibly on a different AS/400 machine), the original
"pointers"
would no longer be valid, because each of the *USRSPC objects would be
located at
a different virtual address anyway.  And, the code to convert between this
kind of
(segment, offset) notation and an actual MI pointer can be pretty efficient,
depending
on how you implement this in the programming language of your choice.

In OPM MI, you can create an array of pointers to spaces of 16 Mb each, and
when
addressing bytes within a space, you can handle the MCH0601 or equivalent
exceptions,
when you try to access beyond the end of a space, and have code that does
something
"appropriate", such as load a pointer to the "base" (beginning) of the next
*USRSPC,
and add an offset within that space object, etc.  Of course, this is not
quite as "easy" as
simply incrementing a pointer and marching through one "vast" teraspace.
However,
again, I must ask, what is it that you are doing that really requires such a
large space?

Also, if you were creating a compiler for a higher-level language, you could
do this
completely "under the covers" in the runtime routines and generated code,
and make it
appear totally "transparent" to the users of your "higher-level language";
the compiler just
emits the extra code where needed to convert between the (segment, offset)
format and
the "native" pointer format, whenever a pointer is picked up and used
(dereferenced).

And, consider the fact that many OS/400 "objects" at or above the MI layer
are actually
composed of one or more "spaces" (segments of up to 16 Mb each) below the MI
layer.
For example, a database "file" actually has at least 5 separate and distinct
components,
one containing the file description (fields, record layouts, etc.), one
containing the actual
data (for each member), one containing an "index" (for key-sequenced data),
etc.
So, this is really "no big deal".

Again, it all comes down to what is it that you want to do, that makes you
think that you
really "need" one very large, contiguously addressable sequence of bytes?

That's just my opinion.  And so, I don't think this is really all that much
of a "big deal".

Cheers,

Mark S. Waterbury


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---