Re: Line-ending for IFS test stream file

[Jon Paris <jon.paris@xxxxxxxxxxxxxx>]

Very weird - if I think of anything else I’ll holler.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jun 3, 2015, at 2:10 PM, MichaelQuigley@xxxxxxxxxx wrote:

> Jon,
>
> The file is 1252 (*PCASCII) and the IBM i job runs with 37. The file 
> starts out with X'0D0A' <CR> and <LF> at the end of each record. I don't 
> actually see the characters during debug when processing the file, but the 
> offset into data at various positions in the file includes two line ending 
> characters between data lines. It's when I write the file back these two 
> characters are simply changed to x'0D' <CR>.
>
> I guess I could watch for x'0D'--EBCDIC <CR> and x'25'--EBCDIC <LF>.  I 
> agree that I would have to code the appropriate hex values if I were 
> originating all the content, but I'm only reading a file which already 
> contains them. My understanding was the *PCASCII (code page 1252) x'0D0A' 
> would automatically translate to what I've assumed are EBCDIC (code page 
> 37) x'0D25'. Then when writing the file back, they should automatically 
> translate back to *PCASCII x'0D0A'.
>
> I could check the characters as the data lines are processed--they should 
> be x'0D25' and then make sure these are still there before rewriting the 
> data. But since I'm not touching these (i.e., simply moving them from the 
> input variable to the variable I use to write the data back), I'm not sure 
> how to make sure they aren't changed when I call the write API.
>
> Any additional thoughts would be appreciated.
>
> Thanks,
> Michael Quigley
> Computer Services
> The Way International
> www.TheWay.org
>
> "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 06/03/2015 
> 12:02:37 PM:
> > ----- Message from Jon Paris <jon.paris@xxxxxxxxxxxxxx> on Wed, 3 
> > Jun 2015 10:57:37 -0400 -----
> >
> > To:
> >
> > Midrange-L Midrange-l <midrange-l@xxxxxxxxxxxx>
> >
> > Subject:
> >
> > Re: Line-ending for IFS test stream file
> >
> > I thought that if you were using  o_TextData you had to code “your” 
> > CRLF as being the appropriate hex values that will result in CRLF 
> > post conversion.  What values are you using and what is the target code 
> page?
> > Jon Paris
> >
> > www.partner400.com
> > www.SystemiDeveloper.com
> >
> > On Jun 2, 2015, at 10:11 PM, MichaelQuigley@xxxxxxxxxx wrote:
> >
> > > Hi folks,
> > >
> > > I've got a program which opens, reads, scans the data modifying some 
> of 
> > > the content, then writes and truncates a file in the IFS. It uses the 
> > > open, write, ftruncate, and close APIs. The open uses the o_TextData 
> flag 
> > > so the CCSIDs are automatically converted for my program to manipulate 
> the 
> > > data on the IBM i. Everything works great with the exception that the 
> line 
> > > ending carriage-return and line feed (CRLF) is being changed. When I 
> debug 
> > > the program and step through file scanning, the CRLF is being 
> processed 
> > > correctly--i.e., I see the two bytes processed at the end of each 
> line. 
> > > But when the file is re-written and closed, the CRLF is modified to 
> simply 
> > > be a carriage-return.
> > >
> > > This isn't a problem most of the time, but there are cases where the 
> PC 
> > > program which later uses the processed data isn't recognizing the last 
>
> > > line of data since it doesn't end with CRLF. Is there an option I've 
> > > overlooked or something I can do to preserve the CRLF?
> > >
> > > Thanks,
> > > Michael Quigley
> > > Computer Services
> > > The Way International
> > > www.TheWay.org
>
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.