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



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.