Re: Table in use message

[CRPence <CRPbottle@xxxxxxxxx>]

  I tried to be clear... There is no way [that I know] for a user to 
"lock" the database files to prevent locks in other jobs.  The attempt 
to "ALCOBJ *EXCL" is insufficient to prevent conflicts.  That "allocate 
object" request will only obtain a *SHRRD lock on the *FILE and the *MEM 
objects; the *EXCL lock is obtained only on the data.  Because the locks 
on the file and member are only read-locks [and thus allow sharing], any 
other job could hold a lock.  Any lock held by another job is 
in-conflict with the *EXCL lock that must be obtained by the database 
[for the add constraint activity] on the *FILE and the *MEM objects, and 
[I presume also] the data.  So even after a successful attempt to ALCOBJ 
((thelib/theparent *FILE *EXCL *first)), there may be other lock holders 
presented on the output from a request to WRKOBJLCK thelib/theparent 
*file MBR(*ALL)

Regards, Chuck

On 28-Oct-2011 06:28 , Raul A. Jager W. wrote:
> 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:
> > <<SNIP>>
> > 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.  <<SNIP>>