× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




    Hi JHHL,

    Given the thunderous response so far, I'd say for a definitive answer
you'd have to try it yourself.

    However, my understanding is that your assumption regarding
sequential-by-key access is incorrect.  In the KeyedFile javadoc it says
"Access the records in an AS/400 file sequentially or by key."  Secondly,
note that the methods you refer to come from AS400File and are not
overridden in KeyedFile.  My conclusion is that those methods ignore the
keys and just read sequentially.

    Given your scenario of read, process, delete, if I were going to use RLA
( and I wouldn't - no flame or arguments, please.  Others would, I'm sure. )
it appears that one of the read() methods that use searchType would be the
way to go.  I'd expect you could set the key to zero and searchType to
KEY_GT to get what you want.

    One thing to be wary of with KeyedFile is this little gem:

Record-Level Access performance tips

Keyed access.  Do not use a KeyedFile when you can get away with using a
SequentialFile. Opening a physical file for keyed access is slower since the
database will order the file by key at the time of the open. If you don't
need any of the key functionality, just use a SequentialFile object.

at:

http://www-03.ibm.com/servers/eserver/iseries/toolbox/perfhints.html

    That seems odd to me, and I don't know anything about it other than what
it says, but I'd certainly check it out.

    HTH,
                                                         Joe Sam

Joe Sam Shirah -        http://www.conceptgo.com
conceptGO       -        Consulting/Development/Outsourcing
Java Filter Forum:       http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International?    http://www.jguru.com/faq/I18N
Que Java400?            http://www.jguru.com/faq/Java400


----- Original Message ----- 
From: "James H H Lampert" <jamesl@xxxxxxxxxxx>
To: <java400-l@xxxxxxxxxxxx>
Sent: Tuesday, August 29, 2006 1:55 PM
Subject: Positioning the Cursor, from the Toolbox


Any Toolbox gurus out there?

Do the cursor-positioning methods in the AS400File class,
i.e., positionCursorBeforeFirst(),
positionCursorToFirst(), and so forth, and the sequential
reading methods, readFirst(), readNext(), and so forth,
produce expected results if applied to a KeyedFile?
Particularly a KeyedFile that's open on a physical file
that is set to re-use deleted records?

Scenario:
Records are constantly being added to a file, FOO, by any
number of jobs throughout the system. This file is being
polled continuously, and records are being read, in FIFO
order, copied into another file, BAR, and deleted from
FOO, as fast as the polling job, FROBOZZ, can process
them. If FROBOZZ opens FOO with the SequentialFile class,
then FOO cannot re-use its deleted records, because if
FIFO order would not be guaranteed if at any point FOO
contains more than one active record. Thus, FROBOZZ, and
all the jobs pouring records into FOO, would have to be
shut down periodically to do a RGZPFM on FOO, or FOO would
eventually overflow.

FOO is, however, keyed uniquely on a rather long (i.e.,
21-digit!) numeric field that is incremented with each
write operation. If we open it using the KeyedFile class,
would I be correct in assuming that the aforementioned
AS400File methods give us sequential-by-key access?

--
JHHL
-- 


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.