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



For the archive, the reorg job was paging constantly. We didn't put much memory on this LPAR because it was supposed to be temporary and it's a dev machine.

We were able to end the batch job that was controlling the reorgs. That transferred the access path rebuilds to whatever EDTRBDAP controls and out of this batch job.

At that point it was easy to stop the indexing, delete the logicals, and clear the physical. I then recreated the logicals & indexes over the empty logical file.


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Maassel, John R.
Sent: Wednesday, October 19, 2016 4:19 PM
To: Midrange Systems Technical Discussion
Subject: [EXTERNAL] RE: reorg not finishing

The reorg job is apparently still running, but slowly. I think we're going to involve the performance team as soon as I can figure out how to send the performance data to them.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Wednesday, October 19, 2016 4:16 PM
To: 'Midrange Systems Technical Discussion'
Subject: [EXTERNAL] Re: reorg not finishing

John,

I've been following this thread.
I was curious if you got an update from IBM and/or how you made out with the reorg.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Maassel, John R.
Sent: Monday, October 17, 2016 11:17 AM
To: Midrange Systems Technical Discussion
Subject: RE: [EXTERNAL] Re: reorg not finishing

Thanks.

I've opened a PMR to see if we can figure out what the damage will be.

Luckily this is a development LPAR that I just refreshed last month, so no problems with production jobs' record locks or data loss.

I will likely just compile an empty set of files rather than restoring the 772 GB physical file after we get it back.


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, October 17, 2016 10:42 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: [EXTERNAL] Re: reorg not finishing

On 17-Oct-2016 09:29 -0500, Richard Reeve wrote:
On Oct 17, 2016 8:46 AM, "Maassel, John R." wrote:
[...] Second, if we did, which objects would we have to restore? The
logical file, for sure, but what of the physical and the other
indexes?

I would delete the physical (must first delete all depended on
logicals and indexes) then restore the physical and all logicals.


Or just the SQL request:
DROP TABLE The_PF CASCADE /* where CASCADE is the default */

But then be sure to review what was actually deleted, so as to know what must be restored.

However for the given situation, I would suggest probably best to
*not* restore. Instead, to create the objects again/anew, from source, and then copy the non-deleted-record data from the old file into the new file; i.e. effectively effect what the reorganize request should have done. That would eliminate any potential issues of origin involving either the objects or the data as it resided in the existing dataspace; both on backup media and on DASD. Obviously not a prudent nor likely even acceptable choice for the current situation, wherein I presume the intention is to get the data accessible vs necessarily determining the origin of the issue and anything possibly preventive. But as I alluded in prior replies, the data may be available as already-reorganized [something that probably could be confirmed easily enough; maybe just Display File Description (DSPFD) to show that there are no deleted records in the member that was reorganized -- and like DSPPFM, the access to the file.mbr implies the data-reorg is completed, despite the access-
path rebuild phase is blocked by the (presumed to be only) one problematic LF index].

--
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: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.midrange.com_mailman_listinfo_midrange-2Dl&d=DQIF-g&c=3crv0V5Gxwbo5hXTsiQI6g&r=PkbfvkKxtcDeNvEOH5BjJL4QM0EQmj0cLL71lzl405I&m=BwaGLL74yW8JCZcG3MHESFfxoVS_JxjlZm3fvcE8yJg&s=C4NJirSENdKV-_p0XtGvMEa6i1m2v8u3dv9EM2WSw8Q&e=
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at https://urldefense.proofpoint.com/v2/url?u=http-3A__archive.midrange.com_midrange-2Dl&d=DQIF-g&c=3crv0V5Gxwbo5hXTsiQI6g&r=PkbfvkKxtcDeNvEOH5BjJL4QM0EQmj0cLL71lzl405I&m=BwaGLL74yW8JCZcG3MHESFfxoVS_JxjlZm3fvcE8yJg&s=7gjZ5BbW1jOicvxK2YOE7gXLI3Xz3RgqRxUA9IIfrSs&e= .

Please contact support@xxxxxxxxxxxx for any subscription related questions.
________________________________

Notice from Bob Evans Farms: This e-mail message, including any attachments, may contain confidential information that is intended only for the person or entity to which it is addressed. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments.
--
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: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.midrange.com_mailman_listinfo_midrange-2Dl&d=DQICAg&c=3crv0V5Gxwbo5hXTsiQI6g&r=PkbfvkKxtcDeNvEOH5BjJL4QM0EQmj0cLL71lzl405I&m=wMBn1KCeOoVjFFZ2naBaPrMM-HrKfEL6XLFsrrSobYI&s=0kVAz3GbSV2Eydv69kQ-qIO_i0Ov7zS5WEeTXex1t44&e=
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at https://urldefense.proofpoint.com/v2/url?u=http-3A__archive.midrange.com_midrange-2Dl&d=DQICAg&c=3crv0V5Gxwbo5hXTsiQI6g&r=PkbfvkKxtcDeNvEOH5BjJL4QM0EQmj0cLL71lzl405I&m=wMBn1KCeOoVjFFZ2naBaPrMM-HrKfEL6XLFsrrSobYI&s=tyDHRLzc5b4xqjB89nT6pSI8kOW0UQCFbAAnKZzCCho&e= .

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.