|
I'm not an expert, but none of the things you mention seem to be limitations of SLS itself, rather limitations of the implementation of the OS. In other words, you could develop an OS without the limits you mentioned that used SLS. The problem is IBM, chose not to do it 30+ years ago and for capabilities sake hasn't changed. Charles Wilt iSeries Systems Administrator / Developer Mitsubishi Electric Automotive America ph: 513-573-4343 fax: 513-398-1121 > -----Original Message----- > From: Steve Richter [mailto:stephenrichter@xxxxxxxxx] > Sent: Tuesday, November 30, 2004 9:39 AM > To: Midrange Systems Technical Discussion > Subject: Re: Laymans explaination for single level store? > > > just to keep things in perspective, the SLS does have its > disadvantages. It is after all 30 years old! > > The 16 meg space size limit is a problem. Why should the APIs that > list to a user space have to include logic that cuts off the list > because of the size limit of a space? > > The object name limitation of 10 or 30 characters should not be. Long > symbolic names are very useful, esp for end users. > > The use of 16 byte pointers to address any object or byte on the > system is very elegant yes, but what is the "point"? Pointers to > system objects and pointers to data bytes are entirely different > animals. Why force them to share the same 16 byte structure? > Arguably pointers to system objects like programs and files should > always be stored as symbolic links, with long object names and the > ability to make that link a relative one ( search the library list ) > or an absolute link. A 16 byte system pointer has no place in a user > application. And my guess is that such pointers are a hassle in > system code also, what with their built in permanent authority to the > object pointed to. > > The aspect of the system that has stood the test of time, the ability > of a program to be automatically reassembled when the CPU instruction > set has changed, has nothing to do with SLS. > > The ability of the system to run code from 25 years ago is due in part > to the fact that the system has not been changed much in the last 25 > years! Introduce long file names, change the character size from 1 > byte to 2 or 4 byte unicode, allow libraries to contain sub libraries. > Enhancements like that would be great, but they would likely require > a source code recompile of programs. > > -Steve Richter > >
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.