[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FTP transfers garbled up



Hello Thomas,

Have a drink on me tonight :) After adding the FTP_codePage call the
transfer is ok, so this is clearly the solution. (Our CCSID in CHGFTPA
was the same as on your boxes: 819)

But what surprises me, is the fact that this program, in which we are
calling the FTPAPI procedures, has been active on several boxes since
april 2007 and never gave any problems what so ever. It only gives a
problem connecting to this one remote FTP server. If it is because of
this CCSID difference, then why doesn't it go wrong in all cases ...?
Because I checked and on every box it is being used the CHGFTPA CCSID is
819.

While it solves my problem in this case, we now need to test if this
adjustment doesn't have an impact on transfers that were previously
going ok.

Many thanks to you and all that replied. And Scott, again sorry for
being so pushy...


Vriendelijke groet / Kind regards,

Mark Smits
Com-Unit BV, The Netherlands
The makers of Spider-Road

Tel. : +31 (0) 20 612 6856
Email: Smits@xxxxxxxxxxxx
WWW  : www.com-unit.com 

> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx 
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Thomas Raddatz
> Sent: Friday, August 14, 2009 9:46 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: Re: FTP transfers garbled up
> 
> Mark,
> 
> Did you already check the default ASCII CCSID of your FTP 
> configuration? If you did not already do that, please type 
> CHGFTPA and press F4 to prompt the command. Then look at the 
> CCSID parameter to get your default ASCII CCSID. That CCSID 
> is used by the IBM FTP command when you set the transfer type 
> to ASCII. For example on our box that parameter is set to 819 
> which means that every file is translated to CCSID 819 when 
> using ASCII mode.
> 
> If your default ASCII CCSID is not equal to 437, which is the 
> default of FTP API, use
> FTP_codePage(session: yourDftAsciiCcsid: 1252) to change the 
> default values of FTP API to match your default ASCII CCSID 
> and the CCSID of the file to be transferred. Then try to send 
> the file again. Is it correct now?
> 
> You may also try to use the IBM FTP command to transfer the 
> file but set the ASCII CCSID to 437 right before transferring 
> the file. Open the FTP client and then use the TYPE command 
> to change the ASCII CCSID:
> 
>     type c 437
> 
> Then transfer the file and check whether it is messed up the 
> same way as if it was transfered using FTP API.
> 
> The problem you have is a CCSID problem and we have to try to 
> figure out what CCSIDs to use.
> 
> Last but not least please ensure that the outgoing and 
> incoming EBCDIC/ASCII table values of CHGFTPA are set to 
> *CCSID to ensure that no table objects are used to do the 
> ASCII/EBCDIC translation. It also may be interesting to know 
> what operating system is running on the target server and and 
> whether the target server knows about CCSIDs or something similar.
> 
> Perhaps I am completely wrong because you did not yet 
> encounter that error with all the other servers you exchange 
> data with. But at least it will not take too much time to 
> check and try the things I described above and perhaps it 
> will let us to new ideas.
> 
> Thomas.
> 
> 
> 
> Mark Smits schrieb:
> > We are using the FTP API to communicate with several FTP 
> servers and never encountered any problems. Until this one 
> server which gives two different problems. We are using ASCII 
> mode to send over the files.
> > 
> > 
> > 1. Storing a file in the IFS, where the CCSID of the IFS 
> file is 1252.  When FTP'ing this file, the contents gets 
> garbled up. As if there has been some kind of code page 
> conversion. This only happens when using the API. Doing a 
> manual FTP (using the FTP command) from the iSeries to the 
> server, the file arrives intact.
> > 
> > 2. Storing a member in a file. This file has CCSID 37. When 
> FTP'ing a CR+LF is translated into a LF. If I am not mistaken 
> this is an "automatic conversion" when using ASCII mode and 
> one side is Unix and the other is PC environment. But we 
> never encountered this before and the strange thing is, that 
> FTP'ing manual from the iSeries this translation is not happening.
> > 
> > In both cases the FTP API seems to do some stuff that 
> manual FTP isn't. And as stated before, we never saw these 
> problems with other servers. And we do exactly the same when 
> communicating to those other servers.
> > 
> > Any ideas of what might be wrong ?
> > 
> > 
> > Vriendelijke groet / Kind regards,
> > 
> > Mark Smits
> > Com-Unit BV, The Netherlands
> > The makers of Spider-Road
> > 
> > Tel. : +31 (0) 20 612 6856
> > Email: Smits@xxxxxxxxxxxx
> > WWW  : www.com-unit.com
> > 
> ----------------------------------------------------------------------
> > - This is the FTPAPI mailing list.  To unsubscribe, please go to:
> > http://www.scottklement.com/mailman/listinfo/ftpapi
> > 
> ----------------------------------------------------------------------
> > -
> > 
> --------------------------------------------------------------
> ---------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> --------------------------------------------------------------
> ---------
> 
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------