Re: Table in use message

Locks are transitory, so "wrong" may be a bit strong. I have often heard similar claims; proven incorrect. Consider that removing all existing locks is not preventive to new locks, and seeing no locks after an in-use message is not evidence that a conflicting lock was not being held by another thread\job at the moment of the diagnosed allocation failure.

Was there a delay in processing the request, a delay reflecting the DFTWAIT() for the job? I do not recall if the DBF network locking for files other than the one named on the FILE() was defined with an effective no-wait\*immed, but if there is an apparent delay, then increasing the default wait for the job to a very large number and then issuing a WRKJOB OPTION(*JOBLCK) against the job while the request is apparently delayed to see what lock(s) appear as status WAIT could provide an easy diagnosis. Also some messages were enhanced to name the job which held the conflicting lock; doubtful, but possibly the CPF3202 was... though if not, and if job was placed in debug with a breakpoint established on the receive-message processing, the message which is then diagnosed instead as CPF3202 would remain in the job message queue, and that message might have the additional data.

That said, there could just as easily be a defect for the CPF3202 being issued when indeed there are no locks held in conflict, or for the wrong file in the dbfile network being diagnosed as having locks. And for the inability to lock the files exclusive [ALCOBJ can lock members and files only with *SHRRD], and no external interface to lock the DBF network [other than SAVLIB\SAVOBJ with all relations included on one save request; i.e. all in same library], tracking down the conflicting lock and holder if they exist, could be troublesome. So if indeed there should be no locks, then probably contacting your service provider at this point is the most appropriate plan of action.

Regards, Chuck

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

The fact that the messages are contradictory makes the problem hard
to solve. The first message is wrong, because I chased out all
users, shut down tcp servers and canceled everything in WRKOBJLCK

Sorry, I misspelled SQL.

CRPence wrote:

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

Joblog (I added the message number after the ---->)

3 > ADDPFCST FILE(PFI520/SOLPUB_KSP) TYPE(*REFCST) KEY(CLIENTE)
CST(cliente_en_addres) PRNFILE(B/ADDRES_NCL) PRNKEY(NCLIE)
DLTRULE(*RESTRICT) UPDRULE(*RESTRICT)
CPF3202 Está utilizándose el archivo ADDRES_NCL de la biblioteca B.
CPD32B1 La restricción no puede eliminarse del archivo SOLPUB_KSP.
CPI32B1 Se ha eliminado la restricción.
CPF32B4 Recuperación satisfactoria de restricción de archivo físico.
CPF32B0 La restricción no puede a¦adirse al archivo SOLPUB_KSP.

I am not sure what [¿probable defect?] has the msgCPD32B1 RC05
being logged, but the outcome contradicts the confusing implication
of that diagnostic condition being logged. That is, the later
messages show the failed add-constraint activity was successfully
backed-out, and finally that the constraint was not added.
<<SNIP>>