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