Re: Table in use message

On 27-Oct-2011 09:09 , Raul A. Jager W. wrote:

<<SNIP>> I know that it is not because of the "abnormal shut down",
and I was more carefull in the search for the problem. The message I
get before the (false) "object in use" is CPD32B1

<<SNIP; message details included here as symptom string & text:
msgCPD32B1 rc5 rc05 F/QDBRMVCT x/2C4D T/QDBARCFR x/0937
"Constraint CLIENTE_EN_ADDRES cannot be removed
from file SOLPUB_KSP in library PFI520
for TYPE value *REFCST, RMVCST value &5. ...
reason code: 05 - File is logically damaged.
recovery: 05 - Delete the file and create it again." >>

I did follow that advise, and the newly created file has the same problem.
Can it be a missing PTF?

What was the CL or SQL request that received the error? What messages were logged from the start of that request until this message, and were any other messages following that? IOW, the full joblog of the request is ideal; would also include release info which was omitted. Regardless ...

What the symptom suggests is that, under database recovery, an attempt was made to effect the equivalent of the request to "RMVPFCST FILE(PFI520/SOLPUB_KSP) CST(cliente_en_addres) TYPE(*REFCST)". Usually that activity occurs as part of backing-out a request to "ADDPFCST FILE(PFI520/SOLPUB_KSP) CST(cliente_en_addres) TYPE(*REFCST) ...", as a side-effect of an error that occurred during processing; at least in part, why what errors precede the given, is relevant. This back-out activity is part of "database recovery" processing which is something the equivalent of having run the request under commitment control, and seeing an implicit ROLLBACK.

The message more specifically means that there is a database recovery object already associated with the file, and the pending activity appears to the db recovery processing to be incompatible with or unassociated with the current task\activity running under db recovery. The scenario may not be nearly so simplistic, because constraint activity requires accessing the entire db network [all related files] rather than one file, and referentially that may be tying two existing db networks into one, such that effectively there are two entire db networks tied up in the processing [minimally for locks obtained].

Since the failure, the following request to dump the database recovery objects for the library might confirm there is still pending database recovery activity; i.e. the file is "logically damaged": DMPSYSOBJ QDBDBDROBJ* PFI520 19 D4

Regards, Chuck