ca.portal.admin

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

Discussion created by ca.portal.admin on Mar 9, 2010
en perhaps the real question becomes:=3D20 =3D20 does Ms Kline need this
ormation real time as it happens, or can=3D20 daily reports suffice=3D20
20
the latter, then certainly the log can be interrogated and all=3D20
essary information can be retrieved=3D20 if the former - good luck - even
you sat all day executing lockmon=3D20 you MIGHT see stalls building, but
y deadlocks could come and go=3D20 between two hits of the ENTER key=3D20
20
is=3D20
he information transmitted is intended only for the person or entity to
ch it is addressed and may contain CONFIDENTIAL material. If you
eceive
s material/information in error, please contact the sender and delete
r
troy 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?
"First of all - I want to tell you all that I am grateful for any ideas, even if it turns out that the lack of tools means I cannot use a suggested approach.
(As to Journal Analyzer - I don't believe we have it.)


""The best you can do is pray that it is not a keep longterm that causes the problem.""

I am afraid that that prayer won't likely be answered ;o(

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)
So based on that alone I am assuming that my poor ""victims"" are the result of some other program's KEEP LONGTERM . . . UPGRADE EXCLUSIVE.?

Reason 2
I have been scanning the ADS code and so far - unless I am missing something - I have found like 150 instances of the word EXCLUSIVE within commands.
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
(And the 4 or 5 that are not in a KEEP LONGTERM, are a couple KEEP EXCLUSIVEs for inventory records that do not appear related to the programs that are stalling.)

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 hundred programs to find where a KEEP LONGTERM . . . UPGRADE EXCLUSIVE has been issued and not released.
At this point, from a practical standpoint - I am not seeing the advantage 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
KEEP LONGTERM 'A' TEST RETURN NOTIFICATION INTO CSR-RETURN-LOCATION.
IF ERROR-STATUS EQ 5121
THEN NEXT COMMAND.
ELSE
IF DB-ANY-ERROR CALL DBERR99.
ELSE
IF CSR-RETURN-LOCATION = 2 OR
CSR-RETURN-LOCATION = 3 OR
CSR-RETURN-LOCATION > 5 DO
PROTECT ALL EXCEPT
(AGR-MODE
,AGR-MAP-RESPONSE
,AGR-PASSED-DATA).
MODIFY MAP CURSOR AT FIELD AGR-MAP-RESPONSE.
KEEP LONGTERM ALL RELEASE.
ROLLBACK.
DISPLAY MESSAGE CODE IS 799998. !*REC IN USE-TRY LATER
END.
KEEP LONGTERM 'A' UPGRADE EXCLUSIVE.



- - - -
(* 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)

----
As an aside, several people have suggested JREPORT 8, and I have been trying to run it but for some reason, even when I think I have the correct file, 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.

Cindy Kline
ASK
440-829-9275

Outcomes