Re: Table in use message

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