Re: QRWTSRVR and QZDASOINT locks on tables? -- MIDRANGE-L

Subject: Re: QRWTSRVR and QZDASOINT locks on tables?
From: Buck Calabro <kc2hiz@xxxxxxxxx>
Date: Fri, 14 Jul 2023 12:20:27 -0400
List-archive: <https://archive.midrange.com/midrange-l/>
List-post: <mailto:midrange-l@lists.midrange.com>
List-subscribe: <https://lists.midrange.com/mailman/listinfo/midrange-l>, <mailto:midrange-l-request@lists.midrange.com?subject=subscribe>
List-unsubscribe: <https://lists.midrange.com/mailman/options/midrange-l>, <mailto:midrange-l-request@lists.midrange.com?subject=unsubscribe>

On 7/14/2023 12:04 PM, K Crawford wrote:

I have a table that has locks on it by QRWTSRVR and QZDASOINT. I know
those are jobs for Prestart job for DRDA and SQL to JDBC and ODBC.

What is the easiest way to get rid of the locks?

If you end them they will come back, I assume due to being prestart jobs
and ODBC jobs. I just need the table for a short time.

The jobs are restarting because they are PJ, but that alone won't lock tables. The locks are coming from some process (web job, end-user using JDBC and that sort of thing) that accesses the table in question.

Stopping the end-user's access is the best way, but sometimes it's left-over SQL pseudo-close that's in play. For those, ALCOBJ *EXCL CONFLICT(*RQSRLS) will hard close the pseudo-closed open data path. Then DLCOBJ and do what you need to do.

https://www.ibm.com/support/pages/pseudo-closed-cursor-faq

As an Amazon Associate we earn from qualifying purchases.

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.