Re: Line-ending for IFS test stream file

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

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.