In May, IBM unveiled V3R1, the largest release of OS/400 since the AS/400 was announced in 1988 (see "Software Announcements: A Blueprint for the Future," MC, June 1994). Because of the magnitude of the announcements, Midrange Computing plans in-depth coverage of some important features of the new release during the next few months. The first topic in our enhanced coverage is the Integrated File System (IFS).

IFS is designed to enhance application portability, particularly for UNIX programs. It allows several different file access methods. IFS supplements traditional access to AS/400 libraries, files and folders with access to two different types of hierarchical directories. One is based on PC standards and the other is based on the POSIX standard, which is widely used on UNIX platforms.

Client/Server Benefits

UNIX portability is important for some AS/400 shops and it provided the driving force for IBM to implement IFS. However, for most AS/400 shops, the ability to store and access PC data efficiently is of more immediate concern. IFS can improve performance for any PC data you store on the AS/400. It also makes the user interface to PC data simpler by allowing data to be accessed using PC file-naming conventions (e.g.,doscommandsfile.exe) from OS/400.

Much of the performance benefit is the result of IFS' ability to manipulate bytestream files. Bytestream files can be contrasted with traditional, record- oriented files. Images, text and audio are examples of bytestream files-each file contains one continuous stream of information. File systems that handle record-oriented files efficiently, such as the AS/400 library system, do not usually handle bytestream data efficiently. IFS uses multiple file systems to handle each type of data in the most efficient way possible-the most obvious result is improved performance for bytestream data that was traditionally stored in shared folders.

If your development plans include client/server applications, IFS may become a key element in your application development strategy.

Data Translation

Another important benefit of IFS is its ability to translate data. When you start moving data from one system to another, you're sure to encounter differences in the way the data is encoded. ASCII vs. EBCDIC is the version of this problem that AS/400 programmers are most likely to encounter. PCs store information in ASCII; but larger IBM systems, including the AS/400, store data in EBCDIC. The translation is not always straightforward. As a result, we may be willing to transfer text between the AS/400 and a PC but we tend to be cautious about data or programs.

IFS puts an end to these concerns. Each of its file systems stores data based on its natural coding-EBCDIC for AS/400 programs; ASCII for PC text files. You can move data from one file system to another. IFS handles data translation based on how the file is opened. What could be better? How about the fact that IFS issues a warning when it cannot translate data rather than leaving you with an unknown problem?

If you are moving data between PC applications and AS/400 applications or if you would like to take advantage of PC word processors to manipulate help text and other AS/400 documents, IFS could make life much simpler. If you are using a PC-based program source editor, IFS could be invaluable. Isn't it reassuring to think that source code can move between the AS/400 and a PC without any data-translation errors? This is what IFS' data translation promises.

IFS Structure

1 illustrates the overall structure of IFS. Your reaction to this may be that there must be a performance penalty for the extra layer of software imposed by IFS, but IBM insists that this is not so. In any event, IFS is here to stay, so it is to your advantage to learn what it can do for you.

Figure 1 illustrates the overall structure of IFS. Your reaction to this may be that there must be a performance penalty for the extra layer of software imposed by IFS, but IBM insists that this is not so. In any event, IFS is here to stay, so it is to your advantage to learn what it can do for you.

IFS provides an interface for dealing with many different types of data by providing separate file systems-currently five file systems are supported. Each file system has its own rules about the types of data allowed and how information is stored, named and retrieved. The rules for each file system are based on the rules for the particular computer system that provides the model for that file system. In the long run, this has two benefits: each data element can be stored in the most efficient way possible, and porting applications from one platform to another is greatly simplified.

Any object is stored within a specific file system. With some restrictions, it is possible to access data between file systems and to move data from one file system to another. The file systems supported on the AS/400 in V3R1 are listed and briefly described below.

QSYS.LIB is the existing AS/400 file system. You can use it to store any AS/400 object-with the exception of folders, documents, directories and bytestream files.

QDLS is the existing AS/400 folders structure.

root is a hierarchical file system based on a PC model.

QOpenSys is based on POSIX and Spec 1170 standards which are widely used in the UNIX world. Like the root system, it supports hierarchical directories, but the naming conventions are different.

QLANSrv stores data using the LANServer/400-licensed program.

IFS Commands

Since data can be stored within any of the file systems, IBM has provided some commands to help you manage objects using IFS. You can still use any of the existing OS/400 commands to work with objects in QSYS.LIB or QDLS, but the new commands provide some advantages of their own. The most striking feature of these new commands is that they do not require an object type. For example, the Copy (CPY) command will copy any object, regardless of the object type or which file system it is stored in. V3R1 also provides the Move (MOV), Rename (RNM), Restore (RST) and Save (SAV) commands to process objects, regardless of type.

This has an immediate benefit because it reduces the number of commands you need to remember. Its real benefit is long term. This type of insensitivity to the contents of an object is a key component of object-oriented programming (OOP).

