On the best method to GET large stream files with FTP from a UNIX system to an iSeries system, 
Marilyn, from Connecticut wrote:

I have a problem where I'm trying to do a GET from a UNIX machine > to an AS400 machine. The UNIX only supports file structure.
The file far exceeds the AS400 limitation for a physical file.
I've tried the STRUCT R command but the UNIX doesn't implement it. I've tried the LOCSITE LRECL=80 command and it won't accept that either.

Answer:

In the V4R4 release of OS/400, the Integrated File System (IFS) provides 64-bit versions of its UNIX-type commands. With the new 64-bit mapping, sizes, offsets, and lengths are represented as 64-bit integers, which eliminates the 2 GB limit. With this change, iSeries users can now store and manipulate large files up to 256 GB in the QSHELL Root (/) or any user-created subdirectory in that environment.

Instead of trying to FTP your file into a conventional physical file, you will need to FTP it to the IFS (Integrated File System).
What this means is that instead of getting your file into a MYLIB/MYFILE.MEMBER format, you would get it into a file format such as  
/QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR

your FTP command will look like  
GET remote_path/remote_file /QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR 

Once you have this file imported in your IFS, you can then use the CPYFRMIMPF command to parse the records out to a conventional, regular physical file. CPYFRMIMPF will even parse fields, if you have delimiters in your incoming data (i.e. data in .csv format). The command would look something like 
CPYFRMIMPF FROMSTMF('/QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR') TOFILE(REGULARLIB/REG_FILE) MBROPT(*REPLACE) RCDDLM(*ALL) 

Here are the actual commands that were used to resolve this question. Note the NAMEFMT 1 command which tells the operating system to look for the IFS file naming convention:

In FTP:
MODE BINARY
NAMEFMT 1
GET remote_path/remote_file /QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR 

From the Command Line:
CPYFRMIMPF FROMSTMF('/QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR') TOFILE(REGULARLIB/REG_FILE) MBROPT(*REPLACE) RCDDLM(*ALL)

Note that this entire stream can be automated using the techniques explained in Practical Programming for AS/400 iSeries FTP Automated Interfaces
A good article in the IFS file-size change can be found in MCPressOnline. It is titled "V4R4 APIs Expand AS/400 IFS File Sizes to 256 GB"

On CPYFRMIMPF not accepting nulls when importing a comma-delimited file
Wayne from Vancouver wrote:

I am trying to import data from a Microsoft XL sheet converted to Comma-delimited format (.csv) using the AS/400 (release v4r4) CPYFRMIMPF command. I and running into trouble when empty cells, represented by two commas with nothing in between (, ,) are interpreted by CPYFRMIMPF as being NULL. Is there any way to circumvent this problem?

Answer:
There are two patches available for the iSeries which address this problem:

The V4R4 patch adds a parameter - RPLNULLVAL(*FLDDFT) - which controls the action of CPYFROMIMPF when it encounters a field which contains a null value. Basically, it puts in a default value so that the import can continue. If the field is numeric, the default is a zero, if the field is alpha, the default is blanks.

The V4R4 PTF numbers are: SF61859 & SF61937
In V4R5 this feature is already there, except for the earlier releases of V4R5. For systems in that situation, the V4R5 PTF SF62142 will do the trick.

These are very small PTFs to download through the ECS modem. They can be installed without having to IPL the system and are effective immediately after applying the patch.

On transmitting special characters, such as square brackets from an RS/6000 UNIX box to an iSeries
John, from Toronto wrote:

Hi, I was on your site recently and was wondering if you could assist me with this problem. We currently FTP text files from our RS6000 to our AS/400 IFS root file system ..eg. /home/user..and need those files to be in codepage 37. It seems to work if we type ebcdic before the put command, however, special characters like [ (left square bracket) and ] (right square bracket) DON'T get translated properly. I read your suggestion to one user about using translation tables, but in this case the FTP is taking place FROM the RS6000 NOT the AS/400. Does AIX have any special subcommands I could you to get it in the right codepage? Any suggestions?

Answer:
This is the answer, which John found by himself:

Hi, I figured it out... You need to change the FTP server attributes on the AS/400 side. You can do this in one of two ways:

1) GO CFGTCP to get to the Configure TCP/IP menu. Then select option 20 Configure TCP/IP applications, option 10 Change FTP Attributes..you will see Server Mapping tables keywords for incoming and outgoing. Change the incoming to a mapping table that has those 4 characters remapped to the right hex codes. Press Enter and restart the FTP server jobs.

2) The second and easier way is through Operations Navigator: Open the system you want to change and click on Network, Servers, TCP/IP. In the right window, right click on the FTP job, click Properties, click Mappings tab, check Use specified mapping tables, click on Tables, check Use incoming mapping table, type in the table name and library and click OK twice. Restart the FTP server by right clicking on FTP, stop, wait a couple of minutes, then right click again and click Start. Now, if you FTP from the Unix side to the AS/400 (an IFS file), you don't need to specify EBCDIC as the type. If you still want files in ASCII code, try using type binary.

On Preserving UNIX Record Structure when FTPing a file from UNIX to an iSeries Physical File,
Sylvan, from Toronto wrote:

I am having an issue regarding FTP that I was hoping you may be able to give me a hand with.

I am trying to GET a file from an FTP site on a UNIX box (Type: L8) directly via scripting from the AS/400. Everything seems to work fine as far as the transfer of data, however when I look at the file which I am receiving from, the carriage returns appear to have been ignore and all records have been concatenated into one long record.
I have tried issuing a STRUCT R, but the system replies with a "202 'STRU' : Command not implemented, superfluous at this site."

I have tried defining the receiving file with the exact record length, but this has only allowed the first record to transmit and truncates any others. Do you have any intuition as to what I may be able to do to correct this? Any help is appreciated greatly.

Response:
I suspect the file on your UNIX box is a simple stream file, which does not have any carriage return characters, thus the difficulties you are experiencing.

Answer:
This is the answer, which Sylvan found by himself:

The original file did contain carriage returns but no line feeds. This did not work. The record structure was not carried to the AS/400 file. We've now tested the FTP process with the same file containing line feeds as well as carriage returns and it now FTP overs to the 400 just fine. I know it sounds odd that a line feed was required since a carriage return already existed, but there were no other changes. Thanks greatly for your time on this problem. I have also tested the FTP process with the file containing only line feeds as record delimiters. This works like a charm--all results now come in record-by-record without issue.

Other Explanations:
Here are some further explanations on this, credit to http://www.dantobias.com/ for this information.

When uploading or downloading HTML files using an FTP (File Transfer Protocol) program, always use ASCII mode rather than BINARY. The reason for this is that different operating systems vary in how they represent line breaks. MS-DOS and Windows systems use a carriage return followed by a linefeed (ASCII characters #13 and #10) at each line break, which is the traditional standard dating back to 1960s Teletypes which needed both characters to get the terminal to both move the carriage to the left margin and move down a line.

Developers of some operating systems have decided that this is wasteful and a single character would suffice, but unfortunately they weren't consistent: UNIX ended up using a linefeed (#10) alone (which Unix developers refer to as a "newline" character), while Apple computers (both the old Apple II line and the Macintosh) chose the opposite course of using a carriage return (#13) by itself.

The result is that there are three different ways of denoting the end of a line, and software can fail if faced with a file that is delimited in a manner different from your operating system's convention. To avoid these problems, the FTP protocol was developed with an "ASCII mode" that converts line breaks to the appropriate style for the destination system. When you're sending from a UNIX server to a Windows PC, it adds a carriage return before each linefeed. Transferring the other way, it strips the carriage return. Transferring from UNIX to a Mac, it converts the linefeeds to carriage returns. Thus, the integrity of the file is maintained no matter what systems it's transferred between

Go Back to the Top

Regarding Translation Tables,
Hany El Moualed, from Saudi Arabia wrote:

I am trying to ftp file from AS400 machine to RS6000 one. The text is mixed Arabic and English. 
I have no problems regarding English text, but the Arabic one is completly rubbish.
Do you have any clue about the case of this.
Appreciate your help

Mr. El Moualed can be reached at elmowald@yahoo.com

Response:
I suggested to Hany that the translation table for the double-byte characters that are the base of the Arabic language on the AS/400 may be the problem. Resolving this turned out to be a relatively simple matter, although it took some time to find it.

Hany found himself the way to do this. He resolved the problem in the following steps:

1) Retrieve the source of the QASCII translation table, using RTVTBLSRC. This takes the contents of the translation table and dumps them into a regular source file.

