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




From: MichaelQuigley@xxxxxxxxxx
To: midrange-l@xxxxxxxxxxxx
Date: 04/06/2015 22:06
Subject: Re: Line-ending for IFS test stream file
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



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

IBM i documentation doesn't indicate that ftruncate does any output to the

file data. Rather it marks the size of the file at whatever length you
specify. It does output x'00' to fill any additional bytes you allocate by

specifying a larger file size than previously existed.

----- Message from paul.roy@xxxxxxx on Thu, 4 Jun 2015 15:17:54 +0200

-----

To:

Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

Subject:

Re: Line-ending for IFS test stream file

I would be very surprised that ftruncate() could have been implemented

to

change the content of a stream file... and removing some EOL
characters... CR or LF are just characters (binary content for the file

system) ...
the operation it normally at the filesystem level, no relation with
lines...

Could you post the (COBOL) code ?

Paul

Yes Paul, I was surprised ftruncate modifies the content of the file. As
said before, I've checked the file using DSPF before and after the
ftruncate() call. By pressing F10, you can see the hex codes. Before
ftruncate, everything looks good with the records delimited by <CRLF>.
Immediately following the ftruncate, the records are delimited by <CR>
without the <LF>. In my understanding, the lines in most Unix files are
delimited by a <LF>. So this is eliminating that. I could almost follow
what's happening if only the <LF> remained, but it's the opposite.

A trimmed down version of the code is posted at:
http://code.midrange.com/9e501564a1.html

I've removed my standard error and message handling routines. If you want
to call the routine, define a command as follows:

CMD PROMPT('Remove Blanks from CSV File')

PARM KWD(STMF) TYPE(*PNAME) LEN(1408) MIN(1) VARY(*YES) +
PROMPT('Stream file')

Then compile the command specifying the program reference above as the
command processing program.