ca.portal.admin

Re: [IDMSVENDOR-L] now to prevent space management page deadlocks???

Discussion created by ca.portal.admin on Jul 13, 2010
when i dirst posted - i was not sure myself to which you were referring

now I can say the former two data pages locked by space management




and Kay hit it right on the head - this was a ""let's add 60000 record
occurances to an area that was build to hold (and has held) 10000
occurrances - AND LETS NOT TELL THE DBAs"" ....

my first question (that I can repeat here) was: how often does the purge
run - to which the answer was (of course) what is this purge thing of
which you speak?

at first i extended to double the size - but of course no one could tell
me how may ROs would be added - so the fist extend failed - i never got an
answer - so i extended it to hold 100000

i wanted to wait for the shake-out of this before i did an UL/RL (though
many times we are never given an outage to do an UL/RL)


Chris Hoelscher
IDMS/DB2 System & Database Architect
Humana Inc
502-476-2538
choelscher@humana.com

you only need to test the programs that you want to work correctly






From:
donjcasey@COMCAST.NET
To:
IDMSVENDOR-L@LISTSERV.IUASSN.COM
Date:
07/12/2010 11:30 AM
Subject:
Re: [IDMSVENDOR-L] now to prevent space management page deadlocks???
Sent by:
IDMS 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>



I'm probably not fully awake yet.

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).

As to what things make this more common; I need more coffee.

Don Casey
Principal Consultant
Run Right, LLC

----- Original Message -----
From: Chris Hoelscher <choelscher@HUMANA.COM>
To: IDMS-L@LISTSERV.IUASSN.COM
Sent: Mon, 12 Jul 2010 14:19:37 -0000 (UTC)
Subject: now to prevent space management page deadlocks???

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?


thanks,
Chris Hoelscher
IDMS/DB2 System & Database Architect
Humana Inc
502-476-2538
choelscher@humana.com

you only need to test the programs that you want to work correctly




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








Normal

Normal
SPACE MAMANGEMENT LOCKS
"This is a multi-part message in MIME format.

------_=_NextPart_001_01CB229F.0D26517B
Content-Type: text/plain;
charset=""us-ascii""
Content-Transfer-Encoding: quoted-printable

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

=20

=20

Dick Weiland=20

CA Technologies
Sr Sustaining Engineer
Tel: +1-630-505-6561
Fax: +1-630-210-9274
Richard.Weiland@ca.com
<mailTo:RichardJr.WeilandJr@ca.com> <http://www.ca.com/>=20

=20


------_=_NextPart_001_01CB229F.0D26517B
Content-Type: image/gif;
name=""image001.gif""
Content-Transfer-Encoding: base64
Content-ID: <image001.gif@01CB2272.502AF600>
Content-Description: image001.gif
Content-Location: image001.gif

