% fortune -ae paul murphy

From Chapter Two: The appliance computing culture

This is the 19th excerpt from the second book in the Defen series: BIT: Business Information Technology: Foundations, Infrastructure, and Culture

Note that the section this is taken from, on the evolution of appliance computing, includes numerous illustrations and note tables omitted here.

The iSeries

The System 38 lineup was an enormous technical success that hardly anyone recognized and IBM sold relatively few units until it was revised and re-released as the AS/400 in 1988. What made it such a technical success was the fact that it was designed, from the ground up, to act as a highly reliable interactive processor.

Unfortunately, the database driven interactive applications model was also why the original System 38 sold slowly. People, particularly those with data processing experience and thus most likely to influence purchase decisions, either saw it as a threat or simply failed to understand it.

IBM addressed its buyers in the older mini-computer market four years later (1982) when it released the System 36, a follow-on to the System 34 and not technically related to the System 38. Its operating system, SSP, included a KSAM (keyed sequential access) database, a much smaller maximum memory configuration, and no ability to handle floating point. Combined with mandatory block mode terminals, the high end of this series overlapped the System 38 on cost, but had nearly an order of magnitude lower performance -and promptly became a ran-away best seller for IBM in large part because most potential customers had an easy time understanding it.

IBM signaled that it had become less conflicted over this in 1988 when changes to the original System 38, made under the leadership of Frank Soltis at IBM's Rochester, Minnesota facility, cemented its technical lead over its competitors and IBM offered it under a new name - the Advanced Server 400 - as a replacement for both the System 36 and System 38 lines.

This was stealth technology at its best - IBM simply didn't tell anyone about the machine's strength; launching, instead, a massive advertising campaign built around its new name and only those who looked long and carefully "under the hood" saw either the relationship to the 1972 prototype or improvements like the potential 64 bit memory space, the isolation of hardware computing technology from operating software, and the ability to incorporate other processors in the box.

Serialization? ate wheatiess did it?
One of the major problems involved in providing concurrent user access to data is deciding the order and dominance of updates.

Suppose two people try to update the same record - which one succeeds? If one person tries to read the data while someone else is changing it, what should the database system do: forward the original value or make the reader wait for the update and then forward the latest data?

The answer to this is a combination of strict serialization with data locks. Serialization is a first come, first served kind of thing;. if two people write the same record, the second one over-writes the first.

Locks mean that if an application needs to update a record (change it) the database software will first lock the table (or rows), then do the update, then unlock the table (or rows). This helps with proper serialization and reduces usage error, but is not as simple to implement as it first looks. In fact, lock management and granularity are subjects of significant research in the database community today.

In the multi-user interactive environment, moving data management and serialization to a database tool which programmers could use but not change, enormously simplified application development while contributing significantly to systems stability.

The biggest technical advantage the System 38 and its successors had over other gear came from its applications model. On other systems, like VAXes, database technology was an add-in (although VMS did contain a KSAM product with a relational overlay: RDB) which application developers could choose to use or ignore.

That had both direct and indirect effects. On the direct side, availability invited use, thus almost all native System 38 applications took immediate advantage of the microcode database and were, therefore, usually both considerably simpler and faster than comparable applications developed for other machine environments.

The indirect effect was, in the long run, even more important. Because the fundamental focus of the machine was database services, it made no sense to license the database separately from the hardware. From the beginning, therefore, System 38 buyers got complete working systems with all necessary tools as part of the basic package and didn't need to get involved in the complexities of choosing, and then integrating, multiple third party tools.

CPF, predecessor to OS/400, handled all key database administrative functions including memory allocation, backup, recovery, and file definition while the database handled serialization. That too simplified both programming and operational administration to produce an enormously more productive system.

Why would a faster CPU be slower?
In 1988, when IBM revised the hardware to change from the integrated CPU board it had started with to the PowerPC architecture, it externalized the database to compiled code - with the odd result that the machine became slower for those applications which used the microcode correctly even while the CPU became much faster.

The database provided with the System 38 had two significant advantages over IMS and related competitors:

  1. It ran in microcode and was, therefore, extremely fast -enabling database reads and writes as single step machine instructions; and,

  2. It was fully relational in structure.

At the time Dr. Codd first applied the term "relational" to the database ideas he was developing, the IMS/IDMS database pair had not yet become commercially successful and "entity-relationship" diagramming did not exist. Thus he had no reason to see his use of the term "relational" as a problem, and used it because it accurately reflected his application of set theory, known as the theory of relations in British English and the more pretentious US textbooks, to data management.

By 1979, however, most data processing professionals had at least some familiarity with entity-relationship diagrams and the parent-child relationships embedded in both hierarchal and network database products. They were sure they knew, therefore, just what a relational database was and, in most cases. proceeded to treat CPF/DBF as a kind of incomplete CICS/IMS.

The resulting confusion had the predictable result that most of their projects failed to deliver according to planned budgets, time lines, and functionality - leading them to then denigrate the System 38 as a difficult and unreliable environment.

A few developers, however, had people who didn't start from a CICS/IMS background and used the microcode database very effectively to fill market niches the 360 hadn't yet reached - in particular the mid size warehousing and distribution center. Here the cachet of the IBM name rapidly gained the machine a foothold and its solid performance as a database machine made first the System 38, and then the AS/400, the distribution industry's system of choice.

Some notes:

  1. These excerpts don't (usually) include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

  2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.

    Notice that getting the facts right is particularly important for BIT - and that the length of the thing plus the complexity of the terminology and ideas introduced suggest that any explanatory anecdotes anyone may want to contribute could be valuable.

  3. When I make changes suggested in the comments, I make those changes only in the original, not in the excerpts reproduced here.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.