Re: Line-ending for IFS test stream file

Vern,

I don't think that page is saying the ftruncate() will change CRLF to CR. That page is part of a tutorial on assembly language programming in FreeBSD, and the sample application it's using for the tutorial is one that's designed to change end-of-line sequences.

While it's true that this sample program (tuc) uses ftruncate(), it's not ftruncate() that changes the EOL sequence, it's the code in the sample 'tuc' program.

-SK


On 6/4/2015 11:28 AM, Vernon Hamberg wrote:

The hit I read very briefly is for FreeBSD, I believe - here it is -
https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86-files.html


It speaks of dropping everything it finds and inserting only an LF - not
sure if this is exactly what ftruncate does, but it IS intriguing.

Vern

On 6/4/2015 8:17 AM, paul.roy@xxxxxxx wrote:

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




From: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 04/06/2015 15:06
Subject: Re: Line-ending for IFS test stream file
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



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

On 6/4/2015 6:44 AM, MichaelQuigley@xxxxxxxxxx wrote:

I'm opening a PMR as the documentation on the ftruncate() doesn't say
anything about line-ending characters being modified. I don't believe

it's

"working as designed." In the meantime, I'll do a work around--either
Buck's suggestion or I have one other thing to try first. I'll post back
to the list with whatever works (or doesn't).

I can empathize with your prejudice against the APIs. They can be very
obscure and the documentation takes a while to get used to. But I've had
such good success with them over the years building a lot of great
utilities and handling various processes.

Thanks for all the suggestions and advice,
Michael Quigley
Computer Services
The Way International
www.TheWay.org

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 06/03/2015
05:30:20 PM:

----- Message from John Yeung <gallium.arsenide@xxxxxxxxx> on Wed, 3
Jun 2015 17:15:00 -0400 -----

To:

Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>

Subject:

Re: Line-ending for IFS test stream file

On Wed, Jun 3, 2015 at 4:41 PM, <MichaelQuigley@xxxxxxxxxx> wrote:

No, the LF characters are missing (removed) at the end of every line.

So

if there's 15 lines of data, the file is shortened an extra 15 bytes

and

all the <CRLF> end-of-record delimiters are now simply <CR>. Strange,

eh?

Yeah, that's strange.

It does reinforce my prejudice against using IBM system APIs for
stream file processing. I think my biggest blind spot in this area is
that I keep forgetting about Qshell and PASE. Unix-based tools were
designed specifically for this kind of stuff, and Buck points out a
really good example of this.

(I was a very happy Unix user and fan in college. I think I never took
Qshell seriously because (1) I was underexposed to it, and (2) there
were enough niggling differences between it and the Unix shells I was
used to that I never fully embraced it. And, if I'm being honest with
myself, I never really mastered Unix one-liners even in genuine Unix
environments.)

John Y.