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

Hi Shane,

I'm glad you found the problem and reported it back here. It's ironic
that the "something different" is that names are the same on runs after the
first. Still, I would have expected that you would receive a ZipException
(subclass of IOException) for duplicates.

As it happens, sometime in the next few months I'm going to work on
something similar, except for zip entry rewrites, on *large* volume data.
I'll post if I come across any performance gain possibilities.


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: <Shane_Cessna@xxxxxxx>
To: "Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
Sent: Wednesday, June 13, 2007 9:44 AM
Subject: Re: length of time a java pgm runs in batch...


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
file...

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
<java400-l@xxxxxxxxxxxx>


To
"Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
cc

Subject
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
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