Needed FTP command parms: to get file filexyz.file to filexyz.txt at client PC
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
Result:
㌱〱ㄷ〸㌳㈴吰䥓䅓䕖†儠单䉒䵒†⨠䥆䕌†匠噁⁆††〠
or
??????????Å????Å???Å???ÅÅ?
Hello,
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:
QSYSVAL QCCSID : 65535
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 :
DSPOBJD OBJ(MYLIB/QUSRBRM) OBJTYPE(*FILE) OUTPUT(*OUTFILE) -
OUTFILE(MYLIB/QUSRBRM)
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.
File which arrives at PC is no readable textfile.
What are possible reasons : Codepage, Charakterset ... ?
FTP command: get filexxxx.file filexxx.txt
Result:
㌱〱ㄷ〸㌳㈴吰䥓䅓䕖†儠单䉒䵒†⨠䥆䕌†匠噁⁆††〠
or
??????????Å????Å???Å???ÅÅ?
Hello,
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:
QSYSVAL QCCSID : 65535
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 :
DSPOBJD OBJ(MYLIB/QUSRBRM) OBJTYPE(*FILE) OUTPUT(*OUTFILE) -
OUTFILE(MYLIB/QUSRBRM)
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.
Darned auto-correct: EBCDIC.
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
added more details to question description.
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 */
DSPOBJD OBJ(MYLIB/QUSRBRM) OBJTYPE(*FILE) OUTPUT(*OUTFILE) OUTFILE(QTEMP/OUTFILE)
CPYTOIMPF FROMFILE(QTEMP/OUTFILE) TOSTMF('/somedir/qusrbrm.c
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
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 */
DSPOBJD OBJ(MYLIB/QUSRBRM) OBJTYPE(*FILE) OUTPUT(*OUTFILE) OUTFILE(QTEMP/OUTFILE)
CPYTOIMPF FROMFILE(QTEMP/OUTFILE) TOSTMF('/somedir/qusrbrm.c
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
ASKER
Hello,
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".
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".
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?
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?
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?
quote rcmd CPYTOIMPF FROMFILE(OUTFILE) TOSTMF('/tmp/qusrbrm.csv')
get /somedir/qusrbrm.csv
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?
ASKER
Hello,
i did some more tests, also with copytoimpf and downloaded with FTP - it works correct:
....+....1....+....2....+.
************Beginning of data**************
"1","030818","101437","TSI
************End of Data********************
FTP to .csv:
"1","030818","034216","TSI
==========================
Further i found, the "gibberisch" comes not from FTP!
(sorry i did not seen before).
Reason:
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:
If exist TMPLIST.CSV (more<TMPLIST.CSV >> TMPLISTS.CSV)
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:
??????????Å????Å???Å???ÅÅ?
????ÅÅ??????%ÅÅÅÅÅÅÅÅÅÅÅÅÅ
??
??????????Å????Å?
??????Å?????
2.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
œ?1*SYSBAS *SYSBAS
3.LPAR
??????????Å????Å???Å???ÅÅ?
????ÅÅ??????%ÅÅÅÅÅÅÅÅÅÅÅÅÅ
??????????Å????Å?
??????Å?????
4.LPAR
??????????Å????Å???Å???ÅÅ?
????ÅÅ??????%ÅÅÅÅÅÅÅÅÅÅÅÅÅ
??
??????????Å????Å?
??????Å?????
5.LPAR
??????????Å????Å???Å???ÅÅ?
????ÅÅ??????%ÅÅÅÅÅÅÅÅÅÅÅÅÅ
??
??????????Å????Å?
??????Å?????
6.LPAR
??????????Å????Å???Å???ÅÅ?
????ÅÅ??????%ÅÅÅÅÅÅÅÅÅÅÅÅÅ
??
??????????Å????Å?
??????Å?????
7.LPAR
1030818101437TSISAVE QUSRBRM *FILE SAVF 0
“ q|qusrbrm for flashcopy restore 001030518100956TSISEC 1051818131640SAVLIB œÉÌâä 00Tape UQ0420 01051918083508999999 1 00231080318100941 01TSISAVE ASUSKP11TSIFABIA ASUFLP21Y1080318
? *SV7R1M0 X010 *NONE
ìÁc
é *NONE 000000002300
kë?
é 0000100001*SYSBAS *SYSBAS 00
œ?1*SYSBAS *SYSBAS
==========================
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>
<PWD>
ascii
cd /qsys.lib
cd MYLIB.lib
get qusrbrm.file TMPLIST.csv
quit
No idea, why "gibberisch" is created in TMPLISTS with :
If exist TMPLIST.CSV (more<TMPLIST.CSV >> TMPLISTS.CSV)
:-(
i did some more tests, also with copytoimpf and downloaded with FTP - it works correct:
....+....1....+....2....+.
************Beginning of data**************
"1","030818","101437","TSI
************End of Data********************
FTP to .csv:
"1","030818","034216","TSI
==========================
Further i found, the "gibberisch" comes not from FTP!
(sorry i did not seen before).
Reason:
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:
If exist TMPLIST.CSV (more<TMPLIST.CSV >> TMPLISTS.CSV)
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:
??????????Å????Å???Å???ÅÅ?
????ÅÅ??????%ÅÅÅÅÅÅÅÅÅÅÅÅÅ
??
??????????Å????Å?
??????Å?????
2.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
œ?1*SYSBAS *SYSBAS
3.LPAR
??????????Å????Å???Å???ÅÅ?
????ÅÅ??????%ÅÅÅÅÅÅÅÅÅÅÅÅÅ
??????????Å????Å?
??????Å?????
4.LPAR
??????????Å????Å???Å???ÅÅ?
????ÅÅ??????%ÅÅÅÅÅÅÅÅÅÅÅÅÅ
??
??????????Å????Å?
??????Å?????
5.LPAR
??????????Å????Å???Å???ÅÅ?
????ÅÅ??????%ÅÅÅÅÅÅÅÅÅÅÅÅÅ
??
??????????Å????Å?
??????Å?????
6.LPAR
??????????Å????Å???Å???ÅÅ?
????ÅÅ??????%ÅÅÅÅÅÅÅÅÅÅÅÅÅ
??
??????????Å????Å?
??????Å?????
7.LPAR
1030818101437TSISAVE QUSRBRM *FILE SAVF 0
“ q|qusrbrm for flashcopy restore 001030518100956TSISEC 1051818131640SAVLIB œÉÌâä 00Tape UQ0420 01051918083508999999 1 00231080318100941 01TSISAVE ASUSKP11TSIFABIA ASUFLP21Y1080318
? *SV7R1M0 X010 *NONE
ìÁc
é *NONE 000000002300
kë?
é 0000100001*SYSBAS *SYSBAS 00
œ?1*SYSBAS *SYSBAS
==========================
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>
<PWD>
ascii
cd /qsys.lib
cd MYLIB.lib
get qusrbrm.file TMPLIST.csv
quit
No idea, why "gibberisch" is created in TMPLISTS with :
If exist TMPLIST.CSV (more<TMPLIST.CSV >> TMPLISTS.CSV)
:-(
ASKER
Problem was a "text file issue".
Solution: Command "more" replaced by "type":
replaced
more<TMPLIST.doc >> TMPLISTS.doc
by
type TMPLIST.csv >> TMPLISTS.CSV
then file TMPLISTS gets readable.
Solution: Command "more" replaced by "type":
replaced
more<TMPLIST.doc >> TMPLISTS.doc
by
type TMPLIST.csv >> TMPLISTS.CSV
then file TMPLISTS gets readable.
If not, then you might have a problem where the source data is in EBCIDIC.