2) Modify the newly retrieved translation table, using values that would meet the specific requirements of the transfer. Note: this table contains only the translation, for example, in QASCII, EBCDIC Hex 04 translates to ASCII Hex 9C. In the translation table, only 9C will show. An easy way to see this type of table is to use the Work with Tables (WRKTBL) command. Pick the table you want to see and put a 5 in front of it. This will display the values inside the table.  I have also suggested to Hany to look at the following website: ftp://ftp.unicode.org/Public/UNIDATA/ which contains a number of hex tables for foreign languages.

3) Re-Create the translation table using CRTTBL. Note that the table type is *CVT. Note, it is a good idea not to override a standard IBM table, like QASCII or QEBCDIC. Rather, create your own version of a new table, say "XASCII" or "XEBCDIC" for example.

4) When starting an FTP session, automated or manual, you will use the FTP command. This command is promptable. If you hit F4, you will only get the remote system parameter, but if you hit F10 after that, you will get a new set of parameters, amongst which there is the name of the incoming and outgoing ASCII/EBCDIC tables to use. At this point, you can enter your own customized version of the translation table, as in "XASCII" or "XEBCDIC" for example.

5) Test your new setup with FTP transmissions of data sets that will allow you to reliably verify the desired results.

Go Back to the Top

Regarding Reliable FTP CLIENT on PC SERVER,  
Jeff,  from Chicago, wrote:

I'm wondering if you could point me in the right direction on a problem I'm currently having with the AS/400 FTP client?  I am using the WAR FTP Daemon on my PC.  Using the AS/400 FTP client, I can GET files from my PC to the 400, but when I try to PUT a file, nothing happens. An empty shell of the file is created on the PC, but no data transfer takes place.

The WAR FTP Daemon responds with:

    227 Entering Passive Mode (nn,n,n,nnn,n,nn)
  125 Ready to receive "my-file-name" . Mode Stream Type Ascii

This is all that happens - no data gets transferred. Ultimately, my goal is to automate PUTting Domino/Notes files from the AS/400 to my Network.  Can you help me?
 

Response:

As far as WAR FTP, did you study the possible settings in the manual (assumed) supplied with the software? Perhaps the answer is simpler than you would think.

I had very reliable and consistent success with an FTP software package for Windows called WS_FTP Server, by IPswitch. IPswitch has a website at http://www.ipswitch.com/. You can order the product and download the manuals on-line.

Jeff wrote:

Thanks for your help -- I found my problem.  It was with the PASV subcommand.  I needed to turn it off.  Everything seems to be working now.
I am writing from a suburb of Chicago.

Additional Note: For best understanding of Active/Passive FTP, go to Active FTP vs. Passive FTP, a Definitive Explanation. This is an excellent page, explaining exactly how FTP behaves in Active mode vs. Passive mode.

Go Back to the Top

Regarding Retrieving MGET Results,
Amanda,  from Ohio, wrote:

I am trying to do a multiple get from a novell network to an as400 using ftp. I want to get all exe files from the network and store them in an as400 folder for backup purposes. I thought I could use the mget command but when I try this, the files go the the qgpl library instead of the folder. This is not where I want them!! What am I doing wrong?? Any help you can give is appreciated. Also, thanks for your article about automating FTP ... It was a HUGE help to me!! Thanks. Amanda

I am using mget *.exe /qdls/plant trying to get it to copy to the plant folder.

Response:

If you do a HELP MGET in your FTP environment in the AS/400, you will get detailed help on using this command. The key here is that MGET places the results into your current library. If you do not have a current library specified for your environment, OS/400 deems QGPL to be the default. If you issue with your CL the following command, CHGCURLIB CURLIB(XYZ) then XYZ will become your current library and MGET will bring back anything you tell it to and place it in XYZ.

