|
I don't really know what is the answer - it's not my field, but I see no
reason why it could not be done.
My guess is that it was not deemed important enough.
I honestly do not see how *USRSPC limitation hurts me as an application
designer.
It's maybe an annoying limitation, but I can live with it - and live easily
at that.
For a specific situation:
> what about the list api's like quslobj?
> Will the usrspc always have enough room for all the list entries?
I understand your concern.
I guess this is a realm of personal preferences. I for one avoid large
result sets.
I feel something inherently wasteful to retrieve so much data at once.
There are very few cases when I want *all* available data. In most cases I
would want to subset, filter, etc - to find a way to limit amount of data.
But I agree that probably APIs should start returning data in teraspace
instead of *USRSPC.
However, this is just my personal opinion.
Alexei Pytel
"Steve
Richter" To: <MI400@midrange.com>
<srichter@Auto cc:
Coder.com> Subject: Re: why the 16meg space
size limit?
Sent by:
owner-mi400@mi
drange.com
05/21/2001
06:42 PM
Please respond
to MI400
>> can I turn the question back on you?
>> why was it so important for ibm to provide teraspace functionality?
>
>You are welcome ;-)
>Many applications want to have data structures during processing which are
>larger than 16MB (JVM, for example). With 16MB limit one has to split
these
>structures in smaller pieces, which is awkward. Teraspace solved this.
>Now if you want to store permanently vast amounts of data, you have (and
>always had!) several ways to do this.
>I've already mentioned database files and stream files.
>
>So I am back to my question - what is so special about *USRSPC object that
>you want it to be larger than 16MB ?
to answer your specific question, what about the list api's like quslobj?
Will the usrspc always have enough room for all the list entries?
It is basically a technical question re the system architecture. what are
its capabilities and limits. what can be expected from it going into the
future. are there components of it that make it a dead end or will it be
able to evolve to meet tomorrows computing needs.
The decision to provide teraspace functionality was a good opportunity to
expand the size limit of the space. This would have been a more seamless
solution than the teraspace. But ibm did not do it this way.
Do you agree that expanding the space size limit would have been a better
way to provide teraspace functionality?
I learned what I know of computers by listening to ibm reasons for why the
s/38 architecture was best. single level store, pointers with capability,
seamless migration to 64 bits, etc. An effectively unlimited limit? ( 1
gig ) to the size of a space, is in my opinion, a logical and usefull
extension of this design concept.
I welcome the back and forth on this subject, but the question is still a a
technical one. What does it take, or what prevents the space size limit
extension.
Steve Richter
+---
| 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
+---
+---
| 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
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.