× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We've been in a similar dilemma where we don't reorg our very big files and
the rest we schedule reorgs in a downtime window on a 4 weekly cycle.

Are we saying that we should have the RGZPFM statement with "ALWCANCEL=YES"
and "LOCK=*SHRUPD" and also off course the file must be defined with reuse
deleted records.

This would then allow us to run reorg's "in the background" and all the time
enbabling concurrent file updates etc.

Is there much of a performance knock?

Paul Tormey

2009/8/27 John Jones <chianime@xxxxxxxxx>

If you're on a recent OS release the reorg can be run in the background so
it more or less takes no time at all. No downtime, anyway. Check the LOCK
parm of RGZPFM. I think you have to be V5R3 and up.


http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/cl/rgzpfm.htm

Also, don't forget to change the file to reuse deleted records so deleted
record growth is slow going forward.

On Wed, Aug 26, 2009 at 5:43 PM, Alan Campin <alan0307d@xxxxxxxxx> wrote:

Only two ways to get out. Reorganize or copy out. It would seem to me
that
a
copy would be slower but never did any timings.

On Wed, Aug 26, 2009 at 2:13 PM, Tim Gornall <tgornall@xxxxxxxxxx>
wrote:

We have file with 51 million current records, and 30 million deleted
records. I need to get rid of the deleted records. I restored a copy
of
the file a few days ago it finished in about 15 - 20 minutes. If I
recall
it takes much longer than that to reorg that many records. I'm trying
to
get an idea of how long it will take. The file is keyed, but has no
logicals. Is restore faster?

Tim




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


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




--
JJ
"I'm in no condition to drive...Wait! I shouldn't listen to myself, I'm
drunk!"
- Homer J. Simpson
--
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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

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