AS400 Operating System Introduction

So what makes the AS/400 Operating System so special?

The AS400 Operating System is one of the most modern Operating Systems in wide spread use today. I was at an interesting talk given by Doctor Frank Soltis the chief designer for the IBM AS/400 and the IBM System 38 that came before it. He explained that Windows can trace it’s roots back via Windows NT to VAX VMS, Unix, Linux and OSX can trace their roots back into the late 60’s. In comparison OS/400 or CPF (Control Program Function) as it was known on the System/38 was designed the ground up in the 1980’s.

In current terms OS/400 has more in common with the Java Virtual Machine (JVM) than operating systems like Windows. OS/400 has a machine independent layer that sits between it and the underlying processors and hardware. Over the years the processors have changed many times, for example from CISC to RISC whilst marinating software compatibility. Software first compiled in the 1980’s on long forgotten hardware can still be run on the latest hardware today without being recompiled.

In addition to the Technology Independence Layer, OS/400 also features something called Single Level Storage. In computer software the most expensive operation is the Branch operation. This is where the processor switches from one task to another. OS/400 handles this by having a single continuous 128 bit address range. This covers all the physical memory and disk storage. The Operating System then uses heretical storage management to move the most frequently used content into the fastest memory in the Single Level Storage. These days this will range from slow mass storage drives, SANS, fast drives, SSD’s to RAM.

OS/400 is not a truly Object Orientated Operating System in the current sense (i.e. inheritance and polymorphism) but it is Object Based and very much embraces Encapsulation. Being Object Based literally everything on the system is an Object. Each object has a set of interfaces and can only be accessed through those interfaces. This has made the platform incredible secure as most of the memory overrun and buffer attacks that hackers exploit on other platforms are not possible.

The other interesting thing about OS/400 is that it has a built in database. These days it’s called DB/2 and shares much of the DB/2 technology from other platforms. OS/400 uses this built in database for many of it’s own storage requirements. DB/2 on iSeries leverages the Single Level storage to be highly reliable and low maintenance. Unlike on other platforms the AS/400 will run for years without any operator or DBA (Database Administrator) assistance. For example I’m aware of several companies in the UK where AS/400 applications run for years on end with little to no operations support. I’d contrast this with Microsoft SQL Server based applications where performance degrades if not given regular attention. IBM S/38 was the first commercial computer to implement a Relational Database using SQL. This took the conceptual work from Ted Codd at IBM and implemented it for real in the S/38. At the time the S/38 CPF Operating System was ahead of the processing power really available for this type of processing. It was slow but successfully proved the vision of a Relational Database based on SQL. IBM had invested everything in the development of the S/38 and continued this investment as they improved the processors, hardware and Operating System and relaunched it in the 1990’s as AS/400.

The AS/400 as a whole is often perceived to be out of date (by people who don’t know better) because it still runs many Green Screen or Character based applications on dumb terminals or terminal emulation. From a systems architecture perspective this is no more relevant than say the console interface on Mac OS (OSX) or the Terminal Interface on Windows. These days most modern applications are browser based and the users would never know that the backend is running on OS/400.

For anyone studying Systems Architecture or Computer Science OS/400 is something you really must study to get an alternative view of how well a fully integrated, single vendor system can work on an enterprise scale. Few doubt this today on the desktop or iPhone when they look at Apple products.

How to find out what version of OS/400, AS/400 (IBM iSeries / IBM i) Operating System you have installed.

There may be more than one way of doing this but this is how I would do it….

From a command line type DSPJOB OUTPUT(*PRINT) and press ENTER. This will create a spool file containing information about your current interactive job. At the top of almost every AS/400 Operating System report like the one generated by the DSPJOB command you will find the Operating System Version. For example:

In the above example the second block of characters on the top line of the spool file is the version of OS/400 currently installed. In this case V5R4M0 which means Version 5 Release 4 Modification level 0 commonly known as OS/400 5.4.

Updated Feb 20th 2015:

Thanks to Jose for leaving a comment below pointing out that the DSPPTF (Display Program Temporary Fix) command is probably the best way to find the version of IBM i / AS400 operating system you have installed. The original method shown above will work with minimal access rights but if you have access to the DSPPTF command then best to use this instead. In the example shown below the machine is running OS/400 Version 7 Release 1 Modification Level 0.

How to find what Tech Refresh (TR) is installed?

It is worth noting that from OS/400 7.1 IBM decided to increase the frequency between actual OS point upgrades e.g. from 7.1 to 7.2 as these can be costly and disruptive to perform. At the same time IBM wanted to be able to accelerate the pace at which new features are added to OS/400. So from 7.1 IBM have now added the concept of “Tech Refreshes” (TR). In other words not all 7.1 and 7.2 systems are equal you now need to know the OS/400 version AND the TR level to know if a particular feature is available.

To do this you use the command DSPPTF 5770999 and then page through and look for the highest PTF starting MF99… For example:

This system has OS/400 7.1 Tech Refresh (TR) 9 installed, and you can see below it that TR8, 7, 6, 5, 4 etc were previously installed.

iSeries SQL failing to use an existing index.

Why would a perfectly good SQL based application which has been running well for years suddenly start to run slowly?

It’s easy for us iSeries users to forget about database administration because the OS/400 or i5/OS does such a good job of managing this for us.

From time to time an AS/400 (for that is still what I like to call it) logical file (index) can become invalidated. This typically happens if a job is using it when the subsystem goes down for some reason.

Doing a little research what I’ve found is that if an RPG program with the table specified on an F Spec tries to opens a damaged logical it triggers the system to rebuild the logical during the file open. This isn’t the case when you run an SQL statement. The SQL processor only considers currently valid access paths when it builds its access plan, therefore skipping damaged logical (indexes).

In my case, this was causing the SQL processor to drop back to a full table scan rather than an indexed lookup. This changed the usual runtime of the SQL statement from less than a second to several minutes.

Using OpsNav and the Visual Explain tool you can view the SQL statement and see exactly what it’s doing but it may still not be obvious why it didn’t use the logical view that you know exists.

The tip is to have your System Operator run the EDTRBDAP (Edit Rebuild of Access Paths) command which will list any damaged access paths. The system gives you an estimated time for the fix which so far we’ve found to be quite accurate. It’s best probably to plan to fix the access path out of normal operational hours. This screen does get displayed during an attended IPL but most SysOps I’ve spoken to say they were taught to just press Enter – because the system will sort the problem out later – which is obviously no longer true if you’re using SQL.