× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.