As more AS/400s move into UNIX environments, the demand for file sharing with UNIX computers by using the Network File System (NFS) protocol has increased incredibly. This article teaches you everything you need to know about AS/400 NFS and how you can start using NFS to exchange files today between OS/400 and your UNIX systems.

To communicate with someone, you must speak that person’s language. When it comes to the language of computer file sharing, however, there is probably no better known protocol (in the UNIX world, at least) than Network File System (NFS). Fortunately, this happens to be a language the AS/400 speaks fluently.

In this article, I describe how the AS/400 speaks NFS. I review what options are available, how to get started, how to export and mount directories, how to choose among language support options, and how to control NFS graphically by using some new options that are now available in Operations Navigator. I address all the OS/400-specific commands and concepts you need to quickly start using NFS on your AS/400.

AS/400 NFS Basics

IBM first released its full NFS client and server implementation in OS/400 Version 3, Release 7 (V3R7). AS/400 NFS supports Version 2 of the NFS specification, and it is installed as part of the base OS/400 operating system. Before V3R7, a TCP/IP system application called File System Server (FSS/400) was available that contained partial server- side NFS functionality. NFS for AS/400 is the replacement for FSS/400, and you should migrate existing FSS/400 applications to the new implementation. Migration information is available in Chapter 6 of the Exploring NFS on AS/400 Redbook.

You use NFS on the AS/400 the same as you would use it in a UNIX environment. If you are already familiar with NFS, adding an AS/400 server or client is easy. In many cases, the same /etc/exports file used by UNIX-based NFS platforms can be used directly

by AS/400 NFS. You need only to FTP it over to the /ETC directory on the AS/400. Be aware, however, that some NFS implementations, such as Linux, have changed the format of exporting file systems. If you are not familiar with NFS, using your AS/400 to provide file sharing with NFS only takes a few simple steps. Please refer to the sidebar, “Learning the NFS Lingo,” for a short introduction.

Unlike most UNIX platforms with a single type of file system, the AS/400 contains a variety of native and network-based file systems residing under the AS/400 Integrated File System (AS/400 IFS). The AS/400 IFS provides a common set of APIs and commands that work with data in a consistent way, regardless of the file system. Each file system can be reached from the / (slash or root) directory in the root file system. Since NFS is a part of the AS/400 IFS, many of these interfaces can be used transparently within or under NFS mount points.

Several AS/400 file systems can be exported through NFS. These include the root file system, QOpenSys, QDLS, QSYS.LIB, and QOPT. For example, your C source file members in /QSYS.LIB/MYLIB.LIB/QCSRC.FILE can be exported and edited from a UNIX or PC client. The variety of data that can be exported makes NFS a powerful tool. However, it should be noted that some traditional AS/400 objects cannot be accessed through NFS, including externally described database (DB2/400) files. NFS was designed to handle stream file objects and cannot process objects that contain different field formats within their records.

In addition to its export capabilities, remote NFS file systems can be mounted over AS/400 directories. A mounted file allows your AS/400 applications or client to access a location in the AS/400 IFS—such as in the root file system, the QOpenSys file system, NFS, or UDFS (User-defined File System)—that points to a storage location on another non-AS/400 system running NFS. With exporting and mounting, files can be shared between any other NFS system and the AS/400.

Starting AS/400 NFS Is Easy

Before starting NFS on your AS/400, you need to ensure that TCP/IP is running and configured properly. The Start TCP/IP (STRTCP) command starts your TCP/IP servers, and the Configure TCP/IP (CFGTCP) command brings up the TCP/IP configuration menu. If a Domain Name System (DNS) is present in the network, it should be configured under option 12 (option 13 prior to V4R2) in CFGTCP.

If no DNS is available, NFS requires that both the short and long names of the NFS host, and the other hosts it will communicate with through NFS, be in the TCP/IP Host Table for their respective IP addresses. The short name (e.g., MYHOST) is just the name given for a particular IP address, and the long name consists of the short name appended by a dot and the domain name (e.g., MYHOST.NETWORK.DOMAIN.COM). A missing long name for an IP interface can be added under option 10 of the configuration menu. This step needs to be taken for each AS/400 on the network using NFS for which there is no DNS available to perform name resolution.

In many cases, the only other requirement prior to starting NFS support is to make sure your profile has been enrolled in the system’s distribution directory by using the Add Distribution Directory Entry (ADDDIRE) command. In addition to enrolling the administrator who will start the servers, if the Documents and Library Services (QDLS) file system is going to be utilized, then any user who will access QDLS through NFS also needs to have a distribution directory entry on the AS/400 server. This includes the NFS anonymous profile (QNFSANON), if anonymous access is allowed.

