Re: Positioning the Cursor, from the Toolbox

    Hi Joe,

Heee! In order to make your Java programs faster, just double
your disk usage!

    It was unfortunate to have to make that kind of trade off not just for
Java, but for I18N issues in general.  The good news, for I18N anyway, is
that as of V5R3, UTF-8 is supported.  The only downside is that for some
character sets UTF-8 actually requires *three* bytes.  Fortunately, those
are relatively rare.  For most languages, UTF-8 will use just one byte, so
shops using UCS-2 and those staying away from Unicode due to previously
having to use UCS-2 may want to convert/reconsider.

    Java will still convert to standard Unicode.


                                                         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: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
To: "'Java Programming on and around the iSeries / AS400'"
<java400-l@xxxxxxxxxxxx>
Sent: Wednesday, August 30, 2006 6:21 PM
Subject: RE: Positioning the Cursor, from the Toolbox

Yeah, a lot of us know the answer.  Sometimes we don't have time to
immediately respond in the list, though <smile>.

I've done extensive work with the RLA methods (I've even written a for-fee
lab on the subject which explains how RLA compares to JDBC for file

access).

I can definitively say the following:

1. The AS400KeyedFile allows keyed access ALMOST exactly like you would
expect in standard native I/O, including partial key access.  There is a
subtle difference in that the "cursor" for RLA is effectively "on" a given
record, where with native I/O it is effectively "between" records.  It
really only makes a difference when you're switching directions during
sequential-by-key processing.

2. I've never run into any performance issues opening a keyed file.  I

have

no idea who wrote that statement; there's a good chance that they were
dealing with a file with MAINT(*DELAY) on the access path.  Note that they
talk about opening a KeyedFile over a physical; they don't seem to
understand the concept of a logical file (I suspect that if you tried to
open a KeyedFile over a physical with no keys, it would fail).

These performance hints are written by people who are more familiar with
Java than the iSeries.  For example, another hint on the same page says:

"Specify a CCSID of 13488 for any of your text fields in your physical

file.

CCSID 13488 is Unicode, so when data is read and written between Java and
i5/OS, little if any text conversion needs to be done. Most text fields in

a

physical file (for an English system) default to 37 - the English EBCDIC
CCSID. Data translation occurs between this CCSID and Unicode since all

Java

characters and Strings are in Unicode. Character conversion can become a
serious bottleneck for applications that handle large amounts of string d
data."

Heee! In order to make your Java programs faster, just double your disk
usage!  So, take the hints with a grain of salt.  If you'd like to know

for

certain about the open time, I'd suggest a very simple program: create a
KeyedFile over your largest logical view, then open it and read a record.

Joe