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:=20 =20 does Ms Kline need this
ormation real time as it happens, or can=20 daily reports suffice=20
20
the latter, then certainly the log can be interrogated and all=20
essary information can be retrieved=20 if the former - good luck - even
you sat all day executing lockmon=20 you MIGHT see stalls building, but
y deadlocks could come and go=20 between two hits of the ENTER key=20
20
is=20
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 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?
"then how bout .....

we make sure TASK stats are being written to the log

if the stall info can tell you what LTERM (if not an active program) holds
the resources
look thru the task stats for the concurrent (or most recent) task executed
on that LTERM to determine who set the keep longterm
(or at least to see who executed something that might have locked the
resource in the immediate past to the the stall ...


just a thought




Chris Hoelscher
IDMS/DB2 Database Architect
Humana Inc
502-476-2538
choelscher@humana.com

you only need to test the programs that you want to work correctly






From:
Cynthia Kline <cakask@AOL.COM>
To:
IDMSVENDOR-L@LISTSERV.IUASSN.COM
Date:
03/11/2010 11:02 PM
Subject:
Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?
Sent by:
IDMS 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>



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