You should be able to get away with mget *.exe alone (provided you are in the right directory) and that only would be enough to bring back your files to XYZ or what ever current library you specify for your job.

See also the question below, from Mike from Wisconsin:

Go Back to the Top

Regarding Targetting library-specific files on AS/400,
Mike,  from Wisconsin, wrote:

I was wondering if Amanda (see question above) solved her problem by looking in the help. It looked to me like she may have needed to change name formats and then change directories.

For example:
namefmt 1
lcd /qdls/plant

Response:

Following your comment, I have done some digging on the namefmt command. Here for the readers of this website is the short story on namefmt and lcd. I do agree, this combination of commands enable a more precise targetting of libraries and file system within FTP without having to affect the current library and thus the entire job.

NAMEFMT (Select File Naming Format)

namefmt 1 is the default iSeries format.
With it, one can use file notation such as libname/filename.mbrname

namefmt 2 is the a naming format for all file systems supported by FTP.
With it, one can use file notation such as /QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR

LCD (Change Working Library or Folder)

The LCD subcommand has the same function on the client system as the CD subcommand has on the server system. To change the default library, folder, or directory to which file transfer commands apply on the local system, use the LCD subcommand as follows: lcd pathname

Notes:
1. The current library is not changed by the LCD subcommand. Therefore, you can place files where you want them without changing the current directory.
2. When using the LCD FTP command to change from one file system to another file system, the "root" directory must be specified. For example, /QDLS or /QOPT.

Go Back to the Top

Regarding the Type of File Necessary to Store an FTP Script,
Lance, from Washington wrote:

What type of file should be used to store the FTP Script?

Response:

The "INPUT" file that will contain the FTP script should be a one-field file.
My easy short-cut technique for creating a prototype involves creating a file with the following source:

-----------------------------------------------------------------------------------
A R REC24 TEXT('Import Record Fmt')
A SRCDTA 80A TEXT('Source Data Field')
-----------------------------------------------------------------------------------

What you can then do is create a source file where you enter your FTP script.
All source files have three fields, the sequence number, the date and the source data. All you have to do once you have used PDM to create your script in your source file member is to do a CPYF to send the content of your newly populated source file member to your FTP script source file.
Since you are copying from a source file to a regular file, you have to use the convert source (*CVTSRC) format option.

CPYF FROMFILE(CATDA7/QSRC) TOFILE(CATDA7/FTPINPUT) FROMMBR(FTPINST) TOMBR(*FIRST) MBROPT(*REPLACE) FMTOPT(*CVTSRC)

Go Back to the Top

Regarding the PASV Command on the AS/400, 
Woody,  from Georgia, wrote:

Thibault, I saw a recent discussion on your site about a problem in exchanging files between an AS/400 and a PC. The solution to the problem that the gentleman reported (Jeff) was simply turning off the "pasv" command.

Some customers are exchanging data with us from the AS/400 platform using FTP. Most of the time everything works very well but some of them are reporting an occasional disconnect. We have analyzed this situation and found that they always occur on the "pasv" command. Their client automatically issues the "pasv" as a sub command when they perform a "put" or "get". The disconnects always occur when they do not get an ack back from the first "pasv". The client reissues the command then you see both the client and our server issue disconnects. We are not sure why the packets get lost because we do see the ack going back.

The "pasv" command is not essential for us but the one client that we have worked with on this is saying that they cannot turn it off. I now know that they can. We are not an AS/400 shop so can you tell me how this command can be turned off?

Woody

PS. I have been to your city and the surrounding area a couple of times and your view is better than the one I have in Atlanta as well.

Response:

Hi Woody, Thanks for your question. You want to tell your customer to use the SENDPAsv command. Here is the syntax and some explanation of how to use this command:

SENDPASV (Specify Whether to send a PASV Subcommand) is an FTP Client Subcommand used to specify whether or not to send a PASV subcommand to the FTP server when doing a data transfer or issuing the DIR and LS subcommands.

