Drawn from the need to send objects between different machines, IBM's SNADS was a relatively rich architecture used to send objects between AS/400s. Today, with FTP over TCP/IP being the dominant choice for file transfer, many people want FTP to be as easy as (or easier than) SNADS.
Why FTP? Because configuring my machine so that I can send you a source member is nothing short of rocket science. With FTP, I simply provide the IP address and the file I want to send and--bam!--it gets sent.
The downside of FTP is that you have to write an FTP script or start the interactive FTP session. This isn't difficult at all, unless you haven't used FTP before. Using a script is nice, but it does require that you know what you're doing; the interactive session is OK, but it can get to be tedious for simple transfers or transfers that need to be run frequently.
What I want is a command that allows me to say something like "Send this file using FTP. Here are the IP address, user ID, and password. Now, go do it." But no such CL command exists.
My choices are to write a new script each time a user needs to send a different file, to write a ridged script that works only in one particular situation, or to invent a CL command that handles most of the situations. I choose to write a CL command.
Send a File Using FTP
The Send File Using FTP (FTPSNDFILE) command has a long list of parameters that allows you to send any file directly through FTP without starting the interactive FTP session or writing an FTP script. The FTPSNDFILE command builds an FTP script on the fly and then runs it by calling the FTP command.
You can specify a remote system IP address or domain, the file and member you want to send, and the target location. As is usually the case with CL commands that I write, I've selected a good set of default parameter values so that you have to know only the IP address, file name, user profile, and password. The rest of the parameters can be left to default. Here's a description of the parameters.
RMTSYS--Remote system. Specify the IP address or domain name of the system that will receive the file you are sending.
FILE--Local file name. Specify the qualified name of the file that you want to send using FTP. A value of *LIBL may be specified for the file's library. However, the FTPSNDFILE command's processing program will convert *LIBL into the actual library name at runtime.
MBR--Local member name. Specify the name of the member that you want to send. The default member name is *FIRST, but you may specify*FILE, *LAST, or *ALL. In addition, you may specify a generic member name.
TOFILE--Remote file name. Specify the name of the file that will receive the data from the file you are sending. The file should already exist so that the external description is preserved. If the file does not exist, the FTP server will create the file for you, but you won't like the results (a flat file).
TOMBR--Remote member name. Specify the name of the member into which the data is stored. You may specify either a member name or one of the following special values:
- *FROMMBR--Use this when the remote member name should be the same as the local member name specified on the MBR parameter. This value must be specified when a generic local member name is specified or when *ALL is specified for the local member name (MBR) parameter.
- *TOFILE--The member name is the same as the remote file name specified on the TOFILE parameter.
REPLACE--Replace remote member's data. This parameter adds the "(Replace parameter" to the FTP PUT command. Yes, FTP uses "(Replace" to indicate REPLACE(*YES). However, this parameter has no impact on the results when iSeries-to-iSeries transfers are being performed. On the iSeries, the target file/member's data is always replaced. Therefore, this parameter is reserved for future use.
USER--Remote FTP user profile. Specify the user profile of the user that is needed to sign onto the remote system.
PWD--Remote FTP user's password. Specify the password for the remote user. Note that this parameter's value is not recorded in the joblog and must be entered each time you run FTPSNDFILE from the command entry display. From within a CL program, the password can be stored in a CL variable.
MODE--Transfer mode. Specify the kind of transfer to be performed. The valid choices are as follows:
- *BINARY--The transfer mode is IMAGE/BINARY. This is recommended for iSeries objects such as database files.
- *ASCII--The transfer mode is plain ASCII text. This transfer mode is valid for non-database files, such as source file members.
SRCFILE--The name of the source that will receive the generated FTP script. This source file should be as long as possible but at least 152 bytes in length (140 bytes for the source line and the usual 12 bytes for the source sequence and change dates area).
If this source file does not exist, it will be created with a record length of 152 bytes. The default source file name is as follows: Source file QFTPSRC, Library QTEMP.
SRCMBR--The FTP script source member name. This is the name of the member into which the FTP script is generated. Specify any valid source member name, *FROMMBR, or *GEN. If the member exists, it is cleared; if it does not exist, it is added. The two special values for this parameter are as follows:
- *FROMMBR--The name specified on the MBR parameter is used as the member name for the FTP script. This member is added to the source file specified on the SRCFILE parameter.
- *GEN--A member name using the following pattern is automatically generated: FSyyyymmdd, where FS is a constant, and YYYYMMDD is today's system name in YMD format.
LOG--FTP message logging file. Specify the name of a source file that will receive the messages generated by the FTP command. Optionally, specify that the messages are to be delivered as they normally are, via the STDOUT (standard output) device. This parameter has the following special values:
- *STDOUT (or *STDIO)--Indicates that the FTP log is written to the standard output device, which scrolls up the 5250 screen, similar to an old teletype interface.
- *NONE--The FTP log is not displayed.
Unlike the SRCFILE parameter, the file specified on the LOG parameter must exist because the FTPSNDFILE command will not create it. You may, however, use the same file name as the SRCFILE parameter, in which case the file is created due to its being specified on the SRCFILE parameter.
LOGMBR--The member name where the FTP log is saved.
DSPLOG--Display the FTP log. If *YES is specified, the FTP log is displayed when the FTP transfer completes; if *NO, the FTP log is not displayed.
As always, you can download the source from my RPGLab Web site. The command definition source code for the FTPSNDFILE command is reproduced below, but the RPG IV source of the command processing program is a bit too lengthy to reproduce here. So visit the Web site to download the RPG IV source.
|
This version of the FTPSNDFILE command works best with database or source files. I am working on updating it to handle *SAVF (Save files) just as easily and will post that update in the RPGLab as soon as it is ready.
Bob Cozzi is a programmer/consultant, writer/author, and software developer. His popular RPG xTools add-on subprocedure library for RPG IV is fast becoming a standard with RPG developers. His book The Modern RPG Language has been the most widely used RPG programming book for more than a decade. He, along with others, speaks at and produces the highly popular RPG World conference for RPG programmers.
Bob Cozzi is a programmer/consultant, writer/author, and software developer. His popular RPG xTools add-on subprocedure library for RPG IV is fast becoming a standard with RPG developers. His book The Modern RPG Language has been the most widely used RPG programming book for more than a decade. He, along with others, speaks at and produces the highly popular RPG World conference for RPG programmers.
MC Press books written by Robert Cozzi available now on the MC Press Bookstore.
 |
||
 |
|
RPG TnT Get this jam-packed resource of quick, easy-to-implement RPG tips! List Price $65.00 Now On Sale
|
|
||
 |
|
The Modern RPG IV Language Cozzi on everything RPG! What more could you want? List Price $99.95
Now On Sale
|
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