Re: how to use CCSID info to get corresponding data as normal

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

Hello,

> These fields below are actually fields in audit journal entries(in entry 
> specific data portion), just to get an idea of what I am saying, see IBM 
> security reference, Appendix "Layout of journal entries",

That's over 100 pages long!

> table for each entry type. In some of the entry types, information is 
> given about the field length, field CCSID and Field data. I am trying to 
> figure out if I need to do something special if CCSID info is given.

CCSID specifies the character set of the data.  I haven't taken the time 
to read that entire book to see if it explains more than that.  That's a 
big book!

I would assume that if you want to ensure that the data is correct for the 
system you're displaying it on, you should translate it from the given 
CCSID to the computer's default CCSID.

> > There's no such data type as BINARY(5).  Someone is very confused.
>
> What I understood is : BINARY means the value needs to be interpreted as 
> raw data. Like say Binary(4), a sequence of 4 bytes, we interpret as 
> integer, similarly Binary(5) is a sequence of 5 bytes representing a 
> number, in my case, when printed as hex value the CCSID field is 00 00 
> 00 25 00.

I guess what you say makes sense, however, I've never seen a programming 
language that has a 5-byte binary data type.  I program in C, RPG and CL, 
and all of them have binary data types that are 1, 2, 4 or 8 bytes long.

Furthermore, if you look at the offset of the CCSID for a field, and then 
you look at the offset of the field that follows it, they're only 4 bytes 
apart.  Where would it store the 5th byte?  It would overlap the next 
field!

To add to that, a CCSID is a number from 1-65535.  A 4-byte integer can 
store much larger numbers than that!   However, you will note that 65535 
is a 5-digit number (not 5 bytes, but 5 digits).  Like I said, I think 
someone is confused -- namely, the author who wrote that documentation.

I suspect that the field is actually binary(4), since the offsets are 4 
bytes apart, so binary(4) would make the most sense.


> I'm sorry, maybe I got a bit confused here. I will reframe the question: 
> Right now when I see the data using printf, it's printed in plain 
> english(for eg: "CHKUSAGE") even though a separate CCSID is given.

The characters that make up the string "CHKUSAGE" are the same in any 
EBCDIC CCSID, so it wouldn't matter if the CCSID was different (unless, of 
course, it was ASCII or Unicode)

However, if you had a character that isn't the same in the different 
CCSIDs, you'd have problems.  This'll mostly be a problem with certain 
punctuation symbols, such as the @ (at sign), [] (brackets), $ (dollar 
sign), and so on...


> So I can use it easily inside the program, my purpose is solved. But 
> just for the sake of info: the system gives me a sequence of bytes 
> saying these bytes are in CCSID xxxxx. This means these bytes represent 
> whatever they do only in the given CCSID. Now if I transfer these 
> sequence of bytes to another country say from US to UK which uses 
> different CCSID, the same sequence of bytes would represent something 
> else in UK than whatever was in US.

Yes, but that won't happen with the text "CHKUSAGE" because those letters 
happen to be the same in the UK and the US. In fact, the basic capitol 
letters are the same on pretty much every EBCDIC system. It's the more 
obscure punctuation symbols that vary from encoding to encoding.

But, you're right. if you want to make sure that the data displays 
properly in the UK, even though it originally encoded using a CCSID 
intended for the US, you should translate the data to the job's CCSID.

> To get the right information, I will have to convert these sequence of 
> bytes (US) to corresponding sequence of bytes (UK) so that the data 
> would mean the same at both ends. Did I understand this right? If so, is 
> there any API which does this and how do I use it? I have seen 
> iconv_xxx() set of functions. Are these the ones to be used?

Yes, that's exactly what I'd use.

I prefer QtqIconvOpen() to iconv_open() because the former API makes it 
easy to specify the data by CCSID. (Other than that, they work the same).

Then, call the iconv() API to translate the data.

Then call iconv_close() when you're done to free up the memory that 
QtqIconvOpen() used.

I haven't used these for audit journal entries, but I've used them for 
other things and they work nicely.