ca.portal.admin

Re: Dead locking Information

Discussion created by ca.portal.admin on Oct 17, 2005
Hello Everyone:

It turns out that this is more a perception and transaction scheduling
issue than a real dead locking problem. My client processed 3.6 Millions
tasks and out of that had a total of 260 dead locks, that is
approximately one tenth of one percent.

That is a very low number, I would like to hear what others are
experiencing.

Now to the cause, some PC jockey wrote a macro and pumped the same
transactions into the CV for over two hours straight, the dead locks
were the same task code, different run units, all dead locking on each
other.

I still would like to receive as much information as I can to send to
the application development staff.

Bill Allen

In a message dated 10/17/2005 2:29:46 P.M. Eastern Daylight Time,
dan.l.miley@LMCO.COM writes:

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

"
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
"Bill,

We have some deadlocking issues that we have resolved by writing DC COBOL
programs to ENQUEUE/DEQUEUE resources that more or less need to be single
threaded (OOAK records, highly updated indexes, etc). In one, there is a
retry mechanism that sends a message back to the screen basically saying
'busy, try again' when the enqueue fails. The other, waits one second if
the enqueue fails and then tries again. It will retry 8 times and then give
up trying to get the enqueue and just let the program take its chances.
Both prevent most of the deadlocks in some key processes, but do elongate
processing and response times. The users didn't like either at first, but
once they realized the alternative (abending and starting over), they have
stopped complaining.

We (DBA) had to take this approach because of the evolution of the
application (not easy to change some things) and the inability on the part
of an overwhelmed programming staff to fix some old problems. We also
needed to short circuit the problem with deadlock abends causing even more
bottlenecks due to the overhead of abend processing and deadlock management.
Just changing a few key dialogs has resolved a lot of problems.

Linda Campbell
Informatix Inc

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








Normal

Normal
Release 16.0 APAR's
"Hello All:

A while back there was a discussion and someone mentioned an APAR for IDMS
16.0 SP2 for ADSOSTAE and also an APAR for an ADSO problem when using LINK
NOSAVE.

Can you send me the APAR numbers please?

I have a site that is receiving a 5105 Abort which is a currency issue with
a KEEP LONGTERM, the Dialog is using a LINK NOSAVE and it just started
failing with the implementation of IDMS 16.0 SP2 in Production.

We have temporarily gotten around this issue by changing the LINK NOSAVE to
a straight LINK.

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: Release 16.0 APAR's
"Concerning the LINK NOSAVE apar, TF24458 was applied to resolve some
isolated ADSO currency problems (0306) after we upgraded to R16.1.

Stan Robinson
American Greetings

Outcomes