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

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


Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?
"What happens at point 2 below:

When ADS fires up the response process (or more correctly when the first
functional DML VERB is executed in the response process), ADS will
re-establish currencies based on the notify locks, and re-establish currency
locks (shared locks). From the end of the premap task, and up to this point
in the response process, there should be no locks being held that would
cause a DBKEY wait.

You are correct that even if the response process does not access these
RECORDs, there would be currency locks held on them until end of the
response process. HOWEVER, the stall is happening on an OBTAIN, which
implies to me the lock must be an update/exclusive, not a shared lock.
Currency locks re-established at the beginning of a response process don't
fit this scenario.

With all that, (and since Linda mentioned it to me and I don't recall seeing
it anywhere on this thread), stalls typically indicate some batch
interference somewhere... are there batch jobs being run while online is