Re: Table in use message

On 28-Oct-2011 06:32 , Raul A. Jager W. wrote:

I will try this. It is not so easy, because the file has many users
24 x 7.

That statement implies a greater likelihood that either transitory locks or other non-data locks on the parent file could be the origin. Unless there is a means to ensure no users or [batch] jobs do not in any way "touch" the parent file, then the opportunity exists for a conflicting lock to be established by some another activity.

Even so, given both proper care was taken to remove existing holders of locks listed in WRKOBJLCK thelib/theparent *file MBR(*NONE) and having ensured beyond much doubt that no new lock holders would be added since, plus that one of the diagnostics logged implied a condition of "logically damaged", the scenario very well may be the result of a defect. Note too, that the outcome for the equivalent SQL request [irrespective of isolation\commit level in effect] should have been a -913 [sql0913], even if some of the logged diagnostic messages would have been the same as those issued for the ADDPFCST... assuming the origin is a legitimate case of the parent being unavailable to the requester of the ALTER to add the referential constraint.

Regards, Chuck