×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Hi Joe
I seem to recall that in"Inside the AS/400" Frank Soltis claimed that a lot
of this came about because of the decision/design policy to make the system
API driven as opposed to allowing bare metal programming, particularly at
the application layer.
Frank also discusses the move to 32 bit operating systems in this book and
many of the problems and inability to leverage the new hardware could be
laid at the fact that at a basic intrinsic level these programs used
whatever number of registers (for example) were dictated by the hardware
and without actually rewriting the programs nothing could alter that fact.
Extend this simple example and it makes some sense as to why so many of
these programs will never reap the full benefit of the new hardware or be
as efficient as they might otherwise be, even if they manage to run. I
can't really claim to understand this at a deep level but it makes a lot of
sense.
The system/38 and the AS/400 insulated the hardware via the TIMI or SLIC
(If I get the name wrong it's not really that important - it just means I
haven't looked at the book to check) and therefore the details of the
hardware are not hardwired into any programs. Since there is no hard
dependency the binaries can be translated or simply start using am upgraded
API with all the resultant benefits.
Just another opinion on why it's better :)
Regards
Evan Harris
<SNIP>
Second, and less obvious, is that since they use the large pointers, you
never have to hear about application programs having to be converted to use
"the new 16-bit", or "32-bit" or now "64-bit" architecture. If Windows
moves to 64-bit pointers, that's a whole lot of application programs that
will need to change.
Other than stability and object-level security, you mean? See, you and I
have a different opinion on what makes the midrange successful. For me,
it's the fact that things are so encapsulated, including access to files and
programs. The single store memory mechanism is a significant part of that
encapsulation, in my opinion.
But hey, opinions are like - well, everyone's got one, anyway <grin>.
Joe
</SNIP>
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.
midrange.com
