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



Okay, I'm about to lose my mind here.

I've done all the research I can to address the issue.  The business
problem is to take a small hunk of EBCDIC DBCS data and write it to a
file in Shift-JIS encoding, along with normal ASCII information.  The
second part is the killer, as you'll soon see.


Okay, I tried the simplest way - just opening a file using the IFS APIs
(_C_IFS_fopen) with a CCSID of 943.  No go.  I keep getting conversion
errors on the file open.  Maybe because I'm a single-byte machine?  I
cannot create files of CCSID 5026 or 943 using the fopen API.

Okay, that means I'll have to do the conversion myself.  After a little
clonking around, I came up with some rather nice wrapper routines for
the iconv family of APIs.  I can now convert anything to anything in RPG
with no problems.

So, that's the HARD part, right?  The easy part should be writing this
raw data to the file, right?  Well, I'm missing something, because it
ain't easy.

If I open the file with an ASCII codepage, all of the routines (this
includes fputs, fputc and fwrite) convert the bytes from EBCDIC to
ASCII.  Since I've already converted to ASCII, this results in a double
conversion and unusable output.  So I have to somehow stop the
conversion.

I tried opening a file with CCSID 65535, and while I can create it, I
can't then reopen it for write.  I get a null pointer from fopen,
although there is no error when I check the strerror function (the error
code is zero, and the text you get back says "There is no error."  How
helpful...

So, my last resort was to use EBCDIC, with the idea that I would later
change the CCSID using the CHGATR.  IT WORKED!  Except for one little
problem:

In ASCII, the percent sign (%) is x'25'.  In EBCDIC, x'25' is LF
(linefeed).  All of the Unix-like routines have this neat little quirk -
when they notice a LF, they magically prepend a CR (carriage return).
So now, wherever there is a percent sign in my output, I see a newline.

What should be:

<HTML>
<% bean.method(); %>

Is instead:

<HTML>
<
% bean.method(); 
%>

I tried every IFS write technique I could think of.  I used fputs,
fputc, fwrite and putc, and all of them acted the same way.  The only
thing I can figure is that I somehow have to set the CCSID of my job to
an ASCII value and open the file with an ASCII code.  But I can't for
the life of me figure out how to do that.

As you can see, I'm tracking this down at midnight on Sunday night.  Any
help would be most appreciated.

Joe


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.