Re: reorg not finishing

On 17-Oct-2016 07:58 -0500, Jim Oberholtzer wrote:

That's where you pay IBM for software maintenance. The Database or
storage management person you will be put into contact with will
understand the ramifications of killing the job and be able to do
some diagnostics to figure out what's going on. And advise you how
to recover if needed.

My own thought would be you would need the physical (table) and any
logical files (which consists of an index and a view), but also any
independent index and view objects, as well as triggers. In short,
potentially quite a bit.

For edification only: With regard to a Reorganize Physical File Member (RGZPFM) and Allow Cancel (ALWCANCEL) *NO scenario, only the saved database physical file and keyed logical files [including EVI], plus journaled changes since the save made prior to the request; for any save done post-reorg of the data, then the same, but conspicuously journal changes would be moot, and the access paths of the keyed LFs that are invalid would not be saved irrespective the Save Access Paths (ACCPTH) specification. That is, triggers and views are immaterial with regard to the operation of the problematic reorg request.

Note: To effect a proper restore for such a scenario however, requires additionally that the entire DataBase File Network be saved; i.e. if a keyed Join LF (JLF) references two tables or a keyed Multi-Format Logical File (MFLF) references more than the one member being reorganized, the other file.mbrs need also be saved, in the same save request -- and if there are logical references spanning libraries, then the spanned files must first be moved into the same library from which the one save is taken. And then, even after all the care is taken, if the original ordering of files created is not matched to the algorithm to ensure maximum access path sharing [per failure of DBF setup to prevent that], then what eventually is restored will still not be a match to what is on the system from which the save was made.

What is likely better is not either of those options however, as there is a great chance that the issue would not be able to be reproduced even with that doc collection [done properly (see possible complexity above) and as necessary to expose what was an origin], but to contact the software service provider from which presumably a remote support session by IBM might allow for review, as alluded by the opening paragraph quoted above.