[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FTP transfers garbled up

From: thomas.raddatz@xxxxxx
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FTP transfers garbled up
Date: Wed, 19 Aug 2009 10:19:26 +0200
Mark,

I followed your advice and had a cold beer last evening.

Somehow it is surprising that you never got that error before, but somehow
it is not suprising. Depending on the locale settings of the target
computer and on the characters you sent everything might appear well
although the CCSIDs are not the same. That is certanly true as long as all
you transfer are invariant characters. Invariant characters have the same
hex code for all CCSIDs. But as soon as you start transferring special
characters such as the German "Umlaute" (ä,ü,ö, ...) you will encounter
problems.

So probably the best way to go is to use a file to store the name of the
target servers alsong with their preffered CCSIDs. Then you can use
FTP_codePage() to set the proper CCSID depending on the target server.

Thomas.


ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 18.08.2009 15:26:28:

> Von:
>
> smits@xxxxxxxxxxxx
>
> An:
>
> ftpapi@xxxxxxxxxxxxxxxxxxxxxx
>
> Datum:
>
> 18.08.2009 15:41
>
> Betreff:
>
> RE: FTP transfers garbled up
>
> Gesendet von:
>
> ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>
> 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
> -----------------------------------------------------------------------


--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a criminal
offence. Please delete if obtained in error and email confirmation to the sender.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
References:
- FTP transfers garbled up
  - From: Mark Smits
- Re: FTP transfers garbled up
  - From: Thomas Raddatz
- RE: FTP transfers garbled up
  - From: Mark Smits
Prev by Date: RE: HTTPAPI vs. XMLToolKit
Next by Date: Problem w/WSDL2RPG v1.7.3
Previous by thread: RE: HTTPAPI vs. XMLToolKit
Next by thread: FW: FTP transfers garbled up
Index(es):
- Date
- Thread