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



Steve,

You need to use the non-text file approach for binary data. Removing
O_TEXTDATA will keep your data from being automatically translated. Hex
characters 0D25 are the EBCDIC values for Cr/Lf. Create a file on you PC
with a Cr/Lf in it (open Notepad, press ENTER and save the file) and
write a small program to read it in binary mode and you'll see what
these characters are.

Once you read the record, you'll need to use iconv() to convert the text
part to EBCDIC.

Matt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Steve Moland
Sent: Thursday, May 24, 2007 3:13 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RPG- IFS Read from PC file translation issue

I've been using Scott Klement's excellent tutorial "Working with the
IFS in
RPG IV"
http://www.scottklement.com/rpg/ifs_ebook/
and after some diversionary problems with AS400/PC Links of my own
making
(which Scott so kindly helped me solve) I've been able to handle a data
import issue with what is remarkable simple code on MY part. Thank you
again, Scott.

It's certainly clear that Scott put an enormous amount of time into not
only
the tutorial but also the example code so that my work was easy.

I'm asking this question publicly because I think the issue would be
rather
generic.

The process I use:
* Reads PC file ASCII records which have CRLF in them
* The code shown below reads the records and they arrive translates into

EBCDIC which is perfect for one of my needs because all the data is text

data even the numbers which I can coerce into numeric fields in the RPG
code. The variable "line" contains the whole contents of the record
which I
parse out.

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

I copied the code from the first program and then tried to modify the
"Open"
so that it would not translate to EBCDIC using various manifestation of
O_CODEPAGE. Some would not compile, some would compile but failed during
the
open.

My logic was to read the data as ASCII and translate the Text portions
in
the RPG and leave the binary numbers alone since they would touchier to
translate back and forth.

I also didn't want to loose the nice IFS feature that it would take care
of
sensing the CRLF and present me with a record buffer.

Though I haven't tried Scott's other examples of reading a non-text
stream
file which (as I interpret the tutorial) would present the data in ASCII
but
require me to figure out and find the records myself.

So two questions
1) Must I use a non text file approach.
2) Does anyone have some sample code for using Scott's "readline"
function
which parses out data into records when the O_CODEPAGE is not used

Steve Moland

=============== snippet of the code
fd = open(%trim(filename):
O_RDONLY+O_TEXTDATA)
if fd < 0
callp die('open(): ' + %str(strerror(errno)))
endif

dow readline(fd: %addr(line): %size(line))>=0
eval pchr = *zeros
eval chr = line
******* chr being a structure with various sub fields




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.