RE: How to handle Graphic database fields

Dave,

Graphic and UCS2 are not necessarily the same. A graphic field indicates that textual data is being stored in 16-bit code points where a given character may need one or more of these 16-bit code points. A UCS2 field is specifically a graphic field with a CCSID of 13488. There are many other CCSIDs that could be associated with a graphic field. These would not be UCS2.

You are correct in your scenario. If you define a UCS2 field within your RPGLE application and initialize it to the correct value, then you can search with that value and get back the expected results. If you are updating other EBCDIC (CCSID 37 for example) encoded files based on data found in the graphic file you will need to make sure and also convert the data to EBCDIC prior to updating/writing to the related files. Again RPGLE makes this fairly easy, especially if you're on V5R3 or V5R4 where PTFs are available for implicit conversions between UCS2 and your job CCSID.

IF (and I capitalize the IF) you are working strictly with English/Latin 1 based information (no Russian, Chinese, Japanese, Arabic, etc and assuming you run in a Latin 1 CCSID such as 37) you can also take the "lazy" way out. Simply create a logical file over the UCS2 encoded physical file and have the logical file map the 'G' fields to 'A' fields. DB2 will then convert the UCS2 data automatically to the EBCDIC CCSID your job is running in when reading records and reverse the conversion when writing or updating records. This approach can work if you're in a hurry and know that you will only be working with textual data that can be represented in a given EBCDIC CCSID.

Hope this helps,
Bruce Vining

Dave Murvin <Dave.Murvin@xxxxxxxxxxxxxxxxx> wrote:
This first application will involve reading order header and order
detail files for specific types of customer orders, then making changes
to other bulk customer orders for the customer based on some logic on
order type, order date, customer ship to address, order quantities, etc.
The data files in question are for the Lawson M3 system which is written
in Java. At a quick glance, it looks like all the fields in the files
are either packed or Graphic (instead of Character). A small sample of
one of the record layouts is:



Field Field Dec Position

Name Len Typ Pos From To Text

OACONO 3 P 0 1 2 Company

OADIVI 6 G 3 8 Division

OAORNO 20 G 9 28 Customer order number

OAORTP 6 G 29 34 Customer order type

OAFACI 6 G 35 40 Facility

OAWHLO 6 G 41 46 Warehouse

OAORST 4 G 47 50 Highest status - customer order



Maybe if I am just using the graphics fields in the records (and like
defines) I should not have to worry? As an example, I will be looking
for a particular order type, so if I define the search order type as a
Graphic (or USC2) and initialize it to the value I am looking for, then
I should be able to search on my defined order type and find what I am
looking for. Correct?



Also the DSPFFD lists the fields as GRAPHIC, not UCS2. Can I consider
them the same thing?



Thanks



Dave



On September 07, 2007 Bruce wrote:



"What is it that you want to do with the data and what type of data is
being stored? That is, is the data really all English but happens to be
stored as UCS2, or is the data multilingual in nature (your example
record is entirely Latin/English in nature). This will help answer how
you might go about working with the data.



RPGLE itself has very good support for UCS2 data. The internal
datatype C identifies data as UCS2, there are implicit conversions
between EBCDIC and UCS2 supported, there are explicit conversions with
builtins, etc."