In the OOP model, objects are self-contained entities that know all of their own internal rules. You can request an action from an object without knowing anything about how the object will perform the action. It is a natural corollary that you can request the same action (e.g., copy) from any object that can perform the action without knowing anything about what is stored in the object.

Finding Your Data

IFS uses some new object types to manage data: directories (*DIR) and links (*SYMLNK).

If you're familiar with PCs, they provide a model for understanding directory objects. On the AS/400, a directory object is the equivalent of a library or a folder-it organizes objects (e.g., files) into a structure. To uniquely name each object, IFS uses a combination of directories and the object name. For example, MIDRANGESHARONFILE01 and MIDRANGEHOFFMANFILE01 are two different objects. The combination of directories is referred to as the "path" to an object.

This is functionally equivalent to having the same object name in two different libraries except that the directory names can be more complex. The path to FILE01 in the first example is MIDRANGESHARON; in the second example, the path is MIDRANGEHOFFMAN. The examples in this article use the PC structure which specifies each directory division with a backslash (). The concepts are also valid for files that use UNIX naming conventions except that a slash (/) is substituted for the backslash.

In addition to explicitly naming the entire path structure, there are other ways to specify an object using IFS. These alternatives take advantage of the directory "tree." In the examples in the previous paragraph, the entire path is spelled out. Any command that omits the initial slash from the object name starts from some point other than the top of the tree. The starting point for the search through the directory tree is determined by the initial characters of the object name according to the rules explained in the following section.

"Home" and "current" directories are important concepts for IFS file searches. Think of the current directory as a starting point in your search through the directory tree to a specific object. In the examples given so far, each path starts with a backslash, indicating that the entire path is spelled out. If the initial backslash is simply omitted, the search starts from the current directory. (The current directory may be set by a user or by a program.) A user whose current directory is MIDRANGE could specify MIDRANGESHARONFILE01 or SHARONFILE01 with precisely the same result.

The home directory is an initial current directory maintained in the user profile. A tilde (~) followed by a slash or a backslash at the beginning of a path name indicates that the search is to begin with the current user's home directory. If the tilde is followed by a user profile name, the search begins with that user's home directory.

No matter how the starting point of the search is determined-by the entire path name, by the current directory or by a user's home directory-a directory- based search follows the same path through the directory tree.

A link is a POSIX concept that establishes multiple paths to the same data. For example, a program could access data about manufacturing personnel using a hierarchical path (manufacturingpersonnelemployee) or using a link that goes directly to the manufacturing employee file. Probably the closest analogy is a logical view of a file-it provides a different way to access the same set of data. Links do this, but at the object level rather than the individual record level.

IFS supports two types of links. Hard links are effectively an alternate name or path to a specific object. A symbolic link is an object (type *SYMLNK) that contains data-a full or partial path name. When IFS encounters the symbolic link, it substitutes the value of the symbolic link into the object name being resolved. This is similar to many soft-coding techniques you may have used in application programs. For example, if you store the company-name headings for reports in a physical file rather than in the program or the DDS, you can change the company name without recompiling. Similarly, you can change the value of a symbolic link, and you can even create a symbolic link to an object that doesn't exist. Symbolic links can cross from one file system to another. Potentially, they provide a method to manage AS/400 data (in QSYS.LIB) using PC programs stored in the root file system.

IFS provides support for wildcard searches similar to PC file systems. An asterisk (*) can be used to replace a string of characters, or a question mark (?) can be used to replace a specific position within a string.

What's in It for Me?

This brief overview should give you an indication of the potential benefits of IFS and how it can fit into your application development strategy. If you already use shared folders extensively and have begun to develop client/server applications, IFS is an important enhancement for your installation. The performance improvements should be noticeable, and you will be able to provide end users with better access to AS/400 data because of the commands built into IFS. At the same time, the MIS department can have confidence that the integrity of all the data on the system is under control of OS/400, reducing concerns about client/server security.

In the long-term picture, it is obvious that bytestream files will become more and more prevalent. If there were no other justification for IFS, the industry trend toward image-based and multimedia applications might be enough. Depending on your company's business, the ability to handle images within the central computer system may be a vital competitive edge.

Finally, if your installation has any requirements for cross-system applications, especially those involving UNIX-based systems, IFS will make it easier to transfer data and applications. Imagine how much easier it would be for users to work with the same interface on the PC, on the RS/6000 and on the AS/400. IFS provides the tools you need to develop applications that have this transparency. Better yet, you may find that the tools your users currently have will be able to access AS/400 data transparently because of the new file system.

In upcoming issues, MC will bring you additional announcement follow-up material on critical subjects such as the new File Server I/O Processor, V3R1 security and Client Access/400. This information should help you prepare to take full advantage of the new capabilities of OS/400 whenever you install the new version.

Sharon Hoffman is the editor of Midrange Computing.