For Programmers: Free Programming Magazines  


Home > Archive > Cobol > August 2006 > Re: db2(us37) data corruption with cobol coprocessor and codepage(1140)









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: db2(us37) data corruption with cobol coprocessor and codepage(1140)
William M. Klein

2006-08-17, 6:55 pm

FYI,
From the IBM-MAIN list

--
Bill Klein
wmklein <at> ix.netcom.com
<itsystem@bper.dpn.ch> wrote in message
news:1155815072.076272.182610@74g2000cwt.googlegroups.com...
IBM SHOULD PUBLISH A RED ALERT CONCERNING THIS FAQ !

Packed decimal 9F is converted to 3F using COBOL with a DB2 Database.
Technote (FAQ)

Problem
Using host variables, MY-DATA is inserted or retrieved from a DB2
table.
02 MY-DATA PICTURE XX.
02 MY-NUMBER REDEFINES MY-DATA PICTURE 9(3) COMP-3.
EXEC SQL SELECT ... INTO :MY-DATA END-EXEC.
If MY-NUMBER is hex 125F or 334F or 100F then it works. Those number
come and go to DB2 as is. If MY-NUMBER is hex 129F or 999F, then it is
converted to 123F or 993F as it comes or goes to DB2. Why is the hex 9F
special?

Cause
The hex 9F is the Euro symbol ?. The default compiler option is
CODEPAGE(1140). The typical code page of a DB2 database is 037. This is
the only difference between code page 1140 and 037. Therefore
translation will happen with character data. Why a 3F? Because hex 3F
is the substitution character. Also known as SUB; this 3F is used
whenever there is a byte that can't be translated from one codepage to
another.

Solution
Use the compile option CODEPAGE(037). That assumes your DB2 database
was generated with 037. The CODEPAGE compiler option must match your
DB2 database option.



Historical Number
PMR_82971_379


Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com