Re: RPG- IFS Read from PC file translation issue

And pray that the binary data value doesn't happen to contain a CRLF
pattern...

Generally binary data representing a "record" would have a fixed length
and format (no need for CRLF sequence) or each "record" would be preceded
by a length attribute (again no need for a CRLF sequence) or there might
be some escape sequence convention in use. Just scanning for a given bit
pattern can be dangerous in working with binary data.

Bruce Vining




Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
05/24/2007 02:32 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: RPG- IFS Read from PC file translation issue






Hi Steve,

I've another ASCII PC file which I need to read but only some of the
data is text. Some of the data is binary numbers so translating all
of the data doesn't get the job done. This file also has CRLF in the
records

Hmmm... well, it's not really an "ASCII PC file" if part of the data is
binary, is it? :) It's a "Mixed ASCII & Binary PC file". Heh.

For situations like that, I do exactly what you describe. I read the
file in binary mode (so no data is translated). This is done by leaving
the O_TEXTDATA flag off of the open() API. (Leave off O_CCSID,
O_CODEPAGE and O_TEXT_CREAT as well... but O_TEXTDATA is the crucial one.)

I can't say that I really use the readline() procedure in my production
code. I just wrote that as an example in the IFS tutorial, it's been
years since I've even looked at it. But, glancing at it now, it looks
like all you have to do is change x'25' to x'0A' in the routine and
it'll magically work on ASCII data instead of EBCDIC data.

Maybe you want to pass the "end of line" characters as parameters to the
readline() and writeline() routines (like I demonstrated in the socket
tutorial) to make it possible to read "lines" of any type of file.

Then, I'd use the iconv() API to translate the individual fields. Maybe
create a nice re-usable wrapper for iconv() and stick it into the
IFSTEXTR4 service program. The open() API calls iconv() under the
covers, so if you coded your own call to iconv() you could provide the
same support that open() does, but you'd be able to have finer grained
control (such as the ability to translate by field instead of by record).

Sounds like a fun project. Wanna switch jobs? :)