Re: Line-ending for IFS test stream file

Well, this was interesting. Paul was very close to the problem. The
problem was a comparison to determine how much data to move when
processing the file was coded incorrectly. This resulted in the call the
ftruncate() chopping off the final byte of the file. I never noticed it
previously because the test data I was looking at just happened to have a
<LF> after the last byte of the file I was processing.

Anyway the final byte being chopped off by the ftruncate eliminated the
last <LF> and left the final record terminated by only <CR>. ftruncate()
changed all the records to match. While this is undocumented behavior, It
should never happen when the correct data is passed to it. I haven't heard
back from IBM, but changing my final comparison logic to match logic used
elsewhere in the program makes it all work. I updated the PMR with IBM and
asked to have it closed.

Chalk it up to not being thorough in the writing of my code and also not
thorough enough in the testing of it.

If anyone wants to see the correct logic I've posted the corrected code
at: http://code.midrange.com/b16539fe4a.html

Thanks for everyone's thoughts--we've got a great community.

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

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 06/04/2015
05:34:17 PM:

----- Message from MichaelQuigley@xxxxxxxxxx on Thu, 4 Jun 2015 16:
06:27 -0400 -----

To:

midrange-l@xxxxxxxxxxxx

Subject:

Re: Line-ending for IFS test stream file

See comments below:

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 06/04/2015
09:18:08 AM:

----- Message from paul.roy@xxxxxxx on Thu, 4 Jun 2015 00:57:56 +0200

-----

To:

"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>

Subject:

Re: Line-ending for IFS test stream file

Could it be that the length passed to the write() api is simply
miscalculated ?

Paul

Thanks Paul but no, the data is written correctly. There are multiple
records and by debugging I can verify that each record is properly
delimited by <CRLF> after the write() API. It's after the ftruncate()

API

that the line ending (record delimiter) characters are changed from

<CRLF>

to <CR>. On a wild hair, I modified the code to add an additional <LF>
between each record and at the end of the file. This leaves me with

<LFLF>

for record delimiters. I've put my program back to its original form and

opened the PMR.

----- Message from Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> on Thu,
04 Jun 2015 08:06:00 -0500 -----

To:

Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

Subject:

Re: Line-ending for IFS test stream file

Hi Michael

I had a suspicion that the ftruncate utility outputs only CRs or LFs -

one of the other - so the documentation might be elsewhere as to this
behavior. The utility is found in Unix and Linux and has been around

for

a long time,. so there is expected behavior. Not sure if it can be
managed with options.

I did run across some hits that suggest that something like this is

the

case. I will be curious to hear IBM's answer.

Cheers
Vern