To use this instruction, enter the SENDPASV FTP client subcommand: SENDPASV [0|1] If there is no parameter SENDPASV works like a toggle switch.

The SENDPASV value toggles from 1 (ON) to 0 (OFF) or from 0 to 1. When there is a parameter, the valid values are:
0 Do not send a PASV subcommand
1 Send a PASV subcommand. This is the default. AS/400 system default (on) is to send the PASV subcommand.

When SENDPASV is off, then the server does not send the PASV subcommand.

Additional Note: For best understanding of Active/Passive FTP, go to Active FTP vs. Passive FTP, a Definitive Explanation. This is an excellent page, explaining exactly how FTP behaves in Active mode vs. Passive mode.

Go Back to the Top

Regarding Techniques to Monitor PING Messages,
Stephen,  from Ontario, wrote:

Thibault, I've a CL which monitor the PING, if it failed, the program will not perform FTP immediately. However, the MONMSG of TCP3206/TCP3202/TCP3213 are not working at all. Can you help?

Here is the code:

PGM
/* Verify connection to Host before attempting Transfer */
PING RMTSYS('128.2.2.66')
MONMSG MSGID(TCP3202 TCP3206)
EXEC(SNDPGMMSG + MSG('Ping to remote not successful'))
ENDPGM

Here are the results I got::

Verifying connection to host system 128.2.2.66.
No response from host within 1 seconds for connection verification 1.
No response from host within 1 seconds for connection verification 2.
No response from host within 1 seconds for connection verification 3.
No response from host within 1 seconds for connection verification 4.
No response from host within 1 seconds for connection verification 5.
Connection verification statistics: 0 of 5 successful (0 %).

Response:

Hi Stephen,
I tried what you did. I found I got identical results to yours if I use a numeric IP address (128.2.2.66 for example) instead of a IP table configured system name (SYSTEMR for example).

The remedy for your problem is to configure a proper IP system name and use that name in your program rather than a numeric IP address.

Here is the test code I have used to try this:

PGM
DCL VAR(&LOCATION) TYPE(*CHAR) LEN(10) VALUE(SYSTEM1)
PING RMTSYS(&LOCATION)
MONMSG MSGID(TCP3202)
EXEC(SNDPGMMSG MSG('Ping to remote location does not work'))
ENDPGM

Go Back to the Top

Regarding Line Wrapping in FTP Source Commands,
Jim, from California wrote:

Hi. I'm running FTP on an AS/400 in batch mode, PUTting a file with a very long name, to another very long name & I'm running up against the source file (script file) record length wall.

Is there a way to continue the FTP command across multiple lines/records?

Response:

The response is actually from our local IBM rep, Hadi Kilani:

Thibault, FTP command line wraping is not supported in OS/400. That is not a common problem with our users. I did research IBM reported user Q&A database with no questions like that.

Go Back to the Top

Regarding Line Wrapping in FTP Source Commands,
Jane, from Florida wrote:

"I am sending a 108 byte file to a UNIX box. The last 26 bytes are blank so when they get to the unix box they get lost. The customer wants it to be the full 108 bytes so I null filled the file and they complained because they want it blank and nulls are equal to a numeric. So my question is will STRUCT R keep my length of the file at 108 even though the last 26 bytes are blank. I have already been through asking to send a carriage return at 109 but they refused. Would using "STRUCT R" resolve my problem?"

Response:

This user actually solved the problem without help by using a combination of two FTP subcommands:

LOCSITE TRIM 0
ASCII

The LOCSITE FTP subcommand specifies whether or not to transfer the trailing blanks in a database file to the remote server.

The command can be used in three ways:
TRIM 0     Set Trim option to OFF. Trailing blanks of database records are sent.
TRIM 1     Set Trim option to ON.   Trailing blanks of database records are NOT sent. This is the default setting.
TRIM        Displays the current setting of the Trim option.

Go Back to the Top

Regarding how to transfer Libraries or Save Files using FTP,
Ibrahim Shareef, from Saudi Arabia wrote:

How can I FTP the contents of an entire library from one AS/400 to another AS/400?

Response:

Transferring AS/400 Objects or complete libraries with FTP can be done with the help of Save File (files of type *SAVF)

A SAVF type file is a physical file with records 528 characters long.

Here is how to transfer the contents of a SAVF from one AS/400 to an other:

- Create a Save File (CRTSAVF) on the source machine
- Save objects in the SAVF
- Create a Save file (CRTSAVF) on the target machine
- FTP to Remote AS/400 

mode BINARY 
PUT FROMLIB/SAVEFILE TOLIB/SAVEFILE

- For Automated Procedures (the SAVF does not have to be on the target AS/400: 

mode BINARY 
put /qsys.lib/catda7.lib/fromsavf.savf /qsys.lib/catda7.lib/tosavf.savf

Go Back to the Top

The best method to unpack fields in a physical file before an FTP Transmission

This is a tip that I presented at the Pacific Midrange Systems Association:

Response:

Use the Copy to Import File command: CPYTOIMPF

Example of CPYTOIMPF :

CPYTOIMPF
FROMFILE(DB2FILE)
TOFILE(EXPFILE)
FLDDLM(';') RCDDLM(X'07')

All records of externally described file DB2FILE will be copied to import file EXPFILE.
Fields in the import file will be delimited by a semi-colon (;) character.
Each record in the import file will be delimited by a hexadecimal '07' character.

Go Back to the Top

Signon via FTP does not update the USRPRF profile with the date and time last accessed.
Jim, from Vermont asks:

Any time we sign on to the AS/400 via FTP it does not update the user profile with the date and time last accessed.

We have users that will only be accessing the AS/400 via FTP.
Since we also have a program that deletes user profiles after 60 day's this will cause a problem.

We do not want to set the password expiry date to *NOMAX for security reasons. Is there any way you know of to force as FTP signon to trigger an update to the user profile automatically for the last access date?

Response:

I have discussed the situation you inquired about with my colleague Mark Whiteside, of Shell Canada Limited. The response that follows is the result of our conversation:

1) I have tried myself and verified what you have said about the "Previous Signon" date and time. Signing on via FTP does not update these values for the user profile used.

The problem is that when you signon via FTP, your session is handled by some special FTP server job rather than through a normal QINTER signon session. From all we know, you cannot force FTP signon to trigger an update to the user profile automatically for the last access date.

2) There are two ways to solve the security exposure that is at the heart of your question:

a) If you want a home-grown solution, we advise the following:
It is our joint opinion that the best way to handle this situation is to use an FTP Exit Program to capture the FTP signon event. Based on this event, use the Exit Program to write or update physical file record containing the user profile and the date & time of signon. Your automatic user profile delete program should then check two places instead of one: the user profile last used date and time and the last access date and time in the file you wrote to or update to with the FTP exit program.

FTP Exit programs will accept and return the the following parameters:
- Application ID (FTP Client for example)
- Operation ID (Sending a file for examle)
- User Profile
- Remote IP address
- Length of remote IP address
- Operation
- Length of operation
- Allow Operation (this value when returned, will determine if the operation will be allowed or not)

A good example of an exit program, written by Alex Garrison, can be found on this site in the Downloads area of this website.

- WRKREGINF displays a list of the various system exit points

- The exit point for FTP is QIBMQTMF_SVR_LOGON. This is where you specify a user-built program that is called every time a user tries to logon to your AS/400 via FTP

If you are aiming for a stronger, more comprehensive solution, you can use a complete AS/400 internet and TCP/IP security solution such as PowerLock. You can find more information about their products at http://www.400security.com/products.htm - this would give you a much more robust and complete security solution to this problem.

Note: I have no shares or interest in PowerLock but I can tell you that my experience with their products where I work at my current customer has been very positive.

Alternative Solution proposed by Jim:

Thibault:

We found a API on the system that will allow us to change the signon date and time to current.
It is QSYCHGPR. This API can be called from the exit program or imbedded in the QUOTE RCMD command command if you are executing one within FTP.

Thanks for your help,

Jim

Go Back to the Top