The Start NFS Server (STRNFSSVR) command starts the NFS server daemons while the End NFS Server (ENDNFSSVR) command ends the daemons. If you are new to NFS, it is recommended that you use the command defaults (i.e., STRNFSSVR SERVER(*ALL) and ENDNFSSVR(*ALL)) to start and stop the six NFS daemons in the correct order. You are required to have *IOSYSCFG authority to issue these commands. To determine if the NFS daemons are currently running, use the Work with Active Jobs

(WRKACTJOB) command and check under the QSYSWRK subsystem for the following daemon jobs:

• Remote Procedure Call binder daemon (QNFSRPCD)
• Block I/O, or BIO, daemon (QNFSBIOD)
• NFS server, or SVR, daemon (QNFSNFSD)
• Mount, or MNT, daemon (QNFSMNTD)
• Network Status Monitor, or NSM, daemon (QNFSNSMD)
• Network Lock Manager, or NLM, daemon (QNFSNLMD) If you find that only some of the daemons are started, it is best to end all the daemons before issuing the STRNFSSVR *ALL command to start them in the proper order.

You can add STRNFSSVR to the QSTRUP program to automatically start NFS support after an IPL. These daemons are used by both the NFS client and server, and for two of these daemon types (QNFSNFSD and QNFSBIOD), you can start more than one instance of that daemon to improve performance and throughput. For example, if your AS/400 is a heavily used NFS server, you can start up to 20 QNFSNFSD jobs to better handle the traffic load. To do this, execute the STRNFSSVR SERVER(*SVR) NUMBER(20) command after you have started up the other servers normally.

Exporting Objects from Your AS/400

The command you use to make an AS/400 file system accessible to clients is Change NFS Exports (CHGNFSEXP) or its alias, Export File Systems (EXPORTFS). The user issuing this command is required to have *IOSYSCFG special authority. Note here that all the NFS commands are available through the NFS command menu, accessed by typing GO CMDNFS on the command line. On the menu, select option 6, Change NFS Export. This executes CHGNFSEXP, enabling you to add other exports and to change existing export options. There are two methods for exporting a file system or path.

The first method involves using the /ETC/EXPORTS file, just as you would in a UNIX system. The following command tells the system to export each of the paths listed in the /ETC/EXPORTS file using the options also specified in the file:

EXPORTFS OPTIONS(‘-A’)

This method is recommended because exports are not persistent across IPLs. This command can also be added to the QSTRUP program so that the same exported objects are available at IPL. If you do not have an /ETC/EXPORTS file, STRNFSSVR creates a default file for you containing instructions and examples on how to add export entries to it. A sample /ETC/EXPORTS file is shown in Figure 1. For information on editing this file, consult section 3.5 of the Exploring NFS on AS/400 Redbook.

The second export method allows you to export one path at a time using only the EXPORTFS command. Use this to quickly start NFS or if you don’t plan to use the /ETC/EXPORTS file. With this method, the DIR parameter specifies the absolute path (beginning with /) being exported. The OPTIONS parameter must begin with the -I flag to tell the system to ignore the /ETC/EXPORTS file and just export this single path. Other flags and options may be specified on the OPTIONS parameter. For example, the following command exports the /home/data directory, with all of its objects and subdirectories, using the default options (universal read-write access, anonymous access allowed, root access not allowed):

EXPORTFS OPTIONS(‘-I’) DIR(‘/home/data’)

You can specify more explicit options in the command, such as the following:

EXPORTFS OPTIONS(‘-I -O access=host01:host02:nfsgroup, +

rw=host01,root=host01,anon=-1’) [.notequal]

DIR(‘/home/data’)

In this example, EXPORTFS exports the /home/data directory, but now only clients host01, host02, and those in the nfsgroup netgroup are able to access it. Everyone else is excluded. In addition, only the host01 client has read-write access. Requests coming from host01 with user IDs (UIDs) that map to AS/400 profiles with *ALLOBJ (i.e., root authority) will be honored; in other words, users will not be mapped to the anonymous profile as they would if the ROOT= option was not specified). Additionally, the anon=-1 option means that requests from anonymous users are not allowed. For further explanation of the EXPORTFS options, please consult the NFS documentation listed in the References section at the end of this article.

To “unexport” a file system (so it is no longer accessible through a client mount point), use the EXPORTFS command with the -U option. For example, the following command unexports the /home/data directory:

