RE: JT400 Record-level access problem

Thanks, Chuck.

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.

Dan
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, October 19, 2012 2:22 AM
To: java400-l@xxxxxxxxxxxx
Subject: Re: JT400 Record-level access problem

Establishing cursor position for keyed read [random I\O] is somewhat moot; keyedfile should have established position already, typically to *START, then the I\O with a key specified determine where to position and get the row. There seems no reason both to get random position and then to get random position with an I\O.? Ignoring the [then missing] try\catch, what about the changes inline below; i.e. use a request to read-first instead of positioning, then loop on read-next-equal? IIRC, that is how I would have coded to the equivalent MI methods to effect [what I infer is] the desired, as described and from the given source.

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:

I'm using the following code to read all the records from one file
(fileVAL) with keys matching the key in another file (fileINF).
Occasionally, I'll get records from fileVal that are greater than the
search key. Not always. Most of the time, I'll get a null back from
the readNextEqual() when the next record in the file has a higher
value for the key. fileINF is set as unique(*yes) and fileVal is set
as unique(*no). 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?

fileINF.positionCursorBeforeFirst();
recordINF = fileINF.readNext();
if (recordINF != null) {
String result=null;
this.doAnother = !((String)(recordINF.getKeyFields()[0])).equals("**QUIT**");
if (doAnother){
this.doAnother=true;
Object[] keys = recordINF.getKeyFields();
String uniqueId = recordINF.getField(0).toString();
WorkpieceCreationInfo wpCreate = new WorkpieceCreationInfo(
recordINF.getField(1).toString().trim(),
recordINF.getField(2).toString().trim(),
recordINF.getField(3).toString().trim(),
recordINF.getField(4).toString().trim());
log.debug("FLOCWPINF read"+
"\n\t"+recordINF.getField(0).toString().trim()+
"\n\t"+recordINF.getField(1).toString().trim()+
"\n\t"+recordINF.getField(2).toString().trim()+
"\n\t"+recordINF.getField(3).toString().trim()+
"\n\t"+recordINF.getField(4).toString().trim());
{
Record recordVAL = null;
try {

// read first or fail to find key
recordVAL = fileVAL.read(keys);

do {
if (recordVAL != null) {
wpCreate.addValue(
recordVAL.getField(1).toString().trim(),
recordVAL.getField(2).toString().trim());
log.debug("FLOCWPVAL read"+
"\n\t"+recordVAL.getField(0).toString().trim()+
"\n\t"+recordVAL.getField(1).toString().trim()+
"\n\t"+recordVAL.getField(2).toString().trim());
}

// read next-equal or fail to find key
recordVAL = fileVAL.readNextEqual(keys);

} while (recordVAL != null);
} catch (AS400Exception e){
// nothing in the file for the key
}
}

--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.