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 Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Access to Lock Data Used in PMRM?
"OK to jump back in...

Yes they have CAS, yes they have modified the code so I cannot tell what=
is just older CAS code and what is modified. =20

Since I don't know yet which particular programs are holding the records/l=
ocks, I was looking around at some potential candidates and searched throu=
gh ALL of the dialogs looking
for EXCLUSIVE. I found that a bunch of programs are using TSTLCK95 - and=
some are using a varient of it. =20
From what I've seen this is called in most cases only in the RESPONSE when=
preparing to UPDATE. =20
TSTLCK does a TEST RETURN NOTIFICATION and KEEP LONGTERM 'A' UPGRADE EXCLU=
SIVE. =20
**I do see that most of the programs I have looked at do a KEEP LONGTERM=
ALL RELEASE before EXEC NEXT FUNCTION, but since I don't know which progr=
am(s) to concentrate on, I do not know that all of the programs are doing=
a release before continuing on (in every case).
**Actually I am pretty sure that some programs are NOT releasing locks- ev=
en when no processing is going on if I look in LOCKMON or OPER I see a bun=
ch of users with dozens of Notify locks. =20
=20
However, the STALL victim that I am looking into seems to be hanging up in=
the premap (which is also readied as UPDATE)=20
(I see that the premap does do a KEEP LONGTERM ALL RELEASE - but I have ne=
ver been totally clear on longterm locks - I assume that release only appl=
ies to LT locks set within the same program?)

Don - I believe that you wrote that LONGTERM locks do not lock the records=
(contributing to stalls)? Would that still apply if there is an upgade=
to exclusive?=20


FROM TSTLCK95:

KEEP LONGTERM 'A' TEST =20
RETURN NOTIFICATION INTO CSR-RETURN-LOCATION. =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

Outcomes