Re: Line-ending for IFS test stream file

Scott,

The whole process is that we export data from the IBM i using CPYTOIMPF to
a delimited file--i.e., using DTAFMT(*DLM) and RMVBLANK(*TRAILING). Some
of the character fields are all blanks. In the resulting comma separated
file, these all blank fields are rendered as " "--i.e,. Quote,Space,Quote.
The PC process which later uses the data doesn't interpret these as blank
fields. So I wrote a little utility to take out the intervening space
between the two quotes. To do this I scan through the file data, moving it
from an input field to an output field used with the write() API and I
skip the space between two quotes. Everything else, I simply move exactly
as it comes in. When I've scanned the whole file, I call the write API
using my revised data. Then I have to use the ftruncate() API to shorten
the file to its new length.

And no, I'm not simply confused by the way the data looks on the screen.
I've looked at the file using DSPF and then pressing <F10> to display the
data in Hex. Even though it had the x'0D25' in my field used by write(),
the file only has x'0D'.

I did a little deeper debugging and the write() API is retaining the
x'0D0A'. It's after the ftruncate() API, the x'0A' is removed. I'll double
check that API's documentation and get back to you (and the rest of the
list) on what I find.

Thanks,
Michael Quigley
Computer Services
The Way International
www.TheWay.org

P.S. You probably wouldn't enjoy seeing the source--I write it in COBOL
since most other folks in my shop don't know RPG.

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 06/03/2015
12:02:37 PM:

----- Message from Scott Klement <midrange-l@xxxxxxxxxxxxxxxx> on
Wed, 03 Jun 2015 10:16:13 -0500 -----

To:

Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

Subject:

Re: Line-ending for IFS test stream file

Michael,

Can you explain what you're using ftruncate() for? This was the only
part of your message I didn't understand. Just using it to clear the
file (instead of O_TRUNC?)

The open/write/close APIs will not change your CRLF. If you are writing

two characters (both CR and LF) then it may translate this to ASCII or
something, but it won't ever remove one of them. (You may be thinking
of the ANSI C fopen() API with the crln setting? But as that's not
being used here, it can't come into play. The Unix open() API does not
do this.)

My guess is that you are viewing the file in a Unix text editor. For
that reason, you're seeing the carriage return on the screen (since Unix

never expects a carriage return) but you're not seeing the LF because
it's expected and is just treated as a line break. Could that be it?
(That you are just confused by the way it looks on your screen, and both

characters are there?)

Otherwise, please post your code -- I've been using these APIs for
decades (and on Unix systems before that) and have never heard of them
changing CRLF to just CR...

-SK