Features that separate the AS/400 from common computer systems

The AS/400 as a whole of Soft- and Hardware has a bunch of unique features as advertised by IBM:

• High Level Machine,
• Object Orientation,
• Single Level Storage,
• Hierarchy of Microprocessors,
• Operating System: OS/400.

These are nicely explained in the video linked below.

Reviewed in 2018, some are still relevant, some are no longer. Additionally, I'll highlight features which I think are unique compared to common platforms, and not listed above.

Split OS

OS/400 may be seen as split in half. An good deal of it (about 1 GiB with V4) is called System Licensed Internal Code (SLIC) and handles hardware dependent stuff. This includes features like multiple processors with dedicated memory just for I/O tasks.

Above the SLIC is the OS/400 and it's components System Administrators and Users usually see and deal with. This is called CPF, a leftover from the AS/400's ancestor, the System/38.

Byte Code

Compilers don't output CPU native byte code but kind of intermediate code, for example like Java does. This makes compiled programs surprisingly large in size but enables an unprecedented backwards compatibility on binary level.

Binary programs copied to a newer machine with different processor technology can just be started like on the old platform. The start will take a few moments in which the SLIC recognizes missing CPU native code, compiles the intermediate byte code and adds the result to the program object. After that, the program is started and runs as native code on a possibly completely different CPU architecture.

IBM exploited this possibility when they switched the hardware from a custom 48-Bit CISC CPU architecture to the PowerPC AS architecture in the mid-1990s.

Additionally, IBM made the 9401-P02 and P03, the so called portable AS/400, mostly for hands-on advertising of sales reps to CxO's in companies. They are said to have a stock INTeL 386 processor instead of the standard RISC CPUs of bigger machines.

Backwards Compatibility

IBM has a long history building platforms which span a multi-decade backward compatibility at binary level. The AS/400 is no exception. Programs compiled on earlier platforms and/or versions can be transferred to a newer machine and usually run without hassle.
Source code written with older releases of OS/400 usually compiles without any changes on newer platforms.

These features aren't of much interested on the first look. But it enables one to develop an application on an older system and run it on newer platforms. This could be seen as a base requirement for more free and Open Source Software: It's easier to acquire an older machine.

Unfortunately, transferring stuff from newer systems to older isn't that easy. The Savlib command writes stuff into a pre-created Save-File and records the release string of OS/400 where it was run. It is possible to set pre-set different values but the newer the utilized OS version, the newer the oldest possible compatibility level. V4R5 permits V3R2 as oldest release and select V4 releases.
Transfers from old to new systems are painless, though.

Single Level Storage

Since it's first incarnations the AS/400 creates a virtual 128 Bit address space for the OS layer and application programs. This comprises physical memory and hard disk space.

A hard disk may be seen as a giant memory area mmap'ed into the address space of upper layer OS components. Swapping and Paging isn't done on the application layer as most conventional systems do but on the address layer. Applications simply request contents from addresses and the layer below the OS called SLIC takes care of shuffling the data into RAM, should a page fault occur.

The advantage of this approach is the ability to do very fast context switches (if no or only a few page faults occur). This is the reason why even older machines with 100 % loaded CPU still have an astonishing fast response time when compared with common platforms of that era. If disk accesses are necessary for a context switch to take place, there's no notable speed difference to common platforms, though.

Running Application Programs: Activation and Activation Groups

Since programs are already existent as object in the address space, there's no need to load them from disk a common OS' need to do. To actually run such an application program needs some housekeeping, though. Commonly a program needs a Stack and a Heap for variables and other internal data structures to be able to run. The AS/400 is no different in this case, although this stuff is buried very deep into the OS's innards.

Actually starting a program to be run on an AS/400 is called activation. This task creates necessary storage as outlined above and adds the program to to the job scheduling queue. This is also necessary to provide a properly isolated environment when multiple users start the same application.

Completely different compared to common platforms, it's possible to share some of this space between programs. That is, while creating a new program (by compiling and linking), one can tell the compiler/linker if the program is to be run in

