Sometime in late May, according to our sources, IBM business partners and value-added resellers will be briefed about the new RISC AS/400s. A week or so later, everybody expects IBM formally to announce the new boxes. Just because the new boxes will be announced in early June, don’t expect to be able to get your hands on one, especially if you are looking to buy a large 9406 system. According to people familiar with IBM’s plans, the very largest RISC AS/400s won’t be generally available until the first quarter of 1996. Usually there is a month or two delay between announcement and shipment for largest members of a new AS/400 family, but this is pushing it. IBM will reportedly ship the smallest new AS/400s beginning in September, while RISC AS/400s in the middle of the line will ship in December. What happened? The problem is OS/400 3.6. The new software, which will be required for the RISC machines, is radically different from OS/400 2.3 and quite a bit different from 3.1.

Obscure

On the surface, OS/400 still looks pretty much like OS/400, whether it’s a release of V2 or V3. But behind the green screens and underneath the machine interface layer, where IBM’s Licensed Internal Code lurks, just about everything has changed or soon will. The LIC for OS/400 versions prior to 3.R1 was written in assembler and PL/I, really obscure and tough languages but ones that programmers in Rochester knew pretty well. Starting with 3.1, IBM began using C++ to write portions of LIC. C++ is a really obscure and tough language that IBMers don’t know very well, so there have been some difficulties. The pieces of LIC that were rewritten first were mainly concerned with auxilliary storage control; this code resided out in the disk input-output processors, controlling the spreading of data across multiple disk drives. Not coincidentally, this C++ code is exactly where they scariest bugs in 3.1 now hide. Customers who have moved to 3.1 have had disk sectors lost; IBM is continually working on Program Temporary Fixes, but it is merely putting out fires. The PTFs do not allow lost data to be recovered. There are actually two pieces of code that make up Licensed Internal Code, vertical LIC and horizontal LIC. Each has different tasks translating OS/400 commands to hardware instructions. With OS/400 3.6, some VLIC and all HLIC will be done away with, being replaced by a single integrated System Licensed Internal Code, or SLIC. The new SLIC consists of over 1m lines of C++ code and 6,000 classes of C++ objects. Anyone that thought that the transition to a PowerPC-derived processor for the AS/400 was going to be easy must have been living on another planet for the last 20 years, or be fresh out of school. It was always certain that several of the things that could go wrong would go wrong: here Timothy Prickett highlights one of the most serious things that has gone wrong. For those not acquainted with C++, those are absurdly large numbers, attesting to the growing complexity of OS/400. This SLIC layer of software will in turn talk to a Unix kernel, which may be Mach or WorkPlace or AIX. Nobody is saying. With OS/400 4, which will debut with the second generation RISC AS/400s, all of VLIC will be dropped and OS/400 reportedly will ride on top of a full implementation of Unix. This will be a Unix that developers will not be able to get at, however. What does all this mean? Not much, unless you plan to move to a RISC AS/400. When an RPG program is compiled using 3.1 or earlier software, it generates an RPG VLIC template. The IBM term for this template is observability. Up until now, this VLIC template was not needed actually to execute a program. Since VLIC templates account for 75% of the disk space of RPG programs, customers tight for disk space often deleted them. Starting with 3.6, these templates will be required for any RPG program to run. If a customer has its VLIC templates, the programs will run using them; if they recompile their source code using the ILE RPG or RPG/400, it will create new SLIC templates that match 3.6.

Thrilled

Those who have deleted their VLIC templates from the system can recover them without recompiling. Harmon Resources, of Norwood, Ohio and Advanced Systems Concepts, of Schaumburg, Illinois both retrieve RPG observability. But recreating these Vertical Licensed Internal Code templates costs a lot of money, between 75 cents and $1.25 per RPG line, and it could take weeks per RPG module. Customers are never thrilled at the prospect of having to recompile their applications, but they may have no choice. For a typical AS/400 user, recompiling applications might take between one and three days. The problem is that people don’t keep track of source code very well. The more complex the system, the greater the risk that someone forgot to back up or correctly label a set of applications source files.

Information

From the April 1995 edition of The Four Hundred, published by Technology News Ltd, 110 Gloucester Avenue, London NW1 8JA, phone 0171 483 2681, fax 0171 483 4541. (C) 1995 Technology News Ltd.