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

Charles Wilt wrote:

One other thing, the internal document is the only one say WAITFILE is a factor. This one:

http://www-912.ibm.com/s_dir/slkbase.NSF/96919068949082bf8625680b0002036e/4c7e1e2f94136bdd86256c6200577243?OpenDocument

Also discusses WAITFILE(*IMMED) and pseduo-close,
but doesn't mention CLRPFM.

Presumably what was meant was to suggest the previously discussed "internal document is _not_ the only one to suggest that WAITFILE is a factor."?

My assumption is that the [above linked] document is somewhat deceptive for how generic its implication about a very specific scenario, yet that it is technically accurate. That is, the WAITFILE is used instead of DFTWAIT, for the wait time on open requests. Again, the WAITFILE should apply _only_ to /open/ activity; i.e. where the route through data management is to open a member:
QDMROUTE -> QDMCOPEN -> QDBOPEN

At the moment I can only think of that special case and the other special case of DELETE FROM with no WHERE clause [which when it attempts to perform an effective CLRPFM if functionally equivalent\allowed] whereby the event is signaled in an attempt to resolve a conflicting lock; the operating assumption, that the conflicting lock may be held by a pseudo-close cursor.

The document refers to a case of SELECT DISTINCT failing for a special isolation _implementation_ whereby a *SHRNUP lock is used instead of actual row locks. The given /v4r5 equivalence/ comment is most likely the original intent of the document, and that the specific commitment control level issue was added to describe an additional scenario [which would be resolved for files created with the new default, or with files changed with the given CHGxF invocations].

Regards, Chuck