What an AS/400 is, and why it resembles nothing else

An AS/400 is not a server with a different operating system on top. It is a machine designed around one precise idea: programs are not written for the processor that runs them.

The layer that hides the machine

Between the operating system and the metal sits the Licensed Internal Code, and above it an abstract interface, the Machine Interface (MI). A compiled program is made of instructions for that abstract machine. The real processor instructions are generated by the system when it creates the program, and IBM writes that they "can be changed over time to provide more efficient programs or to accommodate new hardware".

That is where the platform's reputation comes from: a program does not depend on the processor it was born on, and does not need rewriting when the hardware changes.

Memory and disk

The second pillar is called single-level storage: the machine manages main storage and disk with the same unit, the page, and a program works on objects, not on disk blocks.

From this follows something that surprises people arriving from other systems: you do not choose which disk a library goes on. The system spreads data across all the units of the set it belongs to, and does so by itself. When a disk is added, existing data can be redistributed with ASP balancing (capacity balance).

Sets of disks are called ASPs (Auxiliary Storage Pools), and they are the one place where anything is decided about where data lands. ASP 1 is the system one, where everything not placed elsewhere goes; alongside it there can be others, up to the independent ones, which in a cluster move from one machine to another. The kinds behave differently, and the difference matters enough to deserve the chapter that follows.

Everything is an object

On Unix, everything is a file. Here everything is an object, and every object has a type the system knows: a program is type *PGM, a file *FILE, a user profile *USRPRF, a print queue *OUTQ.

This is not a naming convention. Commands work on specific types, and the type decides what can be done with an object: a file is read and written, a program is called. The chapter on objects and libraries tells it in full.

The database is not a separate product

Db2 for i is integrated in the operating system: IBM describes it as "the relational database manager that is fully integrated on your system". It is not a separate product to buy and install.

A physical file created with DDS is a table you can query in SQL, with no conversion: IBM keeps a table of terms that says so plainly. The SQL table is the physical file, the row is the record, the view is the logical file, the schema is the library.

For a sysadmin this changes daily work. There are not two lists of users, one for the system and one for the database: authorities are those of the objects. And a great deal of system state is read in SQL, because the system exposes it as views and functions: that is why so many of the recipes on this site are queries.

What changes for whoever administers it

Almost nothing is configured at file level. Configuration lives in objects (subsystem descriptions, job descriptions, system values) changed with commands.

The system is verbose by nature. IBM messages live in message files, such as QCPFMSG, and every message has a first-level text and a second-level text with the cause and the recovery. People coming from other systems look for logs in a directory: here the record, the job log, is attached to the job that produced it.

Defaults need checking one by one. The system carries many of them across many releases, and each has a shipped value the system itself knows. Whether they suit a given machine is another question: "how it came from the factory" is not an answer to "is it configured well".

Example. A system value next to its shipped value, in SQL:

SELECT SYSTEM_VALUE_NAME, SYSTEM_VALUE, SHIPPED_DEFAULT_VALUE
  FROM QSYS2.SYSTEM_VALUE_INFO
 WHERE SYSTEM_VALUE_NAME = 'QSECURITY'

Sources

• IBM: Machine Interface Introduction ("Atomicity" paragraph)
• IBM: Analyze Object Conversion (ANZOBJCVN)
• IBM: Types of disk pools
• IBM: Working with ASP trace and ASP balance
• IBM: Database overview
• IBM: Terminology: SQL versus traditional file access
• IBM: Types of messages
• IBM: Add Message Description (ADDMSGD)
• IBM: SYSTEM_VALUE_INFO view