Single-level storage |
 |
By Ken Graap, Search400.com expert
23 Oct 2001 | Search400.com |
|
|
Application programs on an iSeries or AS/400e server are unaware of the
underlying hardware characteristics, because of the iSeries Layer (or TIMI)
(Technology Independent Machine Interface). Applications are also unaware of
the characteristics of any storage devices on the system because of single-level storage.
As with TIMI, the concept of single-level storage means that the knowledge
of the underlying characteristics of hardware devices (in this case, main
storage and disk storage) reside in the SLIC. All of the storage is
automatically managed by the system. No user intervention is ever needed to
take full advantage of any storage technology. Programs work with objects.
Objects are accessed by name, not by address.
The iSeries and AS/400e server address size is vast. iSeries and AS/400e
models can address the number of bytes that 64 bits allows it to address.
The value 264 is equal to 18,446,744,073,709,551,616. Therefore, the iSeries
and AS/400e models can address 18,446,744,073,709,551,616 bytes, or 18.4
quintillion bytes. To put this into more meaningful terms, it is twice the
number of millimeters in a light year. Light travels at approximately 6,000,000,000,000 miles in one year.
Single-level storage also enables another extremely important iSeries and
AS/400e benefit, object persistence. Object persistence means that the
object continues to exist in single-level storage (unless purposely deleted
by the customer). Memory access is extremely fast. A customary machine requires that information be stored in a separate file system if the information is to be shared or retained for a long time.
Persistence of objects is extremely important for future support of
object-oriented databases for data accessibility and recovery. Objects
continue to exist even after their creator goes away. The iSeries and
AS/400e models are uniquely positioned to exploit this characteristic of
object persistence, where customary systems use a less-elegant mechanism
that requires them to store their persistent objects in a separate file system, with all the attendant performance implications.
|
|
|
|
