i5/OS V6R1: The TIMI, It Is A-Changing
August 20, 2007 Timothy Prickett Morgan
|
By their very nature, technology transitions are difficult. There were many brilliant things about the design of the System/38 and AS/400 minicomputers that are the ancestors of today’s System i platform, but perhaps the most important one is that IBM wove a technology-independent machine interface (TIMI) between the operating system and the underlying hardware. This has made changing the OS layer or the hardware layer a lot easier than is the case with other platforms. But sometimes, the hardware changes so much that even TIMI needs to change. Such is the case with the forthcoming i5/OS V6R1. And when TIMI has to change, that means RPG, Java, COBOL, and C, applications have to be tweaked to run on the new operating system and the new hardware that is associated with it. In the case of V6R1, customers running it on older iron (using Power5 and Power5+ chips) will also have to cope with some changes to their applications. The good news is that IBM is handling this transition a lot better than it did the move from OS/400 V3R1 running on the 48-bit CISC-based AS/400s to OS/400 V3R6 and V4R1 running on the 64-bit PowerPC-based AS/400s back in 1995 and 1996. In the long history of the System/38-AS/400-iSeries-System i line, IBM has only changed the machine interface twice. Once when moving from the System/38 and its CFP operating system to the original AS/400s and OS/400 V1R1 back in June 1988, and the other during that CISC-to-RISC jump back in 1995. With each jump, the underlying processor technology changed so radically that this machine interface–which is a kind of virtualized machine that OS/400 runs on top of and which applications talk to rather than the underlying iron–has to be tweaked to take advantage of all of the new features in the hardware. These changes are a good thing, and IBM has done a lot to automate the process of moving applications to V6R1 running on either Power5 or Power6 hardware. Perhaps most importantly, IBM has published a Redpaper technical report on the move, entitled i5/OS Program Conversion: Getting Ready for V6R1. A draft version of this report was published last week, and the final version is expected in January 2008, just ahead of what we presume is the official launch of i5/OS V6R1 and a new line of Power6-based System i servers. The reason why this report is important is because there was no such report in the CISC-to-RISC transition from 1995, and because people were unaware of the underlying machine interface and how it works, some people couldn’t make the jump as easily as they should have to new technology. Without getting too technical, here’s what happens on the OS/400 and i5/OS platform when you create applications, which explains the problem customers ran into in 1995 and which IBM wants them to avoid in 2008. A programmer writes an application in say, RPG. They run it through a compiler, either using the Original Program Model (OPM) or the Integrated Language Environment (ILE) compilers, and the code compiles so they can run it. Or, rather, that is what it looks like to the programmer. What is really happening is that this application is compiled into an intermediate stage, which some IBMers have called RPG templates (in the case of RPG applications). These templates have a property called observability, which in essence means they are compiled to the TIMI layer. These intermediate templates are then used by the TIMI layer on an actual piece of hardware with a specific processor and instruction set to compile the application to run on that specific processor. TIMI compiles these RPG templates down to actual compiled code behind the scenes the first time an application runs, and because the code was originally compiled to the TIMI layer, there is no need to change the source code. Only the object code changes, which end users never had access to anyway because only TIMI can reach down there. This is the brilliant way that IBM has preserved customers’ vast investments in RPG, COBOL, and other applications over the years. But again, when the underlying hardware changes, then TIMI has to change, and that means applications have to be converted from one TIMI to another and then recompiled by TIMI to work on the iron. In some cases, to get the best performance out of an application, customers have to actually recompile their code on both the new operating system and the new hardware. Sometimes, having TIMI do the conversion is enough, even if all the features of the new platform are not available to these converted applications. Back in 1995, because customers did not know any of this, some customers were a little too clever for their own good. You have to remember that disk capacity back in the early 1990s cost $10 per MB, and by 1997 had only fallen to anywhere from $3 to $7 per MB (depending on the make and model of the disk array), and customers were doing everything they could to save disk capacity. That unfortunately included deleting some mysterious files on their machines that didn’t seem to affect how the applications ran on CISC-based AS/400s as they upgraded over the years. These files were, in fact, the templates used by TIMI for observability. The problem was that for many customers, applications were very old and in some cases they no longer had source code. So TIMI could not do a recompile from the intermediate level and RPG compilers could not do a new compile on the new OS and hardware. (To get the story of the bumpy transition back in 1995, see TFH Flashback: The Joy of V3R6.) Oops! The reason this happened, of course, is that OS/400 shops didn’t really know how RPG and COBOL applications worked on their machines. They thought IBM had invented some sort of magic box, where applications would just run, no matter what. The architecture of the i5/OS and OS/400 platform is very smart, but it ain’t magic. This time around, IBM is being really clear about this. And it has also put a belt and suspenders on the process. For instance, any program compiled on OS/400 V5R1 will later automatically have its creation data (which is the new term for application template or observability) saved on the system. According to the report, customers who have applications compiled for V4R5 or earlier OS/400 releases have to make sure these templates are still on their machines before converting to V6R1. IBM has also created a tool, called Analyze Object Conversion (ANZOBJCVN), which will be available through PTF patches for OS/400 V5R3 and i5/OS V5R4, to automatically comb through the applications on a system to see what programs and files need to be converted as part of a move to V6R1. As it turns out, the changes to TIMI and the underlying Power6 hardware are so substantial that a lot of things need to change. (Message to IT managers: You really need to have you technical people read this draft report.) Java programs need to be altered as well, and so do some file names in the Integrated File System because V6R1 supports the new Unicode V4 standard rather than the Unicode V2 standard used in V5R4. Moreover, applications that are created on V6R1 will have to be back-converted or sometimes recompiled (it depends on the code) to run on V5 or prior releases. Applications compiled for V6R1 on hardware earlier than Power6-based servers will not have to be converted, since the new TIMI that comes with V6R1 knows about Power6 iron as well as earlier Power4, Power5, and Power5+ iron. Remember, V6R1 will run on second-generation iSeries and System i 515, 520, 525, 550, 570, 595 machines as well as on iSeries 800, 810, 825, 870, and 890. Earlier first generation iSeries 270, 820, 830, 840 machines will not run V6R1. Of course, the future System i 6XX machine, also expected in early 2008, will run V6R1, as will subsequent generations of machine, probably out to the Power7+ generation or maybe even the Power8 chips. RELATED STORY TFH Flashback: The Joy of V3R6
|
