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 that 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 that 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. In later incarnations, there have been some restrictions regarding this feature, requiring applications compiled with obervability turned on.

Backwards Compatibility

IBM has a long history building platforms that 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 upper 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. Thus, page faults can occur also for data, not only for executables.

This concept also explains why the AS/400 platform lacks a conventional File System on it's disks. Since disks are essentially memory mapped into virtual memory space, everything visible is just an object at an address with certain properties. This allows to easily share these objects between requesting entities.

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 objects in the single level store memory space, there's no need to load them from disk as 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. This shared space is called an activation group. 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, that contains most of the OS,
• the caller's activation group, to allow a more dynamic approach, or
• a new activation group that 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, or when a group is explicitly deallocated with the RCLACTGRP program. For details see weblinks.

Sharing an activation group shares (amongst other data):

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

There's a certain intersection of functionality between a common activation group and fork()ing an application on Linux/Unix platforms. Even if it 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 that lead to a complete crash of the operating system. There may be edge cases that 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 that 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 that 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

Times they are a changin'

Today, development tasks are most often done on Windows PCs, with IBM provided tools, that pull a local copy of a source file to edit.

Also, since the late 1990's, IBM has been trying to establish Java as the language of choice, along with helper programs for shifting away from the old fashioned character based applications (green screen) to a pure web-browser based way of user's interaction with the system.

Also, the AS/400 Language, RPG, has been enhanced and modernised slowly but constantly. While most examples in this collection of knowledge are based on ILE RPG IV, newer OS releases were accompanied by compilers allowing to escape the punched card appeal of RPG more and more. V5 introduced the possibility to write actual code (not definition statements, though) in a free form, while with some V7 all parts of a RPG program may be written without being forced to write statements at a certain position within a line. This generates a load of syntactical changes to be learned.

Examples of positional code are slowly vanishing from Internet Websites. Looking up how to do stuff in positional code is getting increasingly difficult. Asking around in mailing lists for positional code examples sometimes yield unhelpful and cynic comments.
Still, many companies have old to very old code to be maintained that predates compilers allowing free syntax. Providing mainly positional RPG examples is supposed to help understanding this old way of writing RPG, while examples for newer techniques are easily found with an internet search engine of choice.

Weblinks

• IBM AS/400 The Best Architecture In The World 1992, Video at YouTube.
• Introduction to ILE RPG Activation Groups, McPress online.
• i5/OS V6R1: Upgrade Now or Later? with some background information regarding code observability