ca.portal.admin

Re: Dead locking Information

Discussion created by ca.portal.admin on Oct 17, 2005
Bill,
Most deadlocks these days are caused by ADSO retrieval locking which
came into existence with release 12.0, around 1993 and has been causing
grief ever since. Because CA thought they were fixing a bug and not
adding a new feature, they did not publish the change, at first. I've
attached some information from the current ADS manual about it and also
a program I wrote to extract all dialogs from the dictionaary with the
retrieval locking indicator and whether the dialog is update or
retrieval only. It's very crude and puts the records into a file so they
can be sorted or downloaded to a spreadsheet. The list will also
indicate whether the dialog links or invokes another dialog. The first
thing you can do, is turn retrieval locks off for all dialogs which are
retrieval only and don't link to other dialogs. Also, monitor the log
for deadlocks because often it is only a few dialogs causing the
problem. Look for errors of ""0361"" or ""0306"". Another thing that happens
with retrieval locking deadlocks is that the dialog run unit terminates
and then starts up again at the next DML command. This is what causes
the ""0306""s because currency has been lost. If the problem dialogs are
update dialogs, that are linked to from another dialog, you will want to
try and isolate the update functions as much as possible, by putting
them in mapless dialogs, passing DBKEYS for them to re-establish
currency and using the LINK NOSAVE option to execute them. If you can
give me a scenario you're dealing with, I can give you more specifics on
how to handle it. Let me know if you have any questions on this and good
luck!
Margaret


-----Original Message-----
From: Bill Allen [mailTo:ARCHCONB@AOL.COM]
Sent: Friday, October 14, 2005 10:32 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Dead locking Information

Hello All:

Anyone have any tips, tricks, techniques, documentation, white papers
or CA
World Presentations on Dead Locking?

I would be grateful if you would share them with me. I already have the
CA
World 2004 Presentations.

Bill Allen
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Dead locking Information
" I am not sure that I would agree that most deadlocks occur
because of ADS/O retrieval locking. I would suggest that Bill analyze
the CV logs to find determine which programs are deadlocking the most
and on what records. A point to remember about the dbkey in the log, is
that the dbkey reported in the log is in horizontal hex format
(ppppppll, page and line, assuming a radix of 8).

Then after proper analysis, attention can be paid to the
programs involved. One area that usually causes a lot of problems are
OOAK records, where a next key is retrieved. We eliminated most of the
deadlocks on these types of records by using a small sub-program as a
separate run-unit, that did an OBTAIN KEEP EXCLUSIVE, updated the
record, FINISHED, and returned the next key to the caller. Another
deadlock avoidance methodology would be to at retry logic to troublesome
programs (remember that currencies must be restored and the run unit
rebound and readied).

Here some other pointers:

Situations which Encourage Deadlocks
------------------------------------
1. Holding many resources
a. Batch programs without commit logic
b. Online ""hogs""

2. Holding resources too long
a. Conversational programs
b. I/O Intensive applications

3. Holding scarce resources
a. OOAK (One of a Kind) Records
b. FOAK (Few of a Kind) Records
c. Holding Resources Unnecessarily
d. Unnecessary IDMS calls

Avoiding Deadlocks
------------------

1. In batch programs, use commit logic as instructed.

2. In online programs:

a. Code efficiently as possible.
b. Avoid conversational mode (applicable only for DC COBOL).
c. Minimize I/O by saving data in working storage or at least
save DBKey's.
d. Don't use Entry Point records and walk long sets (use CALC or
INDEX keys if possible).
e. Do update towards end of program (records won't be held as long).
f. Don't do unnecessary OBTAINS when FINDs will do.
g. Don't do FIND CURRENT if you don't have to -- learn how currency
works!
h. Walk sets intelligently! If the data is most likely at the end
of the set, walk the set backwards using OBTAIN PRIOR.

Dan Miley
Lockeed Martin

Outcomes