Re: Table in use message

A restricted state would certainly work but it seems a bit draconian to me. If the real problem is jobs that use the objects in question need to stop using them. Using a restricted state to solve the problem feels like the wrong hammer for this nail. Rather why not write a program to find all the jobs that are accessing the object and end them, and then stop the applications that use them temporarily ?

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 10/28/2011 3:52 PM, Raul A. Jager W. wrote:

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

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

--