The Four Hundred--The Mysteries of i5/OS V5R3M5 and V5R4

Newsletters

Subscriptions

Forums

Store

Career

Media Kit

About Us

Contact

Home

Volume 14, Number 35 -- September 6, 2005

The Mysteries of i5/OS V5R3M5 and V5R4

by Timothy Prickett Morgan

The only way to keep a secret in this world is to not tell another living soul whatever it is you don't want the world to know--and then make sure you don't talk in your sleep. So it comes as no surprise that information concerning the future releases of i5/OS is starting to be processed by the rumor mill in the wake of a presentation that IBM gave to around 100 beta customers in early August.

While we are accustomed to talking about the OS/400 or the i5/OS operating system, what we call the operating system--the green screens or the new graphical screens that provide access to the functions of the system software and OS/400 kernel--is not really the operating system at all. OS/400 has always been a layered environment, and different enhancements get made to different layers of the OS/400 software stack. This is one of the reasons why I think there has been some confusion about the upcoming release of i5/OS, which is due in the first quarter of 2006. Before I get into the expected features coming in i5/OS V5R4, which this release will apparently be called, it is probably a good idea to review the different layers in OS/400 and i5/OS so this makes some sense.

Virtualization Engine, SLIC, TIMI, and OS/400

Back in November 2004, when I did a story on the necessity to keep the microcode on the i5 machines updated even when customers were not changing OS/400 release levels, I gave a detailed description of how the OS/400 software stack was architected and how it has changed over time. I want to expand on that a little bit.

In the early days of the AS/400, there were three primary layers to an AS/400. There was the hardware, which consisted of various generations of proprietary CISC, PowerPC, and Power processors. On top of this hardware was a layer of software called the System Licensed Internal Code, or SLIC. Riding above the SLIC was the operating system layer, what we all see as OS/400.

The SLIC software is functionally equivalent to the kernel of a Unix or Linux operating system, in that it controls how the system services that comprise the operating system gain access to hardware features and interact with one another through the hardware. But SLIC is much slicker than that, because IBM Rochester is clever. The SLIC layer is also where the Technology Independent Machine Interface (TIMI) was encoded. TIMI is a hardware abstraction layer that presents a virtualized implementation of AS/400 hardware that OS/400 talks to. Because OS/400, DB2/400, RPG, and COBOL never talk directly to the iron, but only to this intermediate microcode buried in SLIC, IBM can radically change the underlying hardware in the box, and as long as the hardware talks to the microcode properly, OS/400, DB2/400, and their related RPG and COBOL applications, will run properly. (This is a bit of an oversimplification, I realize. In truth, these RPG and COBOL applications are compiled to an intermediate level at the SLIC layer and are fully compiled for a specific piece of AS/400 hardware the first time they are executed on these machines. This is all done invisibly, and programmers are not aware of this when they upgrade from, say, an AS/400 to an iSeries to an i5. This is one of the magical things about the OS/400 platform.)

Given this architecture, when IBM wanted to change something in the AS/400 software stack, in either the SLIC or the OS/400 layer, the company issued a batch of PTFs or rolled up a new OS/400 version or release (this was common with a significant underlying hardware change).

With the i5 machines, IBM had to abstract the SLIC software and get it onto the Virtualization Engine hypervisor layer for the Power4 and Power5 platforms. There is also a Linux-based service processor embedded in the i5 machines that monitors the system and its logical partitions and other virtualized features (such as on-demand processors or memory capacity), which is accessed through the Hardware Management Console (HMC). The Virtualization Engine hypervisor abstracts the underlying hardware in a Power5-based "Squadron" server, whether it is an eServer i5 or an eServer p5, much as TIMI did for OS/400-based servers in the past. All of these components (the service processor, the Virtualization Engine, and the HMC) consist of another set of microcode that runs on these devices and has to be tweaked from time to time and updated in a manner that is somewhat different from the normal PTF process.

i5 machines also support AIX and Linux partitions, which do not have SLIC or TIMI, but rather have equivalents that also ride on top of the Virtualization Engine hypervisor. Specifically, there is a layer called system firmware, which is comprised of two pieces of microcode. The first is a special low-level firmware, which allows AIX and Linux to talk to High Speed Loops (HSLs), Remote I/O (RIO) cages, and PCI-X bridges, and the second is what IBM calls open firmware, which has drivers for disks, LAN adapters, boot managers, PCI devices and other things that AIX and Linux need to run properly. Sitting beside this system firmware layer, which is above the hypervisor and below AIX and Linux, is something called the RunTime Abstraction Services (RTAS), which is a functional equivalent to SLIC in that it takes platform-dependent calls from AIX and Linux and allows them to be passed on to the Virtualization Engine hypervisor and then down to the iron itself. The idea is to make AIX and Linux instances that are running inside logical partitions think they are talking to iron when they are realty not doing that at all.

