teraspace, user spaces, etc. -- MI400


Interesting discussions about teraspace and related topics. Hopefully I can
contribute, for those willing to tolerate a long note. :-)

The Machine Interface (MI) architecture that serves as the cornerstone for
iSeries systems (and System/38 and AS/400 systems before them) was designed
as a high level abstraction to enable drastic implementation changes to be
made in an upwardly compatible manner. Thus implementation of a given MI
function can be changed over time to take advantage of new hardware
features, e.g.. Perhaps the high level of abstraction is frustrating for
those who want to know the underlying details, but such abstraction is
required for adaptability. Giving out details below the published level of
abstraction would make change much more difficult, because then
dependencies on one particular implementation could be developed. The
ability to adapt, which the iSeries family of systems have spectacularly
demonstrated over time, aids system longevity and that's good for all of us
who develop, sell, buy or use it.

Single level store (SLS) is a key concept embedded within MI. One of its
hallmarks is the persistent mapping between address ranges and objects that
provides a very efficient object identification and location mechanism. The
use of such a persistent mapping requires lots of object addresses. Current
hardware has 64-bit addresses, from which all object addresses must come,
for the life (between full installs, at least) of a particular machine.
Competitive processors are very costly to design and build. While current
generations of 64-bit hardware are in use, permanent user spaces are likely
to retain their 16 MB limitation. Could iSeries systems someday move to
hardware that supplies a larger address, much like the transistion from
IMPI (48 bit) to RISC (64 bit)? Certainly, and even more easily than that
previous transition.  Then both the maximum number of objects and size of
objects could expand to use the larger address space. However, no
compelling need exists now that would justify the development cost and
resulting expense for system buyers.

Teraspace was merged with SLS to satisfy the needs of several different
programming paradigms. With more programming paradigms, it is easier to
entice application providers to supply applications. In part, the more
applications a system supports, the more useful it is and so the more
likely it is to be purchased. Teraspace greatly expands the maximum
contiguous addressing range, and in V5R1, allows use of untagged 8-byte
pointers and supports file mapping. It fills the bill for classes of data
that are inherently scoped to one process (job) and needed only while
threads within the process are active. In my humble but clearly biased
opinion, the addition of teraspace was quite seamless, given the  desire to
preserve the utility of customer programs created before teraspace was even
initially proposed and the limits of time for its first release. For
example, most interfaces that accept a space pointer can handle a pointer
to any space, including teraspace.

However, it's true that some APIs that accept the name of a user space do
not use teraspace, because teraspaces are not named objects. Instead, like
the other spaces that can be used to supply automatic and static storage
for running programs, teraspace is affiliated with the type of MI system
object used to define a process. Since its introduction in V4R4 teraspace
integration has improved. A reasonable bet is that it will continue to do
so, though I can't promise what I don't control. IBM development labs don't
decide their own funding levels. So, when improvements take longer than
you'd hoped, frequently the underlying reason is that there are other
enhancements being added first, within the funding level provided by the
company.

"Rochester people think IBM knows what's best for you." Perhaps it seems
that way at times, but I find little, if any, evidence of that attitude
among the people I work with. Far from dictating what is best for
customers, a strong theme present throughout my many years of work here has
been to try very hard to provide what customers need.

Paul Godtland (speaking only for me)
Teraspace, etc. development; Rochester, MN

+---
| 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
+---