Hi Paul,
Thanks. I assume you've probably seen my previous post about fixing the
problem.
I discovered the same thing you did when I tried different test data. With
my previous test data, I could put the program in debug and stop
immediately after the write. The data looked fine because the old data in
the file originally had a <LF> immediately after the last character I
wrote--so everything looked fine. I had the thought and tried some
radically different test data--plain text with no commas or quotes. With
this test data, nothing should have changed. Then I found the file length
to be written was one byte shorter than the original size of the file.
(This is the same value used by the ftruncate API.) So I was indeed
chopping off the final character which was a <LF>. Then the ftruncate is
evidently modifying all the line endings to match the final "record". Not
documented behavior, but it's only happening when ftruncate is passed the
wrong length value.
I did a more thorough examination of the code. The comparison at line 335
wasn't matching the comparison at line 329. When I changed line 335 to
match, everything works as expected.
My learning? Try a bunch of different test data--especially when you've
got something that simply overwrites the previous data as the write() API
does.
Regarding your comment about DSPF not adapting to a file with mixed EOL,
you're saying a dump shows the <CRLF> values are still there on lines
previous to the end, but DSPF is simply shows the same for all lines? If I
debug RMVCSVBC2 and stop the run after the write(), DSPF (hex view) shows
all lines ending in <CRLF> except the last one. Then all the line ends
change after the ftruncate API.
Thanks again,
Michael Quigley
Computer Services
The Way International
www.TheWay.org
"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 06/04/2015
07:25:51 PM:
----- Message from paul.roy@xxxxxxx on Fri, 5 Jun 2015 01:25:36 +0200
-----
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject:
Re: Line-ending for IFS test stream file
Hi,
I did compile and run your code (but not dig into it)
My interpretation :
the ftruncate is not the reason.
All lines keep their EOL as CRLF but the last one... (the last
character
of the last line is dropped..)
If you use DMP to check your stream file, you will see that the CRLF are
still there ...
So DSPF cannot adapt to a file with mixed EOL. (I did not check the
documentation : is this a bug ? )
Paul
As an Amazon Associate we earn from qualifying purchases.