Regarding an FTP QUOTE operation to a target system which works from one location but not from the other,
Ricky from Arkansas asks:

I am trying to help an associate figure out why he can't issue the QUOTE subcommand from an ftp session on his AS/400 when I can do it from my AS/400.
The problem goes like this: I, in Arkansas, can FTP a file to a client in Kentucky and then issue "QUOTE RCMD CALL LIBNAME/PGMNAME" and have it execute successfully.

When my associate, in New Jersey, FTP's a file to the same client in Kentucky (logged in with the same user name as me) his QUOTE statement always fails.

The log file always lists reply code 500 "Syntax error; command unrecognized." Any suggestions you might have into this matter will be greatly appreciated.

Response:

My first observation is that since you use the same user profile, the only difference between you and your New Jersey colleague is the origin from which you come do enter your Kentucky client's system. You obviously connect from different IP addresses.

If anything is right, your client probably has (at least, one does not exclude an other) one of the following 3 IP protection tools running on their network:
- an external firewall
- an AS/400 IP security software system, such as PowerTech PowerLock
- an AS/400 home-grown exit program

I cannot talk about all firewalls, but certainly, I can tell you about what AS/400 FTP exit programs can do. These exit programs can accept 7 different parameters to decide if they want to block a command. Conceivably, they can block an FTP command such as QUOTE, based on, amongst other things, the remote IP address.

FTP Exit programs will accept and return the the following parameters:

FTP Exit programs will accept and return the the following parameters:
- Application ID (FTP Client for example)
- Operation ID (Sending a file for example)
- User Profile
- Remote IP address
- Length of remote IP address
- Operation
- Length of operation
- Allow Operation (this value when returned, will determine if the operation will be allowed or not)

Knowing this, it is conceivable that your client has opened up your Kansas Location FTP access in either their firewall or their AS/400 controls with some rules based on remote IP address. I suspect strongly that they have not granted the EXACT SAME privileges to your New Jersey colleague as they have to you in Arkansas. This would explain why the New Jersey requests are rejected. They are rejected on the basis of "where does the command come from?".

The error message, saying "Syntax error; command unrecognized." to me is a bit of a red herring. AS/400 FTP error messages, in my experience, are not always meaningful and sometimes they are downright misleading. I would ask your client's network administrator and AS/400 TCP/IP administrator what actions they took to open their system to you-in-Arkansas, and how they would differ with how they opened the connection to you-in-New-Jersey. They may say the openings are identical, but I would question that, based on what you told me. Give me some news on this if you are successful, this is a very interesting problem. Thanks, Thibault.

Confirmation from Ricky:

Thank you for your quick reply and thoughts. You were correct in the suggestion that a firewall was involved, however the problem wasn't at Kentucky but at New Jersey. Within the software on New Jersey's LAN server, you had to specifically enter in acceptable FTP subcommands that were allowed and of course the QUOTE command wasn't there. Once added, everything fell into place. Thanks again for your help.

Yours truly, Ricky

Go Back to the Top

On how to override the FTP default port of communication on iSeries,
Monlisa, of Toronto, asks:

I have a HK partner giving me the IP address as '111.222.133.114' . When using a standard FTP command on the iSeries, it will automatically routes the transmission to through port 21.
Our partner however, asked me to use port 2888 rather than port 21.
How can I redirect FTP to use an other port?
Can I specify during the initial ftp command ?

Response:

I did not find the answer to this question, but Monlisa did get it from IBM's Technical Services. The answer is YES to both questions above.

The solution :

The solution is to FTP to either an IP address, or a named server, followed by a blank character and then by the port number.
Here is an example of the command and the resulting response from an FTP example where the FTP client who is issuing the command wants to communicate on Port 2888:

FTP request from the local system:
FTP RMTSYS('111.222.133.114 2888')
FTP response from the remote system:
Connecting to remote host 111.222.133.114 using port 2888.
220 hksvr005 Microsoft FTP Service (Version 4.0).

Note: The example above shows an IP address, a www address can be used also, if it is an FTP host. The command would then look like:
FTP RMTSYS('www.example.net 1777')

Go Back to the Top

