Re: Where is IBM? -- MIDRANGE-L

Joe Pluta wrote:

There's nothing
really in RPG or COBOL that take advantage of the single level store
concept!


Well, yes and no.  First, the obvious benefit is that the operating system
automatically handles really large files without you having to do anything
about it.  In desktop operating environments, terabyte files require some
serious manipulation in your application, if for nothing else than because
you have to deal with them as multi-volume files.

Well, that's a red herring, isn't it? How many desktop systems really need to handle terabyte files locally? That's what mainframes are for! And there's no reason you can't access a terabyte database from a workstation using a protocol like ODBC.

In other words, managing the size and complexity of the database is the job of the database engine (such as DB2), and not the job of the application program. Large address spaces may make the implementation of a database engine easier, but is not essential.


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.

Less obvious since it's only an issue on upgrade. Also a red herring since Windows has never been a shining example of ease of upgrade.

Personally, I'm less impressed with the magnitude of N when discussing "N-bit architectures", if only for the fact that it seems to matter mainly in large monolithic system architectures. If a system is broken down into a distributed environment (as is common these days), it doesn't really seem to be that big an issue. Even iSeries and zSeries machines are commonly split into multiple partitions.

But yes, for legacy applications, if your pointers have to be large to begin with, it does make it easier to scale up applications to monolithic proportions. In other words, you pay a penalty in advance for the prospect of easier upgrades in the future.

Then again, if your application is written in an interpreted language like Python, then the word size doesn't matter at all. The porting of programs in such languages to different machines is very painless. (You *knew* I had to get a Python reference in somehow!)

What's my point in all this? Single level store is certainly an
interesting idea. But in my opinion, it's not really that
significant a factor in the success of the AS/400 and iSeries. And
because of it's heavy resource requirements, it may have been a
limiting factor, especially in the days of the S/38. But then who
knows where we would be today if the S/38 had been designed with a
more conventional architecture?

<laughing>

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.

My point is just that, based on my own experience within IBM, I think the quality of the AS/400 and iSeries can be explained by factors other than the single level store. For example, Rochester's strict project management regimen, and a zealous attitude towards testing.

Yes, single level store offers good stability and security. But you can (and do) get that in conventional architectures as well. You have to balance the advantages with the disadvantages, such as the cost of the higher resource requirements, to get the complete picture.

In other words, the technology is interesting in a theoretical sense. But in a practical sense, no one really cares why the iSeries is a good machine. What matters is that it is.

Cheers! Hans