02
Mon, Dec
0 New Articles

Share Files with UNIX Systems Through AS/400 NFS

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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


 SERVER: Fido

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


 SERVER: Fido


proj1




Figure 2: Starting the NFS servers from Operations Navigator



Share_Files_with_UNIX_Systems_Through...08-00.png 900x510





Share_Files_with_UNIX_Systems_Through...08-01.png 897x702

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





Share_Files_with_UNIX_Systems_Through...09-00.png 900x483
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: