I think I figured out the problem...when I add a new file to my zip file
that has the same name as a previous entry in the zip file, the zip file
becomes corrupted and will no longer open or add any new files to the zip

Shane Cessna
Senior iSeries Programmer
North American Lighting, Inc.
217.465.6600 x7776

"Joe Sam Shirah" <joe_sam@xxxxxxxxxxxxx>
Sent by: java400-l-bounces@xxxxxxxxxxxx
06/11/2007 07:39 PM
Please respond to
Java Programming on and around the iSeries / AS400

"Java Programming on and around the iSeries / AS400"

Re: length of time a java pgm runs in batch...

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
much performance-wise after about 8K for buffers. Also, you init
filenames[] as new String[500], but later redo it. Smaller memory issue
still there. You can also make your code less complicated by using a
try statement with multiple catches since you don't appear to have any

I'm also a little uncomfortable with your use of Toolbox/JTOpen
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
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.
in this section:

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
my thought is that the invocation is different between the two runs and
zip file just rewrites itself. Again, that's just a guess. The
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"
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:

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

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.