Features that separate the AS/400 from common computer systems

From Try-AS/400
Revision as of 18:19, 31 December 2018 by PoC (talk | contribs) (Cat)
Jump to navigation Jump to search

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 relevant, some are no longer. Additionally, I'll highlight features which I think are unique compared to other platforms.

Split OS

OS/400 may be seen as split in half.[1] An good deal of it (about 1 GB) 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.[2]

Above the SLIC is the OS/400 and it's components System Administrators and Users usually see and deal with.

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.[3]

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

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, hard disk space, and virtual memory as well.
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 more common platforms of that era.

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.

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.[5] This includes but is not limited to a full system backup or certain hardware failure recovery procedures.

Weblinks

Footnotes

  1. Not necessarily even halves.
  2. This may be seen as a technical borrowing from the mainframe world within IBM. This technique is called Channel there.
  3. IBM exploited this facility to a great extent on the 9401-P01, a portable AS/400 (probably only for marketing purposes). This machine had an INTeL 80386-based main CPU.
  4. Derived from the CPUs in IBM Mainframes of the 1980s era.
  5. In Unix this would be called Single User Mode, with not much more than init and a root-shell running.