The iSeries provides many facilities to allow the transfer of data between the iSeries and other platforms. These facilities include
- iSeries NetServer for stream files. This tool lets the iSeries appear in the Windows Network Neighborhood.
- iSeries Access (formerly Client Access) network drives for stream files. This tool also lets the iSeries appear in the Windows Network Neighborhood and works over many protocols. However, it is slow and causes PC performance and stability problems.
- FTP for stream and database files for TCP/IP standard file transfer protocol. This is the most widely used data transfer tool; it can transfer files to any iSeries file system. It supports binary or text files, and it can transfer save files between iSeries systems. However, it doesn't automatically convert packed data.
- Network File Transfer (NFT) for stream files. This is the widely used standard in the Unix world.
- iSeries Access (formerly Client Access) data transfer for transferring database files from the iSeries to iSeries Access platforms. This tool has strong record selection and joining capabilities.
- ODBC and OLE DB for database files. This tool provides programmatic database access to DB2 UDB data.
- JDBC for database files. This tool is used for Java-based applications.
Of these methods, only FTP encompasses data transfer of stream and database files. Here, we discuss how you can use CL to automate FTP. This approach allows data transfer of OS/400 objects, thus making remote maintenance possible. To learn more about the various options for iSeries data transfer, see "A Quick Guide to AS/400 Data Transfer" (December 2000), article
Using FTP in Online Mode
The strength of FTP lies in its syntax and options. Here are the basic steps for using FTP for data transfers:
- Use the FTP command to establish a connection to the remote system. You can connect by specifying either the name or the IP address of the remote system.
- Enter a valid user ID and password to log on to the remote system.
- Set the mode of transfer to one of the following modes:
- Binary. Binary image transfer is required for certain files such as save files and hierarchical file system files (QDLS documents). If TYPE is not set to binary when you try to transfer such files, a message appears indicating that binary is required.
- ASCII. You use the ASCII transfer type when you're transferring document files to or from an ASCII system that doesn't support EBCDIC representation. ASCII is the default transfer type.
- EBCDIC. The EBCDIC transfer type is useful when you're transferring files to or from another EBCDIC system because it precludes the need to translate between ASCII and EBCDIC on both systems.
In realtime scenarios, it's often not feasible to use interactive FTP because file dumps may be created during a batch process and need to be transferred immediately to remote systems. Also, the database file may be available to the system only at a particular time or date. Furthermore, night jobs involving file transfers may be difficult because user personnel may not be available. Finally, online FTP subcommands aren't supported in normal CL programming.
In such scenarios, the concept of automated FTP can be extremely useful.
FTP provides a useful feature to help automate the task of data transfer: INPUT and OUTPUT files. The FTP statement reads (by default) from the INPUT file (if it exists) and executes all the statements contained within it. Similarly, it directs the log of the executed statements and their status (whether they were successful or not) to the OUTPUT file. Using these two files, you can write a script that automates the process of transferring data from a remote system.
For example, Figure 1 shows a sample CL program that acts as a driver program for the auto FTP feature. It creates a temporary file called FTPSRC with two members — FTPMBR and FTPLOG — that are overwritten to the files INPUT and OUTPUT (which will be used by the FTP command).
The INPUT file (which has been overwritten) is populated by an RPG program that's called from the driver CL. This RPG program writes all the required FTP commands into the INPUT file, including the dummy user ID and password fields required for connecting to the local machine (more on this later).
Figure 2 shows a sample RPG program that gets called from the driver CL program (Figure 1) and writes the requisite FTP commands onto the INPUT file. (Note that you must create the file FTPSRC by using the command shown in the CL program in Figure 1 before you can create the RPG program. This is required for compilation purposes.) At the end of the program, the INPUT file contains the set of FTP statements to be executed. Figure 3 shows a sample INPUT file.
The next FTP statement in the driver CL program (Figure 1) reads from the INPUT file and starts executing the statements within it. One drawback that you may notice is that we don't have the flexibility to connect to any machine; we would need to hardcode the IP address of a remote machine. The FTP RMTSYS (LOOPBACK) statement is used to circumvent this problem. This statement does nothing other than connect to the local machine itself (i.e., connect to the IP 127.0.0.1 using port 21). The purpose of this is just to get into the FTP mode. We can then specify some dummy user ID and password (inside the INPUT file) that will be rejected, but our purpose of entering into FTP mode is accomplished. Now, we can open a connection to any remote machine we want, and we can do so as many times as we want. The address of the remote system can also be accepted as a parameter and need not be hardcoded.
Note that you must make a few changes in the RPG program (Figure 2) to make it usable in the user's specific environment. Specifically, you must change the statement
EVAL SRCDTA = 'OPEN XXX.XXX.XX.XX''
to reflect the system name/IP address of the remote iSeries. You must change the statement
EVAL SRCDTA = 'USER ANONYMOUS PASSWORD'
to take in the actual user ID and password of the remote machine. Finally, you must change
EVAL SRCDTA = 'CD FTPFILES'
EVAL SRCDTA = 'LCD TEST'
to reflect the remote directory from which the user wants to transfer data and the local directory to which the user wants to transfer data.
The FTP statement directs its log and the status of the different FTP statements executed to the file OUTPUT. Figure 4 shows a typical OUTPUT file. You can use the OUTPUT file to track the status of execution, and you can automate further processing based on it.
You can now schedule the driver program (via the OS/400 scheduler) to run at a particular time of the day. The FTP process is automated!
We have studied various methods of data transfer, and through realtime deployment we've come to the conclusion that automating FTP using CL commands is fast and scalable. Automated FTP also limits the need for manual intervention and provides opportunities for remote maintenance of OS/400 objects. This can be a huge help in large projects — specifically when distributed users are accessing and maintaining the system.
We'd like to thank Infosys for its encouragement in the development of this research.
N. Vijay Sundaresan is project manager at Infosys Technologies Limited in Bhubaneswar, India. You can reach him at email@example.com.
Baljeet Kaur formerly worked at Infosys Technologies Limited in Bhubaneswar, India.
Rakesh Agarwal is manager at Infosys Technologies Limited in Bhubaneswar, India. You can reach him at firstname.lastname@example.org.