RE: How to handle Graphic database fields

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."