The Four Hundred

In last week's Admin Alert, I began a simple primer on how to move all objects and subdirectories in an IFS directory from one iSeries to another. At the end of that article, I saved an IFS directory called tfh to a save file called ADMIN/TFHSAVE. This week, I'll cover how to send your save file to another iSeries box and restore that tfh directory on that box.

The quickest way to move our save file to another iSeries is through the OS/400 FTP command. If your source OS/400 box can directly reach the target iSeries or AS/400 through TCP/IP, you can open a simple FTP session and directly transfer your save file.

To use FTP, the OS/400 FTP server must be active on both your source and your target AS/400. The FTP server can be started by using the green-screen Start TCP/IP Server (STRTCPSVR) command or by using iSeries Operations Navigator. To use STRTCPSVR to start FTP, enter the following string from a command line:

To start FTP from Operations Navigator, open the Network-Servers-TCP/IP node and right-click the FTP entry. From the pop-up menu that appears, select Start, and your FTP server will start.

To open an FTP session with a target AS/400 whose IP address is designated by an entry in your source iSeries' host table, you can use the OS/400 FTP command to open a session with that machine, as follows:

The FTP server session will prompt you for your user ID and password to begin the session. After signing on, you could transfer the TFHSAVE file to the target iSeries by entering the following FTP subcommands inside your FTP session:

The NAMEFMT 1 command tells FTP that this transfer will be done using IFS file notation. In many instances, OS/400 FTP will automatically change your session to NAMEFMT 1 when it sees an IFS naming convention being used, but I've always preferred to explicitly specify NAMEFMT 1 in my sessions, to ensure a clean transfer. The BIN command tells FTP that this is a binary transfer, which will transfer the save file, bit-by-bit, without attempting to translate the file to the format used by the receiving system. Binary transfers are generally the fastest type of FTP transfer.

The PUT statement explicitly takes our ADMIN/TFHSAVE save file and transfers it to the ADMIN library on our target system. The confusing thing here is that the IFS syntax we're using is different from what we used in the SAV command in the last issue. In SAV commands, we use .FILE in our DEV pathname to tell SAV that our device was a save file. However, when using an FTP GET or PUT subcommand to transfer a save file, I usually specify the object type of the save file as .SAVF, because it makes for a more reliable transfer. If the ADMIN/TFHSAVE file isn't already present on the target OS/400 system, the PUT will create the save file on the target machine as part of the transfer. If you specify .FILE in the FTP save file path name, or use NAMEFMT 0 in the transfer (which doesn't use IFS notation), OS/400 will transfer your save file, but it may mark it as a regular file on your destination iSeries or AS/400, not as a save file object.

When dealing with FTP, however, it's not always possible to perform a direct transfer between OS/400 boxes. If you're a vendor servicing a client, you may have to e-mail the save file to the client, who will then have to transfer it to an iSeries or AS/400. To retrieve our OS/400 ADMIN/TFHSAVE file to a PC for e-mailing, you can start an FTP session with your AS/400 from a PC client and execute the following FTP subcommands:

We use QUOTE SITE NAMEFMT 1 to send the NAMEFMT command to our target AS/400 for execution (the NAMEFMT subcommand isn't available on non-OS/400 boxes). Executing these subcommands will bring the file down to whatever PC drive and directory you specify as x:/directory, and the PC file name of your save file will be tfhsave.savf.

In this AS/400-to-PC session, a binary transfer (the BIN subcommand) is essential, because we want to park an exact copy of our save file on the PC, which will then be e-mailed and uploaded back to another OS/400 box. We don't want to modify the file in any way, and we especially don't want to convert it from EBCDIC to ASCII format. Since this session is initiated from the PC, we have to use the GET subcommand to explicitly transfer the file to the PC client. Once the tfhsave.savf file is downloaded to the PC, we can send that file as an e-mail attachment to a remote location or to a customer with whom we don't have a direct AS/400 connection.

Once the remote PC location receives the file in e-mail, it can be detached and uploaded to the iSeries or AS/400 by starting a FTP session with the OS/400 box and executing the following FTP subcommands:

The same PUT considerations that applied to AS/400-to-AS/400 transfers also apply here. The BIN subcommand is again used to prevent data transformation as the save file is sent back to an AS/400 environment.

At this point--whether you've performed an AS/400-to-AS/400 transfer or whether your file has been e-mailed and uploaded through intermediate machines--your save file is sitting on your target AS/400, ready for you to restore the IFS directory that is saved within it.

Restoring the directory by using the green-screen Restore (RST) command is probably the easiest part of this process. In our case, we would type in the following command to perform the restore:

Where libname is the name of the library you want to restore the save file to. You'll notice that the RST command has a lot in common with the SAV command we used to save the IFS directory last week. It uses the same IFS syntax--where it marks the save file as a .FILE --and the OBJ parameter is virtually the same as what we used in the SAV. But RST adds two other parameters that tell OS/400 exactly how to handle the restored data. The Directory subtree parameter, SUBTREE(*ALL), tells OS/400 to restore all files and subdirectories that exist under the tfh directory; while the Allow Object Differences parameter, ALWOBJDIF(*ALL), tells OS/400 to allow for any differences that exist between restored objects that have the same name as objects that may already exist in the tfh directory. With this command, all objects that exist in the save file will be restored to the new system. (For a more complete description of how to use the RST command in a single IFS directory restore, see "Restore a Single IFS Directory.")