RE: Where is IBM?

[Evan Harris <spanner@xxxxxxxxxx>]

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>