EXPORTFS OPTIONS(‘-U’) DIR(‘/home/data’)

To unexport all NFS exported file systems on the machine, use this command:

EXPORTFS OPTIONS(‘-U -A’)

Mounting and Accessing UNIX Files Through AS/400 NFS

To enable the AS/400 as an NFS client on the network, perform the mounting operation by using the Add Mounted File System (ADDMFS) command or its alias, MOUNT. Remove a mounted file system by executing the Unmount (UNMOUNT) command. These and other related commands are accessed from the Mounted File System commands menu reached from option 12 of the CMDNFS menu.

For example, to mount the exported /clients/profiles directory from the server (here, called WARRIOR), issue the following command:

MOUNT TYPE(*NFS) MFS(‘WARRIOR:/clients/profiles’) +

MNTOVRDIR(‘/clientdata’) +

OPTIONS(‘timeo=60,soft’) CODEPAGE(*BINARY *ASCII)

The TYPE parameter indicates the file system type being mounted (*NFS, *NETWARE for NetWare files, or *UDFS for a User-Defined File System). The MFS parameter specifies the name of the server followed by a colon (:) and the file system you want to mount. [Editor’s Note: For NetWare and UDFS, the syntax for defining the host server path name is different. Consult your documentation for the correct syntax.] The MNTOVRDIR parameter contains the location on your local AS/400 client to place the remote file system.

Other parameters available on the MOUNT command include OPTIONS and CODEPAGE. In many cases, the defaults are all you need to complete the mount correctly. The OPTIONS parameter contains various mount preferences that are similar to the options available on the UNIX mount command. In the previous example, a request will timeout after six seconds (60 tenths) before it is retried and the mount is designated “soft,” meaning retries (if no response comes from the server) will be performed for only the default number of times before failing.

The CODEPAGE parameter is specific to OS/400’s NFS and is part of the National Language Support (NLS) discussed in the next section. In the previous example, the client expects the file data to come over-the-wire with no conversion (*BINARY), and it expects the file names to come in ASCII (the actual code page is the ASCII equivalent of the default job Coded Character Set Identifier, or CCSID).

Language Is No Problem with AS/400 NLS

AS/400 NFS takes advantage of OS/400’s National Language Support (NLS), which is useful for international companies that need to share natively stored data. Textual data stored in the code page of one country can be converted on the fly into the code page that another client expects. NLS is also crucial for clients sharing files in a network in which an ASCII-to-EBCDIC or EBCDIC-to-ASCII conversion is needed. Only the client or the server needs be an AS/400 to take advantage of this support. First, I’ll discuss the AS/400 server.

The EXPORTFS command has an optional set of parameters called Host Options that can be specified for a certain client or netgroup. By default, no conversion is performed on data, while path name components are sent in an ASCII code page. With the parameters, you can specify the code pages for each client (or netgroup), and the outgoing data or path names will be converted appropriately. For data coming in from a client, these are the expected code pages for receiving data and path names.

As previously mentioned, the MOUNT command for AS/400 clients also contains code page options. In the AS/400 IFS, each data file is tagged with a code page (or 65535 for binary). So, for example, if you were to specify 297 for the data file code page on a mount, the AS/400 IFS APIs will now assume the data is stored in the ASCII French character set and interpret the data correctly.

NFS Gets Graphic with Client Access Operations Navigator

With OS/400 V4R3 and Client Access for Windows 95/NT V3R2, IBM added several key features to the Operations Navigator program that runs on Windows 95/NT PCs with Client Access installed. Operations Navigator provides a Windows Explorer-like interface for performing AS/400 system management functions. NFS management has been included in Client Access V3R2 Operations Navigator, so NFS server operations and file export are integrated right into its GUI.

Figure 2 displays the Operations Navigator exploring the “Asbigboy” AS/400 primary environment. The left pane shows that you have expanded the Network category, and, inside that, you have expanded Servers for Asbigboy. Click on TCP/IP, and once you locate the NFS server entry in the list shown on the right-hand pane, right-click on the entry and the pop-up menu shown in the figure will be displayed. From here, you can start and stop your NFS servers—either all at once or individually—and add, remove, or modify NFS exports.

This support can be used in lieu of the AS/400 green-screen commands displayed previously in the article. (You’ll need at least *IOSYSCFG authority.)

