By 'SMP deadlock' do you mean a 'space on this here page' deadlock (line
index 255) or a lock on the SMP page itself?

If the latter, I don't recall any locking taking place on the SMP pages.

If the former, then if two run units are attempting to modify space on the
same page, and have some other resource conflict, then yes, you can get
deadlocks. IDMS locks this artificial line index (highest possible, based
on radix if I remember correctly) in order to ensure a rollback can take
place (can't give up space deleted for a new record until IDMS is sure
that space is going to stick around).

i think we all know the bad programming code that can lead to db-key
deadlocks - but are SMP deadlocks just a matter of coincidence?
can they just occur because of where record occurrence STORES or DELETES
(or MODIFYs) are intended to take place?

The information transmitted is intended only for the person or entity to
which it is addressed and may contain CONFIDENTIAL material. If you
receive this material/information in error, please contact the sender and
delete or destroy the material/information.

The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP

I thought I'd comment on a few things based on previous activity
concerning SMP pages and their locking.

=20

First there are never any dbkey locks set on any portion of an SMP since
there are no dbkeys associated with an SMP. Also space is never
allocated or freed on an SMP so the space lock is also never set. This
is fine since no updates to the SMP are ever journaled or recovered as
their data is never meant to always be 100% accurate relative to the
actual space on a page. What is maintained is a very short duration
buffer lock. This lock is not maintained through the lock manager but
uses a simple ECB maintained within the buffer's BME. When a run-unit
gets control of a buffer with the intent to update the page it places an
exclusive lock on its buffer when the buffer is accessed. A run-unit
can only hold concurrent locks on 3 buffers so they are typically cycled
rather quickly. Their purpose is to make sure no two run-units are
actively altering a page at the same time. In a CV environment these
locks are always released at the conclusion of a DML's execution. Since
it is possible for contention for one of these locks between run-units
it is possible that time-outs or other deadlocks could occur but they
would not be reported as dbkey deadlocks.

=20

Certainly the space available in an area will have an impact on the
frequency of contention on these locks but unless there is an
application where records are being heavily stored concurrently on a
small range of pages I would not expect to see that many time-outs or
deadlocks related to these buffer locks. I would suspect that page
space lock contention on the actual data pages would be more prevalent.

=20

Page space locks have also been changed from their original
implementation. We no longer use line index 255 as the 'dbkey' used to
lock space. With the creation of the lock manager in Release 12.0 a
separate 'space' lock is now maintained. If you see a dbkey lock
conflict for line index 255 of a page you are now actually seeing a
conflict for a record which has been assigned to line index 255.=20

Normal
SPACE MAMANGEMENT LOCKS
"I thought I'd comment on a few things based on previous activity
concerning SMP pages and their locking.

First there are never any dbkey locks set on any portion of an SMP since
there are no dbkeys associated with an SMP. Also space is never
allocated or freed on an SMP so the space lock is also never set. This
is fine since no updates to the SMP are ever journaled or recovered as
their data is never meant to always be 100% accurate relative to the
actual space on a page. What is maintained is a very short duration
buffer lock. This lock is not maintained through the lock manager but
uses a simple ECB maintained within the buffer's BME. When a run-unit
gets control of a buffer with the intent to update the page it places an
exclusive lock on its buffer when the buffer is accessed. A run-unit
can only hold concurrent locks on 3 buffers so they are typically cycled
rather quickly. Their purpose is to make sure no two run-units are
actively altering a page at the same time. In a CV environment these
locks are always released at the conclusion of a DML's execution. Since
it is possible for contention for one of these locks between run-units
it is possible that time-outs or other deadlocks could occur but they
would not be reported as dbkey deadlocks.

Certainly the space available in an area will have an impact on the
frequency of contention on these locks but unless there is an
application where records are being heavily stored concurrently on a
small range of pages I would not expect to see that many time-outs or
deadlocks related to these buffer locks. I would suspect that page
space lock contention on the actual data pages would be more prevalent.

Page space locks have also been changed from their original
implementation. We no longer use line index 255 as the 'dbkey' used to
lock space. With the creation of the lock manager in Release 12.0 a
separate 'space' lock is now maintained. If you see a dbkey lock
conflict for line index 255 of a page you are now actually seeing a
conflict for a record which has been assigned to line index 255.

Normal
IDMS Connections - call for submissions for September 2010 Issue
"Just as you were starting to wonder how to spend your summer vacation (or t=
he long winter nights down here) - here's an opportunity to keep busy and d=
o something for the IDMS User Community!

This is an open call for people within the IDMS User community to tell us a=
bout anything that you think may be of interest to the rest of the communit=
y:

* WHAT do you do with IDMS? Tell us about interesting or unusual applicatio=
ns, new developments and/or mission critical applications

* HOW do you do it? Provide technical tips for DBA's, hints for application=
developers, change control, project management techniques, maximising use =
of functionality of the tools

* WHY do you do it? What does IDMS or applications built on IDMS/ADS do to =
""add value to the business""?

If you are planning to provide an article, please let me know soon with at =
least a ""title"" so that we can try to build up a picture as to how we are g=
oing for content. Also, if I know you are planning to submit an article I c=
an send you the ""Guidelines for Contributors to Connections"" document, whic=
h you will find useful to help to minimise your work and reduce duplication=
of effort by our publisher. If you would like to make a contribution to th=
e next IDMS Connections I will need your completed submission by Monday Aug=
ust 23rd (Tuesday 24th in Asia-Pacific), for publication in September.

And a special thought for vendors - do you have any new tools that you want=
to tell the IDMS Community about? If so, why not place a =BD page or full =
page ad in the September issue. Placing your ads helps to support IDMS Conn=
ections and it's a terrific way of letting people know what you are up to b=
etween CA-Worlds!

IDMS Connections is ""best practice"" for communications amongst the CA User =
Communities - you can help us to keep it that way.

This e-mail message and any attachments are qualified as follows: Addressin=
g: If you have received this e-mail in error, please advise by reply e-mai=
l to the sender. Please also destroy the original transmission and its con=
tents. Confidentiality: This e-mail may contain confidential information w=
hich also may be legally privileged. Only the intended recipient(s) may ac=
cess, use, distribute or copy this e-mail. Individual Views: Unless otherw=
ise indicated, the views expressed are those of the sender, not Justice Tec=
hnology Services. Computer Viruses: It is the recipient's responsibility t=
o check the e-mail and any attached files for viruses.
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP