Needed FTP command parms:  to get file filexyz.file   to filexyz.txt at client PC

asdf13 used Ask the Experts™
Started logon on iSeries with FTP.  for getting:   PF file (character fields) to WIN-PC, as txt-file.

File which arrives at PC is no readable textfile.
What are possible reasons : Codepage, Charakterset ... ?

FTP command:  get  filexxxx.file  filexxx.txt



??????????Å????Å???Å???ÅÅ???????????????????ÅÅÅÅÅÅÅÅÅÅ???????????Å??????????ÅÅ?????????ÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅ??????????ÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅ?ÅÅÅÅÅÅÅÅÅÅÅ?????????????Å????Å?ÅÅÅÅÅÅÅÅÅÅÅÅ????????Å?????????'ÅÅÅ????ÅÅÅÅÅÅ??ÅÅÅÅÅÅÅÅÅÅÅ???ÅÅ ??ñ

thanks a lot for detailed Information about FTP so far.
Problem seems System (LPAR) dependend. I tested on two different LPAR: one was OK, on the other LPAR notOK (see above) with the same FTP (Log below)

OK FTP result:
1010818102824TSISAVE   QUSRBRM   *FILE   SAVF      0_c€à_ qusrbrm for flashcopy restore                     001030518100956

Both LPAR have the same, following definitions:
PF CCSID                : 37

PF field is  :
 (wanted only to get field ODDDAT from QUSRBRM.file,  for Monitoring reasons on WIN-PC. Ignored other fields in the record .. . . . )
ODDDAT     CHAR            6       6         2        Both
      Coded Character Set Identifier  . . . . . :     37      

QUSRBRM.file was created by :

Question is: what may be the reason for unreadable FTP result.  (other/more  sysval as CCSID ?)            
FTP log is the same on both LPAR:

230 xxxxxxxx  logged on.
ftp> cd /qsys.lib
250-NAMEFMT set to 1.
250 "/QSYS.LIB" is current library.
ftp> cd MYLIB.lib
250 "/QSYS.LIB/MYLIB.LIB" is current library.
ftp> get QUSRBRM.file TMPLIST.csv
200 PORT subcommand request successful.
150 Retrieving member QUSRBRM in file QUSRBRM in library MYLIB.
226 File transfer completed successfully.
ftp: 648 bytes received in 0.00Seconds 648000.00Kbytes/sec.
ftp> quit
221 QUIT subcommand received.

i tested  output file with defintion  .TXT and .CSV : same negative result.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Bill BachPresident and Btrieve Guru

First, try changing FTP to binary mode with the command "bin", and see if that helps.  
If not, then you might have a problem where the source data is in EBCIDIC.
Bill BachPresident and Btrieve Guru

Darned auto-correct: EBCDIC.
Gary PattersonVP Technology / Senior Consultant

the ".file" extension you show leads me to think that you may be trying to use FTP to transfer a native file system (QSYS.LIB) *FILE object, which is generally a "physical file" - it is also an iSeries DB2 table.

Except in unusual cases, transfer of physical file/DB2 table objects via FTP to any host other than another iSeries really isn't going to do much that is useful for you.  Data in these objects can be encoded in very complex ways.  For example, each column in a physical file/DB2 table can be encoded in a different way, depending on the data type (and for character columns, the associated CCSID).  FTP doesn't know, for example, how to convert an Integer column, or a packed decimal column to anything usable to a PC.

Can you explain what it is you are trying to accomplish, and actually provide the full FTP session dialog?  Guesswork makes it hard, and there are a lot of possible complications.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

VP Technology / Senior Consultant
Just re-read question, and saw answer - this is a PF with character fields.  Use DSPFD and post the CCSID associated with the file.  Then use DSPFFD and post the CCSID(s) associated with each column (it will probably be the same as the file, but since we're looking, lets be thorough).

When you use a BINARY transfer on a *PF, you get what you ask for - a binary image of the PF contents.  If you're working on a US-localized system like I am, that means that odds are the data is probably encoded in CCSID 37 (US EBCDIC), and the PF is flagged as wither CCSID 37, or CCSID 65535 (binary/"do not translate").  Either way, you're going to get an EBCDIC file, which is meaningless to most PC programs (though Notepad++ has a plugin called TextFX that can do EBCDIC/ASCII conversion and vice-versa).

If you use an "ASCII" transfer on a *PF, you're asking FTP (I don't actually know if the conversion is performed by the server or the client) to take each byte and try to convert it to ASCII code page.  If the PF is CCSID 37, the system will attempt to convert EBCDIC to ASCII.  If the PF is CCSID 65535, I'm not sure what happens.

Anyway, FTP isn't a good tool for transferring *PF objects (to non iSeries hosts) - it is only barely supported, and lots of things can break it or give you garbage.  Lots of other tools are available to get a PF in a PC-friendly format, for example, use CPYTOIMPPF to convert the PF to a CSV, and then download the CSV via FTP.  Or use IBM i Access for Windows Data Transfer to get your *PF downloaded in a choice of PC formats with proper field-by-field conversion, including character conversion, numeric conversion, data conversion, etc.


added  more details to question description.
Gary PattersonVP Technology / Senior Consultant

Try forcing ASCII transfer before issuing GET in FTP session.  

If the outfile you created is CCSID 37 on both systems (is it?), that will force ASCII conversion during download.  If outfile is CCSID 65535, ASCII and BINARY transfer will produce the same result - usually gibberish on the PC - untranslated EBCDIC.

