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

Charles Wilt wrote:

<<SNIP>>

However, I'm not sure that proves anything. I think it's possible that things are difference with a pseduo-closed file. Otherwise, the document in question hasn't just confused DFTWAIT and WAITFILE, but the whole section makes no sense.

The point of the section is that you have to allow the system some time to hard close the pseudo-closed file; thus make sure WAITFILE is not *IMMED but is at least 1. On the other hand, DFTWAIT doesn't have *IMMED or 0 available as a valid, it is always at least 1. So if DFTWAIT is the controlling factor, then the whole section is pointless.

So, based on your experience, do you think pseduo-closed files are a special case, or is that whole section of the document is a pipe dream?

I tried to test CLRPFM and pseudo-closed cursors myself, however even with the file set to WAITFILE(*IMMED) and the job set to DFTWAIT(1), the CLRPFM didn't fail.

Try the ALCOBJ WAIT(*IMMED) CONFLICT(*RQSRLS). Presumably the reference to the /immediate/ or no-wait, alludes to that case which enables an effective default wait of zero.

My recollection is that WAITFILE value has no relevance for CLRPFM, and absolute confidence that if WAITFILE actually had any relevance, then at least never from an OVRDBF due to data management handling for the request.

My guess is that two or more parameters were effectively /confused/ for one another by the writer. For example that the WAITFILE help text from CRTPF or the WAIT from ALCOBJ, was researched as source to provide the commentary about the /wait time/. Thus that DFTWAIT is the actual control [or WAIT in ALCOBJ, which overrides job DFTWAIT], and so the document _incorrectly_ implies that *IMMED is an available special value. Of course as an /internal/ document, the reference, review, and any correction to that text has to be done by someone in IBM [support in Rochester] with access to that KB database... and this conversation is all that exists to /correct/ the archive here.

"For this to function correctly, the minimum wait time
used must be set to a value other than *IMMED. The
time to wait is specified in the WAIT() parameter of
ALCOBJ, or in other operations is derived from the
DFTWAIT() parameter [minimum is currently one] of the
job. In general, a value of one second or greater is
sufficient. The actual time required depends on the
overall system performance; sufficient time must be
allowed for all lock holders to effect their close."

Regards, Chuck