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



Thank you Scott. o_ccsid=0 worked perfectly.

On Mon, Apr 26, 2021 at 12:29 PM Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
wrote:

Hello,

Apologies, I'm not sure that I've "absorbed" everything in this thread.
There are a lot of messages, and most seemed either off-base or really
didn't say anything.

I have used these APIs extensively, and there are a few things I wanted
to explain:

1. Its confusing to refer to the API as 'OpenFile' or 'c_ifs_open'. The
actual name of the function is 'fopen', and it is part of the standard C
library, used on all platforms, and conforming to an ISO standard.
Since this function is used on every computer platform, renaming it to
call it 'OpenFile' is a bad idea. Literally millions of programmers are
familiar with it as 'fopen' why would you want to call it something
else? And 'c_ifs_open' is downright wrong, its actually '_C_IFS_fopen'
(the capitalization and the letter 'f' are required) This is because IBM
i has two variants of fopen, one for record-based files, and one for IFS
files. In C, you always call it as 'fopen', but there's code under the
covers that will map it to _C_IFS_fopen if you compiled your C program
to use IFS files. So keep using the name 'fopen', you'll make things
much easier for other people, and also easier to find documentation,
examples, etc.

2. 1208 is not a valid code page. Although for many of the "simple"
code pages we use in the western world, there's a one-to-one
relationship between the code page and the ccsid, they are not the same
thing. For example, CCSID 819 is the same as code page 819, that is
just because CCSID 819 happens to be a very simple CCSID made of just
one code page. However, 1208 (UTF-8) is not simple it contains over
100,000 characters in a mixed-length encoding. It cannot be represented
as a code page.

3. the fopen() routine on IBM i went through several stages of evolution
over the years. First, they supported code pages only with the
'codepage' keyword. Then, they added the 'ccsid' keyword, but had it
map the ccsid to a code page since the underlying ifs didn't support
code pages at the time. Finally, they added the o_ccsid keyword to
support ccsids properly. Therefore, unless you need to support
positively ancient versions of the OS (and also don't care about
Unicode) you should never use the codepage= or ccsid= keywords. Use
o_ccsid= instead.

4. The o_ccsid keyword (actually, all of these keywords) tells fopen()
the CCSID of *your* *program*, not the file!! This seems to be the
primary mistake you're making. By specifying codepage=1208, you're
telling it that your *program* is 1208. It already knows what the file
is based on the ccsid attribute of the file, you don't have to tell it
that. so the data will be 'garbage' (your word, not mine) in your
program unless your program is written to use 1208 internally.

5. o_ccsid supports a value of 0 which means "my job's ccsid", which is
typically what you want to use, except when you are first creating a file.

So your code should look something like this:

stmf = '/tmp/wc/images/post_out.json';

stm = fopen(stmf: 'r, o_ccsid=0');
if stm = *null;
// check errno to determine error
endif;

Good luck.


On 4/24/2021 5:10 AM, Art Tostaine, Jr. wrote:
Yes thank you. the CCSID has always been 1208. I use codepage=1208 to
open
the file but the data is unreadable.

Ive done a work around to CPYFRMSTMF and I'm reading it as a DBF. I wish
I
could get this to work.


--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


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.