Strategic Java Usage

Nathan,

WRKDBF is interesting, I hadn't seen that utility before, thanks for the
info.

In your following reply, I'm not sure I'm understanding all your points
relative to utilitarian interfaces nor the performance impacts you mention.
Care to elaborate....  ?

******************************************

"It would be possible to create an ILE *SRVPGM, exporting a utilitarian
interface for database maintenance, and bind Web applications to it.

We'd probably want Web applications to support custom HTML interfaces,
rather than having a generic (utilitarian) user interface for every
application.

But if we were to go that route, wouldn't we need to consider the cost of
either inheriting (Java) or binding with (ILE) a comparatively large
"utility" for every maintenance program or Servlet we deploy?  Wouldn't
there be performance implications according to the number of programs or
Servlets deployed?"






date: Mon, 15 Mar 2004 23:05:28 -0800
from: "Paul Holm" <pholm@xxxxxxxxxxxxxxxxx>
subject: Strategic Java Usage

...

Other related random thoughts and experiences:

*  For reasons not 100% clear to me.. the AS/400 Java performance seems to
stink.  I've had and helped 3 clients move their apps to Windows and see the
performance improve dramatically.  My understanding of why is:  a)  The
AS400 JVM goes through an extra step of "byte code verification"  for
security reasons   b)  in terms of processor speed and RAM, Java is very
speed and RAM hungry,  I've watched while a "desktop Windows" running at 3
GHZ with 2GB of RAM runs circles around a decent size AS400.  Rochester,
better circle the wagons here..  Bad story and I know you are working on
it..

...


------------------------------

message: 5
date: Tue, 16 Mar 2004 10:51:37 -0700
from: "Nathan M. Andelin" <nandel@xxxxxxxxxxxxxxxxxxx>
subject: RE: Strategic Java Usage

> In the referenced example, the Java component to
> display a list of employees and departments is
> exactly the same.

> This means that any requirement to select, display,
> edit, delete database records can be generically
> handled via a single component thus saving huge
> amount of redundant programming.

> RPG simply cannot accomplish this.

Actually, it can be done in RPG.  For reference see:

http://www.wrkdbf.com/

It would be possible to create an ILE *SRVPGM, exporting a utilitarian
interface for database maintenance, and bind Web applications to it.

We'd probably want Web applications to support custom HTML interfaces,
rather than having a generic (utilitarian) user interface for every
application.

But if we were to go that route, wouldn't we need to consider the cost of
either inheriting (Java) or binding with (ILE) a comparatively large
"utility" for every maintenance program or Servlet we deploy?  Wouldn't
there be performance implications according to the number of programs or
Servlets deployed?

> For reasons not 100% clear to me.. the AS/400 Java
> performance seems to stink.  I've had and helped 3
> clients move their apps to Windows and see the
> performance improve dramatically.

It could be the speed of the CPU.  IBM synchronizes CPU speed with CPW
targets.  A box running a 4 year old 200 MHz Northstar chip, might actually
be 4 times slower than a box running a 7 year old 100 MHz Apache chip,
according to CPU bound benchmarks.  Hint: get a fast CPU.

Wintel boxes have cheap, fast CPU's, but they don't manage complex workloads
effectively.  Try running a large Oracle database and Websphere on a single
Wintel server, generating reports at the same time as serving Web pages, and
you'll appreciate the performance capabilities of OS/400.

Nathan.






------------------------------

_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
digest 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.



End of JAVA400-L Digest, Vol 2, Issue 97
****************************************