New to the AS/400

By Jack J. Woehr

The IBM AS/400 is a fascinating machine. Its OS/400 operating system provides a rich computing environment. If you are new to the AS/400, or aren't sure why it might interest you, I hope after you read on you will be intrigued and take a look for yourself, perhaps on one of the timeshare systems ... some even offer the first month free of charge.

The AS/400 is a scalable database engine. From a marketing perspective, the IBM Advanced System/400 is the current IBM midrange offering. It is the present-day successor in the lineage stretching back to the 1970s which goes, roughly:

1. Series/1
2. System/34
3. System/36
4. System/38
5. AS/400

IBM, HP, Sun Microsystems and other vendors offer Unix boxes that fill roughly the same niche as the AS/400 in power and networkability, but there is a crucial difference between Unix boxes and the AS/400, and that is the AS/400 operating system: OS/400.

The OS/400 Virtual Machine

OS/400 is more than an operating system. It's effectively a virtual machine, although there is no runtime engine: translation occurs at compile time. Although the AS/400 originally was based on a 48-bit custom CISC processor, the AS/400's current multiple CPUs are in the same RISC-6000 family as the processors that power IBM's RS600-AIX offerings. From the user's point of view, when the switchover between processors occurred there was no difference in the environment, aside from increased speed. This is because high-level language source code compiles into a highly optimized metaformat which carries the virtual machine format, allowing automatic recompilation of the object when transferred to a different OS/400 execution platform.. When users migrated their CISC applications to the RISC boxes, the first time the migrated application image was loaded OS/400 translated the optimized metaformat to the new machine image and wrote the translated image back to disk.

It comes as no surprise that Java runs on the OS/400 as a sort of parallel virtual machine running near the same layer as OS/400 itself, yet integrated with OS/400 so as to exploit OS/400 system services and be subject to the latter's security restraints.

OS/400 is not, however, a bytecode engine like Java. There were few external constraints of portability applied to this proprietary system, so the metaformat is machine-oriented well beyond strategies available to portability-committed Java bytecode. There is even an OS/400 command called CRTJVAPGM - Create Java Program - which takes a Java class file and recompiles it as essentially native OS/400 code, writing it back into the class file or elsewhere as desired.

None of the above is startlingly different from a Unix system. To really appreciate the difference between OS/400 and Unix we must look at OS/400's file system(s) and OS/400's work management.

The Integrated File System (IFS) and the Object File System (OFS)

OS/400 has a hierarchical directory-oriented file system, called root (a Unix-like / directory hiearchy) with a case-sensitive parallel view called QOpenSys for POSIX applications. However, in daily OS/400 programming, you're working in the OFS and dealing with record-based files. Stream files exist in the POSIX-compliant QOpenSys file system, but you generally don't use stream files for AS/400 systems programming. Stream files under OS/400 are used by Java, by web servers, for workstation-oriented documents, for compiling POSIX utilities such as gcc and perl, and for general storage.

There are many types of objects under OFS, but the objects that contribute to the hierarchy that most of us recognize as a file system are the following:

• Libraries
• Files
• Members

QSYS is a library object that contains all library objects. QSYS is the only library that contains other libraries. QSYS even contains itself. It also contains the library that implements the Integrated File System. All other OFS objects are either objects within the QSYS library, or are contained within the library objects contained within QSYS.

Libraries contain other objects, such as program objects, command objects, and especially file objects. A file is record-based, essentially with one record format throughout. It can have multiple members, but all members share the record description of the file itself. Each member can have multiple records, up to system or allocation limits.

Not only business data, but source code itself is stored in this type of record-based file. A source physical file is a file with a record format of 92 characters composed of three fields:

• CHAR[6] for sequencing,
• CHAR[80] for program text,
• CHAR[6] for line modification date.

• C - C program source
• CL - OS/400 Command Language program source
• REXX - Rexx program source
• RPG - RPG program source

