RE: IFS Output problem

Hi Jeff,
 
<snip>
This is the RPG code I am using to create / open the file.
D Code_Page S 10U 0 Inz(819)
 
// Create file with correct code page, in text mode
Open_Flag = O_CREAT + O_WRONLY + O_CODEPAGE;
Mode_Flag = S_IWUSR + S_IRUSR + S_IRGRP + S_IROTH;
fd=open(%TrimR(IFS_File_Name) :Open_Flag : Mode_Flag : Code_Page);
// Close file
RC=close(fd);
// File Created - Open for text output
Open_Flag = (O_WRONLY + O_TEXTDATA);
fd=open(%TrimR(IFS_File_Name) : Open_Flag);
>From what I understand, the initial open should have created the file 
>with
code page 819.
If not, what am I doing wrong, and why do I have the garbage imbedded in my
data?
</snip>
 
If you are going to manipulate stream files on the IFS I would suggest a
couple of general pointers:
 
1) Don't use the O_CODEPAGE flag, use O_CCSID instead (this has a constant
value of 32). Get into this habit right at the beginning or you'll come
unstuck when you start using XML in UTF-8 format. This is because UTF-8 has
a CCSID of 1208 but has no codepage. As it is a variable-byte UNICODE
encoding it covers ALL codepages. Setting O_CODEPAGE for UTF-8 is useless
and wont work. These flags merely state that the value you place in the
fourth parameter is a CODEPAGE  or CCSID. For EBCDIC 037 the value is the
same - 37! For other encoding it isn't always that simple. My advice - stick
to O_CCSID.
 
2) The idea behind the "open, close, re-open" technique is to allow you to
create the empty file with an associated CCSID - this is the "file CCSID".
(This is the CCSID of the file - it is completely independent of the CCSID
of the data within the file - you can have a file with one CCSID which
contains data with a different CCSID.) You then close the file, and re-open
it with the O_TEXTDATA and the CCSID of the text data you are going to put
into it - this is the "open CCSID". This extremely simple and powerful
technique tells the system to automatically translate the text data from the
CCSID of the data sitting in your program to the CCSID of the file.
 
When using EBCDIC -to- ASCII you can probably get away with only specifying
the first two parms on the re-open, but I'd strongly advise against it. It's
a bad habit - you should avoid it.
 
You're re-open should look like this:
 
fd=open(%TrimR(IFS_File_Name) :Open_Flag : Mode_Flag : 0);
 
This tells the system that you're data is in the current job CCSID (a CCSID
of zero defaults to the job CCSID). This makes life simple - whatever system
the program runs in it will always successfully translate the data to the
file CCSID. you could specify ANY valid CCSID here - it all depens upon the
CCSID of the data you have. 
 
If your data is in a program variable or on a pointer in the job CCSID then
you can create your own flag O_JOBCCSID with a constant value of zero. and
use:
 
fd=open(%TrimR(IFS_File_Name) :Open_Flag : Mode_Flag : O_JOBCCSID);
 
Finally, if you're data is garbage - keep things simple. Look at the data in
the iSeries BEFORE you consider looking at it on your PC. If it's garbage
when you look via WRKLNK then it really is garbage! Nothing to do with your
PC, Notepad, or anything else. When you look at the data via WRKLNK (EDTF)
check to see if you get a message at the bottom of the screen telling you
the data is in the wrong CCSID. If you create an ASCII file and put EBCDIC
037 data in it then during display using EDTF iSeries will probably realise,
translate it for you, but let you know it's wrong. When you drag that over
to your PC and open it you don't get the same treatment. :-)
 
HTH
 
Larry Ducie