|
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.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
