|
David, I'm reading this Mailing list for a long time and I see some java projects in the 400er area in germany and sometimes I've the idea that I'm looking at rpg programs written in java and the outer world of java is hidden to the 400er community and this is a negative fact for the as400. The main topic is: how to write java applications, well modularized, flexible against changing requirements, stable, failure tolerant and .... fast enough on as400. and so I'm throwing in my few cents (we have this in germany now too) to bring the as400 java community to the mainstream of application development. If CRTJVAPGM speeds up your application and you need it, use it. I've seen constellations, it didn't help anything and took 24 h. The as400 and it never crashs, I've seen boxes running WebsFear: WF took 95% of the CPU, just doing nothing, it was impossible to stop WF, the SBS could not be ended, even an ENDJOBABN didn't help, only PWRDWNSYS stopped this nonsense and luckily we did not run WF 3.5.1 or 3.5.2 (some of us know why). Dieter On Tuesday 05 November 2002 18:17, you wrote: > 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 > > > > > > _______________________________________________ > This is the Java Programming on and around the iSeries / AS400 > (JAVA400-L) mailing list > To post a message email: JAVA400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l > or email: JAVA400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/java400-l. > > _______________________________________________ > This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) > mailing list To post a message email: JAVA400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l > or email: JAVA400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/java400-l. -- mfG Dieter Bender DV-Beratung Dieter Bender Wetzlarerstr. 25 35435 Wettenberg Tel. +49 641 9805855 Fax +49 641 9805856 www.bender-dv.de
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.
midrange.com
