It's an old story, but if you are involved in any way with your iSeries' administration duties, you will want to be sure you understand your system's Integrated File System (IFS). Understanding what it is and how it works will allow you to take full advantage of the IFS. You also need to have a fairly comprehensive understanding of the IFS to perform routine saves and restores.
The evolution to IFS
To understand why the IFS evolved, we must take a quick look at the AS/400's file systems. From its inception, the AS/400 has had two separate and distinct file systems: the OS/400 library-object file system and the document library services file system (also know as DLO, DLS, and shared folders). Access to them was through separate commands and interfaces. For example, to save an OS/400 object to tape, you use the SAVOBJ command; to save a DLS object to tape, you use the SAVDLO command. A PC using CA/400 can access the DLS file system, but not the OS/400 library system.
A number of years ago, the hierarchical file system (HFS) was introduced on the 400. The HFS is not a true file system in and of itself. In IBM-speak, it is an "enabler." That is, it is a set of APIs that allow you to access the DLS file system as well as create and access your own hierarchical file systems.
The HFS was meant as a building block to allow software vendors -- particularly Unix software vendors -- to port their applications to the 400. The only problem was that vendors wanted the building, not just the building blocks. Most Unix vendors were standardized on the Unix-born Open Systems file system standard and, with the HFS, each vendor would have had to create its own version of this file system from the ground up.
Enter IFS: Integrated, yet open
The IFS is a "super-set" file system. It is a new way of looking at and accessing the existing AS/400 file systems and the new file systems that have been added since the inception of the IFS. In abstract terms, it is an umbrella over all the AS/400 file systems; an interface layer that "sits" above all AS/400 file system interface layers (see the figure below.). It does not duplicate the functions of its incorporated file systems -- it adds to them.
|Figure 1: The IFS: a "super-set" file system.|
In MS-DOS terms, the IFS is the root directory on the 400. All AS/400 file systems are first-level directories (or, main branches) off this root directory. The OS/400 library system directory is named QSYS.LIB. The DLS file system is named QDLS.
A call to the IFS interface is translated to the command appropriate for the file system to which the IFS call is directed. For example, the IFS Create Directory command (CRTDIR) is translated to a Create Library command (CRTLIB) when directed to the OS/400 library system. When directed to the DLS file system, it is translated to a Create Folder command (CRTFLR).
Many commands specific to a particular file system do not have an IFS equivalent. For example, there is no IFS command that creates a data area in the OS/400 library system. In these instances, you must drop down a layer and use the command appropriate for the file system (e.g., use the CRTDTAARA command to create a data area). All of the file systems are integrated under the IFS, yet each remains "open" by allowing you to bypass the IFS altogether (e.g., you are not required to use the IFS CRTDIR command to create an OS/400 library).
Likewise, many of the IFS commands do not have equivalents in many of the file systems. In this case, the IFS processes the command itself. It should also be noted that most, if not all, of the file systems created since the inception of the IFS can be accessed only through the IFS. That is, the IFS provides the only interface to them.
One of the driving forces behind the creation of the IFS was the failure of the HFS to attract Unix vendors. One of the file systems created since the introduction of the IFS is the Open Systems file system (or QOpenSys). This file system was designed to greatly simplify porting Unix-based software to the iSeries. Unfortunately, it wasn't initially as successful as hoped in attracting Unix vendors. It is there for the taking, and it is gaining momentum.
But why "integrated"? Simply put, with so many different file systems now on the iSeries and the potential for more, IBM wanted a fast, common way to access them all, hence, integration. Programs on the iSeries as well as the PC can now access OS/400 database file members the same way they access files in any of the other existing and future file systems. Programmers can choose the file system that best suits the particular file without regard to the access method. Additionally, files can be moved from one system to another while maintaining links in the original system, so programs accessing that file do not need to be modified.
With the introduction of the Web-based facilities on the 400 over the past few years, the IFS has again proved itself worthy. Web-pages can be stored anywhere, and it is just as easy to FTP a file from the QOpenSys file system as it is to FTP a file from the QSYS.LIB file system (without the IFS, the latter would be impossible).
The CA/400 folder connection
The CA/400 Shared Folders function is no longer just a connection to the QDLS file system; it is a connection to the entire IFS. And it is no longer called Shared Folders. In fact, it is not called anything. The whole function has been put under the covers of CA/400 and has been integrated right into Windows networking. Now, the PC sees the IFS on the 400 as just another network hard drive waiting to be assigned. Drive letters can be assigned to the entire IFS system, specific file systems or specific subdirectories within specific file systems.
Here is an example of the power of integration. Suppose a PC has drive letter I mapped to the entire IFS system. The following MS-DOS Make Directory command directed at the OS/400 library system would result in the creation of library MYLIB:
The DOS MD command is interpreted by the IFS as an IFS CRTDIR command, which the QSYS.LIB file system translates to an OS/400 CRTLIB command. Recall, the first level directory "QSYS.LIB" is the name of the OS/400 library system. The ".LIB" extension on the library name "MYLIB" is required; it is not a DOS file extension, it tells the IFS that MYLIB is a library.
You can do the same thing in Windows using any one of its many interfaces, such as Windows Explorer.
The power of links
Every object in every file system is tied to the directory in which it is contained. This tie is called a link -- a hard link to be exact. Likewise, every sub-directory is hard linked to the directory in which it is contained. The IFS also supports symbolic links (or soft links). Symbolic links provide a mechanism to link an object or directory in one file system to a directory in another file system.
You can create multiple links to the same object or directory. The first hard link is established when you create a new object or directory. Use the OS/400 Add Link command (ADDLNK) to create additional hard and symbolic links.
You cannot delete an object that has hard links to it, but you can move it. (When moved all links will be updated.) An object is deleted when the last hard link to it is removed. An object having symbolic links to it can be deleted.
One of the most significant uses of links is the ability to move objects without having to recompile programs referring to those objects. For example, if a program refers to file FILE1 in directory DIR1, FILE1 can be moved to directory DIR2 and a symbolic link named FILE1 (the original file name) pointing at "DIR2/FILE1" can be created in DIR1 (the original directory). When the program refers to FILE1 in DIR1, the IFS will determine that it is a symbolic link and redirect the reference to FILE1 in DIR2.
More on links
If you are a little confused on links, you probably aren't alone. Understanding them is kind of on par with understanding pointers. Hard links are the IFS equivalent to MS-DOS directory entries. An MS-DOS directory entry contains the name of the entry (you can think of this as a key) and a pointer to the space occupied by the object. It also contains a few other items of information about the object such as the object's size. This is essentially what a hard link is. It is a directory entry that points to the object and contains information about the object.
Hard links take up only the space of a directory entry; that is, there is only one copy of the object no matter how many links you create to it. In MS-DOS terms, it would be like a file that has more than one name.
Symbolic links are a whole different breed of animal. A symbolic link is actually an object itself, a very small object that contains only a path name. The path name can be that of a complete path to an object or any part of a path. Let that one sink in for a moment with a couple of examples:
/dir1/dir2/dir3/dir4/myfile.doc dir2/dir3/dir4 dir3/dir4/myfile.doc
If the first example path above is put into a symbolic link object named sym1.lnk in any directory (but for sake of argument let's say directory dirz), and the second into a symbolic link object named sym2.lnk in directory /dir1, and the third in sym3.lnk in directory /dir1/dir2, then the following would all point to the same object,
When the system comes across the name of a symbolic link object in a path, it substitutes part of the path with the path contained in the symbolic link. When the path in the symbolic link starts with a slash (as in the first example), the name of the symbolic link and everything before it is replaced with the path in the symbolic link. You can think of this as the system returning back to the root directory and starting the search of the "real" object all over again.
When the path in a symbolic does not start with a slash (as in the second and third examples), only the symbolic link name is removed from the path and replaced by the path contained in the symbolic link object. So /dir1/sym2.lnk/myfile.doc becomes /dir1/dir2/dir3/dir4/myfile.doc after removing sym2.lnk and replacing it with dir2/dir3/dir4.
Something to think about
You can create symbolic links to other symbolic links. You can also create symbolic links to hard links, and vise-versa. Now, I can't think of a reason you might want to do this, but you might. Plus, as soon as I write something like that, two weeks later I run into a situation calling for just that.
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years experience programming for and managing AS/400-iSeries systems.
- Working in shades of SAVbr> It's valuable to understand some of the different backup options available under IBM's Save Object (SAV) command, which is used to save any object in OS/400's Integrated File System (IFS). Using these options, you can perform a full save of the Integrated File System or a partial save of IFS files based on patterns in your file naming conventions.
- Working with IFS
A Search400.com member said recently it was pointed out to hom that the IFS uses the same disk as the rest of the iSeries. Previously, he thought it was restricted to some area. Now he's concerned that a PC application might be able to load up the disk through the IFS. Is this a problem? Security expert Carol Woodbury responds.
- Check for IFS object (link)
With the use of the AS/400 (iSeries) Integrated File System (IFS) becoming more widely spread, wouldn't it be nice to be able to check for the existence of an object (link) before attempting to use it? Here's how Eddie Scott did it.
- List the contents of the IFS directory
Search400.com member Denzil D'Souza had a hurdle in one of his projects to list the contents of an IFS directory -- in the root system. The solutions he found on the Internet were all oriented to using C function, which is interesting, but was not feasible to use as the client had restricted the development language to ILE RPG and CLLE. So through a little bit of 'fiddling around', he found this method.
This was first published in April 2003