Re: Can't get rid of a damaged logical file

Chuck,

I posted additional information on Oct 12 with the fixing PTF #'s and applicable APAR #'s.
 
Neil Palmer, Waterloo, Ontario, Canada


(This account not monitored for personal mail,
remove the last two letters before @ for that)


________________________________
From: CRPence <CRPbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Sunday, October 13, 2013 3:20:42 PM
Subject: Re: Can't get rid of a damaged logical file


On 12 Oct 2013 09:25, Neil Palmer wrote:

I have a damaged logical file in a customer data library that I
can't  get rid of.

  That issue is already resolved by a PTF.  Some other comments,
including about some additional /recovery/ actions for this specific
[type of] incident, and as general edification [for the archives] are
offered.

Trying to DLTF I get:

Message ID . . . . . . :  MCH1668  <<SNIP>>
Message . . . . : System object BLCUSTL9 partially damaged.
  Internal dump ID 01006774. Error class 2, device number X'0001'.
Cause . . . . . : This partially damaged system object BLCUSTL9 has
an error class 2 and a device number X'0001'. Error class indicates
how damage was detected: 0002-logically invalid device sector;

Message ID . . . . . . :  CPF8160  <<SNIP>>
Message . . . . : Partial damage on BLCUSTL9 type X'1901'.
Cause . . . . . : Object BLCUSTL9 type X'1901' is damaged and may no
longer be usable. The owner of the object is FRED. No owner means the
object is a temporary object. The VLOG dump identifier is 01006772.

  Those effective print-screens of the F1=Help is missing necessary
/context/ for the diagnosed conditions; i.e. while it exposes the
condition, it does not expose anything about the circumstances in which
the condition was diagnosed [other than having noted /DLTF/ was the
prior Request Message].  The full output from F6=Print after F1=Help, or
the details copied from a spooled joblog taken with LOG(4 0 *SECLVL) is
required to see that context along with the condition... Or less
desirable, a second copy\paste could be taken from the additional panel
presented with F9=Display message details after [the copy\past taken
from the first panel presented with] F1=Help.

  The APAR included some context, as expressed in the following symptom
strings using the system keyword string convention [which the APARs did
not include :-( per typical, although they did include one proper
symptom keyword in the title\abstract "OSP-MSGMCH1668 CPF8160 DLTF does
not deleted damaged file", even if the non-symptom-keyword text was
effective ChEnglish]:
    msgMCH1668 F/setspaceptrfromptr T/QDMROUTE x/019B
    msgMCH1668 F/setspaceptrfromptr T/QDMDMGNT x/0004
    msgCPF8160 F/QRCPDMGN x/00C6 T/requester rcX1901

  The /context/ of the first exception reveals that the Data Management
router was first to encounter the damage, and that the component failed
to /pass the request/ on to the database file object-owner\processor,
thus the Database feature was never given the chance to be tolerant of
damage during its deletion request... because it was never even asked to
effect the deletion.  Thus, FWiW, the /correction/ to the defect was
apparently to ensure that the CPP for DLTF, in conjunction with its
interface to the Common Data Management feature, to /ignore/ the damage
to a Database *FILE object, and pass the delete request to the QDBDLTFI
program; that fix appears to come from the Librarian feature [a program
with the prefix QLI].

Could not DLTLIB or CLRLIB or move the damaged file to another
library, or rename the library with the damaged object either
(MCH1668 & CPF8160 again).

  Damage is not well tolerated, except by delete.  By design, the
database Delete File processing is supposed to be /tolerant/ of damage.
  Note that because of interrelationships, i.e. the full DBF network and
composites, /tolerance/ is not necessarily a directly positive effect;
i.e. tolerating damage to delete a PF over which a LF is defined, causes
the LF to suffer [a form of] logical damage.  Thus the action of having
deleting the object may have consequences that might not be revealed
until some other processing.  For a Database File Network, when a file
in that network has been deleted with damage tolerated, the _best
recovery_ would have the entire network deleted and re-created; the
network may not be entirely identifiable either because of not having
extracted that information before deletion, or as an effect of the
damage preventing any extraction of that information.  Note: Another
side effect of the tolerance, is that the System Database
Cross-Reference (*DBXREF) may eventually encounter an inconsistency when
a related object in the network is processed [in a /generic/ function
such as delete, rename, grant, move, etc. or in a database operation
such as remove trigger, etc.].

I tried to restore the library from a backup and get:

Message ID . . . . . . :  CPF3819 <<SNIP>>
Message . . . . : Damaged object FILE BLCUSTL9 not restored.

  Restore is intolerant of damage; as is save.  The save\restore
feature will not even tell the database save\restore about a file object
that is damaged... removing the object from the list of those to be
processed by the database.  Again, the /context/ of the message would
reveal that effect.

  The only recovery for [full and partial] damage is deletion of the
damaged object.  Typically that would be followed with some recovery
which generally is restore of the object [and data] or re-create of the
object [and optional restore of the data].

Does anyone have an ideas as to how I can get rid of this damaged
object - or is it time for a RCLSTG ?

  A Reclaim Storage (RCLSTG) can *not* fix partial or full damage!
That feature has a /Damage Notification/ for all permanent objects, such
that every damaged object will be notified by a message in the ranges of
either [¿others?] CPF8100 and CPF8200; i.e. a list of all objects that
require deletion will be identified by messages visible in DSPLOG QHST
afterward... but *not corrected* in any way [unless reclaim is defined
to delete whatever is the object or object-type].  If there is one such
object damaged, then depending on the origin of that damage, there may
be other damaged objects, such that the notification may be worthwhile.
  I intend in my response, to be sure to reinforce the truth that the
reclaim does not /fix/ physical _damage_ conditions, regardless of what
others might [have implied in the past or] imply.

  Again, only deleting the object is a recovery... However... /partial/
damage implies some /data/ [portion of the object] may still be
available; recoverable from disk.  In the case of a *FILE object, which
is a /space/ object, that is unlikely [though I will not try to explain
why, other than to say the /space/ is the data]; the request to dump the
/space/ via the SPACE() parameter of the DMPSYSOBJ command could be
utilized to reveal what is available.

  As alluded earlier, the Reclaim of the *DBXREF may be worthwhile as a
reaction to the recovery-by-deletion of the database file.  If there is
likely to be other damage, e.g. due to a partial disk recovery or lost
cache, then the RCLSTG SELECT(*ALL) should be done [probably best with
OMIT(*DBXREF)] followed up with deleting any other damaged objects [as
notified by that request], and finally just RCLSTG SELECT(*DBXREF) to
refresh the database cross-reference information from only undamaged
objects.

  Of course damage that exists but is not yet detected, with an origin
from such catastrophic incidents as lost disk or cache, could continue
to be exposed over the long-term, and thus continual repeated impacts
are possible... and is why a scratch reload of the system is generally
the better tact as recovery from losses of potentially large amounts of
random storage.