On how to export an iSeries type DB2 file to Microsoft Excel,
Sylvia, of Calgary, asks:

I have a file with a mixture of character, packed and zoned fields, some with positive, some with negative values. What would be the most efficient way to export these to a Microsoft Excel spreadsheet?

Response:
The first challenge in this situation is to unpack the numeric data so that it can be translated from EBCDIC to ASCII, and to keep the signs also.
The second challenge is to insert some type of delimiter between each field, so that EXCEL can see the boundaries between fields when it does the import.

The solution :
One little known command on the standard iSeries operating system can do this for you in one pass: CPYTOIMPF

Here is an example of how to use this command:

CPYTOIMPF FROMFILE(DB2FILE) TOFILE(IMPFILE) FLDDLM(';') RCDDLM(X'07')

In the example above, All records of externally described file DB2FILE will be copied to import file EXPFILE. The packed fields will be unpacked, the zone fields will remain zoned, and each field will be delimited by a ';' character and the record delimiter will be a X'07'.

Once you have the EXPFILE created, you can conveniently FTP it to a PC or to a Local Area Network drive as a .txt file, such as IMPFILE.TXT.

From there, in its new unpacked, delimited and translated to ASCII format, the resulting file (IMPFILE.TXT in this example) can be comfortably imported into an EXCEL sheet.

Go Back to the Top

On how to execute a command on a remote AS/400 using FTP,
Yvon, of Montreal, asks:

I am trying to send command to my AS400 using the FTP.
I can do CLRPFM and other IBM commands but when I do a CALL RPG_PGM passing with it a parameter, it does not do anything.
I have entered the following command:
quote rcmd call ftptestpgm 'testingparm'
Any suggestions?

The solution :

Regarding your question on FTP, the rule of thumb is to write the command as it will be understood by the AS/400. When you type
call ftptestpgm 'testingparm'
on a command line, it is actually parsed and formatted out into something the system can understand:
CALL PGM(FTPTESTPGM) PARM('testingparm')
This parsing and formatting does not occur when you enter your command on the FTP QUOTE RCMD function.
To help you find what should be typed exactly, use the F4 function on the AS/400 command line, then use the F14 function key to display the command string.
Copy and paste the string into your FTP session and it should always be successful. The command line in your script file would thus look like

QUOTE RCMD CALL PGM(FTPTESTPGM) PARM('TESTINGPARM')

Note: the FTP instructions and the call instructions are not case-sensitive. The parameter, however is case-sensitive and should be sent with the case formatting the program is expecting.

Go Back to the Top

On how to dynamically FTP Documents to iSeries Active Users
Will, from Utah, wrote:

"Do you know of any way to dynamically retrieve the IP address of a user's local PC in order to do an FTP to a local drive without requiring the user to do the transfer manually, utilizing the FTP program of the emulation software?

I would like to somehow get the IP address and feed it as a parameter to a CL program where I could then download a file to the PC which has been previously created on the AS400. "

Response:

1) Call the qusrjobi API to retrieve the IP address of your customer. If the job is
still active (the API does tell you if that is the case or not)

2) Using that information, you can use an RPG or COBOL or C program to
customize an INPUT file where it would connect to the IP address just found.

3) You run that INPUT file (see FTP Automation article example and technique to use for batch FTP) and monitor for results.

Note: The QUSRJOBI API program, "Retrieve Job Information", part of iSeries's WORK MANAGEMENT APIs, can retreive the Client IP address in its JOBI0600 format. (search for "API finder" in the IBM iSeries Information Center to get the specs).

Go Back to the Top

On how to access the IFS:

The easiest way to access the contents of the IFS is

dspf '/' to display the IFS root path

WRKLNK IFS  to explore the IFS  

Go Back to the Top

On how to launch a command on a remote server:

The command line to do this is relatively simple. Here is an example launching a .bat file on a Windows server:

RUNRMTCMD CMD('c:\ftpbatfiles\run_procedure.bat') RMTLOCNAME('122.121.123.321' *IP) RMTUSER(USERNAME) RMTPWD('PASSWORD')

Go Back to the Top