You can also use Operations Navigator to create exports by cruising through the File Systems category, as shown in Figure 3. The File Systems category is expanded in the left pane and the contents of the QOpenSys file system are displayed in the right pane. With this interface, you can easily navigate through the file systems and directories to find the folder you wish to export. In this example, you have chosen the exptdir folder and right- clicked it to display the pop-up menu shown. Choose NFS Exports, then Properties to bring up the dialog box shown in Figure 4. From here, you can select the export options desired and then export the directory/folder. (In the figure, I have added the sunfire5 client so that I could give it different access properties to this directory.)

NFS = File Sharing Between Many Computers

Are you wasting time and space FTPing files between machines so your applications can continue processing the data? Why not let your applications access the data seamlessly through NFS? As you can see, AS/400 NFS is a powerful tool that allows you to easily share remote files with any NFS-based system. It acts as an interpreter between the network and your OS/400 file systems and applications. It’s easy to set up, flexible, and even contains its own graphical interface, courtesy of Client Access’ Operations Navigator. With so much going for it, there’s no reason you cannot start sharing files between UNIX and AS/400 boxes today. With NFS, they all speak the same language.

References

Exploring NFS on AS/400, Redbook (SG24-2158-00) OS/400 Integrated File System Introduction V3R6 (SC41-4711-00, CD-ROM QBJAUH00) OS/400 Network File System Support V3R7 (SC41-4714-00, CD-ROM QBJADC00) V4R3 AS/400 System API Reference V4R3 (SC41-5801, CD-ROM QB3AMA02)

Learning the NFS Lingo

Originally developed by Sun Microsystems in the mid-1980s, the Network File System (NFS) has become one of the most popular file sharing standards in the UNIX community. NFS has a number of qualities that account for its prevalence:
• Simple, stateless protocol design
• Seamless and transparent data sharing
• Implementation on a wide range of platforms
• Independence from transport protocols, operating systems, and file systems

NFS allows a computer on the network, called the server, to share files with many other network hosts. These other hosts are termed clients, and, once a connection is made from the client to the shared file system on the server, users access the remote files as if they were local files. NFS file sharing eliminates the need for storing duplicate copies of files on every network host since each client can access the same set of files.

There are several terms associated with NFS file sharing that you should know. The first is called exporting. This action is done on the server, and it makes a specified file system, directory, or object visible to remote clients. The server system administrators decide which files and/or directory subtrees are to be exported and how they are to be exported. For example, you may choose to export one directory to all clients as read- only while restricting the access of another directory to a specific set of clients.

Usually, the exported objects and their respective options are specified in the /etc/exports text file (on UNIX-based platforms). Exporting to a specific group of clients is more easily facilitated though the use of a netgroup. A netgroup is just a name given to a collection of hosts defined in the /etc/netgroup text file.

The client-side counterpart to exporting is called mounting. Once the exports have been specified on the server, a client can mount a particular exported directory (subtree, folder) over some portion of its local name space (the logical area containing all the named objects accessible on your system). This local directory or drive that is mounted over is called a mount point. For example, a UNIX client might mount a remote file system over /home/fondo while a PC client might mount it over drive L: (a designated network drive). Now files in the remote file system appear locally at the client’s mount point. The old contents of /home/fondo and L:, respectively, are “covered” or “mounted over” by the remote file system through NFS. They are not deleted and will be visible again once the remote file system is unmounted. See Figure A for a visual representation of mounting. Usually, administrators will mount a file system over an empty directory, but Figure A shows how the FIDODATA directory is covered up so that file B is no longer accessible.

While mounted, operations performed on or under the mount point appear local to the user but are really sent as requests to the NFS server and the processing on the objects happens there. To handle the communications between the client and the server, NFS uses the Remote Procedure Call (RPC) facility. RPC is itself a common, stateless network protocol that lends itself easily to the NFS paradigm. The NFS protocol has had several versions, but almost every implementation today (including AS/400) supports at least Version 2 (released by Sun in 1985) of the protocol.

Client: Zorba2

home proj2 home proj2

misc misc

fidodata B fidodata

proj2

Figure A: The process of mounting a directory using NFS

# Example: Exporting to a host and specifying all options
#

#

#

/home/joe access=sammy
#HOSTOPT HostName=sammy,

PathNameCodePage=367,

DataFileCodePage=850,

NoWaitForWrites

Figure 1: A sample EXPORTS file for specifying exports when the EXPORTFS command is used

data2 data2 data1 data1

proj1 proj1

Client: Zorba2

proj1

Figure 2: Starting the NFS servers from Operations Navigator

Figure 3: Exporting a directory from Operations Navigator is easy with the right-click popup menu

Figure 4: Selecting export options with the new NFS Export dialog in Operations Navigator