In this particular case I was, because the program was stuck in a Java
method. This naturally does not help me if the program abrubtly ended.
We are currently investigating if it makes sense to make java logging to
the spool file on the debug level, and on info or higher to long term
storage in actual IFS files.
I think that logging is always nice, but please consider that the iSeries provides some nice logging by default. If I try the following:
sbmjob cmd(RUNJVA CLASS('HelloWorld'))
It will fail because there is no 'HelloWorld' class in my classpath. If I run the following command:
wrksbmjob
I see my last two jobs (there might be more old jobs out there). One job type is BATCH, and the other is BATCHI. If I do option 8 to any of them, I can see several job logs that I can view. Have you tried something like that?
Please note that our development machine is an AS/400 running V5R3 - we
naturally test the java code inhouse before it is put on the customers
machines - and our development machine is MUCH MUCH faster than this
particular clients. (and my PC is about 3 times or more faster than our
AS/400).
I just need to find out why, and it is most likely a scheduling priority
issue.
Well, your PC might look faster that your iSeries (and that might be true in a way), but there are several things to remember:
1. Your java job does not use the 100% of the processor when it starts. Even if you change the priority to a very low number (I would not recommend less than 20, because you would affect interactive users), the operating system will not give it a decent slice of the processor to your job until some time has passed. Thus, java jobs look slower.
2. Many iseries have multiple processors, even the old systems. Most of the time a job uses only one processor. I don't know if java multithreading uses multiple processors effectively, but you might want try that (and report your results, please!). Another technique is to launch multiple batch jobs listening to a data queue for data. This is pretty powerful. I can give you more details if you want.
3. The iSeries hardware is optimized by design for *heavy* input/output. The rationale is that business applications make a heavier use of disk (database) than processing.. Although pure processor performance may be lackluster, input/output and database operations are quite surprising (and very stable).
I have actually experimented quite a lot with this as we should do some
image conversions from TIFF to something immediately browsable. For
something CPU heavy "jitc" was 30% faster than -opt40 ... AFTER being
optimized but including JIT'ing. The JIT process took almost a minute
before any output was produced, but it STILL overtook the statically
compiled code. This is most likely due to very aggressive inlining of
method calls. The jit in the 32-bit JVM in V5R4 resulted in the same
speed as the classic JIT.
No, I am certain that this is something which is externally induced. I
just need to be able to figure out what.
This is interesting. I was unaware of that. Thanks for the info! I think that the *JIT is relatively new, and I had not tested it.
midrange.com
