ca.portal.admin

Re:Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?

Discussion created by ca.portal.admin on Mar 9, 2010
then perhaps the real question becomes:=20 =20 does Ms Kline need this
information real time as it happens, or can=20 daily reports suffice=20 =20
if the latter, then certainly the log can be interrogated and all=20
necessary information can be retrieved=20 if the former - good luck - even
if you sat all day executing lockmon=20 you MIGHT see stalls building, but
many deadlocks could come and go=20 between two hits of the ENTER key=20 =20
chris=20



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 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?
"For completeness' sake: the implicit locks placed by default are NOTIFY
locks, and will not and cannot cause a deadlock or stall condition. Unless
the code somewhere does a KEEP... LONGTERM all potentially problematic locks
will be released at the end of the task. I believe Linda has already spoken
to this issue.

Anyway; a brute force approach would be to automate a series of DCMT
displays (D AC TA, D RU, D CV, etc) to run every minute or so on a PC using
a tool that can submit them every minute or so and record the output (e.g.,
something like Winrunner/Loadrunner). You might be able to correlate the
stalls with what's running at the time they occur.

The other, uglier possibility is to use JREPORT8 to fish around in the
journals looking for signs of a run-unit modifying the DBKEY your rununit
stalled on.

Don Casey
Principal Consultant
Run Right, LLC

Outcomes