In today’s world, it is rare to find a company that does not have a blend of several computer environments. Desktop PCs, mainframes, midrange computers, and a variety of servers can all be included in the mix. Such a situation explains the appeal of TCP/IP, which is the thread that binds these diverse computing environments together and allows them to communicate with each other. As long as a computer can communicate via TCP/IP, it can talk to any other computer that has TCP/IP loaded, regardless of the operating system.
One of the workhorses of the TCP/IP product suite is FTP, which is a protocol that allows the transfer of files between any two computers running TCP/IP. FTP is easy to implement, reliable and normally very fast. Well, it’s supposed to be fast. Anyone who has had to opportunity to transfer AS/400 files via FTP knows that large files can take a long time. In this article, I will explain some of the things that can slow down your AS/400 FTP file transfers and what you can do to speed things up.
A Case Study
My company maintains a Web site that can only be accessed by paid members. The membership authorization records are stored and maintained on the AS/400. The records are then transferred to the Web server on a nightly basis using FTP. At first, the transfer took place in a reasonable amount of time, but, as the file grew, it started taking hours to run. It finally got so bad that the transfer was interfering with our nightly AS/400 backups. I took the problem to one of our UNIX experts to see if he could provide an explanation. He shrugged his shoulders and informed me that, based on our line speed, a file this size (about 300 MB) should take minutes to transfer, not hours.
To test this statement, I copied the file to a desktop PC and used FTP to transfer the file to another desktop PC. Sure enough, it transferred in a matter of minutes. The problem was obviously with the AS/400, but what could it be? I guessed that the process of converting an EBCDIC file on the AS/400 to an ASCII file on the Web server, along with all of the normal overhead associated with AS/400 files, might account for much of the slowing in the transfer process. (I later confirmed this hypothesis with technicians from IBM.) What I really needed was something that would do the AS/400-to-PC file conversion before the file was transferred.
Enter the Copy to PC Document Command
The AS/400 Copy to PC Document (CPYTOPCD) command allows an AS/400 EBCDIC file to be converted to PC ASCII format. The document is then stored in a folder on the AS/400. (See Figure 1.)
The following are the parameters of the CPYTOPCD command:
• From File (FROMFILE)—the file and library name of the AS/400 EBCDIC file
• To Folder (TOFLR)—the AS/400 folder where the ASCII file will be stored
• To Document (TODOC)—the name of the converted ASCII file
• Translate Table (TRNTBL)—the name of an alternate EBCDIC-to-ASCII translation table if the default table is not used
• Format of PC Data (TRNFMT)—the format the records in the PC document will have. (If *TEXT is specified, line endings and returns are placed at the end of each record. If *NOTEXT is specified, a fixed-length record is produced.)
Using the CPYTOPCD command to convert my AS/400 file to ASCII before sending it to the Web server made all the difference in the world. The command only took a few minutes to convert the file, and, afterwards, the FTP transmission performed as well as it did on the desktop. The process was reduced from two to three hours to less than 15 minutes!
Batch FTP
Figure 2 shows an example of a CL program for converting an AS/400 file to an ASCII file in a folder and then performing an FTP file transfer. (For more information, see “FTP in the Batch Environment,” in Client Access/400 Expert, November/ December 1996 and reprinted in Client Access/400 Expert Reader.) The following are the AS/400 commands the program uses to transfer the file:
• The CPYTOPCD command converts the file MYFILE in library MYLIB to an ASCII file called MYFILE.ASC. This file is then placed in folder MYFLR.
• The Clear Physical File Member (CLRPFM) command is then used to clear a source member called FTPLOG. This member will be used to store the status messages generated by the FTP session.
• The Override Database File (OVRDBF) commands are then used to override the file names INPUT and OUTPUT to source file members FTPCMD and FTPLOG. The input file FTPCMD is a source member that contains all of the FTP subcommands that will be run when the FTP session is started. (See Figure 3.)
• The FTP command is then used to start the FTP session. The xxx.xx.xxx.xxx in the Remote System (RMTSYS) parameter would be replaced with the IP address of the remote computer.
• After the FTP session is terminated, the overrides on the INPUT and OUTPUT files are deleted.
Figure 3 shows the commands that are executed during the batch FTP session. In turn, each line performs the following functions:
• The first line is a login to the remote computer. The username and password entries would be replaced with the actual user name and password.
• The next line changes your current directory on the remote machine to MYDIR, which is the destination directory of your file.
• The NAMEFMT 1 subcommand is needed so you can specify the naming format of your source file.
• The PUT command performs the actual transfer of the file. As you can see, the file is specified with the format /file system/folder/file.
• The QUIT command terminates the FTP session and returns control to the CL program.
After the FTP session has ended, the source member FTPLOG can be viewed to see if there were any errors in the transfer.
Join the Crowd
With the popularity of the Internet, TCP/IP is rapidly becoming the standard for network communications and IBM has put a lot of work into maximizing the performance of all of the AS/400 TCP/IP tools. If you need to transfer your AS/400 files to a different platform, FTP is a great tool for the job. Just remember to convert your AS/400 files to PC ASCII files before you send them to make your FTP transfers really fly Figure 1: Use the AS/400 Copy to PC Document (CPYTOPCD) command to convert an AS/400 file to PC ASCII format.
Figure 2: This CL program was used to run the souped-up batch FTP transfer.
Figure 3: The FTPCMD source member contains all the commands that are executed to perform the FTP transfer.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online