Re: Table in use message

[Jim Oberholtzer <midrangel@xxxxxxxxxx>]

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