Scott,
I think your next book should be about code pages and CCSIDs! These little
tidbits are priceless, but even more so would be a book describing the "big
picture" with relative examples (like your conversation below).
And maybe you could include something about data queues <tic> (inside
joke).
Thanks for taking the time to type all of that out,
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Scott Klement
Sent: Friday, October 05, 2007 2:05 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Question about writing to IFS (Using Scott Klement's IFS
EbookExamples)
Hi Jack,
There's a weird quirk to O_TEXTDATA. Basically, if a file DOES NOT
exist, O_TEXTDATA assumes that you're trying to create a file from the data
that's in your program. Therefore,the code page you've provided is the code
page of your program's data, and no translation is needed.
For example, if you create a new IFS file and mark it with CCSID 37, it
thinks you're doing this BECAUSE your data is already in CCSID 37. So no
conversion is done, the data from your program is simply written to disk,
and the file is marked with "37" so that subsequent programs know that it's
supposed to be EBCDIC.
Likewise, if you tell it to create a new file and mark it with CCSID 819, it
assumes (and this is the problem) that the data coming from your program is
ALREADY in CCSID 819 (Apparently, the person at IBM who designed it was
thinking that when a new file is created, you're always
looking to mark it with the CCSID of the data in your program.) No
translation is performed, and the file is marked with 819.
That's why you're getting "garbage" when you mark it as 819. The data in
your program is EBCDIC (which might be 37, or might be some other form of
EBCDIC, depending on the country you work in). But you've marked the file
as 819, which tells the system that it's ASCII. So when you view it, it
looks up the hex value of each byte on an ASCII to EBCDIC translation table,
and shows you the translated result. (Since the original result was already
EBCDIC, you end up with garbage.)
Now... everything I've said up to this point refers to what happens when
you create a NEW file. On the other hand, if the file ALREADY EXISTS,
it assumes that your data is in the job's CCSID, not in the file's CCSID.
In that case, it translates from the job's CCSID to the file's, and
vice-versa. (Which is what you want).
For this reason, on pre-V5R2 systems, we typically follow this syntax to
create a new file and automatically translate to ASCII:
a) Use the unlink() API to delete an existing file if it exists.
b) Use the open() API with O_WRONLY + O_CREAT + O_CCSID (or O_CODEPAGE if
you're on V4R5 or earlier). Give it an ASCII CCSID (819, 1252,
whatever..)
c) Call the close() API to close the file from step b. Now you know you
have an EXISTING file, and you know that it's marked with an ASCII CCSID.
d) Call the open() API a second time. This time, specify O_WRONLY (or
whatever you need) + O_TEXTDATA + O_CCSID. Put a 0 in the "mode"
parameter (permissions) since the file isn't going to be created, it'll be
ignored. Put the CCSID you want to translate *from* (i.e. the job's
CCSID) in the CCSID parameter. You can use a special value of 0 to
indicate "the job's current CCSID". You can also leave the O_CCSID and
the CCSID parameter off of the command, but this'll only work if the IFS
file is a single-byte encoding (it won't work with double-byte or Unicode
unless you give O_CCSID and the CCSID parm. I never found out why this
was.)
e) At this point, the file is both marked with the correct CCSID, and
anything written will be translated to that CCSID. This way, both EDTF and
Windows software will be able to read it correctly.
Starting with V5R2, there's an additional flag named O_TEXT_CREAT and an
additional parameter that lets you do the whole thing in one call to the
open() API. To use that technique, do this:
a) Call unlink() to get rid of an existing file.
b) Call open() with O_CREAT+O_WRONLY+O_TEXTDATA+O_CCSID+O_TEXT_CREAT
c) Specify the CCSID to make the file in the 4th parmeter, and the CCSID of
your program's data (or the special value 0 for the job's current
CCSID) in the 5th parameter.
Note that O_CCSID became available for IFS objects in V5R1. Prior to that,
you had to use O_CODEPAGE, which is similar, but only supports single-byte
encodings. O_CODEPAGE does still work in newer releases, but unless you
absolutely need to support V4R5 and earlier, I recommend that you use
O_CCSID to get the additional flexibility that CCSIDs provide.
Jack Tucky wrote:
If I write file as codepage 37, I can view it using EDTF.
But downloading the files to the PC I see garbage.
I want to FTP the file to some other system as ASCII.
If I add the 819 code page, EDTF shows gibberish and PC download.
I think I need the translation set properly, but maybe I have it
wrong? . I open the file and then close it, and then open it again to
begin writing to it.
Here is my code snippet:
c eval flags = O_WRONLY + O_CREAT + O_TRUNC +
c + O_Codepage + o_TextData
**
c eval mode = S_IRUSR + S_IWUSR
c + S_IRGRP
c + S_IROTH
**
c eval fd = open(%trim(IfsFileName) :
c flags: mode : 819 )
c if fd < 0
c eval Msg = 'open(): failed for writing'
c dsply Msg
c eval *inlr = *on
c return
c endif
Thanks
Jack
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
