FTP was one of the first protocols used to transfer files between computers in the early days of the modern Internet. Years ago, I used to log on to the local college’s mainframe computer and FTP files to and fro. It was a fun protocol to learn, and it still is. FTP is a very handy mechanism for moving data between AS/400s or between an AS/400 and almost any other machine, including PCs and UNIX machines. FTP, like HTTP or Simple Mail Transfer Protocol (SMTP), is a standard TCP/IP protocol, which means that, no matter what system you are running, you will be able to communicate with any other system that also uses TCP/IP. In this article, I’m going to share some of the tips and tricks I’ve learned over the years for getting the most out of FTP.

Source Member Transfers

Figure 1 shows the FTP commands you’ll need to enter to retrieve a source member from an AS/400, as well as the responses you’ll get from the FTP server. Notice that the first command you enter after your user name and password, Change Directory (CD), changes the current directory of the host machine to the library BVSLIB. The next command, Local Change Directory (LCD), changes the local directory on your PC to c:download. This is the name of the directory on your local PC where you’ll store the files retrieved from the host.

The next command shown in Figure 1 is the GET command. This command allows you to send or retrieve a file from the host. The naming format for the file in this case is FILENAME.MEMBER. So, in this case, I am retrieving the member TESTPGM from the QRPGLESRC source file. Once the transfer is complete, I will have a file on my PC in the c:download directory named qrpglesrc.textpgm. This file will be a text file, and it can be opened or viewed with a program such as Windows Notepad.

Finally, the QUIT command is issued, which closes the connection to the host machine and, in some cases, ends the FTP client program.

PC to AS/400

The steps to send files to an AS/400 from a PC are exactly the opposite of the steps shown in Figure 1. Figure 2 shows a session that sends the TESTPGM member back to the source physical file QRPGLESRC in library BVSLIB. In this example, I used fully qualified names to illustrate how it works.

Multiple Files

The first two examples were pretty simple. But now I’ll show you how to send or retrieve multiple files from an AS/400. For example, if I wanted to download every member from the QRPGLESRC source file, I would use the Multiple GET (MGET) command. The opposite of MGET is the Multiple PUT (MPUT) command, which is used to send multiple files to a host machine.

Figure 3 shows the commands used for the MGET example. You’ll notice a new command, PROMPT, which tells the host system not to verify that I want to receive each member one at a time. In other words, if I didn’t use the PROMPT command, the host machine would ask whether I am sure that I want to download each particular member.

Trailing Blanks

One problem programmers face when using FTP as a client on the AS/400 is that it is set up as a default to trim trailing blanks from records. What this means is that, if you have a file to be transferred from the PC that has a record length of 250 characters but the longest record in the file is only 200 characters, the file that is created on the remote machine will also have a record length of only 200 characters, rather than 250. This may cause problems on the remote system if the application that needs to read that file is expecting a record length of 250 characters.

This problem is easily solved by using the FTP command TRIM . The TRIM command tells the AS/400 to trim or not to trim trailing blanks during the transfer. This command must be prefixed with the LOCSITE command, which says that the command is applied to the local machine (in this case, the AS/400).

Issuing the command LOCSITE TRIM 0 will turn off trimming. LOCSITE TRIM 1 will turn on trimming. LOCSITE TRIM will display the current mode of TRIM.

FTP Scripts

The next trick that I have found very useful is using a script—either predefined or dynamically created—to tell the FTP client what to do. I have used this method with both Windows and AS/400 FTP clients. While the method performs the same function on both platforms (i.e., telling the FTP client to read its commands from a file), the way it is done for each is fairly different.

To use a script for the AS/400 FTP client, you must use the Override with Database File (OVRDBF) command, which overrides the file INPUT and accesses the file and source member that contains the FTP commands. The standard INPUT and OUTPUT files used by FTP are normally the console running the FTP commands on the AS/400. That is, when an FTP command executes in a script, its output (if any) such as information messages, are directed to the display station the script is executing on. You can override the INPUT and OUTPUT files to a physical file on the AS/400 to capture the output from the FTP script so that any messages issued by the script will be suppressed and the user will not see them.

Figure 4 (page 74) shows the CL command that will tell the FTP client to read its commands from the member FTPSCRIPT1 in file QFTPSRC. The member can be static (hand-keyed with SEU) or built dynami-cally (with an RPG program, for example).

You can also redirect the output produced by the FTP session to a file; the OVRDBF command on the file named OUTPUT does this in Figure 5. In this case, the output will be stored in the file QFTPSRC, member OUT1. OUTPUT is appended to the file, so if you want it cleared before each run, you’ll have to do so yourself. If the file doesn’t already exist, it will be created by the system.

Using scripts with the Windows FTP client is similar. On the FTP command, you specify the file name that contains the FTP scripts. Simply use the -s option on the Windows 9x FTP command and tell it which file to use. For example, ftp

ftp.myserver.com -s:c:ftpscript1.txt tells the Windows FTP client to read its commands from the file script1.txt, located in the FTP directory. Static scripts can be built using Notepad, or the script can be built dynamically with anything from MS-DOS batch commands to Visual Basic.

Using AS/400 Save Files

The last trick, which a lot of people are asking about, is transferring a save file from the AS/400 to a PC platform for storage. I have found myself using this technique when a new machine arrives and I don’t have any tapes available for backups. Saving libraries to a save file and FTPing them to a PC or other server has helped me sleep better at night. This is also a useful technique for transferring save files to other users over the Internet.

Here’s how you do it: Save the objects on your AS/400, FTP them to your PC, attach the *SAVF to an email, and send it to a buddy across the country. When your buddy receives the file, he’ll FTP it to his own AS/400 and restore it. Worldwide object distribution made simple!

