Re: Performance issue - CLRLIB vs RNMOBJ vs DLTLIB / Timeslice

[rob@xxxxxxxxx]

Any chance you can just load the tape from last nights backup and do a 
RSTLIB SAVLIB(MYLIB) DEV(TAP69) MBROPT(*ALL) ALWOBJDIF(*ALL) 
RSTLIB(TESTLIB)

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Steve Johnson" <sjohnson@xxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
01/20/2004 05:07 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
<midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
Performance issue - CLRLIB vs RNMOBJ vs DLTLIB / Timeslice






We currently submit a job to copy data libraries from our prod environment 
to a test environment.  The libraries are very large, and we are currently 
doing a CLRLIB of the to-library followed by a CPYLIB from the prod 
library to populate the cleared test library with production data.  The 
job takes longer than we would like for it to complete, about 2 hours.

With large libraries might another approach perform better?  We thought 
that RNMOBJ/CRTLIB/CPYLIB might help the main process complete faster, 
allowing the DLTLIB of the unneeded RNMOBJ library to be handled later, 
but we didn't notice the job completing any faster.  I would think that a 
DLTLIB/CRTLIB/CPYLIB combination might be even slower in completing.

Have you been there done that? 

One of the first steps in the CLP is a CHGJOB to set the timeslice to 
6,000,000.  Someone once stated that too high of a timeslice will work 
against your own job performance-wise.  Any comments, suggestions?

Thanks,
Steve

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.