|
midrange.com
The journal entry layouts you are looking at are being defined similiar to
how one would define a physical file using DDS. A Binary(4) for instance
is a field which can hold from 1 to 4 digits of information and which
occupies two bytes of storage. A Binary(5) holds from 1 to 5 digits and
occupies 4 bytes of storage, Binary(9) 9 digits and 4 bytes of storage.
You can find this described in the DDS manual under Physical/Logical Files
and Length for phsical and logical files (positions 30 through 34).
Languages such as RPG use and enforce these definitions. For instance if
you take a Binary(4) and Z-ADD 99999 you will end up with a value of 9999;
likewise a Binary(5) with Z-ADD 99999999 will get you 99999 (or if you use
EVAL an overflow exception).
So your Binary(4) fields are 2-byte binary values which are expected to
hold a value up to 9999. The Binary(5) definitions represent a 4-byte
binary field expected to hold a value up to 99999. As CCSIDs can go up to
65535 the use of a Binary(5) makes sense. It's unfortunate that this
convention is being used as most developers wanting to access this
information directly from a *PGM (as opposed to indirectly through an
*OUTFILE) would think a Binary(4) is being defined like a system API would
-- namely a 4-byte binary/integer value... At a minimum this should be
clarified in the documentation.
As a CCSID is being supplied on the interface you would be wise to use it
(similiar to how if an offset is provided use the offset and don't
hardcode/assume anything). Especially when working with Integrated File
System path names I would not in the least be surprised to see CCSID 13488
or 1200 (Unicode CCSIDs) being used in some situations. For display
purposes I would probably retrieve the current jobs default CCSID and then
use APIs such as iconv() to convert the specified length from the specied
CCSID to the job default CCSID (note though that substitutions might occur
much like can with WRKLNK -- if your job/terminal is Latin-1 (English for
instance) and the data to convert Greek then you're just not going to be
able to see sigma).
Country/Region ID and Language ID can be of importance in some special
situations. In the Unicode standard the same character can exist in
multiple languages and have different meaning depending upon the language.
By tagging Unicode strings with a Country/Region/Language one can determine
the origin of a particular Unicode code point. You can specify this type
of information on some APIs - for instance the Qlg* Integrated File System
APIs. You do not need this additional information for simple CCSID
conversions.
Bruce Vining
p prasad
<pprasad_hyd@yaho
o.co.in> To
Sent by: midrange-l@xxxxxxxxxxxx
midrange-l-bounce cc
s@xxxxxxxxxxxx
Subject
Re: how to use CCSID info to get
11/08/2005 08:44 corresponding data as normal
AM
Please respond to
Midrange Systems
Technical
Discussion
Maybe I need to give a brief explanation first:
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", 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.
>> I am given with the following information:
>> - Field length, Binary(4)
>>- Field CCSID, Binary(5)
>>- Field Data, char(100)
>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.
>> The above field data is encoded using CCSID given by Field CCSID. How
do
>> I get corresponding data in normal English form? Any pointers to APIs
>> would be greatly appreciated.
>What do you consider to be "normal" English form? What form is the
data
>in now? (Note that CCSID only specifies a character set, not a
language.)
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. 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. 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?
- P.Prasad
> Similarly, I am given with another set of information:
> - Field length, Binary(4)
> - Field CCSID, Binary(5)
> - Field Country or Region ID, char(2)
> - Field Language ID, char(3)
> - Field Data, char(100)
>
> In the above information, Region ID and Language ID are also given,
how
> are these to be used to convert the Field data into a usable form?
Again, you have BINARY(5) which doesn't exist. (It has to be 2, 4 or 8)
Where is the data now? What format is it currently in? Does the
software
that's passing you the above fiedls have a facility for character set
translation, or do you have to do this manually?
If you're talking about info retrieved from an IBM API, please tell us
which API. They're all different, and I'd rather not take a blind guess
at
what youi mean.
> What would happen if I just use the CCSID, length, data portion and
the
> API for the first scenario ignoring the Region ID and Language ID?
CCSID is just a character set. It's a set of letters, numbers and
other
symbols that can be displayed on a screen. It does not tell you which
language the text is in.
---------------------------------
Enjoy this Diwali with Y! India Click here
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
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.
