|
>> 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.