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
midrange.com
