× 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.



Thanks David for the info.

I am just about to use Tomcat on AS400. There are two questions:



  1.. As400 seems now ships with Tomcat installed. Is it a good idea to use
this copy? Or maybe it is easier to install an Apache copy?
  2.. Is there a way to connect Tomcat login to AS400 validation list/AS400
userID (without storing these info in tomcat-users.xml)?
Thanks.

Bruce




----- Original Message -----
From: "David Morris" <David.Morris@plumcreek.com>
To: <java400-l@midrange.com>
Sent: Tuesday, November 05, 2002 9:17 AM
Subject: Re: AS/400 and Java


> Dieter, Bruce,  and Mark,
>
> The CRTJVAPGM command is still useful and can dramatically improve
> performance even on the latest release. For example, an uncompiled
> version of Tomcat and our site takes at least 5 minutes to start w/o
> compilation. With compilation it takes less than 2 minutes. I don't
> fully
> understand why since most classes are loaded by a custom class loader,
>
> but I have seen it enough to know that this is absolutely the case.
> This
> can be very important when you have a short window to install upgrades,
>
> so I always compile new/changed Jar and Class files that are installed
>
> on our system. I submit these compiles to run during periods of low
> activity. I then create symbolic links to those Jar and Class files
> in our various application directories. Standalone applications tend to
>
> benefit even more from native compilation.
>
> We use JTOpen 3.2 JT400Native.jar (compiled to 40) loaded with the
> system class loader and have not seen any problems. This makes a big
> difference in performance. In our case RPG is invoked via triggers and
>
> at the native exit point to swap user/group and performance is good.
>
> David Morris
>
> >>> brucej@MRC-PRODUCTIVITY.COM 11/04/02 01:31PM >>>
> <zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org> wrote
>
> > 1. read the recent manuals (Performance Capabilities Reference
> > recommends the JIT environment since V4R5!)
> > 2. don't use CRTJVAPGM on boxes > V4R5
>
> I stopped using CRTJVAPGM long ago. Everything seems to be OK.
>
> > 3. don't use the native driver, its buggy, use the latest Toolbox
> driver
>
> I use the native driver all the time. Everything seems to be OK.
>
> > 4. don't use record level access (more IO Operations compared to
> SQL)
>
>  I have not used record level access. Everything seems OK. I primarily
> code
> interactive applications and SQL seems to be good enough.
>
> > 5. run your application server on inexpensive boxes (Wintel, or Linux
>  on
> Intel), if possible (scalability)
>
> Linux may offer some hope. My new Intel/win2000 crashes at least once
> a
> month and they can't fix it.
> In 9 years I did see AS400 crash, once.
>
> > 6. Don't mix Java with RPG and/or COBOL, the context change is very
> expensive
>
> The context change cost probably is often more than compensated. I have
> a
> Java application that calls a big RPG program which calls other CL and
> RPG
> programs and they all do file read/update/delete. The timer shows that
> all
> these take 100 ms (0.1 second). I time it from getting a connection to
> returning a connection. Other applications with fewer file operations
> but
> exclusive JDBC SQL calls would always take more than 100 ms.
>
> > 7. use all features of the as400 as database server, you've paid for
> it.
> > 8. for maximal speed with minimal hardware requirements use assembler
>  and
> shift your bytes bit by bit.
>
>  Labor is more expensive than hardware.
>
>  Bruce


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.