[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FTP transfers garbled up
I know, I know, that's why I apoligised up front, but when there is pressure coming from above... And to be honest, it was not my idea to post again...Again accept my apologies...
Anyway, The edtf doesn't give any message. As an in between solution and as test that the file is really readable and not messed up, we are now also emailing the same file as attachment using some Java program. The file attaches just fine and is readable. Just as when opening with Windows Explorer for example. When attaching a wrong CCSID on purpose, it won't open readable in Windows Explorer for us. So notihng wrong with the file in question. We are really stumped on this one...
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
> Christen, Duane
> Sent: Thursday, August 13, 2009 6:22 PM
> To: HTTPAPI and FTPAPI Projects
> Subject: RE: FTP transfers garbled up
>
> I hope Im not over stepping my bounds here, and if I am sorry Scott.
>
> Scott has a job (several(?)) and while he supports his open
> source projects in an exceptional fashion, he does it on his
> own time so please keep that in mind when demanding service.
>
> That being said,
>
> I would check that the file is tagged with the correct CCSID,
> On a command line enter "edtf
> stmf('/SEX/1/interfacing/BackupHistory/NEE_FR_OUT_SPL3')"
> Your file should come up in the green screen editor, and
> should look correct. At the bottom of the screen, if there is
> a message about the CCSID being incorrect or the data is
> "garbled" then the file is probably tagged with the incorrect CCSID.
>
> If the data looks good but there is a message you can press
> F15 to see the CCSID (option 3) the editor is using to
> display the data. This is probably the CCSID that the file
> should be tagged with.
>
> If the data is "garbled" you need to look at the process that
> created the file and determine what CCSID it is creating the
> data with and ensure that it is tagging the file with the
> correct CCSID.
>
> In any case I would suspect that the file's CCSID attribute
> is incorrect, and that FTPAPI is doing the conversion with
> incorrect information, where the IBM ftp client is
> determining the CCSID of the data, similar to what edtf does.
>
> Hope that helps
>
> Duane Christen
>
>
> --
>
>
> Duane Christen
> Senior Software Engineer
> (319) 790-7162
> Duane.Christen@xxxxxxxxxx
>
> Visit PAETEC.COM
>
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mark Smits
> Sent: Thursday, August 13, 2009 9:55 AM
> To: HTTPAPI and FTPAPI Projects
> Cc: Jan Büscher
> Subject: FW: FTP transfers garbled up
>
> Hi Scott,
>
> Have you had any chance yet to look into the matters below.
> Sorry if I sound a little bit pushing, but it is rather
> urgent and we are out of clues...
>
>
> 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
>
> > Hi Scott,
> >
> > Find below some additions.
> >
> > > Hi Mark,
> > >
> > > > 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.
> > >
> > > The purpose of ASCII mode in FTP is to enable character set
> > > conversion.
> > > So there *should* be code page (or CCSID) conversion
> > going on when
> > > you use FTP in ASCII mode.
> > >
> > > I'm not really sure what is meant by "garbled up". I assume
> > > that means
> > > that it's somehow doing the *wrong* code page conversion, into
> > > something unreadable.
> > >
> >
> > Yes, with garbled up I meant some kind of invalid code page
> > conversion.
> > I have attached an example file, which was attached by reading it
> > directly from the iSeries IFS file system. It opens and reads just
> > fine.
> >
> > Some stuff copied and pasted from the green screen
> properties of the
> > file in question:
> >
> > Object . . . . . . :
> > /SEX/1/interfacing/BackupHistory/NEE_FR_OUT_SPL3
> > >
> > CCSID (Coded Character Set Identifier) : 1252
> >
> >
> > We are using a "FTPAPI_PUT" program to FTP the file, This
> program does
> > the following calls (where in this case the "move/rename" is not
> > executed):
> >
> > * Connect to FTP server ...
>
> > c eval Connection =
>
> > c
> ftp_conn(Server:User:Password)
> > c if Connection < 0
>
> > c eval Message = ftp_errorMsg(0)
>
> > c eval Message =
> iSeriesAdjust(Message:' ')
> > C CallP
> ProgramLog('*ERROR':'FTP0000':Message)
> > c CallP
> SndPgmMsg('FTP0000':'@MSG':Message:
> > c '*ESCAPE')
>
> > c eval *inlr = *on
>
> > c return
>
> > c endif
>
> > * Binary Mode ...
>
> > c callp ftp_binaryMode(Connection:
> *off)
> > * Put file ...
>
> > c if
> ftp_put(Connection:RemoteFile:LocalFile)
> > c
> <0
> > c eval Message =
> ftp_errorMsg(Connection)
> > c eval Message =
> iSeriesAdjust(Message:' ')
> > C CallP
> ProgramLog('*ERROR':'FTP0000':Message)
> > c CallP
> > SndPgmMsg('FTP0000':'@MSG':Message:
> > c '*ESCAPE')
> >
> > c endif
> >
> > * Move / Rename file ...
> >
> > c If %Parms >= 6 and FinalLocation
> > <> ' '
> > c if
> > ftp_rename(Connection:RemoteFile:
> > c
> > FinalLocation) <0
> > c eval Message =
> > ftp_errorMsg(Connection)
> > c eval Message =
> > iSeriesAdjust(Message:' ')
> > C CallP
> > ProgramLog('*ERROR':'FTP0000':Message)
> > c CallP
> > SndPgmMsg('FTP0000':'@MSG':Message:
> > c '*ESCAPE')
> >
> > c endif
> >
> > c Endif
> >
> > * Quit ...
> >
> > c callp ftp_quit(Connection)
> >
> > c eval *inlr = *on
> >
> > C CallP
> > ProgramLog('*SUCCES':'':LocalFile)
> >
> > If you can provide me with your personal email address instead of
> > going through the list, I can give you IP and
> username/password of the
> > system we are FTP'ing to.
> >
> > > I'm going to need more details in order to take this any
> further.
> > > If you can tell me how to reproduce the problem on my own system,
> > > that would help a lot.
> > >
> > >
> > > > 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
> > >
> > > I don't follow this. Members in files don't typically
> have either
> > > CRLF or just LF. Members are record-oriented files, not
> text files,
> > > and so they don't use end-of-line markers, but rather have a
> > > fixed-width field layout.
> >
> > You are right. I got mixed up a bit, because normally when we FTP a
> > member, on the receiving end, each record in the member is
> on its own
> > line, so line delimiters seem to be automatically added. But this
> > receiver is telling us, that everything is received as one
> line. They
> > don't have any linebreaks in the received file.
> >
> > > Is FTPAPI the sender or receiver?
> >
> > In both cases FTPAPI is the sender.
> >
> > > Is the destination a member? Or is it coming from a
> > member? Or both?
> >
> > In both cases the destination is a file on which seems to be a
> > UNIX/LINUX system.
> >
> > >
> > > Please tell me how to reproduce the problem. If I can
> reproduce the
> > > problem, I can troubleshoot and fix it.
> > > Otherwise, I'm stuck trying to guess all of the technical
> details,
> > > which is extremely difficult. So please tell me how to reproduce.
> >
> > Just create a PF (CCSID 37 in this case) with a single
> field. Create a
> > member with several records in it and FTP to destination.
> It uses the
> > same "FTPAPI_PUT" as mentioned above. The destination is
> the same FTP
> > server as in the first problem.
> >
> > To summarize: FTP'ing to the same system. File from IFS to
> destination
> > gets wrong code page conversion. Member to destination does not get
> > any line delimiters.
> >
> > > > 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.
> > >
> > > Working exactly like IBM's FTP client has never been one of the
> > > goals of the FTPAPI project, and probably will never be a
> goal. So
> > > please help me fix things that are causing problems, but
> don't ask
> > > that it works exactly like IBM's tool.
> > >
> > > If you want something that works exactly like IBM's FTP
> client, feel
> > > free to use IBM's FTP client.
> >
> > Only wanted to point out, that manual FTP from the same
> system didn't
> > cause the same problems, and that IMO FTPAPI might be the suspect
> > here.
> >
> > Hoping you have enough information. Please feel free to ask, if you
> > need any more info. Thanks for your time.
> >
> >
> > 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 email has been scanned by the MessageLabs Email Security System.
> For more information please visit
> http://www.messagelabs.com/email
> ______________________________________________________________________
> --------------------------------------------------------------
> ---------
> 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
-----------------------------------------------------------------------