Re: Writing ASCII data to the IFS in RPG

The ILE C IFS routines (of which, _C_IFS_fputs is one) are designed to allow end of line conversions from Unix (where you only send a LF) to Windows (where you send CRLF) and vice-versa.

Since the C language "grew-up" with Unix, the act of writing a LF when the file needs CRLF is ubiquitous.

In EBCDIC, the hex code for LF is x'25'. So every time you write a x'25' it adds a carriage return in front of it (i.e. it adds a x'0d' before it.) That sure sounds like the problem you're experiencing.

If I may be frank with you, Jerry -- if your goal is to write ASCII data from a socket directly to the IFS, this is the wrong way to go about it. Why are you using the ILE C routines instead of the system (Unix-type) IFS APIs?

If you do want to use the C routines instead of the system ones for some reason, I recommend that you do the following:

a) Mark the file as CCSID 1252 (or 819 or whatever you're using) when you create it.
b) Open the file in binary mode (using the 'b' flag) when you open it.
c) Write the data using the binary API fwrite() instead of the text API fputs().

But, I think it's silly to use the C APIs unless you have a good reason. When writing data, I can't think of any value using using these APIs over the standard ones. (When reading data it'll let you read text line by line, but that's not really an issue when writing data..)


GKern@xxxxxxxxxxxxxxxx wrote:

I have a socket server program that accepts ascii data from a client.

After receiving a complete, varying length string, I write it out to the IFS using a prototyped call to the '_C_IFS_fputs' API.
Everything works fine except that if within my string, a percent sign (%) exists (ascii hex 25), when written to the IFS a carriage return (hex 0D) is added preceding the percent sign. I have two percent signs in the string and both are preceded by the carriage return. (This is causing data to be prematurely terminated by applications that read from the IFS.)

I've reviewed the source data with a hex editor to ensure that the carriage return isn't in the source data (and tested this on more than one input file). There are no carriage returns except for those that are where they are supposed to be. I've even reviewed the data in the wdsci debugger using the memory monitor and rendering to ensure the value to be written to the ifs doesn't contain the rouge carriage return (and it doesn't).

At the moment my source data (testing only) is coming from my pc. That implies code page 1252. My IFS folders show ccsid 437 (pc ascii) but the files themselves default to ccsid 37 (unless after the write I do a chgatr to change it to 437 or 819 - and I've tried both).

I suspect that my RPG program being in EBCDIC (ccsid system value is 37) is somehow causing this behavior. Or is it the API doing the write to the IFS?

If so how do I write the data with the proper ccsid or do I need to 'translate' the data somehow before writing it to the IFS?

Or is there something else that might be suspect?

Any ideas greatly appreciated.