Using the IFS can be a little tricky. Ron Turull gives you 10 things to keep in mind.
- To access the IFS from a PC, you need the Client Access/400 V3R1M0 Windows Client or the Optimized for OS/2 Client.
- Each individual file system (e.g., the OS/400 library system or the DLS file system) is a major subtree in the IFS, with only the root above them.
- In QSYS.LIB (the OS/400 library system), libraries are subdirectories, as are database files (because database files contain members). Database file members are considered "objects" or "files" in the IFS, as are other OS/400 objects.
- Each individual file system has it own naming conventions. For example, in the QSYS.LIB file system you must specify a period and the object type after the object name (some examples: ".LIB" for libraries, ".FILE" for files, ".MBR" for database members, or ".OUTQ" for output queues). Also, some file systems, such as QOpenSys, are case-sensitive.
- To access an object in any of the file systems via the IFS, you must specify a DOS-like path name to the object. For example:
/QSYS.LIB/MYLIB.LIB/MYFILE.FILE/MYFILE.MBRspecifies member MYFILE in file MYFILE in library MYLIB in the OS/400 library system. You can use the back-slash character () instead of the front-slash character (/) in path names.
- Hard links cannot cross file system boundaries while symbolic links can. The QSYS.LIB and QDLS file systems support only a single hard link to an object (the one that is created automatically when the object is created). You cannot create symbolic links in either the QSYS.LIB and QDLS file systems. However, symbolic links pointing to objects in QSYS.LIB or QDLS can be created in other file systems.
- Directory and file names are stored in Unicode format. This allows the IFS to automatically convert directory and file names from one code page to another. For example when a PC uses a different code page than the AS/400, directory and file names are converted automatically to the code page of the PC. Caveat: The code page you are using must contain the characters used in the names. Bottom line: Use international letters and symbols only (i.e., use only characters common to all code pages).
- The IFS supports the single-character wildcard character '?' as well as the multiple-character wildcard character '*' . (DOS users should be familiar with this.) For example, this gives AS/400 users the ability to search for objects using a more complex search criteria than that provided by the standard AS/400 generic name facility (e.g., WRKOBJ TEST*). The IFS Work with Object Links command (WRKLNK) can be used to perform a more complex search (for example, WRKLNK '/QSYS.LIB/A?C?.* will find ABCD.LIB and ADCB.FILE, but not ABBCD.LIB). Unfortunately, wildcard characters are allowed only in the object name and not in any of the directories listed in the path.
- For a list of APIs that can be used by AS/400 programs to access the IFS, see "Unix-type APIs" in the API Reference manual.
- The IFS supports local sockets. This allows sockets programming on a single machine to implement single-box client/server programming.
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.
- Understanding and taking advantage of the IFS
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.
This was first published in April 2003