Effectively managing DASD utilization on your System i servers requires a good understanding of both the Integrated File System (IFS) in addition to the traditional OS/400 native file system. We have become familiar with the concept of libraries, files, members and objects. Our disk usage analysis tends to focus only on these types of objects.
The introduction of the IFS on this platform should dramatically expand the focus of any disk storage monitoring. There are numerous folders and stream files outside of '/qsys.lib' and '/qdls' that could be consuming large amounts of DASD. Temporary IFS objects, JPEGs, TIFF files or Word documents may be as large as your Production database files.
Most OS/400 native file system commands have equivalent IFS commands. Become familiar with them:
Work with Object Links (WRKLNK) versusWork with Objects (WRKOBJ)
Save Object (SAV) and Restore Object (RST) versus Save Object (SAVOBJ) and Restore Object (RSTOBJ)
Using the WRKLNK OBJ('/*') command is a good place to start. Be careful with '4=Remove' and especially with the '9=Recursive Delete' inside of the '2=Edit'. These are handy features to be aware of but very dangerous if your user profile has *ALLOBJ authority.
Browsing the IFS using '5=Display' can be very helpful. A common misunderstanding is that the native file system, shared folders and the IFS are completely different and separate. The native file system (/qsys.lib) and shared folders (/qdls) are part of the IFS. The IFS includes every object on the system.
Objects inside of the QSYS library can be accessed by either the native file system commands or the IFS commands. QSYS is a library that contains operating system objects. It also contains all other libraries on the system. The QGPL library is actually inside of the QSYS library. Running the WRKLNK OBJ('/qsys.lib/qgpl.lib/*') command will show QGPL objects via an IFS command.
Why should I care about the IFS?
Most systems running pure RPG or COBOL applications may not need to pay much attention to non-traditional objects or the IFS. Many environments these days though are very mixed with a variety of applications including client/server, web-based, Java or maybe even some ILE C or C++ code. The IFS is structured similar to personal computer and UNIX operating systems.
These newer applications and their cross-platform focus has forced most operating systems into adopting a consistent file structure. Files are stored in folders. One folder may contain several files and may also contain more folders. If your environment is running an HTTP server with a browser-based application running some Java code - you likely have numerous 'stream files' stored on the IFS. These files need to be monitored just like your physical files and OS/400 program objects.
How do I get an IFS folder saved on one system and restored onto another?
- CRTSAVF FILE(QGPL/TESTSAVF)
- SAV DEV('/qsys.lib/qgpl.lib/testsavf.file') OBJ(('/testfolder')) SUBTREE(*ALL) SAVACT(*YES)
- FTP 10.10.10.10 {at DOS prompt w/ valid IP Address}
- login with valid 'User' and 'Password'
- type BINARY and press ENTER
- cd QGPL {if NAMEFMT 0}
- cd /qsys.lib/qgpl.lib {if NAMEFMT 1}
- lcd c:\
- get testsavf.file
- quit
This file can be emailed as one file attachment if being restored onto another system at a different location or by a different person. If the file is too large to email, use the DTACPR(*YES) parameter on the SAV command.
The restore procedure on the target system is as follows:
- CRTSAVF FILE(QGPL/TESTSAVF)
- FTP 10.10.10.10 {at DOS prompt w/ valid IP Address}
- login with valid 'User' and 'Password'
- type BINARY and press ENTER
- cd QGPL {if NAMEFMT 0}
- cd /qsys.lib/qgpl.lib {if NAMEFMT 1}
- lcd c:\
- put testsavf.file
- quit
- RST DEV('/qsys.lib/qgpl.lib/testsavf.file') OBJ(('/testfolder')) SUBTREE(*ALL)
This process is making use of both native file system commands and IFS commands. The save file is a native OS/400 object stored in a library. It is created with the traditional commands. The SAV and RST commands are IFS versions of the SAVOBJ and RSTOBJ commands.
The Workload Performance Series software has significant enhancements within its Disk Navigator tool. Many of these new features relate to detailed 
analysis of the entire Integrated File System - all objects on the system.
Most IBM commands and disk space analysis tools provide functionality for analyzing objects in libraries, objects in shared folders and objects on the 'IFS'. As mentioned earlier, the IFS includes all objects on the system. Why treat them differently? Why provide one set of functionality for data in libraries and different features for shared folders and the rest of the IFS? Our new Disk Navigator takes a unique approach of analyzing all objects together and treating them equally. If JPEGs in folders on the IFS account for more DASD usage than physical files, program objects or data areas - you will easily see this with our data collection approach. You may have huge TIFF files stored in old shared folders.They would show on the top of the list.
You can analyze statistics by object type, object name or library name. A library name will only show for objects stored in the OS/400 native file system. Having the entire system's objects in a single data view or on a single chart gives you a complete picture of what is consuming the DASD on your system.
A new and creative way of looking at this data is through what we call a 'Path Token Analysis'. Through this data view, you are able to see the total size of all objects on the system that contain the word 'TEMP' anywhere in its file name or IFS file path. You may have a 'TEMP' folder on the root of the IFS. There may be several 'TEMP' folders and files throughout the system. There might be some programs, physical files or data areas called 'TEMP'. This 'token' analysis summarizes the statistics for all of these objects across the entire system.
This is an interesting way to analyze DASD usage. You may have temporary folders and files scattered across the system or maybe a user profile shows on the list.