Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
Reason for Deadlocks in IDMS database

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> IDMS/ADSO
View previous topic :: :: View next topic  
Author Message
sandhyalohi

New User


Joined: 24 Jul 2007
Posts: 11
Location: US

PostPosted: Wed Aug 22, 2007 11:51 pm    Post subject: Reason for Deadlocks in IDMS database
Reply with quote

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
Back to top
View user's profile Send private message

dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Aug 23, 2007 12:00 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
sandhyalohi

New User


Joined: 24 Jul 2007
Posts: 11
Location: US

PostPosted: Thu Aug 23, 2007 12:37 am    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
sandhyalohi

New User


Joined: 24 Jul 2007
Posts: 11
Location: US

PostPosted: Sat Aug 25, 2007 1:27 am    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Sat Aug 25, 2007 1:58 am    Post subject:
Reply with quote

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.

Quote:
Firstly due to some implementation all applications on our online region were getting 1473 (max users logged in) message
This might quailfy as what has changed. What was this implementation? I'd suggest that someone look at the "new implementation" code and see if the tables are locked in the "same order" as the transactions that have run successfully for so long.

It may be possible to tune some of the transactions to reduce the exposure.

Your dbas may be able to help balance the number of users and the locking issue.
Back to top
View user's profile Send private message
sandhyalohi

New User


Joined: 24 Jul 2007
Posts: 11
Location: US

PostPosted: Mon Aug 27, 2007 9:07 pm    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Mon Aug 27, 2007 9:40 pm    Post subject:
Reply with quote

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?
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> IDMS/ADSO All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Moving UDB database to Db2 on z/OS Keith Hooley DB2 4 Wed Sep 27, 2017 12:38 am
No new posts IDMS DC027007 T58 TASK:ADS2 PROG:ADSO... gpowell382 IDMS/ADSO 2 Fri Jun 30, 2017 11:52 pm
No new posts Job failing with USER = 4093 REASON C... Pradeepa S ABENDS & Debugging 1 Wed May 17, 2017 3:35 pm
No new posts IMS Database backup info ashek15 IMS DB/DC 14 Wed Nov 16, 2016 5:29 am
No new posts IDMS/DC-COBOL program - SNAP error wh... rakeshsekar1987 IDMS/ADSO 5 Tue Sep 13, 2016 8:28 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us