Hi Shane,
I agree with Thorbjørn; you're allocating 4 gig (!) right off the bat.
Studies I've seen, while getting some age now, indicate that you don't gain
much performance-wise after about 8K for buffers. Also, you init
filenames[] as new String[500], but later redo it. Smaller memory issue but
still there. You can also make your code less complicated by using a single
try statement with multiple catches since you don't appear to have any reset
code.
I'm also a little uncomfortable with your use of Toolbox/JTOpen IFSFile,
and java.io/java.util.zip classes together. That's because of the AS400
object in one set and not the other.
However, none of that addresses why you see a difference in interactive
and batch runs. Taking your word that it runs properly interactively, and
given that you are using absolute paths for most of your input and output,
the code is difficult to debug without your structure and files.
I'd suggest first that you check the date and time of your output zip
file before and after. That will tell you if it was processed during the
run. Next, I'd add some more println's to verify your input argument. Also
in this section:
else
{
filenames = new String[500];
System.out.println("dir not found; new String array");
}
and in the section after:
// Compress the new files
You can see the output in the job log for the batch run. At this point,
my thought is that the invocation is different between the two runs and the
zip file just rewrites itself. Again, that's just a guess. The additional
output I suggested (and any more that you think will be helpful) should
clarify things.
Joe Sam
Joe Sam Shirah -
http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum:
http://www.ibm.com/developerworks/java/
Just the JDBC FAQs:
http://www.jguru.com/faq/JDBC
Going International?
http://www.jguru.com/faq/I18N
Que Java400?
http://www.jguru.com/faq/Java400
----- Original Message -----
From: "Thorbjørn Ravn Andersen" <thunderaxiom@xxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
Sent: Monday, June 11, 2007 6:00 PM
Subject: Re: length of time a java pgm runs in batch...
Shane_Cessna@xxxxxxx skrev den 11-06-2007 21:20:
Joe,
Here's the code...ZipIFSFolder.java
package com.nal.eReqs;
import java.io.*;
import java.util.zip.*;
import com.ibm.as400.access.AS400;
import com.ibm.as400.access.IFSFile;
import com.ibm.as400.access.IFSFileInputStream;
import com.ibm.as400.access.AS400SecurityException;
public class ZipIFSFolder {
public static void ZipFolder(String eReq)
throws IOException {
// Create a buffer for reading the files
byte[] buf = new byte[2147483647];
byte[] buffer = new byte[2147483647];
Are you sure that you need 2Gb buffers? Most IO-routines do not need
such large buffers, and Buffered* classes can do a lot of buffering for you.
But, what does the output file and the spool file say for your submitted
job. You most likely can see a stack trace right there.
Oh, you can always wrap your main routine in a try-catch(Throwable e)
and then dump the stack trace to somewhere where you can see it afterwards.
midrange.com
