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



Paul,

With reorg while active, the access paths only get updated, not rebuilt.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Nelson
Sent: Wednesday, June 29, 2016 4:44 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: RMVM for SQL index objects

Yes, but with some files containing north of 250 million records and close to a hundred logicals and indexes over them, the lights in the data center start to dim while the access paths are being rebuilt.

Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Wednesday, June 29, 2016 3:33 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: RMVM for SQL index objects

Paul,

Did you consider using reorg while active?

I created a little utility (few cdl and querys) that automatically runs once a month.
Removes all deleted records from all files, unattended.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Nelson
Sent: Wednesday, June 29, 2016 4:28 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: RMVM for SQL index objects

We're working on a huge file reorg project. We have a 17TB system that's over 75% full. We have determined we can get down around 50% by getting rid of deleted records. Once we accomplish that, we'll change over to reusing deleted records.

RMVM beforehand and ADDLFM afterward has always been the way to go to avoid thrashing. But that was before the proliferation of SQL indexes.

:-)


Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, June 29, 2016 3:15 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: RMVM for SQL index objects

On 29-Jun-2016 14:55 -0500, Paul Nelson wrote:
On 29-Jun-2016 14:40 -0500, Paul Nelson wrote:
Does anybody know the equivalent command in the SQL world?

That's probably it. If I add the index back after a file reorg, will
that set me up for level checks?


Ah. So the inquiry from the OP is regarding an intention to disable the keyed Access Path (ACCPTH) [maintenance] during a Reorganize Physical File Member (RGZPFM) against the underlying data?

So perhaps the AccPth of the INDEX is defined UNIQUE, thus preventing changing the Maintenance (MAINT) attribute? In that case, the DROP INDEX [or Delete File (DLTF)] can be used after a Save Object (SAVOBJ), and the Restore Object (RSTOBJ) done afterward -- there could be two restores, one first without the member, and then another to restore the member, but there would be no point in so doing.

FWiW the ALWCANCEL(*NO) reorg will already disable a non-unique keyed AccPth, and move the rebuild until afterward in an async runpty-52 QDBSRV## system job. And a non-unique AccPth could be modified with Change Logical File (CHGLF) to set the Maintenance (MAINT) attribute to the special value of *REBLD [¿possibly required?: in conjunction with RECOVER(*NO)].

Maybe some background about the scenario, to help explain the reasoning for the approach; perhaps discussion can lead to a different path.?

--
Regards, Chuck

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.


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

Please contact support@xxxxxxxxxxxx for any subscription related questions.
--
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.

Please contact support@xxxxxxxxxxxx for any subscription related questions.


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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

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.