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


  1.  Home
  2. MIDRANGE-L
  3. November 2013

RE: estimating RGZPFM runtime

We use a combination of RGZ while active and REUSEDLT records.
Some of our apps us the PF RRN as a key, thus REUSEDLT records cannot be used.
We have had great success with RGZ while active, although I must admit we run with little or no activity on the system.
The number of LF over the PF also has a large impact on the time required.
Each addition LF will cause additional IO, access paths need to be updated when the PF record is moved.
A PF with 20 LF, minimum of 21 IO for each record moved.
Also, in iNAV, while the RGZ is running, you can see the % complete per each PF.
We RGZ all are PF(that have dlt records) while active once a month, job averages about 1 hour total.
Hardware also has big impact, currently SSD drives with 5913 controllers.
I remember a RGZ while active, 2 years ago, Power 5, conventional drives, V5R4, the job took 6 days. 1 file alone was 3 days.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Roger Harman
Sent: Monday, November 18, 2013 7:55 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: estimating RGZPFM runtime

Well, a properly designed/implemented price change process would solve your problem. Or, write a change/historical record as part of the maintenance process.

Relying in RRN is not a good practice.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Monday, November 18, 2013 3:01 PM
To: Midrange Systems Technical Discussion
Subject: RE: estimating RGZPFM runtime

Hey - these days everyone wants to know who changed what, and when.

Maybe its SOX stuff, maybe it just goes with the times.

It seems that farming the journals is the easiest way (maybe the only way?) to accomplish this type of requirement.


Yes we cannot use reorg-while active as RRN will not maintain integrity thru that type of process.



I am still looking for a method to estimate RGZPFM run times though if anyone has any ideas.

Thanks!





-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: Monday, November 18, 2013 4:53 PM
To: Midrange Systems Technical Discussion
Subject: Re: estimating RGZPFM runtime

Well, re-reading that, not impossible, but you'll have to do it in a planned way, and your suggestion will probably work.

Seems like what you have to do might defeat the purpose of allowing re-org while active, but I guess it will get you there.

This is the kind of application/operational process that gives me the willies.


On Tue, Nov 19, 2013 at 11:40 AM, Stone, Joel <Joel.Stone@xxxxxxxxxx> wrote:

I don't agree - see my post to Charles. After reading my reply, do
you STILL think RGZPFM is not possible?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: Monday, November 18, 2013 4:27 PM
To: Midrange Systems Technical Discussion
Subject: Re: estimating RGZPFM runtime

Your estimate for RGZPFM should be zero then.
I don't think you *can* reorganize them if you are relying on RRN to
never change.


On Tue, Nov 19, 2013 at 11:15 AM, Stone, Joel <Joel.Stone@xxxxxxxxxx>
wrote:

Another caveat I should have mentioned is that we do "farm the journals"
looking for user data changes. The journal processing depends on
the RRN being intact and unchanging between journal dumps.

For example if Cheerios is item# 123 and was in RRN slot 789
yesterday, then it had better be in slot 789 again tonight with the
next journal farming activity takes place.

I am afraid if we re-used deleted records, we would lose RRN integrity.

Same for RGZPFM while active.





-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gary Thompson
Sent: Monday, November 18, 2013 3:58 PM
To: Midrange Systems Technical Discussion
Subject: RE: estimating RGZPFM runtime

Maybe change to re-use deleted records and skip RGZPFM ?


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Monday, November 18, 2013 2:41 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: estimating RGZPFM runtime

Joel,

If you use RGZPFM while active, no down time. We created a process
(CLs and qry), using RGZ While Active, does all PF with deleted records.

STRJRNPF FILE(&MBLIB/&MBFILE) JRN(QGPL/RGZPFM)

SNDPGMMSG MSG('RGZPFM starting for ' *BCAT &MBLIB *BCAT +
'/' *BCAT &MBFILE *BCAT '.')

RGZPFM FILE(&MBLIB/&MBFILE) MBR(&MBNAME) +
RBDACCPTH(*NO) ALWCANCEL(*YES) +
LOCK(*SHRUPD) /* rgzpfm while active */
MONMSG MSGID(CPF2981 CPF3135 CPF9801 CPF9809 +
CPF9810 CPF9820 CPF2982) EXEC(GOTO +
CMDLBL(ERROR2))


ENDJRNPF FILE(&MBLIB/&MBFILE) JRN(QGPL/RGZPFM)
MONMSG MSGID(CPF9803) EXEC(GOTO CMDLBL(ERROR4))

Thanks
Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Monday, November 18, 2013 4:24 PM
To: Midrange Systems Technical Discussion
Subject: estimating RGZPFM runtime

How can I estimate down-time required to RGZPFM a file? Is there a
utility or rule-of-thumb on these?

Can it be killed if not completed OR will the file then be compromised?

Thanks!



____________________________________________________________________
__ This outbound email has been scanned for all viruses by the
MessageLabs Skyscan service.
For more information please visit
http://www.symanteccloud.com__________________________________________
____________________________
--
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.

--
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 inbound email has been scanned for all viruses by the
MessageLabs SkyScan service.
____________________________________________________________________
____

____________________________________________________________________
__ This outbound email has been scanned for all viruses by the
MessageLabs Skyscan service.
For more information please visit http://www.symanteccloud.com
____________________________________________________________________
__
--
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.




--

Regards
Evan Harris
--
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 inbound email has been scanned for all viruses by the
MessageLabs SkyScan service.
______________________________________________________________________
__

______________________________________________________________________
This outbound email has been scanned for all viruses by the
MessageLabs Skyscan service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
--
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 ...
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.