Newsletters   Subscriptions  Forums  Store   Career  Media Kit  About Us  Contact  Search   Home 
fhg
Volume 5, Number 30 -- August 3, 2005

Admin Alert: Making OS/400 Automatically FTP to Windows


by Joe Hertvik


A recurring problem in OS/400 shops is how to use FTP to automatically transfer files between Windows and OS/400. In previous columns, I have provided procedures for automatically FTPing files between a Windows box and an AS/400, iSeries, or i5 box, where Windows controls the transfer. This week I'll modify my previous procedures and explain how to set up an automated OS/400-to-Windows FTP session, with your OS/400 box controlling the transfer.

While this article is complete in and off itself, it contains information I have published in earlier articles that are listed in the Related Stories section below, so check out those sources for more detail. For our purposes, the following definitions are in effect:

  • References to the FTP Server refer to an FTP server that is actively running on a Windows host machine. The FTP server's job is to accept and fulfill requests from the FTP client machine. Be aware that, depending on the Windows FTP software that you are using, these procedures may need to be modified somewhat for your FTP user.
  • Any references to the FTP Client refer to an AS/400, iSeries, or i5 running OS/400 or i5/OS. The job of the FTP client is to initiate and control the transfer by using commands that it sends to the FTP server. This article was written to an i5/OS V5R3 standard, but it should also work on earlier versions of the operating system.

Once you understand the roles and assumptions about your transfer, you can easily set up an automated FTP transfer between OS/400 and Windows by performing the following steps: Here's my drill for getting the project done.

Step 1: (Optional) Create a TCP/IP Host Table Entry for your FTP server on your FTP client

If you cannot use DNS to resolve your Windows FTP server name from your FTP client, you may want to create a host name on your OS/400 box for that server. You can do this through iSeries Navigator or through the Configure TCP/IP menu on the green screen (CFGTCP). CFGTCP can be reached through the following green screen Go to Menu command (GO):

GO MENU(CFGTCP)

Select option 10 (Work with TCP/IP host table entries) to add a host table entry for your FTP Server. Alternatively, you can also add a DNS entry for your FTP server to the DNS server that your FTP client uses, or you can change your FTP command to FTP directly to the IP address of your Windows FTP server.

For this example, I'll use FTPSERVE as the host table name of our Windows FTP server.

Step 2: Create an FTP user profile on your Windows FTP server

Before you can automate a session, make sure that you're able to connect to that session manually from your OS/400 FTP client. If your Windows FTP server doesn't already have an FTP user for your client, create one.

For our purposes, let's say that the name of the FTP user on the target Windows FTP server is FTPUSER, with a password of GOFTP. FTPUSER should be locked down on the Windows box as much as possible so that, ideally, it has limited authority only to the files that need to be transferred.

To test your connection to the Windows FTP server, run the following green-screen Start TCP/IP File Transfer command (FTP).

FTP RMTSYS(FTPSERVE)

This should open an FTP session where you can try signing on as your target user. Once signed on, close the session and move on to the next step.

Step 3: Create an FTP Input Script File on OS/400 FTP Client Box

To test our batch transfer capabilities to the Windows FTP server, I'll take a copy of the sample Client Access customer master file that IBM provides on most iSeries and AS/400 boxes and copy that file between our FTP client and FTP server machines. The name of this file is QCUSTCDT, and it resides in the QIWS library. For testing purposes, make a copy of that file in the QGPL library of the FTP client machine by executing the following Copy File (CPYF) command:

CPYF FROMFILE(QIWS/QCUSTCDT) TOFILE(QGPL/QCUSTCDT)
   MBROPT(*REPLACE) CRTFILE(*YES)

The next step is to create an FTP input script file on your FTP client box. Your FTP session will use this script file to automatically enter the subcommands that enable your copy. Because we're using an automatic copy, this means we have to embed our FTP user profile name and password inside the script in order to sign on to our FTP server box, which will create a security hole on your system. Because of this, wherever you store your script on the system, it should be tightly locked down. If you store the script in a physical file or a source file, as I'll show here, you can also lock down script access by changing the *PUBLIC authority to *EXCLUDE on your file, which should keep most system users out.

When creating our FTP input file, our sample script will be stored in an OS/400 file member, where each FTP subcommand is entered as its own record. To make it easy to edit the FTP input script, it can be stored as a Text (TXT) member in an OS/400 source file, but this limits your FTP subcommands to 80 characters or less. It doesn't really matter where your store the FTP input script, however. The only requirement is that a CL program must be able to use the FTP input script member in an Override with Database File (OVRDBF) command.

