ca.portal.admin

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

Discussion created by ca.portal.admin on Mar 9, 2010
hen perhaps the real question becomes:=3D20 =3D20 does Ms Kline need =
this
formation real time as it happens, or can=3D20 daily reports =
suffice=3D20
=3D20
the latter, then certainly the log can be interrogated and all=3D20
cessary information can be retrieved=3D20 if the former - good luck - =
even
you sat all day executing lockmon=3D20 you MIGHT see stalls building, =
but
ny deadlocks could come and go=3D20 between two hits of the ENTER =
key=3D20
=3D20
ris=3D20
The information transmitted is intended only for the person or entity to
ich it is addressed and may contain CONFIDENTIAL material. If you
receive
is material/information in error, please contact the sender and delete
or
stroy the material/information.
????
????nded recipient, please notify the sender by return e-mail and =
delete this e-mail and any attachments.
=20
?"
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: Access to Lock Data Used in PMRM?
"First of all - I want to tell you all that I am grateful for any ideas, ev=
en if it turns out that the lack of tools means I cannot use a suggested=
approach.=20
(As to Journal Analyzer - I don't believe we have it.)=20
=20
=20
""The best you can do is pray that it is not a keep longterm that causes th=
e problem.""
=20
I am afraid that that prayer won't likely be answered ;o(
=20
Reason 1
Even after the user gets knocked off the system (with the Stall) and=
they come back in, they cannot get the record, and they stall again)=20
So based on that alone I am assuming that my poor ""victims"" are the re=
sult of some other program's KEEP LONGTERM . . . UPGRADE EXCLUSIVE.?
=20
Reason 2
I have been scanning the ADS code and so far - unless I am missing somethi=
ng - I have found like 150 instances of the word EXCLUSIVE within command=
s.
All but maybe 4 or 5 have been in TSTLCK (type) code: ie (KEEP LONGTERM=
'A' UPGRADE EXCLUSIVE) - also with a variety of longterm-id's=20
(And the 4 or 5 that are not in a KEEP LONGTERM, are a couple KEEP EXCLUSI=
VEs for inventory records that do not appear related to the programs that=
are stalling.)=20
=20
=20
So my original question about identifying which program is holding=
a lock, was with the hope that I wouldn't have to look through over a hun=
dred programs to find where a KEEP LONGTERM . . . UPGRADE EXCLUSIVE has=
been issued and not released. =20

At this point, from a practical standpoint - I am not seeing the advantag=
e of the UPGRADE EXCLUSIVE - especially as a part of the ""generic"" TSTLCK=
. Opinions?
(I especially don't ""get"" the exclusive locks durinng an ADD process)

This is from the TSTLCK95 logic=20
KEEP LONGTERM 'A' TEST RETURN NOTIFICATION INTO CSR-RETURN-LOCAT=
ION. =20
IF ERROR-STATUS EQ 5121 =
=20
THEN NEXT COMMAND. =
=20
ELSE =
=20
IF DB-ANY-ERROR CALL DBERR99. =
=20
ELSE =
=20
IF CSR-RETURN-LOCATION =3D 2 OR =
=20
CSR-RETURN-LOCATION =3D 3 OR =
=20
CSR-RETURN-LOCATION > 5 DO =
=20
PROTECT ALL EXCEPT =
=20
(AGR-MODE =
=20
,AGR-MAP-RESPONSE =
=20
,AGR-PASSED-DATA). =
=20
MODIFY MAP CURSOR AT FIELD AGR-MAP-RESPONSE. =
=20
KEEP LONGTERM ALL RELEASE. =
=20
ROLLBACK. =
=20
DISPLAY MESSAGE CODE IS 799998. !*REC IN USE=
-TRY LATER =20
END. =
=20
KEEP LONGTERM 'A' UPGRADE EXCLUSIVE. =
=20

=20
=20
- - - -
(* I am having trouble even counting how many timess that code is found=
- not sure how to do ""activity logging"", if maybe that would help)

----=20
As an aside, several people have suggested JREPORT 8, and I have been tryi=
ng to run it but for some reason, even when I think I have the correct fil=
e, it does not seem to be finding my offending (victim) dbkeys. Kind of=
seems like a perfect storm - no matter which route I try to take my tools=
seem to be failing me. =20
=20
Cindy Kline=20
ASK
440-829-9275
=20
=20

Outcomes