• the default activation group, which contains most of the OS,
• the caller's activation group, to allow a more dynamic approach, or
• a new activation group which is to be created for every instance the program has,
• a common activation group with a programmer specified name.

As long as any program of any activation group is activated, so is the activation group. Data structures will be destroyed only when the last program terminates, or the job ends.

Sharing an activation group shares (amongst other data):

• Static variables,
• Open files and file pointer positions,
• and more…

The difference between a common activation group and fork()ing an application on Linux/Unix platforms is not exactly the same but maybe it gives you an idea. On OS/400, programs to share an activation group must exist as separate objects while on Linux/Unix all code is either linked to a monolithic program or uses additional code with the aid of shared libraries.

Standardized UI

The whole UI revolves mainly around forms and menus, accompanied by static text. The layouts of these screens are somewhat standardized. AS/400 screens are very recognizable because of this.

See also: About Green Screens and mouse-clickable UIs.

Predictable Command Naming

For experienced users who won't repeatedly navigate though nested menus, commands may be entered on the command line instead of menu numbers. These commands consist of two or more parts, built of abbreviated english words. Abbreviations often take place by omitting vowels and shortening the result to less or equal four characters. The first one being a verb and the second one a subject, optionally followed by more building blocks.

A few examples may illustrate the previous statements:

wrksplf

Work with Spooled Files

chgmsgq

Change Message Queue Properties

crtdspf

Create Display File

dltf

Delete File

dspmsg

Display Messages (from Message Queue)

See also IBM i Control Language and CL Tricks.

Outstanding Reliability

Software is a complex thing built by humans. Humans make errors. Thus, Software contains errors. This is an inevitable fact.

IBM managed to make OS/400 not bug free but caught most problems which lead to a complete crash of the operating system. There may be edge cases which are usually hard to spot.

Also, IBM built multiple measures against defective sectors on hard disks being catastrophic into the OS from early on. Since there is no classical file system, most often, read errors only affect one or more objects which can be easily restored from backup.

Reliability is not the same as availability. Some tasks can only be done when OS/400 is running in a restricted state. This includes but is not limited to a full system backup or certain hardware failure recovery procedures.

Rapid Development

OS/400 comes with a set of tools and supportive facilities within the OS to ease development of application programs. Usually, development comprises of:

• Definition and creation of database tables, display forms and printer output,
• Writing code which references these files and shovels data just by issuing proper READ and WRITE (among other) requests to these files.

The mentioned files are typed in a format called Data Definition Specifications or DDS. It provides data field definitions, field definition references between files, arbitrary placement of static text (not for database files) and a multitude of flags for content to be shaped to fit for the desired presentation.
The Screen Design Agent program (strsda) provides a pseudo-WYSIWYG-interface for creating screen forms and menus.
The Report Layout Utility program (strrlu) provides a pseudo-WYSIWYG-interface for creating layouts for printer output files.

Actual programming can be done in RPG, COBOL, and C/C++. Output of the compilers (called modules) created by any of these languages can be linked together to create an actual program object or a shared library (service program). Any language may call functions of any other language as long as parameters have been defined to be compatible.

The compilable CL "shell"-script language and REXX-Interpreter help in easing traditional automation tasks on the command line level.

Programming is done within the Program Development Manager collection of programs (strpdm). The most used component is the Work with File Members application, wrkmbrpdm, to list source code physical file content. This in turn calls the Source Entry Utility (SEU) with the appropriate parameters for actual code writing/editing with the desired existing or new file member.

SEU provides a linetype-aware form for RPG and DDS, easing the matching of the appropriate columnns. It can be invoked as usual: With F4.

See also: How to program an Application

Weblinks

• IBM AS/400 The Best Architecture In The World 1992, Video at YouTube.
• About activation groups:
  • What you should know about activation groups, IT-Jungle.
  • Activation Group, discussion in NEWSboard (German Language).