For our purposes, I'll store this information in the FTPINTPUT member of the QCLSRC source file in library QGPL. To set up our transfer, create the FTPINPUT member as a Text (TXT) member that contains the following subcommands:

OPEN 
USER FTPUSER GOFTP
NAMEFMT 1
CD windows directory
LCD /QSYS.LIB/QGPL.LIB
ASCII
PUT QCUSTCDT.FILE QCUSTCDT.TXT 
QUIT

When you use this script to run an OS/400-to-Windows FTP transfer, the input script file FTP sub-commands will provide the following functions:

Open (Connect to FTP Server on a Remote System) opens a connection with the target FTP server. Since we are using an OPEN command for this function, the next line feeds the FTP server the user name and the password of the FTPUSER on the remote system. Replace the FTPUSER and GOFTP values with a user name and password that will log you onto your FTP server.

The NAMEFMT 1 (Select File Naming format) subcommand tells the FTP client that any upcoming file transfer locations and names will be coded using IFS notation. (For an explanation of what NAMEFMT 1 does, see "Admin Alert: The OS/400 FTP Subcommand Glossary.")

CD windows directory (Change Working Library or Folder) changes the local working directory on the Windows FTP server machine to the folder where you want to store the downloaded file.

LCD /QSYS.LIB/QGPL.LIB (Change Working Directory or Library) changes the default working directory (library) on the OS/400 client machine to QGPL. This file name is consistent with the IFS naming format for OS/400 libraries that we specified in the NAMEFMT 1 sub-command above.

ASCII (Change File Type to ASCII) designates that this will be an ASCII file transfer between the two boxes, and that the transferred data should be stored in ASCII format on the Windows FTP server. ASCII is the default file type for Windows boxes.

PUT QCUSTCDT.FILE QCUSTCDT.TXT tells FTP to copy the first member of file.

QGPL/QCUSTCDT from the QGPL library on the FTP Client to the QCUSTCDT.TXT file in the windows directory on FTP Server (these locations were defined in the CD and LCD subcommands above).

QUIT ends the FTP session.

4. Create an FTP Output Results File on Your FTP Server Box

We also need to create a member that holds the results of your FTP copy. This is basically just a scratch member that we can examine after the transfer has occurred to determine if everything went well. For our example, create another source TXT file in QGPL/QCLSRC called FTPOUTPUT.

5. Create a CL Program to Control Your Batch FTP File Copy

Now that we have an FTP input file that contains the FTP sub-commands that will power our transfer, as well as an FTP output file where we'll store the results of our copy, we now need to put it all together by creating a CL program to run the transfer. Here's a simple CL program called QCUSTCOPY that will run our automated unattended FTP transfer.

PGM

OVRDBF     FILE(INPUT) TOFILE(QGPL/QCLSRC) +
              MBR(FTPINPUT) /* Override your FTP input +
              input commands to the proper location */ 

CLRPFM  FILE(QGPL/QCLSRC) MBR(FTPOUTPUT) /* +
              Clear out the FTP output file to +
               eliminate records from past transfers */

OVRDBF     FILE(OUTPUT) TOFILE(QGPL/QCLSRC) +
              MBR(FTPOUTPUT) /* Override your FTP output +
              file to the proper location */        
              
FTP        RMTSYS(FTPSERVE) /* FTP over to the server +
              and get your data */

DLTOVR  FILE(*ALL)

ENDPGM

This CL program is very simple to code. It can be created through the green screen PDM program or through WebSphere Development Studio client (WDSc). It performs the following functions.

The first Override Database File (OVRDBF) command assigns our FTPINPUT script member to an FTP variable called INPUT, which OS/400 FTP will use to find the script that contains the FTP subcommands you want to execute.

The Clear Physical File (CLRPFM) statement clears the FTPOUTPUT member of all records from previous FTP transfers. This eliminates any confusion that can be caused by mixing old FTP messages with new ones.

The second OVRDBF command assigns our FTPOUTPUT member to another variable called OUTPUT, which will be used to hold the messages that are generated from our automatic FTP session.

