releasing sql file locks was Re: Casino switches to AIX

["Steve Richter" <stephenrichter@xxxxxxxxx>]

Thanks Elvis.  When I was working with IBM support on this I did not
get very far with the CLOSQLCSR options. The locks remained and that
is when the tech told me about the ALCOBJ CONFLICT(*RQSRLS) parameter.
It was not that important. I was just being a purest and wanted to be
completely lock free.  The objective being to display the locks, and
if any existed, they would point me to code that was not properly
cleaning up after itself.

-Steve


On Sun, Nov 30, 2008 at 4:18 PM, Elvis Budimlic
<ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Regarding SQL locks, if you're willing to take a performance hit, recompile
> your programs with CLOSQLCSR(*ENDMOD).
>
> Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
> OS/400
> www.centerfieldtechnology.com
>
> -----Original Message-----
> Subject: Re: Casino switches to AIX
>
>
> I am not definitive on this because I am only working on V5R3 .... at
> that release for sure, the i is not easy to run 24/7. I am making a
> lot of code changes to a legacy system, writing and deploying new
> apps. There is a constant battle with system locks.  SQL often retains
> a lock on a file after the query is completed. I have to run the
> ALCOBJ CONFLICT(*RQSRLS) command to free the locks up when replacing
> the file. SQL VIEWS also stay locked for some reason, even after the
> using job is ended. I use SQL VIEWs a lot to get a handle on legacy
> databases. When I replace a view in PRD, the system eventually
> releases the lock on the view being replaced, but it takes about 15
> minutes.  Then of course there are all those locks retained by legacy
> code on data and device files ( and database records ). Would help a
> lot to be able to tell the system to at least temporarily release
> those locks.  The system is way behind on PTFs because we cant afford
> the down time ( and lack of knowledge on how to minimize the time
> needed in restricted state to apply the PTFs ).
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.