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

Charles Wilt wrote:

<<SNIP>> I know the system will sometime "pseudo-close" open data
paths. But my understanding is that if an ODP is "pseudo-closed",
any request for an incompatible lock by another process, ie. the
CLRPFM, would cause the ODP to be fully closed and locks released.
Thus, the CLRPFM shouldn't fail from a "pseudo-close".

Is my understanding correct?

Regardless, the question being asked is what changed, as we started
having a problem the day after the upgrade and the Web Method
process has not been changed. So I'm wondering if anybody knows or
has any thoughts about
--When the "pseudo-close" functionality was added.
--System values the might control the use of "pseudo-close" --changes between v5r2 and v5r4 that might be causing this --things to check, like MAXUSE() on the pre-start job entry
that could have been reset by the upgrade

Others?

Links to IBM documentation gladly accepted.

With more performance enhancements, come more incidents of pseudo-closed cursors for the SQL. That is because there is a significant saving of CPU, temporary storage\addresses, and real time, by reducing full opens. With each release there were more enhancements which were achieved by leaving the file open; i.e. the members will remain open in more situations than in the past releases, enabling better performance for those queries. I believe pseudo-closed was originally only a static query feature, but the /extended dynamic/ SQL feature extends dynamic to make the statements pseudo-static. AFaIK even fully dynamic statements may effect pseudo-closed, because repeats of the /same/ statement are the same query, even if they were first extended to be performed with parameter markers [so only /same/ in the re-formed query]; so just as repeats of static statements, repeated dynamic statements are capable of reusing an ODP to the active data.

Regards, Chuck