The first step is to create a save file on your AS/400 by using the Create Save File (CRTSAVF) command. Next, issue a SAVxxx command just as you would if you were saving objects to a tape, but, for the device type, select *SAVF. The command will then prompt you for the save file location. Once the save is complete, start an FTP session from your PC to the AS/400, switch to binary mode using the BIN command, and then issue a GET command to retrieve the save file. Figure 5 shows an example of this technique.

To restore the data to the AS/400, the steps are the same. First, create a save file on the AS/400. Next, start your FTP session to the AS/400, change to binary mode, and then issue a PUT command. The important parts are that you use binary mode and that you create the save file first. If you don’t create the save file first, a physical file will be created when you issue the PUT command. When you create a save file first, the system knows where to put the data. It will even tell you if you not in binary mode.

How Far Will You Take FTP?

I encourage you to experiment with FTP (on a test machine, of course!) to see what it can do for you. You can use FTP for simple file transfers, or you can use it as the backbone of a complex data transfer system. It all depends on how far you want to take it.

If you have a favorite FTP tip, feel free to send them to This email address is being protected from spambots. You need JavaScript enabled to view it. and the MC tech team may make them available in either a future article or in Tech Talk. We’re always looking for easier ways to perform tasks!

ftp> open 207.212.90.55
Connected to 207.212.90.55.
220-QTCP at MC170.
220 Connection will close if idle more than 166 minutes.
User (207.212.90.55:(none)): userid
331 Enter password.

Password:
230 STONE logged on.
ftp> cd bvslib
250 "BVSLIB" is current library.
ftp> lcd c:download
Local directory now C:Download.
ftp> get qrpglesrc.testpgm
200 PORT subcommand request successful.
150 Retrieving member TESTPGM in file QRPGLESRC in library BVSLIB.
250 File transfer completed successfully.
ftp: 11021 bytes received in 1.70Seconds 6.48Kbytes/sec.
ftp>

Figure 1: A simple FTP session will copy a source member to a PC.

ftp> open 207.212.90.55
Connected to 207.212.90.55.
220-QTCP at MC170.
220 Connection will close if idle more than 166 minutes.
User (207.212.90.55:(none)): userid
331 Enter password.

Password:
230 STONE logged on.
ftp> put c:downloadqrpglesrc.testpgm bvslib/qrpglesrc.testpgm
200 PORT subcommand request successful.
150 Sending file to member TESTPGM in file QRPGLESRC in library BVSLIB.
250 File transfer completed successfully.
ftp: 11021 bytes sent in 3.18Seconds 3.47Kbytes/sec.
ftp> ftp> open 207.212.90.55
Connected to 207.212.90.55.
220-QTCP at MC170.
220 Connection will close if idle more than 166 minutes.
User (207.212.90.55:(none)): userid
331 Enter password.

Password:
230 STONE logged on.
ftp> cd bvslib
250 "BVSLIB" is current library.
ftp> lcd c:download
Local directory now C:Download.
ftp> prompt
Interactive mode Off .
ftp> mget qrpglesrc.*
200 Representation type is ASCII nonprint.
200 PORT subcommand request successful.
150 Retrieving member TESTPGM in file QRPGLESRC in library BVSLIB.
250 File transfer completed successfully.
ftp: 11021 bytes received in 4.01Seconds 2.75Kbytes/sec.
200 PORT subcommand request successful.
150 Retrieving member TESTPGM2 in file QRPGLESRC in library BVSLIB.
250 File transfer completed successfully.
ftp: 9514 bytes received in 3.18Seconds 2.99Kbytes/sec.
200 PORT subcommand request successful.
150 Retrieving member TESTPGM3 in file QRPGLESRC in library BVSLIB.
250 File transfer completed successfully.
ftp: 12841 bytes received in 3.73Seconds 3.44Kbytes/sec.
200 PORT subcommand request successful.
150 Retrieving member TESTPGM4 in file QRPGLESRC in library BVSLIB.
250 File transfer completed successfully.
ftp: 12243 bytes received in 3.57Seconds 3.43Kbytes/sec.
ftp>

OVRDBF FILE(INPUT) TOFILE(QFTPSRC) MBR(FTPSCRIPT1)
OVRDBF FILE(OUTPUT) TOFILE(QFTPSRC) MBR(OUT1)
FTP RMTSYS(ftp.myserver.com)
DLTOVR FILE(INPUT OUTPUT) ftp> open 207.212.90.55
Connected to 207.212.90.55.
220-QTCP at MC170.
220 Connection will close if idle more than 166 minutes.
User (207.212.90.55:(none)): userid
331 Enter password.

Password:
230 STONE logged on.
ftp> cd qgpl
250 "QGPL" is current library.
ftp> lcd c:savefiles
Local directory now C:savefiles.
ftp> bin

Figure 2: The steps to send a file to the AS/400 are the opposite of those in Figure 1.

Figure 3: Use the MGET method in an FTP session to retrieve multiple files from an AS/400.

Figure 4: You can use CL commands to tell the AS/400 FTP client to read its commands from a file.

200 Representation type is binary IMAGE.
ftp> get bvslib
200 PORT subcommand request successful.
150 Retrieving member BVSLIB in file BVSLIB in library QGPL.
250 File transfer completed successfully.
ftp: 228096 bytes received in 73.71Seconds 3.09Kbytes/sec.
ftp>

Figure 5: Retrieve a save file from an AS/400 via an FTP session.

Also Read

RPG Academy - Database Modernization: Entity Relationship Diagrams

RPG Academy - Database Modernization: A Bit of Database Theory

Talking About Modernization Isn’t Good Enough