RE: Postmortem on QZDASOINIT jobs

Charles Wilt,
The issue you discussed might (slim chance) stem from what we
encountered on our V5R4M5 system with QZDASOINIT jobs.
IBM created this APAR :
http://www-912.ibm.com/n_dir/nas4apar.nsf/ALLAPARS/MA42187

Abstract
OSP-DB-OTHER-WAIT JOB WAIT IN UDF

Error Description
the secondary that the primary is waiting for a response from
... the UDF being executed from the primary (its in #dbshder).
Problem Conclusion
When a UDF is running and attempts to seize an address already
seized in by the primary thread, allow the seize instead of
making it a fairseize waiter.

++++++++++++++++++++++++++++++++++++++
The APAR is based on our Service request number 82879 370 000
Title QZDASOINIT seize on file did not release
. . . the flushallseize job is trying to extend a file
and cannot because of job . . .
The issue is a seize deadlock:

- Job A tries to extend file File and waits behind readers and "fair
seize" kicks in

- Job B is reading file File, has low seize. It fires a UDF
- Job B's secondary thread is running and needs to seize file File, due
to "fair seize", it waits.

Job B is generally cancellable, there's a "wait time out" message that
wakes it up looking for cancellation