OS/400 File Systems
Where Web Server/400 stores Web content differs from most Unix and PC based
Web servers. This is due to the rich variety of file systems that OS/400
supports. Each file system is available for different purposes, each
having its own uses and specialties.
In comparison, a Unix product would only access data off of one file system
(one similar to the Root file system). On an AS/400, supporting only a
subset of the above file systems would be extremely limiting. Each file
system has its own advantages and uses making
them all useful for storing data served by a Web server.
A Uniform Resource Locator (URL) describes where to find something of
interest stored somewhere on the Internet. A URL has enough information in
it to uniquely describe any resource on any host anywhere in the world.
The basic form of a World Wide Web URL is:
- QSYS is what most people refer to as the file system
of OS/400. It consists of libraries and objects. Some of the types of
objects are database files, programs, and spooled files.
- The common names for this are Document Library Services (DLS) or shared
folders. Office Vision/400 uses DLS to store data generated by Office
users. Shared folders is the file system accessible by PC Support/400
- With the release of V3R1 of OS/400, a new Integrated File System (IFS)
was introduced. IFS is an all-encompassing file system that includes all
of the above file systems and additional ones. The "Root" file system is
part of IFS and is based on Unix. In these pages, "Root" will refer to all
file systems in IFS except QSYS and QDLS. IFS can be accessed through a
new set of commands and APIs and also through the new Client Access/400
- is the protocol being used. Over the Web, the Hypertext Transfer
Protocol (HTTP) is used. This is the language spoken between servers and
- is the fully qualified domain name of the machine that contains the
- is the socket port on the host machine that is running the HTTP server.
The :port is optional. If the port is not included, it defaults
to port 80.
- is the fully qualified, hierarchical path to the resource. This can be
based on the machine's file system hierarchy or an arbitrary (but unique)
naming scheme. An empty URL-path is valid.
- Query String
- The Query String begins with the first unescaped question mark ("?")
after the URL-path. This is generally used to pass parameters into scripts
or to modify the default behavior of serving a Web document.
Three factors come into play when the server attempts to locate the
resource that is requested by the browser:
- Identifies the file document.html in the samples
directory on the host www.inetmi.com. The request is an HTTP
request that is handled by the Web server running on port 80 (the default).
- Identifies the directory samples on the host
www.inetmi.com. The request is an HTTP request that is handled by
the Web server running on port 2064.
- Identifies the image jane_doe.jpg in the
/company/info/employee/profile/ subdirectory on the host
your.host.net. The request is an HTTP request that is handled by
the Web server running on port 80 (the default).
- the URL-path,
- the source file system, and
- the root of all documents on that file system.
Once a server starts handling a request from a browser, the URL-path is the
most interesting portion of a URL. The other portions of a URL are
responsible for correctly routing the request to the proper host. The Web
server then takes the URL-path and determines what should be sent back to
URL-paths are typically hierarchical with the structure indicated by
names separated by slashes ("/"). This is very similar to path names on
Unix or PC file systems or OS/400's new IFS. In fact, for the most part
Web Server/400 does map a URL-path's hierarchy directly to IFS's
directories and files. So when a browser requests a URL-path of
/abc/xyz.html, the server looks for a directory called
abc with a file in it called
The URL's Source File System
Web Server/400 determines which file system contains the data needed to
serve a request through configuration values, aliases, and the URL-path. The URL-path is
checked to see if it begins with a configured alias. If it does not, the
Default Source Type configuration value indicates
where the URL-path points to. If the URL-path does begin with an alias,
the alias can indicate a file system to use other
than the default.
All three file systems, QSYS, QDLS, and Root, have a different location to
begin looking for files in that file system. This location is referred to
as the Document Root. All URL-paths are
relative to the appropriate Document Root.
The Root and QDLS file systems each have configurable document roots that
are quite similar: Document Root and
Document Root QDLS, respectively.
The QSYS file system really has two document roots.
- The Document Root QSYS is similar to
the Root and QDLS document roots. QSYS's document root is configurable and
URL-paths are searched for in this library. However, not
all URL-paths are considered relative to the Document Root
QSYS. Only URL-paths that do not include an explicit library are relative
to the Document Root QSYS library. So, a URL-path that contains only a
file and member would be considered relative to this special library. This
is especially useful when the Default Source
Type is set to QSYS. Then the Index Name
Web document is pulled from the Document Root QSYS library if it doesn't
have a path on the beginning of it. Note: Be sure to add
the library specified by Document Root QSYS to the Include Libraries configuration value.
- The other QSYS document root is QSYS itself. All references to
URL-paths that have a library in them are relative to QSYS. This is
because all libraries are in QSYS and QSYS is the only library that can
contain libraries. This limited hierarchy forces URL-paths with
library names to be relative to QSYS.
An example is in order. Assume that the Default Source Type is the Root
file system and that an alias exists that maps all
/qsys.lib/ and that the Document Root for the
Root file system is set to
/webpages/. If a user requests a
/info/page.html, then the server would look in the
Root file system for the file to serve since
info is not
aliased and the Default Source Type is the Root file system. The
server would then make the URL-path relative to the Document Root. This
would cause it to look for the file
If the user requests a URL-path of
/library/ProdData.lib/Prices.file, the server would look in
the QSYS file system for the file since the alias maps all references
/library/ to files in QSYS. It would then
look for the file
PRICES in the library
Although a URL-path is generally directly mapped to a file system's
directory structure, this doesn't have to be the case. In several cases,
Web Server/400 defines a logical URL-path to a physically different file
system path. The usual reason for this mapping is to fit a feature of
OS/400 into something consistent with typical URL-paths. This makes for a
more seamless integration of OS/400 concepts with the WWW.
The details of URL-paths are separated out by file system and type of
resource being referred to: