Re: ASCII/EBCDIC translate oddities

["Justin Kiteley" <justin@xxxxxxxxxx>]

Sender: "Justin Kiteley" <justin@xxxxxxxxxx>

  When I use the FTP client on the 400 I am just using the default mode,
whatever that is. (ASCII?)
  When I choose ftp_binary(*off) in the FTP_API program, I don't think it is
setting the flag properly.  I still get EBCDIC data on the PC.  This is the
log that generates on the pc, when I use FTP_API.

5/17/01 12:03:56 PM - Requested FTP connection from xxx.xxx.xx.xxx ID=6
5/17/01 12:03:57 PM - (     6) 220 ArGoSoft FTP Server Plus, Version 1.2
(1.2.0.9) [UNREGISTERED]
5/17/01 12:03:58 PM - (     6) USER xxx
5/17/01 12:03:58 PM - (     6) 331 User name OK, need password
5/17/01 12:04:00 PM - (     6) PASS xxxx
5/17/01 12:04:00 PM - (     6) 230 User xxx logged in successfully **
5/17/01 12:04:03 PM - (     6) TYPE A
5/17/01 12:04:03 PM - (     6) 200 Type set to ASCII
5/17/01 12:04:04 PM - (     6) PORT xxx,xxx,xx,xxx,21,93
5/17/01 12:04:04 PM - (     6) 200 Port command successful
5/17/01 12:04:06 PM - (     6) STOR NV12010002
5/17/01 12:04:06 PM - (     6) 150 Opening ASCII data connection
5/17/01 12:04:12 PM - (     6) 226 Transfer complete
5/17/01 12:04:14 PM - (     6) QUIT
5/17/01 12:04:14 PM - (     6) 221 Aba he
5/17/01 12:04:16 PM - FTP connection with xxx.xxx.xx.xxx ended. ID=6

One of the differences I see in the 400 log and in the PC log when I use
FTP_API is that there is no total at the end for file size, transfer speed,
transfer time.  Do you get this as well when using the API calls?  I'm
stumped at this point.  I feel I'm missing something small thats screwing it
all up.  Right now I'm going through the code in FTPAPIR4.  I see in the
comments at top that there is no implementation to send/recv files from
/qsys.lib.  I just take the file and lib and build the path for the local
file to be transferred via FTP.  I guess that could be implemented in the
API set.

  Reading the code in FTPAPIR4 I found the get_byline, which converts from
ASCII to EBCDIC, but did not find a put_byline, just a put_block.  Perhaps
there is no translation occuring at all for put's, as I don't see the Binary
flag being used at all and there is no put_byline.

  Oh well, enough of my rambling!

Justin


----- Original Message -----
From: "Buck Calabro" <Buck.Calabro@xxxxxxxxxxxx>
To: <ftpapi@xxxxxxxxxxxxx>
Sent: Thursday, May 17, 2001 10:37 AM
Subject: RE: ASCII/EBCDIC translate oddities


> Sender: Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>
>
> >Command line FTP in Binary works with all the files I transfer to UNIX or
> >PC.  It translates character data and the result is not scrambled at all.
>
> I'm a bit confused (not for the first time!)  Binary does NOT translate at
> all - that's the point: Binary means "send the bits exactly as they are
> because it's binary data, not text."
>
> >I've done the test you've referred to many times and what works with
basic
> >FTP command line ( no commands executed before put) does not work with
> >FTP_API using ASCII mode.
>
> Hrm.
>
> >The file I'm working with is just a flat file
> >with a 72 long alpha field.  The file name, member and field name is
> >IR03270450, would that cause any problems?
>
> Nothing odd there.
>
> I just did a test.  If I callp ftp_binary(*on) and transfer a file from
DB2
> (/QSYS.LIB/BUCK.LIB/TEXT.FILE/TEXT.MBR) to the IFS (/QOpenSys/ftp.txt) The
> code page is marked as 819, but the data is in fact EBCDIC as verified
with
> a hex viewer and DSPPFM F10, F11.
>


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