Re: Table in use message

I have already tried ALCOBJ *EXCL, that is why I think the "file in use" is caused by something else, maybe the CPD32B1 (object has damage). (The "damage" may not be real)

I contacted our support, they will install the latest PTF as the first step.

Tank you, I will comment on the results.
___________________________________________________________________________________________
CRPence wrote:

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