Reason for Deadlocks in IDMS database

sandhyalohi · New User Joined: 24 Jul 2007 Posts: 11 Location: US

Hi,

We have a very stable application that uses IDMS database. But recently, for the past few days our screens are abending with 0329/1229 abend codes which is a deadlock. This is something that has never happened in the past. If its a design issue, we should be having this prob rit from the beginning but this application has been running for the past 25 years. The other interesting point is that all the abends happens at around 4pm in the later part of the day. And there are very few users logged in at this time which means there isn't much contention.

Then what could be the problem.

Sandhya

dick scherrer · Posted: Thu Aug 23, 2007 12:00 am

Hello,

Please review what changes have been implememted recently - not necessarily in the code where the deadlocks occur. Are the deadlock always on the same tables?

What often happens is that new update code is put into existing modules, but the order in which the tables are read for update conflicts with other existing code. When the locks occur "out of order" this deadlock may occur.

Another possibility is that there has been something added/changed in the environment that causes certain transactions to run longer than previously thereby opening the window where deadlocks might occur.

As your application has run successfully for so long, i would be most suspicious of anything done recently.

sandhyalohi · New User Joined: 24 Jul 2007 Posts: 11 Location: US

Hi Dick,

Thanks for the quick reply. There were no software changes recently, I'm trying to find out if there were any changes in the environment.

The deadlocks are not on the same tables but on different records and spread across diff screens. A couple of error messages are as follows

1.GL INTERFACE ERROR - 122 9 =RC, 00000009: CANNOT STORE 402-R
2.CONTACT SUPERVISOR. IDMS ERROR CODE=0329 SEQUENCE #= 0033 B420
3.CONTACT SUPERVISOR. IDMS ERROR CODE=0329 SEQUENCE #= 0033 B420

Apart from possible environment changes, is there anythg we can look into?

Sandhya

sandhyalohi · New User Joined: 24 Jul 2007 Posts: 11 Location: US

Dick,

I need your expertise on this. Let me explain the pattern.

Firstly due to some implementation all applications on our online region were getting 1473 (max users logged in) message.

So our DBAs increased the max limit from 60 to 70. This removed the 1473 error message, BUT we started getting other errors like deadlocks and duplicates which I've explained above.

What I mean to say is does incresing the IDMS MAX ERUS from 60 to 70 got anything to do with the deadlock problem we're facing. Are 70 users on the IDMS database reducing the response time which inturn is causing the deadlock?

Sandhya

dick scherrer · Posted: Sat Aug 25, 2007 1:58 am

Hello,

I'd say that you have "discovered" a locking situation that has been there for a long time and only now is a problem because the interaction(s) between the transactions are taking longer and the "window" where a deadlock might occur is "open" longer.

sandhyalohi · New User Joined: 24 Jul 2007 Posts: 11 Location: US

Thankyou Dick

Here's the interesting part

1. The implementation was backed out when we started getting the error messages. So the only change that remains is increasing the MAX ERUS from 60 to 70.

2. The deadlock messages all come during the later part of the day: between 4 to 5pm EST when there are less users logged in to the application. Evrthg goes fine during the peak hour :-)

Sandhya

dick scherrer · Posted: Mon Aug 27, 2007 9:40 pm

You're welcome,

Sounds like some processes may be left "hanging around" with resources locked.

What happens if you cut back the MAX ERUS?

Is there some newer group of mountain or pacific time zone users that are using the system heavily at that time?

Are there some end-of-day transactions that users only issue later in the day?

Is any batch processing starting around that time that may have an impact?