ca.portal.admin

Re: [IDMS-L] Informational APAR's

Discussion created by ca.portal.admin on Jul 1, 2006
At 10:55 6/30/2006, you wrote:
Is there a list anywhere of all of the IDMS-related informational
(QI******) APAR's?
Kay - first , look in member PIB in your most recent SAMPJCL

also, i would assume doing a supportconnect serach on keyword PIB might
obtain a more up-to-date list for your release of choice

chris

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








Normal

Normal
CA-IDMS R16 SP4 webcast
"CA is pleased to announce the general availability of CA-IDMS r16
Service Pack 4 in July 2006. SP4 is a service pack that introduces new
features designed to improve system availability and facilitate
compliance and audit reporting.



On Wednesday July 19, 2006 at 11:00 AM ET, CA will host a webcast that
introduces CA-IDMS r16 SP4 and explores the benefits and features of
this new release, including test results of beta program customers.



This webcast is intended for database administration (DBA) management,
DBAs and applications staff.



To register for this webcast, please follow this link:
http://livemeeting.viewcentral.com/reg/ca/1517Live3

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








Normal

Normal
"No commits, SOS, dynamic lock table allocation, syslocks"
"I know the pat answer to SOS in pool 0 conditions is to either increase
the commit frequency and or sysgen more syslocks. But why is increasing
syslocks so much more efficient then dynamic lock allocation? What is
it about dynamic lock allocation that is so wasteful? And why does it
have to come out of pool 0 instead of some above the line pool, like
255? Does anyone have a technical explanation? I am getting the
sneaking suspicion that there is a bug in dynamic lock allocation.

Lutz Petzold


-----------------------------------------
This e-mail may contain confidential or privileged information. If
you think you have received this
e-mail in error, please advise the sender by reply
e-mail and then delete this e-mail immediately. Thank you. Aetna


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








Normal

Normal
"Re: No commits, SOS, dynamic lock table allocation, syslocks"
"Think of doing a binary search for active, and the cost of it. Now
consider doing 2 (second allocation) if the key isn't in the first
table, or a third search for the item if not in the 1st or 2nd table.
This basicly would be the cost.

P.S. If there is room to allocate the extended SYSLOCK table out of the
255 pool, IDMS will do so, if not an attempt is made to pool 0, and most
likely no pool 0 will have room for an extend syslock table.

Edward A. Timm
Sallie Mae, Senior Database Analyst
ETIMM@salliemae.com
(317) 596-1182
Fax (317) 595-1494
PetzoldL@Aetna.Com 07/06/2006 10:07:29 AM >>>
I know the pat answer to SOS in pool 0 conditions is to either
increase
the commit frequency and or sysgen more syslocks. But why is
increasing
syslocks so much more efficient then dynamic lock allocation? What is
it about dynamic lock allocation that is so wasteful? And why does it
have to come out of pool 0 instead of some above the line pool, like
255? Does anyone have a technical explanation? I am getting the
sneaking suspicion that there is a bug in dynamic lock allocation.

Lutz Petzold


-----------------------------------------
This e-mail may contain confidential or privileged information. If
you think you have received this
e-mail in error, please advise the sender by reply
e-mail and then delete this e-mail immediately. Thank you. Aetna


This E-Mail has been scanned for viruses.

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








Normal

Normal
"Re: No commits, SOS, dynamic lock table allocation, syslocks"
"Agreed, but the second allocations buy so much fewer updates then the
initial syslocks.
Pool 0 is the last resort, right, after pool 255?

Lutz Petzold


-----------------------------------------
This e-mail may contain confidential or privileged information. If
you think you have received this
e-mail in error, please advise the sender by reply
e-mail and then delete this e-mail immediately. Thank you. Aetna


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








Normal

Normal
"Re: No commits, SOS, dynamic lock table allocation, syslocks"
"Also be aware that on a 15.0 system with QO72183 or 16.0 with either of
QO74383 or QO74385 you are restricting the lock overflow into XA, pool
255, only.

From my experience it does not seem to take too much activity to get
lock overflow with CA's recommended 100k locks. Also be aware of lock
overflow when an area gets varied offline and users try to access it
online. This produces lock overflow in 16.0. Also pointed out on this
list, badly organized indexes can increase the number of locks.

So keep the lock allocation high, segregate different storage types into
different storage pools, give pool 255 a reasonable cushion, rebuild
badly organized indexes and stop jobs/tasks from making massive numbers
of updates without commits.

Chris Wood
Alberta Department of Energy
CANADA

Outcomes