Another post from the "IDMS Help Desk" series. This post contains a question from an IDMS Application Developer / Support person - but has two distinct threads to it: 1) DBA issues about the best way to get the "lock" related information for debugging purposes, and 2) Application coding, design and ADS run-time behaviour. This thread ran for over a week and there were a great many post from both the OP (Original Poster) and Responder/Repliers - with the two discussion thread truly "mashed". I have done my best to preserve sequence and intent while separating out the DBA and application issues - enjoy:
-----Original Message-----
From: IDMS User
To: IDMS Help Desk
Subject: Access to Lock Data in PMRM
I have been looking at a bunch of DEADLOCK and STALL issues in some CAS code. I have a couple programs that are stalling quite often. One in particular appears, based on the last command displayed in the Log (using ADS TRACE), that the next command that SHOULD be executed is a OBTAIN OWNER - which SHOULD get the PURCHASE-ORDER (owner of an activity junction record).
I am assuming that another program is locking the record (and it seems like this data stays locked for quite a long time - stalls leading to aborts).
The client does not have PMRM which I would think would help identify what program might be holding onto the record the stall program is not getting (the example below is from a presentation on dealing with Deadlocks). Is there some other way to see this data (which programs are holding a lock) - be it the Network (IDMSNWKA) or some kind of journal report?
From a presentation on Deadlocks: (My apologies to the author for not knowing who wrote it):
PMRM - Active User Task Detail PM-R16.0 TECHDC99 Computer Associates Intl. V545 04.112
CMD--> 02 Active User Task Detail
Task Task Current Waited_On Dbkey
Number Code Program Dbkey Holder
109414 ADS2 DBCRUPD 680037: 13 VL500006
109887 ADS2 DBCRUPD 680021: 13 VL500035
109923 ADS2 DBCRUPD 680022: 1 VL500025
109917 ADS2 DBCRUPD 680039: 13 VL500003
109797 ADS2 DBCRUPD 680019: 11 VL500018
109700 ADS2 DBCRUPD
109827 ADS2 DBCRUPD 680047: 1 VL500024
What I am trying to determine is:
Which program is holding onto the records and causing a stall in another program?
Since I have been able to execute a TRACE while a STALL is happening and see the TRACE stop right before an OBTAIN OWNER, I figured if I can determine which program is holding onto (locking) the record the Stalled program needs, then I can check out THAT program to find out why it won't let go.
Thank you
IDMS User – Application Developer / Application Support
No answer is provided in the attachment - which includes the original question - but two extended discussions are provided which may prove to be of interest? Hoping Somebody Will Enjoy This - cheers - GaryC