Re: AS/400 and Java

<Dieter.Bender=zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org> wrote in message
1036423799.3dc69277cafac@webmail.t-online.de">news:1036423799.3dc69277cafac@webmail.t-online.de...
> things have changed with JIT and V4R5, but some "experts" didn't
> recognize this, maybe they are not reading recent documentation.
> Just have a look to the mainstream of java development, which takes
> place on other boxes and yoe see were the future will be. if the as400
> wants to survive as java plattform, then it will go this way too.

Dieter:

In some respects, I agree with that statement ... but you made some pretty
bold, and quite specific, recommendations in your previous message ...
before I consider them to be reliable, I really need to know what you are
basing them on.

I'll address my concerns with the statements directly ...

> 1. read the recent manuals (Performance Capabilities Reference
> recommends the JIT environment since V4R5!)
> 2. don't use CRTJVAPGM on boxes > V4R5

Which manuals is that?  I can't find it.

> 3. don't use the native driver, its buggy, use the latest Toolbox driver

How is it buggy?  Are there APAR's out for it that haven't yet been PTF'ed?
Using the native capabilities of the database has got to be better than
using a JDBC connection.  Even it's local.

> 4. don't use record level access (more IO Operations compared to SQL)

Huh?  That's backwards.  Record level IO, while not being very portable, is
far more efficient than SQL (at least for record processing).  I think Joe
Pluta's research has shown that in spades.

> 5. run your application server on inexpensive boxes
> (Wintel, or Linux on Intel), if possible (scalability)

Again, Huh?  No PC comes close to an iSeries in terms of scalability.  This
is one of the systems primary strengths.

> 6. Don't mix Java with RPG and/or COBOL, the context change is
> very expensive

Where is this documented?

> 7. use all features of the as400 as database server, you've paid
> for it

While this is true ... being a database server is by no means the only thing
the iSeries can do.

> 8. for maximal speed with minimal hardware requirements use
> assembler and shift your bytes bit by bit

This goes without saying ... all systems run faster at the machine level
than the application level... but few programmers (in general) program at
the machine level.

david