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

Re:



Sender: Scott Klement <klemscot@xxxxxxxxxxxx>



On Thu, 17 May 2001, Justin Kiteley wrote:
> 
> Hello again!
> 
> I've been working on the FTP_API pack in my spare time at work to improve
> some of our batch transfer applications.  The problem I encountered
> once I had all the syntax correct and calls working smoothly was the data
> conversion. The file that lands on the PC or UNIX machine is not in ascii
> format (all funny characters looks like the ebcdic translation was not
> done).

According to the internet FTP spec, the difference between ASCII mode
and binary mode is that in ASCII mode, each line of text is converted
to use a CR/LF end of line pair by the server, and the client is to 
convert that to it's local end of line conventions.

In binary mode, of course, nothing is to ever be modified.   The whole
idea of binary mode is to ensure that the data is sent verbatim.

I can see why it'd be convienient for ASCII mode (when transferring from
an AS/400 to a PC) to translate from EBCDIC to ASCII...   but how do we
know that we're not transferring to another EBCDIC machine when we do
this?


>  Now I've tried setting Binary mode on and off using ftp_binary with
> no change in what the data looks like.  I have also tried sending the exact
> same
> commands as the 400 client sends (SYST PASV) using ftp_quote, with no
> results.
> Am I missing something that has to
> be done so that conversion from ebcdic to ascii happens?  When I use the 400
> ftp client to connect to my pc which is running an FTP server, and do a put,
> without changing anything I just sign on then make sure the working
> directory is
> right and type "put XXXXX"  the file is transferred and is readable on
> the pc as a text file in columnar format.  Here is what a log looks like of
> first the 400 client, then the FTP_API call in ascii and bin.  Anything that
> is X'd out are
> IP's or user/pass's.

Yeah, there's no code in the FTPAPI to translate files from EBCDIC to
ASCII...  Doesn't matter which options you set, the code will be 
untranslated :)

This is a bit of an oversight on my part.   This, along with the ability
to deal with record-based files and save files, REALLY need to be worked
on... :)

On that note, I need some input from you guys:

    1)  Does anyone know a reliable way of determining if an object in
         the IFS is a record-based file, a save file, or a stream file?
         Keeping in mind that symbolic links could be used to make a
         file in /QOpnSys/ (for example) point to a file in /QSYS.LIB

    2)  Assuming that a file does need to be converted from EBCDIC to
         ASCII, how can I know which codepage of ASCII to use?

    3)  What if I'm talking to another AS/400 (or other EBCDIC machine)?
         Could I safely assume that binary mode would be used in that
         scenario?


If I can get some good ideas on how to handle these things, then I'll try
to find some time to code them.   So please fire ideas at me at full
speed... :)

Thanks for your input!



-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------