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



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.



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.