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