FTP works everywhere, but it's not always the most practical solution; sometimes you just need to mount a drive.

The more integrated the IBM i gets, the more ways it needs to touch other systems. Tools abound that allow us to stretch beyond the boundaries of traditional DB2 data into everything from XML to PDF to ZIP files. The IFS affords a wonderful place to store those files, but you can't just create them; eventually you have to share them with others. FTP is an old standby: simple yet extremely flexible. Email is another popular approach. But today we're going to learn about something just a little sleeker. Welcome to the world of Network File System (NFS) files!

To FTP or Not to FTP

FTP's simplicity is probably why it's one of the most common techniques in use today. But "simple" is a relative term; while FTP is very easy to use from a command line, and even easier to use with a desktop client, it's not always the easiest thing to do programmatically. In fact, there are really two programmatic techniques: scripting and sockets.

Scripting is the easier technique: you create a text file with the commands you want to run, and then you use the FTP command to run the script. The rather barebones approach does have a drawback; it's not very helpful when it comes to handling errors. You have to parse the output, kind of like running through a joblog or a compile listing. Not difficult, but definitely not elegant.

If you like getting your hands dirty with some low-level programming, the sockets approach may be more your style. You get to pretend you're the FTP client, and you get to talk directly to the FTP server, one packet at a time. It's very rewarding if you like that sort of thing, but also not for the faint of heart. Building an RPG sockets program from scratch is a rather arduous undertaking, but luckily you don't have to do that; there's a wonderful tutorial available. Almost anybody who has learned sockets programming in RPG in the last decade or so has at least taken a look at Scott Klement's tutorial, and if you find yourself leaning in that direction, I highly recommend it.

Email is another technique, but unless your IBM i is your primary mail server (unusual but not unheard of even in these days of Exchange Server ubiquity), it's going to require some programming. We do it using Java; we have a Java server that does all sorts of things that Java does well, one of which is sending email. You could probably whip something up in RPG if you had to, but I don't even have a link to an example. Java is simply much better at it.

But When Do I Use NFS?

Yes, we should return to the topic at hand, which is NFS mount points. Mounting an NFS drive is much simpler. If you can copy a file into an IFS folder, with an NFS mount point you can copy it to another machine—or another country! For today's purposes, I'm only going to talk about using the IBM i as an NFS client; that is, we'll copy a file from an IFS folder on the IBM i to a folder physically residing on another machine. You can set the IBM i up as an NFS server, meaning that other machine can copy files to your IFS. But that's another topic.

To me, the beauty of the NFS technique is that it's very familiar to most of the folks who have some knowledge of the IBM i. Your Linux admins and Apple fans and, yes, your Windows developers will all understand the concept of an NFS mount point and will know how to export one. And since the majority of the work is in the export of the mount point, your job is very simple. Let me show you just how simple:

ADDMFS TYPE(*NFS)                  

       MFS('MYNFS:/ibmi/pdfreports')

       MNTOVRDIR('/pdf/reports')  

       OPTIONS('rw,timeo=20,soft')

The ADDMFS command can be broken into two basic sections: the connection and the options. The first three keywords identify the connection. The type is *NFS (other values exist, but we're not going to be talking about either *UDFS or *NETWARE in this article). The MFS is the full network address of the folder you're connecting to; your network administrator supplies you with this name. The MNTOVRDIR identifies the folder on your IFS that you want to act as the conduit between the two machines. The last keyword is OPTIONS, and it contains a comma-delimited list of keywords that specify various characteristics of the connection. You can learn about all the options and more at the IBM Knowledge Center. The ones that I find most important are the access type and the mount type. Access type (also called protection) is either ro (read only) or rw (read write). Clearly, if you're writing to the folder, you'll want rw, but other applications might require mounting an external file system for read access (say, to access images). Mount type is either soft or hard. I almost always use soft simply because hard is rather unforgiving. If your target stops responding, your machine just sits and retries…forever. You have to cancel the job. Finally the timeo value (which only makes sense if your mount type is soft) is a little tricky; it specifies the length of the first timeout in tenths of a second. So the timeo factor in the example specifies an initial 2-second timeout.

If you need to remove the mount point, the RMVMFS command does the trick. Just specify the TYPE and MNTOVRDIR keywords and you're done.

A Final Note

You might want to consider something about NFS mount points: they tend to be used exclusively behind a firewall. Typically, the two machines are part of a larger, trusted IT infrastructure. You won't usually see NFS mounts over externally addressable IP addresses. In fact, NFS mounts work best on LAN-connected machines; even WANs can insert enough latency to make them act up. So if you're sending PDFs to a customer, you still have to fall back to FTP or email. But if you want really fast, really easy transfer within your network, you should consider NFS mount points.