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

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