The FTP command performs three functions: It starts an FTP session with the remote server specified in the Remote System (RMTSYS) parameter of the FTP command. It runs the FTP sub-commands contained in the FTPINPUT member in QGPL/QCLSRC, performing whatever functions are listed into the FTPINPUT source member. It stores the results of each FTP command in the FTPOUTPUT member.

The last step in the CL program is to execute the Delete Override (DLTOVR) command, which performs end-of-program maintenance by deleting all the overrides created in this program.

Before you run the transfer, make sure the FTP server is started on your remote Windows box (FTPSERVE, in this case).


When you run the QCUSTCOPY CL program from the OS/400-based FTP client, it starts a session, automatically copies the designated files to the Windows FTP server, and ends the program. You can view the results of the transfer in the FTPOUTPUT member and correct any errors that occur.

6. Once successful, replace the commands in the FTPINPUT file with the commands for your particular transfer

Once you know you can perform this simple transfer, you can configure the batch transfer for your own purposes by replacing the FTP commands in the FTPINPUT member of QTXTSRC with commands that pertain to your own project. Test and make sure this transfer is working okay.

7. Schedule Automated FTP Copying Using the WRKJOBSCDE command

Now that you've distilled your designated FTP transfer into an easy-to-call CL program, you now need to put an entry in the OS/400 job scheduler, so that this program can copy files at the proper time (which may be done on a daily, weekly, or monthly basis). To do this, call the Work with Job Schedule Entries (WRKJOBSCDE) command to set up a standard day and time when this job will be executed. Once on the WRKJOBSCDE screen, press the F6 key and enter a new entry for running the FTP CL program at the appropriate times. Be sure to check the results stored in your FTPOUTPUT member on a regular basis to determine if the file transfer ran successfully; if it didn't, find out what errors occurred and correct them.


RELATED STORIES

A Simple Batch FTP Tutorial

Commenting FTP Scripts

FTP Basics: Batch Processing

FTPing a Library

The OS/400 FTP Subcommand Glossary

Using FTP to Poll for File

Sponsored By
MAXIMUM AVAILABILITY

Vacancy!
iSeries OS/400 Technical Support Specialist

Maximum Availability - a global leader in the development and deployment of High Availability and Data Replication software solutions - is seeking an experienced iSeries Technical Specialist to join its expanding team in the USA.

The successful applicant will work as an integral member of the North American sales team to help continue the successful drive of *NoMAX - our suite of High Availability and Data Replication products - to market. Key areas of responsibility include: managing live demonstrations, product installations, and close-in technical support to a rapidly growing partner and customer base throughout the U.S. Continent.

The successful applicant will have a comprehensive background as an iSeries Technical Support Specialist combined with an advanced understanding of OS/400 Journaling. In this high-energy and customer-centric role, excellent communication and presentation skills will be essential. Experience in iSeries High Availability & Disaster Recovery projects will also be a distinct advantage.

If you have the background and skills that we are looking for and the desire to be a key player in a company that is going from strength-to-strength, please send your resume to vacancies@maxava.com


Technical Editors: Howard Arner, Joe Hertvik, Ted Holt,
Shannon O'Donnell, Kevin Vandever
Contributing Technical Editors: Joel Cochran, Wayne O. Evans, Raymond Everhart,
Bruce Guetzkow, Marc Logemann, David Morris
Publisher and Advertising Director: Jenny Thomas
Advertising Sales Representative: Kim Reed
Contact the Editors: To contact anyone on the IT Jungle Team
Go to our contacts page and send us a message.


THIS ISSUE
SPONSORED BY:

WorksRight Software
Advanced Systems Concepts
Maximum Availability


Four Hundred Guru

BACK ISSUES

TABLE OF
CONTENTS
API Corner: List Spooled Files From an Application

Avoid Changed Default Values

Admin Alert: Making OS/400 Automatically FTP to Windows


The Four Hundred
Lunch, Sort Of, with Mark Shearer, iSeries GM

IBM Rational-izes WebSphere Development Tools with Version 6

Sarbanes-Oxley, Offshore Outsourcing, and Entitlement

We Work for the Internet

Four Hundred Stuff
DRV Technologies Gets Hip to Forms

KCI Updates Excel-Based Business Intelligence Tool

Farabi Bolsters Host Access Wares with HostFront 4.0

No Summer Vacation for Intentia as it Preps for Lawson Merger

Four Hundred Monitor


Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved.
Guild Companies, Inc. (formerly Midrange Server), 50 Park Terrace East, Suite 8F, New York, NY 10034
Privacy Statement