R0lGODlhQgA8APcAAAZ3hARxkglxmwFmqgBlrQBkrwJqoQFopgJlsARmsAZosQhpsgpqsgxrsw9t
tBFutBNwtRRwtSB3uSJ4uSt+vA+XPRGdLxOlHxSqExWqFBerFhirFxisFxirGBmsGBytGh6tHRKh
JhKkIBqiNSCuHyGvICOvIiSwIiWwJCexJiixJymxKCyyKy2zLC+0LjC0LzK0MTS1Mza2NDe2Njm3
ODq4OTy4Oz25PD+5Pg2PTguMVgyNUw2QTQiBbUC6P0G6QES7Q0S7REa8RUm8SEq+SUu+Sky+S02/
TVC/T1DAT1LAUlPAVVTBU1bBVVjDV1jDWFvEWlzEW13EXF/FX2DFX2LGYWTHY2XHZGXGZ2fIZmjI
Z2nJaGvJamvKa2zKa23KbG/LbnDLcHHMcXTMc3bNdXjOd3nOeHrPenvOfXzPe33QfH/Rfy+AvjCB
vjWEvzWEwDmGwTyIwj+Kwl6xk0GLw0KMxEePxVCUyFKWyFmaylyczGGfzWWhzmeiz2qk0HGo0nes
1Hqu1Xuv1n24wH6w1oDRf4Cy14Kz2IO02IW12Yi32ou42oy524+73JK93YLRgYXShIfUh4bTiIjU
h4rUiY3WjI7WjpDXj5HXkJXYlJbZlpjal5jamJrbmp3bnJ7cnqDcn6HdoKTepKffpqjfp6ngqarg
qqzhq63hrbDir7DisbXktbjlt7nlubznu73nvL7nvr7ovpfA3prB357E4KDF4aLG4qXI46jK46jK
5KzM5bDP5rfT6LjU6L7X6sPa7MTb7Mbc7cDowMTpw8Xpx8XqxMjryMrsys7tztHu0NLv0tTv09Tv
1NXw1dbw1tjx19nx2Nzy293z3d7z3szg79bq597v69Pk8dXl8tfm8tjo89vp9N3q9OD03+Ds9ePu
9uTu9uH04eX15en36ev46+z46+z47O757ufw9+ry+O30+e/1+vD57/D2+vD58PD68PP78/L59PT7
9Pb89vT4+/X5/Pb6/Pj7/Pj8+Pr9+vv9/fz++/z9/vz+/P7+/gAAACH5BAEAAP8ALAAAAABCADwA
AAj/AP0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLAun1OpRHDhsKbersYRRMX8J+yUCZkTLkhg0c
RaaoGSUNI8FeeBYU2MmzZwEIfq4VNAYGBYajSJMinVHJ3MVfbnxKlZoHnD9iQ5Rq3VqiU7+J9/4g
mEq254M5Gbaq1XoFX8R2dcrK5UmAx9q7SLdArBdnrt8CBCrgxVvqYZ6/fw1cGLz2Rb6GtRAj7sF4
7SuG6iLMhUMLW7pvvfgkKDtAxNEgoJiZc+dMEwu8axgKmmvoYLAHZXVgkPS1YDkcd5ssrIe7bJ6E
tMoCWJKwWVq1NhbekpvAW8J7DsgeUKWwyNoWC/HI/62z8E3ZagrTrFWhkF9xsogW3rNHv379hZTW
K8w2d5fNfuIgs0ooljwihH4J6TIXNRT1owwnW/gAwnOMsZcQI3NZF5EwYKhQ2VYWIgTIXOlAhIoN
FH6oVIgH+UGiQ+IokaKKKyrkolzoNLTMCpWV8MMTPiCI0B9zbcOQODzetYIYqIQzECZCHpTIXMEw
1MRdN6jyWEGXRGmQLXPlspAwa2UQyZYGVeJlQdTMFchCWKxFiUKPrEnQPQzIBcdCSWoFA5oHaWEn
QXbIhYA2CVkzI1JiLCTDoAPNMhceCQ2ylhoKGXMXiwet08BchBzEiwBrOXFSVpAORORcceDijT3t
AP/TRwIHLHqUB9AgBAlenB6UznuS7RTCWjM8UxA8ZAzW60GSBsvTDndtAEUmqIhChlHKOnSYswUE
YCuNSqXgkD10cFtADuBioIIHapXwED13cHuABTSWgAy2WmnQm0OL6BSsASN8qMIx/tSwlpMQcaPH
aH9NMEs8aHQwWBPiCPTEWq1MBI4icChAlgR89MLPQNOc8ZpWJVgxDEGfJOHyyy+LYlE91OgiSyOO
2OJLjglBk0onm4SyijOA2mT00UgnrfTSTDft9NMGyTNPQ5Wc4hAQZkRUjArINDSDXgzFwIVDMHyx
IQYEM8RK2gqhgsIPn/jzDiZmXOZPPqGQ8YlbMHj/cUoZsPhjziXOXKLGNALFYgYl4/hDJsHiUHJG
MQJB88gjxjwiDyis+NNPKXo/dk4lZ1z2CAgreLEPED6UAQIq/oBRQhYoVOEPDB4o8QMH4UCDAQpW
rPCDP6hkIMUMMcjzODst1PBEBquEA8ITUmBgBj4y6FVICmnAAIY/uouhgpMxeOE4BsKI48UQ5miw
iT/HXAaDFf5o6orvpPgDiQb+CCFcNBgwxeNAkYGKGQEJofAAPvrxAU/4I3v4AAElxCEKDrxjfueY
mj/E5o9QYMAEKDiBD5KBAbsJpGz+IGErfMcdSmTAHyg4g+c2QInHFYIEAgmDC5zhgTGYAX0P3EI4
/zAAghCeoBunAMEHxDA1DqoCA7kSyDQwADup3c5syMDACjHQwheWT24Z4MTjLLEBt1ThBuS4gRGo
UJggniMDnSBIP87BCRBo4oFGEIY5SBCFVjxhTjcAQiuaMIQr+iOLW+yiP9RgAlSMwQPSeFwzNHAG
U4BgEp/wACQ+0YqpZc8fR5DBKgrBBHkUwRLHYIEl/HEJFBDBH7G4wQmSwAx/QOMIJxCCMvzRBEj4
wxk2KMY0bBALf3ziBv6YxxdSQAPuHMMGuzSFDFQgBnxAYwVHKIIHhveER/gjHEo4wQ1gh4oaoEAK
54BaQroAhK9U4gNFU+eGWnCCFqzAFPK8SD/GIQeOfeXznwEBADs=

------_=_NextPart_001_01CB229F.0D26517B--
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

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.





Dick Weiland

CA Technologies
Sr Sustaining Engineer
Tel: +1-630-505-6561
Fax: +1-630-210-9274
Richard.Weiland@ca.com
<mailTo:RichardJr.WeilandJr@ca.com> <http://www.ca.com/>



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








Normal

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.

Thanks in advance - looking forward to your contributions, thoughts and=
feedback - cheers - Gary


Gary Cherlet
Justice Technology Services
Department of Justice, SA Government

President Australian IDMS User Group (OZIUA)
IUA Board member responsible for Connections
And User Contributed Library

"""""""" Telephone +61 (0)8 8226 5199
@@ Facsimile +61 (0)8 8226 5311
> Mobile +61 (0)41 333 1613
\/ MailTo:gary.cherlet@sa.gov.au

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








Normal

Normal
Re: IDMS Connections - call for submissions for September 2010 Issue
"Gary,

I think you still have a article from me ""on hold"". Is that right?

Outcomes