I/O, I/O, It's Off to Work I Go

If that is not complicated enough for you, then get ready for a few more twists. The original AS/400 design didn't just have three layers of system software, but three layers of system hardware. The AS/400 was, in fact, what I would call an example of asymmetrical multiprocessing (AMP). A powerful central processor that could support a relational database and lot of users was a very expensive thing to build two decades ago, which is why IBM broke the hardware into three pieces. On big mainframes and Unix boxes, the processors handle data processing for applications and middleware as well as the I/O processing associated with it. In a typical OLTP scenario, this I/O processing can eat up to 20 to 25 percent of the aggregate processing capacity of the central CPUs. So the AS/400 had auxiliary Input/Output Processors (IOPs) that handled the processing of I/O instructions instead of putting them on the main CPU or, after 1991, multiple CPUs in AS/400s implemented with symmetric multiprocessing (SMP) for the central electronics complexes. The advent of SMP did not negate the need to do AMP. Those SMP-enabled CPUs were still pretty expensive and not very powerful, so offloading I/O to the IOPs made a lot of sense. The IOPs did actually handle the peripherals (disk adapters, tape drive adapters, twinax adapters, LAN links, and so forth) attached to the AS/400, but rather talked to the I/O Adapter (IOA) cards that linked into the IOPs through SPD and then PCI and PCI-X bus adapter cards.