For example, if I have a library called JAXSOURCE with a file MYCPROGS and a member HELLO of type C, I can refer to my OS/400 hello.c program as

JAXSOURCE/MYCPROGS.HELLO

/qsys.lib/jaxsource.lib/mycprogs.file/hello.mbr

An interesting facet of this duality is the 'namefmt' site command when FTP-ing to an AS/400.

ftp> quote site namefmt 0

ftp> quote site namefmt 1

The other big difference from Unix is work management. OS/400 is essentially a runtime environment for batch jobs. To OS/400, an interactive session is essentially an unusually inefficient and resource-consuming batch job. Multiple user-defined subsystems with their own job queues, priority management and private memory pools divide up the work in an entirely user-customizable fashion. Jobs may be routed from step to step and from subsystem to subsystem. This high level of granularity of work management control is necessary in enterprise computers, where workloads must be tightly tuned and finely integrated so that accounting departments can complete the daily close before start of business the next day.

OS/400 Databasing

HMNRSC/EMPL
HMNRSC/SSEC
HMNRSC/BNFPLN

PAYROL/HOURS

PROD/EMPHRS

In this entirely flat database file space (all File objects being at the same level) the programmer's field of vision is cleared to perceive data relations as the sole available augmentation of dimensional depth.

Data access methods include RPG, C APIs, SQL, REXX SQL, remote SQL, ODBC/JDBC, and more. SQL CREATE COLLECTION creates a new library and does some journaling in system libraries, thereby mapping SQL to OFS.

Sublime, isn't it? The AS/400 is a scalable database engine that can service both batches and from one to thousands of interactive sessions. And no talking paperclips.

Integrating Old and New Ideas

The OS/400 command environment ranges from the native menu-plus-line-input screen-oriented 5250 terminal session to remote GUI sessions provided by various integration tools. Programs don't write streams to stdout; they write records to a display file. OS/400 commands are highly structured formal entities and can prompt the user for each parameter individually. Command names are up to ten characters in length and employ an easy, consistent naming system. Once you get the "Zen of" OS/400 command naming conventions, you tend to guess the name of the command you want, even if you have never used it before. OS/400 probably offers the most sophisticated character-mode interface ever deployed in a major operating system.

The original environment for OS/400 OFS database programming was entirely RPG with OS/400 CL (Command Language) to bind procedures together. CL looks somewhat like the klunky old EXEC2 language from VM, but is actually very cleverly designed and constrained for easy reading of source and utter disambiguity of expression.

The AS/400 has had Rexx , COBOL and C for a long time; BASIC and PASCAL were there but are now gone. Now C++ with embedded SQL is common on the platform. OS/400 C/C++ programming is well-integrated with both OFS and the two main OS/400 stream file systems. The AS/400 is also well suited for Java development, complete with Remote AWT, which lets you assign a workstation display as the AWT display for an application running native on the server. Don't miss IBM's mostly-open-source JTOpen Java Toolkit for the AS/400 which is a bag of Beans that is delightful to use for native or remote client Java programming.

Networking and Security

Parenthetically, let me point out that SNA networking is a gas; you should also take a quick peek at SNA before it mostly fades from the scene. IPv4 didn't come close to SNA in sophistication, though IPv6 has probably surpassed it. Some open source AS/400 types have even ported SNA to Linux.

The security policy is very flexible on the AS/400, ranging from screen-door-on-a-submarine to totally fascist. As these machines tend to be used as billing machines, back-end point-of-sale, and for financial applications, you can believe that there is one heck of an audit trail. Permission permutation is fairly fine-grained and security exits are ubiquitous. An astute system operator can maintain a much tighter ship than on a Unix box, by design.

See for Yourself

Some selected AS/400 Web resources are listed on my Jax RCFB IBM AS/400 Page. These resources include links to documentation, tools, free source code and timeshare accounts for OS/400 application development.