BCD from NT to MF somtimes garbled, sometimes not

[robert]

we successfully code numeric data with java on NT (1.4.1_02) into
COMP-3 format, write that to a file, then attempt to write to
DB2/390/v6.1. viewing the intermediate file using a hex editor, it
looks correct. the target column is VARCHAR FOR BIT DATA.

if we remove the input decimal point (an xml file) from the input
data, some (but not all) occurrences of 90 (hex) end up on DB2 as 3F.
if we leave the decimal point in the input data, we get the correct
data, but a 0 (a nibble, not byte) where the decimal point had been
is in the intermediate file and the subsequent DB2 column.

the data stream is created as a zero filled ByteArray, which is
then overwritten with data.

my recollection is that COMP-3 has no real, only implied, decimal points,
so that 0-as-decimal-point messes things up.

does this sound remotely familiar to anyone?

thanks,
robert

[Mark A]

"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...

we successfully code numeric data with java on NT (1.4.1_02) into
COMP-3 format, write that to a file, then attempt to write to
DB2/390/v6.1. viewing the intermediate file using a hex editor, it
looks correct. the target column is VARCHAR FOR BIT DATA.

if we remove the input decimal point (an xml file) from the input
data, some (but not all) occurrences of 90 (hex) end up on DB2 as 3F.
if we leave the decimal point in the input data, we get the correct
data, but a 0 (a nibble, not byte) where the decimal point had been
is in the intermediate file and the subsequent DB2 column.

the data stream is created as a zero filled ByteArray, which is
then overwritten with data.

my recollection is that COMP-3 has no real, only implied, decimal points,
so that 0-as-decimal-point messes things up.

does this sound remotely familiar to anyone?

thanks,
robert

COMP-3 on mainframe has no decimal point in the data (it's implied as you
put it). I assumed that BCD works the same, but don't know for sure. I don't
know what BCD uses for plus/minus/neutral sign half-byte.

[Mark Yudkin]

"Varchar for bit data" means "do not translate the bit patterns"; it is
typically used - for historical reasons - for binary formats such as (small)
gifs. For the most part, it has been superceded by BLOBs.

Since your client is on NT, your server on /390, and the BCD decimal formats
are different on the two platforms, this will not work. The correct
translation in DB2 is DECIMAL.

"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...

we successfully code numeric data with java on NT (1.4.1_02) into
COMP-3 format, write that to a file, then attempt to write to
DB2/390/v6.1. viewing the intermediate file using a hex editor, it
looks correct. the target column is VARCHAR FOR BIT DATA.

if we remove the input decimal point (an xml file) from the input
data, some (but not all) occurrences of 90 (hex) end up on DB2 as 3F.
if we leave the decimal point in the input data, we get the correct
data, but a 0 (a nibble, not byte) where the decimal point had been
is in the intermediate file and the subsequent DB2 column.

the data stream is created as a zero filled ByteArray, which is
then overwritten with data.

my recollection is that COMP-3 has no real, only implied, decimal points,
so that 0-as-decimal-point messes things up.

does this sound remotely familiar to anyone?

thanks,
robert

[robert]

"Mark Yudkin" <my***********************@nospam.org> wrote in message news:<bo**********@ngspool-d02.news.aol.com>...

"Varchar for bit data" means "do not translate the bit patterns"; it is
typically used - for historical reasons - for binary formats such as (small)
gifs. For the most part, it has been superceded by BLOBs.

Since your client is on NT, your server on /390, and the BCD decimal formats
are different on the two platforms, this will not work. The correct
translation in DB2 is DECIMAL.
thanks. i'll define a column and give it a rip in the morning.

robert

"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...

we successfully code numeric data with java on NT (1.4.1_02) into
COMP-3 format, write that to a file, then attempt to write to
DB2/390/v6.1. viewing the intermediate file using a hex editor, it
looks correct. the target column is VARCHAR FOR BIT DATA.

if we remove the input decimal point (an xml file) from the input
data, some (but not all) occurrences of 90 (hex) end up on DB2 as 3F.
if we leave the decimal point in the input data, we get the correct
data, but a 0 (a nibble, not byte) where the decimal point had been
is in the intermediate file and the subsequent DB2 column.

the data stream is created as a zero filled ByteArray, which is
then overwritten with data.

my recollection is that COMP-3 has no real, only implied, decimal points,
so that 0-as-decimal-point messes things up.

does this sound remotely familiar to anyone?

thanks,
robert

[robert]

"Mark Yudkin" <my***********************@nospam.org> wrote in message news:<bo**********@ngspool-d02.news.aol.com>...

the moral of the story: the devil is in the details. turns out that
another part of the system was string-izing the data, which was then
moved into the byte array. 90, 81, 8D, 9D don't have character
assignments in the standard windows code page; thus getting set to ?/3F
before extraction into the byte array. doh?!

thanks,
robert

"Varchar for bit data" means "do not translate the bit patterns"; it is
typically used - for historical reasons - for binary formats such as (small)
gifs. For the most part, it has been superceded by BLOBs.

Since your client is on NT, your server on /390, and the BCD decimal formats
are different on the two platforms, this will not work. The correct
translation in DB2 is DECIMAL.

"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...

we successfully code numeric data with java on NT (1.4.1_02) into
COMP-3 format, write that to a file, then attempt to write to
DB2/390/v6.1. viewing the intermediate file using a hex editor, it
looks correct. the target column is VARCHAR FOR BIT DATA.

if we remove the input decimal point (an xml file) from the input
data, some (but not all) occurrences of 90 (hex) end up on DB2 as 3F.
if we leave the decimal point in the input data, we get the correct
data, but a 0 (a nibble, not byte) where the decimal point had been
is in the intermediate file and the subsequent DB2 column.

the data stream is created as a zero filled ByteArray, which is
then overwritten with data.

my recollection is that COMP-3 has no real, only implied, decimal points,
so that 0-as-decimal-point messes things up.

does this sound remotely familiar to anyone?

thanks,
robert