When I talked to IBM sources several years ago, they made no secret that the company wanted to get the I/O structure of the iSeries platform to look more like that of the pSeries platform, which does not have a staged I/O structure. The reasons why IBM wants to do this are fairly straightforward. First, no one can say that the i5 platform does not have ample computing power in its central processors these days. Even a 1.5 GHz Power5 core that has been geared down from 3,300 CPWs to 500 CPWs, 1,000 CPWs, and as of this fall 2,400 CPWs has a lot of inherent green screen RPG and COBOL processing capacity. And when IBM does gear down these Power5 chips to make the i5 520 Express machines, the extra 2,500 CPWs, 2,000 CPWs, and 900 CPWs of performance inherent in the chip is just being idled. There is plenty of capacity there to move the I/O processing back on the chip (you'd only need about 825 CPWs for I/O processing for a normal OLTP workload in my estimation) and get rid of that IOP altogether. IBM hinted that it would be doing this for disk I/O a few years ago, and it may go even further. Two other good reasons to dump the IOP approach is that IOPs cost money and they are another thing that can fail in the field. X86 and RISC servers don't use IOPs, either, so just explaining this architecture to customers must be a bit of a pain. Getting rid of the IOP approach and moving some I/O processing back to the central processors or out to intelligent I/O adapters should make the iSeries just as resilient and a bit less expensive.

Incidentally, I am told by sources that the feature 5706 two-port PCI-X Gigabit Ethernet adapter card and the feature 5712 PCI-X tape controller adapter card, which shipped with the i5s, are already capable of running in i5 systems without an IOP. There are undoubtedly others--I would expect that most or all of the PCI-X adapter cards IBM rolled out with the i5s would have such capabilities, thereby protecting customers' investments. But this may not have been possible for technical reasons.

By the way, there is also some confusion as to how much I/O processing will be handled by the central CPUs and how much by the intelligent adapter cards. The handful of sources I talked to were unclear exactly how this would work. It is my guess that it will vary depending on adapter card and server technology.

An Important Aside

Since the advent of OS/400 V5R2 (and quite possibly before that), IBM has been introducing new releases of the microcode that sits beside SLIC on the iSeries and i5s managing the service processor, the Virtualization Engine hypervisor, the HMC, and that Linux and AIX microcode. IBM has also changed SLIC at least once as a single unit. Specifically, OS/400 V5R2 came out in January 2003, and around October 2003 there was an update to SLIC, which was made to effect the substantial changes in iSeries and OS/400 packaging as well as to support new hardware features.

In May 2004, when i5/OS V5R3 was first shipped, there was a package of this microcode that was combined as the GA1 microcode; in July 2004, when the i5 570 was added to the line and IBM made improvements to the HMC, the GA2 level of this microcode came out, and GA3 was expected around Thanksgiving. You do not have to update the SLIC layer or the OS/400 or i5/OS layer to machine changes to this adjunct microcode. The SLIC was also apparently updated when the i5 570 and i5 595 were added to the i5 line, but I have been unable to verify that with IBM.

The important thing to remember is that IBM can change hardware, SLIC, non-SLIC microcode, and OS/400 independently. This is a very sophisticated design, and it is one of the reasons you pay big bucks for your iSeries.

i5/OS V5R3M5 and i5/OS V5R4M0

So what will IBM call the new i5/OS release? Some people are hearing i5/OS V5R3M5--that's Version 5 Release 3 Modification 5--and others are hearing V5R4M0, with the modification level being 0 and hence ignored. If you look at this IBM document, you can see that there are two future releases, i5/OS V5R3M5 and i5/OS V5R4M0.

The people I have talked to (some of whom were at the IBM beta event, some of whom were not but who are also in the know) believe that i5/OS V5R3M5 is an interim release that will be used to test the IOP-less I/O structure of the future i5/OS V5R4 commercial release. The V5R3M5 release is apparently going to contain some, if not all, of the features that will be in production in the official V5R4 release. My best guess is that V5R3M5 has the new features that will be common across the iSeries line (such as the IOP-less I/O), and the V5R4 release will include support for the forthcoming Power5+ servers that IBM is expected to announce more or less concurrently with V5R4 sometime around March 2006.

Here are the new features that are apparently coming with i5/OS V5R4 in addition to the IOP-less I/O processing:

RAID 6: One of the new features apparently coming out, according to sources at the IBM beta briefing, is an improvement over RAID 5 data protection for disks called RAID 6. With RAID 5, you stripe data across many disks and then generate parity data (which is created by running the striped bits of data through an algorithm) that is stored in the array. If a disk fails, you run the algorithm backwards using the disks that are still alive and the parity and you can recreate the lost data on the failed drive. This takes some time, but it can be done on the fly as the data is being rebuilt, which is kinda nice.

With RAID 6, which Hewlett-Packard (thanks to Compaq) has been shipping as Advanced Data Guarding (ADG) since 2001, you create two sets of parity and you can lose two disks in the RAID set and still recover from the failure.

SCSI-Attached IxA Adapters: One of the rumored features coming in the spring with i5/OS V5R4 and possibly an new i5 server using the Power5+ processor is a direct SCSI attachment for the Integrated xSeries Adapter (IxA) cards. Right now, to attach an external xSeries server to the iSeries or i5 server, you have to use a special HSL link and adapter card in the xSeries box. Only certain xSeries models have room for this HSL feature in their chassis, and that means customers are limited in the choice of xSeries servers that can lash to their iSeries and i5 boxes in a hybrid cluster. Future i5 machines will apparently be able to use a plain old SCSI link between the i5 and the xSeries server to create a link between the xSeries machine and the i5's disks to cluster them together at the storage level. This will simplify the link and also mean that companies do not have to sacrifice an HSL link for each server. What this means for bandwidth between the two machines remains to be seen.

It is also unclear how the Integrated xSeries Server co-processors will be linked into i5 processor complexes. This could change as well, but the sources I spoke to were not sure of IBM's plans.

IPv6: In keeping pace with the theme of sixes, i5/OS V5R4 will apparently also support the latest IPv6 protocol, which is an upgrade to the IPv4 protocol that is the backbone of most of the Internet these days. IPv6 has a different software stack and the IP addressing schemes are totally different, but you can run IPv4 side-by-side with IPv6, which offers more addresses and better security compared to IPv4.

Virtual Tape Server: IBM has been shipping a product that offers virtual tape serving capability for years, but now instead of being a standalone product, VTS is apparently being brought under the skins of the i5 systems themselves. This provides a way to back up OS/400 libraries to the Integrated File System on disk drives instead of using an actual tape drive to archive the data. This means that you can restore from those archived files (and presumably search through them) at disk-to-disk speeds. This will be a boon for companies who want to maintain uptime and speed up their backup and recovery windows. When an OS/400 server is archiving data, it is generally offline. (Yes, I know about Save While Active, but it has its limitations.) By having Virtual Tape Server capability, companies should be able to archive to the IFS and then back up from there at their leisure--perhaps even using network-based archiving software that runs on other platforms that can also read IFS files. (This latter bit might be a stretch, but wouldn't it be nice to have a unified archiving solution that spans OS/400, Linux, and Unix?)

Spool File Save: OS/400 applications kick out a tremendous amount of spool files as they run their batch and interactive workloads. While there are myriad third-party OS/400 tools for doing all kinds of things with spool files--archiving them, zipping them, and moving them between machines--this capability is not native to OS/400 or i5/OS. A lot of Four Hundred Gurus have rolled their own code to save and restore spool files. Well, IBM is apparently getting in on the act now, too. So now you guys and gals will have a bit more time to do something else.