RE: Seize deadlock: threads, fair seizes, file extends; PRTLCKRPT; IBM confidential

Two comments from IBM:
<comment1>
Can you get us a DSPFD for all of the files referenced in the SQL
statement:
select count(*) as countDiff from CRMSAT.F55QUOTE left join
AMSDTA.F4211LA on AMSDTA.F4211LA.SDKCOO=QUCMPY and
AMSDTA.F4211LA.SDDCTO=QUTYPE and AMSDTA.F4211LA.SDDOCO=QUID and
AMSDTA.F4211LA.SDNXTR <> ? left join CRMSAT.F55QURV on JOBID=QUJBID and
REVISN=(select max(REVISN) from crmsat.f55qurv where JOBID=QUJBID and
~~~ more ~~~
DSPFD FILE(CRMSAT/F55QUOTE) OUTPUT(*PRINT)
DSPFD FILE(AMSDTA/F4211LA) OUTPUT(*PRINT)
DSPFD FILE(CRMSAT/F55QURV) OUTPUT(*PRINT)
We are thinking one of those must be an SQL view that has a UDF within
it. Either that or we didn't get the right SQL statement.
[IBM] Development says that these issues are extremely rare and timing
sensitive. It is not easy to get into these situations. If you get
into a position where this does happen more than once, we can look at
having you change the PF to: CHGPF ALLOCATE(*YES) for how much storage
you think you will need for the immediate future. That means the file
won't need to be extended further, but it does suck up the space today
that will be needed for the future.
Development says that if we can find a way to change the design to get
around this issue, it will be tested at a future release. Then if it
works well there for a significant period of testing, then they can
consider moving this back to previous releases like R540. But this
would not be a quick process, as this code is used often and any change
could have unintended consequences.
</comment1>
<comment2>
I need to amend one thing: Development says that these issues are
extremely rare and timing
sensitive. It is not easy to get into these situations. If you get
into a position where this does happen more than once, we can look at
having you change the PF to: CHGPF FILE(LIB/FILE) SIZE(row-to-allocate)
ALLOCATE(*YES)
for how much storage you think you will need for the immediate future.
That means the file
won't need to be extended further, but it does suck up the space today
that will be needed for the future.
Where the size(rows-to-allocate) is the number of rows you want
to allocate to the file. For this change to take affect you either need
to issue RGZPFM
on that file or clear and restore. Otherwise, the next time the
system needs to extend the file it will allocate the space set
on the CHGPF.
</comment2>