Re: Table in use message

On 28-Oct-2011 13:52 , Raul A. Jager W. wrote:

Can I allocate the library?

The library would be just as difficult to lock for exclusive use in the job requesting the ALTER; i.e. ALCOBJ can not obtain an exclusive lock on the library object either. Although rather than allowing only certain components of the composite being locked exclusively, as occurs with database *FILE objects, the lock level *EXCL is simply disallowed in conjunction with the library object type *LIB. An attempt to "ALCOBJ ((aLib *LIB *EXCL)) will fail with message CPF0979 "Lock *EXCL not valid for object type *LIB.".

or should I go to the console and use "ENDSBS *ALL"?

While restricted state would prevent users and other user [batch] jobs from accessing the file, that would not prevent some other possible origins. System jobs are still active in restricted state. For example index rebuild activity which occurs in system jobs continues even while in restricted state. An ACLOBJ to exclusively allocate the data of the file would prevent access path rebuild activity however. So by ensuring each of restricted state, no entries on WRKOBJLCK MBR(*NONE) nor MBR(*ALL), and ALCOBJ ((thelib/theparent *FILE *EXCL *FIRST)), then there should be nothing [that I can think of] that should conflict. That would be extreme measures, but would be significant support for the idea that the origin of the problem is a defect rather than having an origin in transitory locks for which the allocation error might be legitimate.

I was under the impression however, that the issue had already been pursued under a service call... though IIRC, the status of that may have been the typical "apply PTFs, then call if the problem persists."

CRPence wrote:

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)