IBM Corp mid-range machines used to be a world unto themselves. Everything in their design – both hardware and software – made them different from other mid-range systems, including any other type of IBM mid-range machines. IBM made its various mid-range systems unique because it was tuning them to support one or another type of […]
IBM Corp mid-range machines used to be a world unto themselves. Everything in their design – both hardware and software – made them different from other mid-range systems, including any other type of IBM mid-range machines. IBM made its various mid-range systems unique because it was tuning them to support one or another type of workload. The System/36, with its flat file database, was very good for batch transaction processing. A few years before the launch of the System/36, IBM’s programmers were working on a more advanced (and incompatible) file system that would eventually lie at the heart of the AS/400: a relational database file system that made it an excellent on-line transaction processing machine. Had the personal computer not taken over the world and had the Unix standard shrivelled up and died, OS/400 would have looked very different from the way it does today. The new OS/400, by which we mean both V3.1 and V3.6, sports a file structure IBM calls the Integrated File System.
The IFS enables the AS/400 to handle file types that are used with personal computers and Unix systems. This was either difficult or impossible with prior releases of the AS/400’s operating system. The central idea behind IFS is to make the AS/400 a better file server for client networks while at the same time preserving the benefits of the AS/400’s database file structure (which is called QSYS.LIB in IBM lingo) and remaining compatible with the existing shared folder personal computer file system (that’s QDLS, which stands for Document Library System) that enabled desktops working through PC Support to store their files on the AS/400 as if the AS/400 were one big hard drive attached to the personal computer. IBM accomplished its goals with the IFS not by expanding the prior AS/400 file system, but by dumping it. IFS is based on IBM’s OS/2 High Performance File System. This file system is arguably IBM’s best and certainly its most recent file system, so it makes sense that IBM would use it in the guts of OS/4 00. The OS/2 system is now the root file system of OS/400. IFS brings a hierarchical directory and file structure to OS/400 that is just like that of MS-DOS, Windows, OS/2 and Unix. It is very much unlike the single, flat object space of the AS/400’s database file system, QSYS.LIB, which is now an offshoot of this root file system. QSYS.LIB bears the same relationship to the IFS root file as an Oracle database running on a personal computer server does to OS/2, Windows or any other personal computer server operating system. In effect, IBM has ported DB2/400 to the OS/2 file system. This new OS/400 file system doesn’t require that customers do anything to run their existing applications. But there are some positive side effects that come along with the IFS that customers will appreciate. IBM hasn’t been specific about this, but says that the IFS actually improves database performance even though it moves the database one step further away from the iron. The peppiness of the OS/2 file system more than offsets t he overhead of propping up the AS/400’s formerly native database file system. Likewise, shared folders are much less sluggish under the IFS. One of the main reasons that the shared folder function has been such a dog in prior releases is the way that the files were stored on the AS/400. Shared folders were stored in a format called EBCDIC-encapsulated ASCII. EBCDIC is the numeric character encoding scheme used with IBM mid-range and mainframe systems; ASCII is the form used by everybody else. To store a personal computer ASCII file on the AS/400, OS/400 had to wrap a shell of EBCDIC code around it so it would look like a native file. If a personal computer called for the file, the AS/400 had to strip off this EBCDIC code before it sent it down the wire.
By Timothy Prickett
Performing this file transformation takes AS/400 CPU power. Shared folders were also slow because PC Support, the software linking the personal computers and the AS/400, was not very quick either. Now that share
d folders don’t have to be converted to and from EBCDIC form and Client Access is three to eight times faster than PC Support, moving shared folders around is a lot quicker. It is still not as fast as a directly connected personal computer hard drive, but it’s a lot closer. OS/400’s IFS has other file subsystems under its umbrella, too. The first is called QOPENSYS. This is a Unix file system that is compliant with the Unix Posix and XPG standards that everybody else is trying to be compatible with. It is essentially the same as the OS/2 root file sys tem, except that it can differentiate between upper and lower case letters in file names (none of the personal computer file systems from IBM or Microsoft Corp apart from Windows NT do this). QOPENSYS makes it much easier for Unix applications vendors to port their software to OS/400, which is why IBM did it. It also makes it easier for Unix systems to talk to the AS/400. QOPENSYS is included in both V3.1 and V3.6 of OS/400, but V3.6 will include one more Unix feature not included in the previous release of the operating system. IBM plans to add what is called Unicode national language support to OS/400 for the RISC boxes. This is a standard way of supporting double-byte character sets, which are necessary to support Asian versions of systems and applications programs. (IBM has had double-byte character sets for OS/400 since the beginning, but not an industry standard set.) Another file subsystem under IFS is called QLANSERV. This is the file system that is used by the LAN Server FSIOP card. LAN Server files are a bit different from plain OS/2 files, so they are kept separated.
That doesn’t mean that native AS/400 applications can’t access the files – they can, using filters built into OS/400. The LAN Server files are kept separate to simplify the process of managing the files, which are also coincidentally kept on a dedicated portion of an AS/400’s hard disk capacity. But wait, that’s not all you get: IBM has added two new file systems to the IFS with V3.6. The first, QOPT, was added to IFS to give native support to the CD-ROM drive that is built into each RISC AS/400 model. The other new file system is called QFILESERV. This file system has a few interesting features. QFILESERV allows end users or applications residing on one AS/400 to access transparently files stored on another AS/400 that is linked to their primary system through standard network connections – local net, modem, high speed phone lines, direct twinax attachment, and OptiConnect using either SNA or TCP/IP communications protocols. QFILESERV even enables the primary system to access files on a system that is not directly attached to it, but to any other AS/400 that is somehow linked through it. In many ways, this telephone-tag form of surfing systems for files is like the Advanced Peer-to Peer Networking code that IBM has built into SSP and OS/400 from the beginning. APPN wasn’t used all that much by AS/400 shops because it ate a lot of CPU cycles and communications software and hardware were too slow to make it practical. Neither is the case now, so now would be a good time for IBM to resurrect APPN. QFILESERV differs from APPN in that it actually enables end users physically to see what files are stored on remote AS/400s, rather than simply have to ask each system if it has a file or not. From The Four Hundred, July 1995Copyright (C) 1995 Technology News Ltd.