Re: JT400 Record-level access problem

[CRPence <CRPbottle@xxxxxxxxx>]

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