Dataset Processing (CREATE, DELETE, EXTEND) should get a timelimit

We had an unimportant pageset, which was defined with ERASE YES. Due to the long timeframe of writing x'00' (ERASE YES) on the tracks of this pageset, another dataset processing (EXTEND) of a very important pageset waits and is timed out. This timing out of the important pageset has more follow-on consequences, like disabling IAG2 etc., which is critical in our installation.

Therefore we want that DSM times out pageset/dataset processing (CREATE, DELETE, EXTEND) after timeframe controlled by IRLMRWT and write at least a message about this timeout with the holder and the waiter.  Today only 

DSNP014I -DB4P DSNPXTN1 - IRLM MANUAL LOCK REQUEST 659

FAILED FOR VDX.DSNDBC.GIBELE01.GIBEL001.J0001.A174.

RC=8, SC=20000000,

CONNECTION-ID=SERVER, CORRELATION-ID=db2jcc_appli,

LUW-ID=GAFC9A20.PF40.E0D09207D224=132388 

and

DSNT376I -DB1P PLAN=BCT..... WITH 396

CORRELATION-ID=014.DMASFP01

CONNECTION-ID=DB1P

LUW-ID=DEDATEV1.LUPDDB1P.E0D091FBE4A3

THREAD-INFO=SYSOPR:*:*:*:*:* :*:*

IS TIMED OUT. ONE HOLDER OF THE RESOURCE IS PLAN=

WITH

CORRELATION-ID=014.DMASFP01

CONNECTION-ID=DB6P

LUW-ID=DEDATEV1.LUPDDB6P.E0D091E8B64E

THREAD-INFO=SYSOPR:*:*:*:*:* :*:*

ON MEMBER DB6P

REQUESTER USING TIMEOUT VALUE=30 FROM IRLMRWT

HOLDER USING TIMEOUT VALUE=30 FROM IRLMRWT

are issued, which do not help much.

Ideally DSM cancels the underlying tasks/jobs (after a timeframe controlled by IRLMRWT and a new zPARM as multiplier) which do such long dataset processing: 

In our case the culprit job was a LOAD REPLACE which did this ERASE YES processing.

This processing is probably always outside of DB2 so only a cancel can clairfy the situation.