Re: Table in use message

["Raul A. Jager W." <raul@xxxxxxxxxx>]

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