An AS/400 is not a server with a different operating system on top. It is a machine designed around an idea nobody else followed: the operating system does not know the hardware.
The layer that hides the machine
Between the operating system and the metal sits a layer called SLIC (System Licensed Internal Code), and above it an abstract interface, the Machine Interface. When you compile a program, the result is not code for a particular processor: it is code for that abstract machine. Translation into real instructions happens underneath, and is no concern of whoever wrote the program.
The practical consequence is the one the platform is known for: a program compiled in the nineties runs on a current Power system, with processors that did not exist back then. This is not emulation, and there is no virtual machine in between. The program simply never knew what it was running on.
Warning
compatibility is not absolute. Moving to release 6.1 required program objects to be converted to the new format, and conversion needs either the source or the observability — the translation information kept inside the object. A program compiled on a very old release, whose source nobody has any more and whose observability somebody stripped to save space, cannot be carried forward. These cases are rare, and when they happen they hold up an upgrade for months.
Memory and disk are the same thing
The second pillar is called single-level storage. A program does not ask "read this block from disk": it addresses an object, and the system decides whether that object is already in memory or has to be brought in. There is no notion of an open file with a disk position the program has to manage.
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 every unit in the pool the data belongs to, and it does so by itself. Adding a disk does not require moving anything by hand.
Sets of disks are called ASPs (Auxiliary Storage Pools), and they are the one place where anything is decided about where data physically 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 detach from one machine and attach to another. The three 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
declared type the system knows and enforces: a program is type *PGM, a file *FILE, a
user profile *USRPRF, a print queue *OUTQ.
This is not a naming convention. The system knows what can be done to an object from its type, and refuses the rest. A data file cannot be executed — not because a permission is missing, but because the operation does not exist for that type. This is a large part of why the platform has a different security history from other systems: many classes of attack assume you can pass off as code something that was written as data, and here that boundary is in the architecture rather than in a check that can be worked around.
The database is not an installed product
Db2 for i is inside the operating system. Nothing to install, nothing to start, no process to watch. A physical file created with DDS thirty years ago is a table you can query in SQL today, with no conversion: they are the same thing seen through two interfaces.
For a sysadmin this changes daily work more than it sounds. There is no database to keep in step with the operating system, no second list of users, and no such thing as "who administers the database" as a separate role. Conversely: a great deal of system state is read in SQL, because the system exposes it as views. That is why so many of the recipes on this site are queries.
What changes for whoever administers it
Three things, worth fixing in mind before going on.
Almost nothing is configured at file level. There is no /etc to edit. Configuration
lives in objects — subsystem descriptions, job descriptions, system values — changed with
commands and validated by the system at the moment you touch them.
The system is verbose by nature. Every job leaves a record, every error has a code, and the code has a two-level explanation you can read on the spot. People coming from other systems look for logs in a directory: here the record is attached to the job that produced it.
The defaults are old. Many initial choices date from the eighties and stayed for compatibility. That is not a flaw, but it does mean "how it came from the factory" is never an answer to "is it configured well".
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up