RE: 64-bit

I don't foresee the 16meg segment limit changing soon. That'd be a
gargantuan task, and on the iSeries, we lowly HLL developers never need to
worry about Storage Management requests.

OTOH, teraspace uses full 8-byte pointers, not the system and space
pointers of single-level store. The potential exists, surely, for larger
structures. It seems like teraspace is another abstraction layer over the
existing storage management scheme.

But then, I'm not privy to those plans.

At 09:00 PM 3/21/02 -0500, you wrote:
>The very real advantage to >64 bits is that the 16meg size limit on a space
>can be increased.
>
>Currently the 8 byte address is divided as a 5 byte segment number and a 3
>byte offset. If 128 bits, the division could be 8 byte segment and 8 byte
>offset. It is the offset that limits the size of the segment/space.
>
>Many ask "why do you need a larger than 16meg space" ?.   One function is
>the saving of the state of a program.  Copy the the allocated memory of a
>job to disk, shut down the job, then at a later time, start another job back
>up, copy the state of the original job to the new job, and resume running.
>Makes a nice debug feature.
>
>Doing this with 16meg segments is tough because the segments of the renewed
>state job will have different segment addresses ( the 5 byte segment
>number ) and pointers that were valid in the original job will no longer be
>so.
>
>The same reasoning applies to saving a large pgm data structure to a perm
>disk object and restoring it later for use by another job.
>
>
>Steve Richter
>
>-----Original Message-----
>From: midrange-l-admin@midrange.com
>[mailto:midrange-l-admin@midrange.com]On Behalf Of Raikov, Lo
>Sent: Thursday, March 21, 2002 8:43 PM
>To: 'midrange-l@midrange.com'
>Subject: RE: 64-bit
>
>
>I'd say imagination is irrelevant here. I (you) can surely imagine a lot,
>but until we are given a comprehensive set of tools (APIs, functions,
>methods) to navigate the 64-bit space, we (I agree on this point) are doomed
>to stay 16-bit animals dreaming of the open spaces but gravitationally
>chained to the mother Earth. With 3rd generation languages we most
>definitely are.
>
>Lo
>
>-----Original Message-----
>From: Leif Svalgaard [mailto:leif@leif.org]
>Sent: 22 ????? 2002 ?. 12:30
>To: midrange-l@midrange.com
>Subject: Re: 64-bit
>
>
>From: Raikov, Lo <Lo.Raikov@MISYS.COM>
> > even if you are given a chance to explore 64-bit data space, what can you
> > meaningfully do with it? Low-level tweaking (e.g. sort) does not really
> > count.
> >
>
>address space is like money and sex, you can't get too much.
>Our (your?) imagination what you can  do is still 16-bit.
>
>
>_______________________________________________
>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.
>_______________________________________________
>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.
>
>
>_______________________________________________
>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.