Healing Failed Windows-i5/OS FTP Transfers

Published: October 22, 2008

Hey, Joe:

I tried running the attached FTP script to automatically transfer AS/400 Integrated File System (AS/400 IFS) files to a Windows server, but I can't get it to work. I can run my transfer commands manually but not automatically. Can you tell me what I'm doing wrong?

--Dave

Thanks, Dave. I'll give it a shot. Here's the FTP script that you sent me.

OPEN system_name
USERNAME
PASSWORD
CD /ifs_directory_name
LCD C:\directory_name
MGET *.*
QUIT

Here's the Windows FTP command that you're using to run the script.

ftp -s:getfile.scr system_name

Once you run the command, you get the following FTP error:

> User (system_name:(none)):
< 501 User name not valid in USER subcommand.
< Login failed.

Here's what I think is happening.

In your Windows FTP statement, you added the name of the i5/OS system (system_name) that you're connecting to as the last parameter of that statement.

ftp -s:getfile.scr system_name

This initiates the connection with your AS/400, iSeries, or System i box. However, in your FTP script file, you also have this Connect to FTP Server on a Remote System subcommand (OPEN) listed.

OPEN system_name 

In your case, OPEN tells FTP to attempt a second connection to your system. However, because the connection is already open, the automated FTP transfer won't execute this command. Instead, the transfer tries to use the values in the OPEN subcommand as the user name and password to sign on to your system with (because it's the first line in your FTP script). At that point, your automated FTP connection fails because it can't sign on with that information.

To combat this problem and to test my theory, I changed your FTP statement and your FTP script to the values below.

Updated Windows FTP command:

ftp -s:test.scr -i system_name

Updated Windows FTP script:

USERNAME
PASSWORD
QUOTE SITE NA 1
CD /ifs_directory_name
LCD C:\directory_name
ASCII
MGET *.*
QUIT

After I made the changes, the automated transfer worked. Here's what I did and why it worked.

1. I eliminated the redundant OPEN command in the FTP script. This solved your user sign-on problem by allowing the script to use the correct USERNAME and PASSWORD values when signing on.

2. I added a Select File Naming Format (QUOTE SITE NA 1) subcommand to the script. The NA command tells i5/OS to accept IFS naming file formats during the transfer (format '1'). By default, the system uses naming format '0', which only allows FTP to use standard i5/OS library names in the CD and MGET commands. On your system, the transfer might work depending on what the default system value is for your FTP Initial Naming Format parameter. You can check the default value by prompting the Change FTP Attributes (CHGFTPA) command, as follows.

CHGFTPA

Look at the Initial name format (NAMEFMT) parameter. If it is set to *LIB, your default naming format value is '0'. If set to *PATH, the default naming format value is '1'. For more information on the Initial File Naming Format and other FTP configuration parameters, see this article on Configuring OS/400 FTP.

3. To allow the Copy Multiple Files subcommand (MGET) command to work, I added the –i parameter to the Windows FTP call statement, like this:

ftp -s:test.scr -i system_name

The -i tells FTP to ignore any interactive prompting during multiple transfers. This eliminates hang-ups caused when FTP prompts for a confirmation on each file transfer that is initiated through MGET. With –i, MGET transfers all its files without any user interaction. The need for this fix appeared after I solved the sign-on problem in point 1.

4. I added the Change File Type to ASCII FTP (ASCII) subcommand to tell FTP that it is transferring files to an ASCII system. The transfer may run without it, but I put it in for insurance.

Once I made these changes, the transfer started working normally.

HTH

--Joe

About Our Testing Environment

Configurations described in this article were tested on an i5 550 box running i5/OS V5R4. Many of the commands are also available in earlier versions of the operating system running on Power i, System i, iSeries or AS/400 machines. If a command is present in earlier versions of the i5/OS or OS/400 operating systems, you may notice variations in the pre-V5R4 copies of these commands. These differences may be due to command improvements that have occurred from release to release.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot