× 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.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.