Re: Table in use message

[CRPence <CRPbottle@xxxxxxxxx>]

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