RE: Training in Green Screen Java performance and debugging?

I am correcting my last entry... sorry... it was hard to tell where I was writing.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Thorbjørn Ravn Andersen
Sent: Sunday, December 09, 2007 4:33 PM
To: Java Programming on and around the iSeries / AS400
Subject: Re: Training in Green Screen Java performance and debugging?

Sure. This particular problem was a Java 1.3 program doing
ftp-transfers which repeatedly got stuck in TIMW. Since this was
ancient production code from before my time we could not just throw new
versions in there, and I could not attach a debugger (no network access
but telnet and ftp) so I could not ask WHERE this happened. Usually I
have a stack trace to deal with but I could not figure out how to get
one. Well, option 11 on the job gave me a call stack window, and
THANKFULLY the stack entries for the java code is very readable so it
was very easy to identify the culprit (an accept() waiting for a
connection which never came). I believe this is Java 1.3 under V5R1.

Here I would have loved to be able to get a readable Javastacktrace or
just the option 11 to a spool file (perhaps even in IFS? *oh*) so I
could get an overview much faster than poking around in the call stack
stuff.

<Luis>
I'm glad you are able to peek into the details of the job. Keep in mind that when the job finishes (or dies), the job logs have a lot of useful information. If you write down the user id of the job, then you can always use WRKUSRJOB to the job logs. If you have the whole information (job name, user, and job number) you can also use DSPJOB. IMPORTANT! The job information is gone if no spool files were generated. So if you are unable to display a job, it may be because the job finished successfully AND printed output was generated.
Another way where you can see the output of your program is running your java within the qshell (have you tried that?) If you have worked with any Unix shell, you'll feel at home with qshell. Just type QSH in the greenscreen command line. In some ways qshell is a bit limited, but it behaves almost like a unix shell.
</Luis>
We also have another system which runs my code noticeably slower than on
our development system, and where we have ruled out insufficient memory
pool or batch/interactive but not gotten much further yet. From Unix I
am used to top and sar which can tell me the paging activity (swap) for
a given process and WHY and WHERE it waits. I would like similar
knowledge for AS/400 - WHY is the system not giving my process top
prority and resources? WHERE does all the resources go? etc. If I
recall correctly this is Java 1.4 on a V5R4.

<Luis>
ISeries is notorious for running Java code slower than in PC or Unix machines. I believe that one of the main reasons is the way the iSeries allocates processing time to a process. Windows and Unix will use as much processing power as possible when running a program. So it may be possible that your processor utilization in Unix/Windows goes up to 100% when you run a Java program. That means that if you are the only user on the machine, a program with no I/O may run in 10 seconds. If there were 10 users running the same program at the same time, they would finish in a 100 seconds, that is *10 times* more time to complete. On the other hand, the iSeries philosophy is to provide a more uniform experience... if you are the only user on an iSeries, and then you run the same java program, it may assign only 15% of the processor to the java program at the beginning, so it would take 60 seconds to run; however, if there were 10 users running the same program at the same time that would take maybe a 100 seconds, that is *1.7 times* more time to complete. The user experience is more uniform. However, when a program runs for a long time, the policy of the operating system is to give it a bigger and bigger processor slice, so it can finish it as soon as possible.
Have you optimized your java programs? If not, use command Create Java Program (CRTJVAPGM) and optimize your jar and class files. Although the main (and original purpose) of CRTJVAPGM was to be the equivalent of javac, it can also be used to optimize already compiled code. This is the best way to improve performance. Try to optimize all your jar and class files up to level 40. Just be aware that it may take a long time, but it's worth it.
</Luis>
And naturally all this must be doable in a green screen. I need to be
able to work with the tools intended for the system instead of whining
about missing network access.

I found a AS/400 performance analysis manual on a shelf - I believe I
should be able to use that information just to get started .

Thanks for your replies - it helps to play ball with somebody.