[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FTP transfers garbled up
CHGFTPA controls the IBM FTP server. It has no impact on FTPAPI.
Mark Smits wrote:
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: [1]Smits@xxxxxxxxxxxx
WWW : [2]www.com-unit.com
-----Original Message-----
From: [3]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[[4]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: [5]Smits@xxxxxxxxxxxx
WWW : [6]www.com-unit.com
----------------------------------------------------------------------
- This is the FTPAPI mailing list. To unsubscribe, please go to:
[7]http://www.scottklement.com/mailman/listinfo/ftpapi
----------------------------------------------------------------------
-
--------------------------------------------------------------
---------
This is the FTPAPI mailing list. To unsubscribe, please go to:
[8]http://www.scottklement.com/mailman/listinfo/ftpapi
--------------------------------------------------------------
---------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
[9]http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
References
1. mailto:Smits@xxxxxxxxxxxx
2. http://www.com-unit.com/
3. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
4. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
5. mailto:Smits@xxxxxxxxxxxx
6. http://www.com-unit.com/
7. http://www.scottklement.com/mailman/listinfo/ftpapi
8. http://www.scottklement.com/mailman/listinfo/ftpapi
9. 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
-----------------------------------------------------------------------