Re: JT400 Record-level access problem

Reminder to self... Do *not* read\reply overnight, while preparing to or actually falling asleep!

For some reason I totally missed the "defined as eight characters, CCSID 37", having read\processed only the "8-byte unsigned integer".

I suppose a likely problem origin is for use of CCSID 37 instead of FOR BIT DATA; the collation [Sort Sequence] would be moot for the kind of issue I am thinking of.

Using CHAR as INTEGER requires use of [actual or effective] BINARY to ensure no unintended character conversions. There could be some effective translation between the ASCII and EBCDIC encodings, even if just for the space\blank character. The JAVA interface likely identifies itself to the database open as an ASCII interface. So even if not wild results for full conversion of the key, very possibly any integer 'string' ending with any 0x20 character(s) may be comparing equal with EBCDIC character string ending in 0x40 character(s).... or something silly like that. I had diagnosed past issues for which unpredictable results were the problem, for a user of a keyed access method, with key values generated by concatenating integer data as though it were either null-terminated-string or fixed-length character string.

Regards, Chuck

On 19 Oct 2012 09:50, Dan Kimmel wrote:

To the database, the key is a character field. But it holds data
that may be outside the usual character set. While the collating
sequence is set for *HEX, I wonder if some characters might be
considered equal by the API using the collating sequence.

Positioning the cursor and reading with ReadNextEqual doesn't appear
to be a problem. The reads always start in the right place. Part of
the reason may be that the key is ever increasing, never goes back.
With the 8-byte integer, it won't start over for a couple hundred
years. It's a good suggestion, though. I'll test, but I think I'll
get the same results.

CRPence on Friday, October 19, 2012 2:22 AM wrote:

<<SNIP>>

As for the use of unsigned, AFaIK the database has no support for
unsigned numeric; not integer nor decimal types. A "large"
unsigned provided as an input key could presumably select a
negative value if the type mismatch was not diagnosed.?

Regards, Chuck

On 18 Oct 2012 18:17, Dan Kimmel wrote:

<<SNIP>> The key is defined as eight characters long, CCSID 37,
collating sequence *HEX. The value is an ever incrementing
8-byte unsigned integer. Are there values where, perhaps when the
low order byte is somewhere in the hex 00 to hex 20 range, that
readNextEqual() will consider different values as equal?
<<SNIP>>