First, set the STALL interval for the DMLO task to something specific. For example this will set it to 30 seconds:
DCMT VARY TASK DMLO STALL 30
(Note, in the SYSTEM GENERATION definition, this parameter is called the INACTIVE INTERVAL.)
Now, using DML/O, READY your database area in SHARED UPDATE usage-mode and then OBTAIN and MODIFY one particular record occurrence. Leave that session open.
Then, in a second DML/O session, do the same, but this time only OBTAIN the same record occurrence.
The problem in forcing a stall on a database resource is that at this point, it is likely that you will encounter a DC001003 stall on the PTERM of the first session before you get the database stall.
To avoid this, enter any command in the first DML/O session at least once every 30 seconds while the second session is being created. The command can be the simple OBTAIN on the same record – it doesn’t matter. As long as you don’t FINISH the session, the exclusive lock which is what you need to get the stall will still be held.
Eventually, the second session will get the stall. Message such as these will appear on the dc-log (OLP):
IDMS DC001007 V65 T232 TASK:DMLO PROG:USDTPIF2 WAITING FOR LTXNLOCK 00000008 0124FF01
IDMS DC001008 V65 T232 TXNID:15899 PROG:USDMAIN0 SUBSCHEMA:EMPSS01 MODE:S
IDMS DC001009 V65 T232 TSKID:229 TASK:DMLO PROG:USDTPIF2 HOLDS LTXNLOCK 00000008 0124FF01
IDMS DC001010 V65 T232 TXNID:15894 PROG:USDMAIN0 SUBSCHEMA:EMPSS01 MODE:X
IDMS DC001003 V65 T232 TASK:DMLO PROG:USDTPIF2 STALLED WAITING FOR LTXNLOCK 00000008 0124FF01
IDMS DC027007 V65 T232 TASK:DMLO PROG:USDTPIF2 ABENDED WITH CODE D002
The interval you use can be anything, but you need to strike a balance between it being long enough to allow you to issue the DML/O commands and short enough so that you don’t have to wait too long. 30 seconds should be fine.