Re: FTP or IFS?

Hi Dave,

If you're building the file yourself with the IFS routines, then it seems to me you must be putting the characters there yourself. They wouldn't be added automatically.

Perhaps a bug?

The only other thing I can think of... maybe you put options(*string) on the prototype for the write() API? (It belongs on many of the other IFS APIs, but not on write()) Though, having said that, if your length is being passed correctly, this still shouldn't cause nulls to appear. So this is probably not what's happening.

Perhaps you're simply getting the length wrong and picking up data from beyond the end of your variable (of which, x'00' would be the most common data to pick up.)

Hard to say without debugging/troubleshooting the code. But I would guess it's a bug in your program.


On 12/10/2010 8:39 AM, daparnin@xxxxxxxxxxxxxx wrote:

I've got a question about carriage-return and linefeed characters in a
stream file. I am building a text file in the IFS using routines from
Scott Klement's IFS e-book. (Thanks Scott!) Ultimately, we want to
schedule a job to build this file and FTP it to a remote site directly
from the AS/400. In testing I've FTPed the file to my PC from the IFS via
a DOS FTP command. I used an ASCII transfer. The recipient wants to
verify the file before we go into production. They don't have us set up
for FTP yet so I uploaded the file to their web site for content
verification. They told me that there were characters at the end of each
"record" that needed to be removed. At first I didn't notice anything but
when I looked at the file but when I opened it with a hex editor I see the
hex characters 00 00 0D 0A at the end of each record which would seem to
be two nulls, a carriage-return, and a linefeed. Is it likely that these
are being inserted when I am building the IFS file or could they be
getting added in the EBCDIC to ASCII translation in the FTP process? The
recipient says that they only want a carriage-return. Thoughts?


Dave Parnin