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



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.