Re: DASD upgrade and start Mirroring

[CRPence <crp@xxxxxxxxxxxxxxxxxxxx>]

  Object damage is discussed in the Appendix I of the Redbooks 
publication SG24-8253-00 or its -01 draft version:
  http://www.redbooks.ibm.com/abstracts/SG248253.html?Open

  Although RCLSTG can not correct 'physical' damage to any object, the 
processing by the request may delete some damaged objects, which in 
effect may be the required resolution to a problem -- thus appearing to 
correct the problem, even though it did not [because it can not] ever 
correct any physical damage.  However objects that can be corrected in 
that manner are usually corrected instead by the run-time feature that 
uses the object, and thus would not require a reclaim to effect that; 
e.g. queues for features that are not expected to survive a crash, 
should be deleted by the feature upon first touch after the IPL from a 
crash, and a message logged of its impact -- like cpf32A1 does

  Reclaim storage _notifies_ of existing damage; i.e. after a reclaim, 
there should be a CPF81## [and CPF82## ?; I just review both] message 
for each damaged object for which the operator then should optionally 
perform [object & data] recovery, by restoring or creating a good 
object, and then copying the data from the damaged object to the new 
object.  After each reclaim issue DSPLOG QHST (( span reclaim )) 
MSGID(CPF8100 CPF8200) to review which objects need to be deleted and 
perhaps recovered depending on what object and what data.

  Logical damage is more likely to be corrected by a reclaim; i.e. 
where the object is logically incorrect, in a manner whereby some 
specific actions [typically only by design] has some intention of 
resolving that type of logical error.  For example, when a constraint 
definition does not exist on the dataspace, but the database directory 
claims one does, the database directory cleanup will remove that bogus 
constraint definition from the file.

Regards, Chuck
-- All comments provided "as is" with no warranties of any kind 
whatsoever and may not represent positions, strategies, nor views of my 
employer

Turnidge, Dave wrote:
> Sure glad I used the word "may"... However, some times these (broadly
> speaking) "kinds" of problems are corrected by RCLSTG - and sometimes
> the message includes that as a recommendation. But, this is a good
> learning experience!!
>
> Where would us lowly users find this information on our own? Is it
> available to us anywhere?