Re: QZDASOINIT file lock prevents CLRPFM after v5r2 --> v5r4 upgrade

Chuck,

So the IBM document referenced is wrong/out-of-date?

"What Are the Impacts of Pseudo Closed Cursors?
<snip>
Shared file locks even when all cursors are closed:
As stated above, a pseudo closed cursor does not hold any record locks;
however, it will continue to hold a shared lock on the file. In theory,
the shared lock left on the file should have a minimal effect on other
applications. Some operating system commands and all SQL statements that
require an exclusive lock (DLTF, DROP TABLE, CLRPFM, and so on) will cause
a pseudo closed cursor to be hard closed so that the lock is released.
Each command that wants to force closing of pseudo closed cursors causes an
event to be signaled if a lock conflict occurs. This event causes a
program to run that hard-closes any pseudo closed cursors that hold the
object. For this to function correctly, the maximum file wait time
(WAITFILE) must be set to a value other than *IMMED. In general, a value
of 1 second or greater is sufficient (actual time depends on system
performance)."

The way I read the above, WAITFILE effects CLRPFM.

Charles

On Mon, Feb 9, 2009 at 4:42 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

Charles Wilt wrote:

On Mon, Feb 9, 2009 at 3:40 PM, Elvis Budimlic wrote:

Nice find. That post supports what you said about CLRPFM hard
closing the pseudo closed cursors, provided file's WAITFILE
attribute is set to 1 or greater. Based on that, check the WAITFILE
keyword. If that checks out, then perhaps this isn't a pseudo
closed cursor but an open cursor?

Yes, I've forwarded the info to the other team; recommended checking
WAITFILE and to try the ALCOBJ CONFLICT(*RQSRLS) to see if the lock
goes away.

If the lock doesn't go away that would seem to indicate the problem
is not the result of a pseudo close.

WAITFILE is for open, not for clear. The DFTWAIT of the requesting
job controls the wait time for the clear opeartion [excepting any
defects or special cases]. Since both the held lock and the close
activity take place in another job, the wait-time must suffice for those
other holders to effect their close activity, plus requires that no new
opens of the file [in that same job or another] since the close-event
was initiated [and received by the holding jobs]. Note also there is an
exit program for this event driven close processing which can choose to
prevent\ignore the close request, which can make a pseudo-closed open
act like a normal open.

Thus only "seem to" because... The file may not be allocated using
the request to release the conflict _even if_ it were pseudo-closed, due
to one of: a programmed response to disallow close, insufficient time
allowed in waiting for the close to be effected, the possibility that
another open\close [or another type of allocation] may have been
initiated since the request to close was initiated.

Regards, Chuck
--
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.