Or, just try this alternate approach.  This should specifically produce an ASCII CSV in the IFS that you can then download (and this approach works even when you have numeric columns or data columns in the PF).  If you are on a recent version of IBM i, you can optionally get column headings, too.

/* Note ADDCOLNAM(*SYS) is only supported in V7R1 TR5 and later - it adds column names to the top of the file */


Other CPYTOIMPF options can get it with other delimiters, or in fixed format if CSV is a problem for you.

If the outfile for some reason is CCSID 65535, add the FROMCCSID(37) parameter to force EBCDIC-to-ASCII conversion

Then in your FTP session (you need namefmt 1 to download from the IFS - quote site namefmt 1 to explicitly set if needed)

get /somedir/qusrbrm.csv


yes, both outfiles have CCSID 37.

But from some LPARs  "gibberisch"  Textfile will be created by FTP on PC.
Of course, other transfer mehtods  (as you wrote) work better.
But i can not do anything on the monitored LPARs.
So i have to figure out, why FTP with some LPAR works  as intended, on other LPAR delivers "gibberisch".
Gary PattersonVP Technology / Senior Consultant

In your example, you have MYLIB/QUSRBRM for both the OBJ() and the OUTFILE().  That does not look right.  Any chance you are trying to transfer the wrong file?

You can run DSPOBJD (or it is being run for you), but you cannot run CPYTOIMPF?  Is that correct?

Could you run it using the ftp "rcmd" command from Windows FTP?

get /somedir/qusrbrm.csv

On the problem LPAR, can you download the file using both ASCII and BINARY downloads, and post files here?
Is your PC running an English version of Windows?


i did some more tests, also with copytoimpf and downloaded with FTP - it works correct:

 ************Beginning of data**************                                    
"1","030818","101437","TSISAVE   ","QUSRBRM   ","*FILE   ","SAVF      ","0",3003   . . . . . .. .
 ************End of Data********************  

FTP to .csv:
"1","030818","034216","TSISAVE   ","QUSRBRM   ","*FILE   ","SAVF      ","0",4363460608  ,"qusrbrm for flashcopy restore  . . . .. . .          

Further i found, the "gibberisch" comes not from FTP!
 (sorry i did not seen before).
After FTP - which gets the csv-file  to PC: , there  is a command, which adds single downloaded FTP-file to a cumulated file: TMPLISTS (in a looop) :

WIN command for this is:

within this command sometimes "gibberisch" will be created in TMPLISTS.CSV.  (TMPLIST.CSV is always OK)
So it seems, FTP-file from special LPARS are wrong, but it is only a result of "add" command above.
As Example, TMPLISTS from 7 LPARS :

1. LPAR:
??????????Å????Å???Å???ÅÅ???????????????????ÅÅÅÅÅÅÅÅÅÅ???????????Å??????????ÅÅ?????????ÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅ??????????ÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅ?ÅÅÅÅÅÅÅÅÅÅÅ?????????????Å????Å?ÅÅÅÅÅÅÅÅÅÅÅÅ????????Å??????????ÅÅÅ????ÅÅÅÅÅÅ??ÅÅÅÅÅÅÅÅÅÅÅ???ÅÅ ??!



1020818235835TSISAVE   QUSRBRM   *FILE   SAVF      0
e?qusrbrm for flashcopy restore                     001030518100956TSISEC    1051818125843SAVLIB    †cˆà±00Band      UQ0420                                                      01051818212849999999                                                                1                        00101080218235515                    01TSISAVE                 ASUFFP11TSIFABIA  ASUFLP21Y1080218
                *SV7R1M0            X010                       *NONE    


é *NONE     000000001000                                  


é 0000100001*SYSBAS   *SYSBAS   00














1030818101437TSISAVE   QUSRBRM   *FILE   SAVF      0
“       q|qusrbrm for flashcopy restore                     001030518100956TSISEC    1051818131640SAVLIB    œÉÌâä 00Tape      UQ0420                                                      01051918083508999999                                                                1                        00231080318100941                    01TSISAVE                 ASUSKP11TSIFABIA  ASUFLP21Y1080318
        ?       *SV7R1M0            X010                       *NONE    


é *NONE     000000002300                                  


é 0000100001*SYSBAS   *SYSBAS   00


Ccomplete Monitor Skripts, which create TMPLISTS:

Start command (Loop) :  
                                 for /F "tokens=1,2" %%x in (SYSTEMPROD.txt) do PUTMON.cmd %%x %%y

                                 with SYSTEMPROD  Textfile like :    LPARNAM1  < IP 1>
                                                                                              LPARNAM2  < IP 2>
                                                                                               LPARNAM3  < IP 3>
                                                                                              . . .  more
                                with PUTMON :
                                                            C:\WINDOWS\system32\FTP  -s:MONFTP.txt %2>> log.txt
                                                            If exist TMPLIST.CSV (more<TMPLIST.CSV >> TMPLISTS.CSV)  
                               with MONFTP: <USER>
                                                         cd /qsys.lib
                                                         cd MYLIB.lib
                                                        get qusrbrm.file TMPLIST.csv

No idea, why "gibberisch" is created in TMPLISTS with :


Problem was a  "text file issue".
Solution:  Command "more" replaced by "type":

more<TMPLIST.doc >> TMPLISTS.doc


then file TMPLISTS gets readable.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial