Use o_ccsid instead of ccsid.  Also, consider whether you really want to hard-code 278, or if you'd be better off using o_ccsid=0 (0 means current job's ccsid).

The ccsid= keyword is legacy cruft -- don't use it.  It was for old releases before the IFS supported CCSIDs, so what it does is convert the CCSID to a corresponding code page, and then uses that... this won't work with anything that requires multiple code pages (such as Unicode.)

https://www.ibm.com/docs/api/v1/content/ssw_ibm_i_74/rtref/fopen.htm

On 1/3/2022 12:15 PM, stefan@xxxxxxxxxx wrote:
I need to read thru a bunch of IFS-files in an rpg-program to locate some
items.

Using fopen( %trimr( file ): 'r, ccsid=278' ); seems to work pretty well
until I encounter a file with CCSID=13488.

That one gives me an errno=3490=Conversion error.

If I modify the fopen to fopen( %trimr( file ): 'rb' ); binary mode makes me
get thru the open but then I have to translate all the data by myself.

What is the proper way of dealing with this?


I am expecting to find files in various ccsid's like 819, 37, 819, 278,
13488, 1252 etc.

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