Re: Explaining single level store to non i people

The System/38 was developed in the mid-to-late '70s, with First Customer Ship in the early '80s.

At that time, IBM was busy researching "bubble memory" and other similar technologies that held the promise for "solid state disks" -- so it certainly was not the case that IBM made "a plan based on some questionable technology that would not happen for ... 40 years" ... :-o

Instead, what happened was, the density of magnetic media (tape and disk) continued to increase at a fast enough pace, and so the storage capacity of disk and tape continued to increase, and in part, with higher density, came faster data transfer rates, so that those devices continued to evolve to be "fast enough" and "large enough" to meet the needs of most users. Also, the "bubble memory" technology did not "pan out" ... it was too slow and not "cost-effective" to be competitive. So, that was "shelved."
IBM continued this kind of research through the 1980s and 1990s, looking at alternatives. What did happen was, the price of real main storage (RAM) continued to decline, in terms of price per megabyte, so that it became possible to add "cache" memory to the IOPs and IOAs, to offset some of the inherent delays with the moving heads and rotating platters, etc. -- so that way, if the I/O controller could satisfy the request from the cache, that was much faster than having to move the heads and wait for the data to rotate around under those heads. Also, the total amounts and size of real main storage continued to increase, so that applications could "cache" their own application-specific data structures in memory to achieve higher performance.

To give this discussion of the "pros and cons" of single-level storage some additional historical perspective, you should consider that, at the time (mid 1970s) that the System/38 was first developed, the prevailing technology was the IBM mainframes (System/360 and System/370).

Mainframe customers had to worry about not only the total size and capacity of each DASD volume, but also the "geometry" of each drive. The capacity of each track was different for each model of DASD (2311, 2314, 3330, 3350, etc.) so that you would have to change the blocking factor (block size) for files when moving from one DASD device to another. This would often require changes to the application software, too.

Managing file allocation on the DASD volumes was a "part-time job" for someone at small-to-medium size installations (running DOS-VS or OS/VS1) and a "full-time job" for someone at most medium-to-large shops (running OS/VS2 SVS or MVS).

Single-level storage, as implemented by CPF on System/38 and OS/400 on AS/400, and i5/OS on POWER systems, eliminates these concerns. You just don't have to worry about it. And, you are almost never forced to change applications software, as a result of these kinds of changes.

With DOS/VS or OS/VS, whenever you made changes to programs, you had to link-edit them into a program library, either a "core image" library on DOS/VS, or a partitioned data set (PDS) on OS/VS, and this always caused the size of the library to expand. Eventually, you would have to "compress" these libraries. This required the applications to be "shut down" so the compress job could have "exclusive use" of those program library data sets for the duration of the compress operation. If you did not do this periodically, and just allowed the libraries to grow into "secondary extents", performance would suffer and gradually degrade (due to increased seek-times, etc.) SLS completely eliminates all of these concerns.

Also, in the 1970s, and into the 1980s, Unix systems were prone to various "crashes" that would leave the file system on disk in a corrupted or damaged state. The system administrator would first have to run "fsck" (file system checker) while the system was in a dedicated (single-user) mode, before restarting the multi-user Unix system. (This is somewhat analogous to having to compress program libraries in DOS/VS or OS/VS). It was not until the late '80s or in the 1990s before Unix reached a level of maturity where these kinds of episodes became "rare".

Nowadays, all modern Operating Systems support RAID and mirroring, etc. -- but IBM had it first -- System/38 CPF first introduced what was then called DASD "parity protection", in the 1980s, well before these ideas were implemented on any other hardware or software platform. Not even the vaunted IBM mainframes had this at that time.