ca.portal.admin

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

Discussion created by ca.portal.admin on Mar 11, 2010
EEP LONGTERM... EXCLUSIVE would be problematic. Why is this being
one?
----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM] On
half Of Cynthia Kline
Sent: Wednesday, March 10, 2010 6:05 AM
: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?
K to jump back in...
es they have CAS, yes they have modified the code so I cannot tell what
s
st older CAS code and what is modified.
ince I don't know yet which particular programs are holding the
cords/locks, I was looking around at some potential candidates and
arched through ALL of the dialogs looking
r EXCLUSIVE. I found that a bunch of programs are using TSTLCK95 - and
me are using a varient of it.
om what I've seen this is called in most cases only in the RESPONSE
hen
eparing to UPDATE.
TLCK does a TEST RETURN NOTIFICATION and KEEP LONGTERM 'A' UPGRADE
CLUSIVE.
I do see that most of the programs I have looked at do a KEEP LONGTERM
LL
LEASE before EXEC NEXT FUNCTION, but since I don't know which
rogram(s)
concentrate on, I do not know that all of the programs are doing a
lease before continuing on (in every case).
Actually I am pretty sure that some programs are NOT releasing locks-
ven
en no processing is going on if I look in LOCKMON or OPER I see a bunch
f
ers with dozens of Notify locks.
owever, the STALL victim that I am looking into seems to be hanging up
n
e premap (which is also readied as UPDATE)
see that the premap does do a KEEP LONGTERM ALL RELEASE - but I have
ver been totally clear on longterm locks - I assume that release only
plies to LT locks set within the same program?)
on - I believe that you wrote that LONGTERM locks do not lock the
ecords
ontributing to stalls)? Would that still apply if there is an upgade
o
clusive?
ROM TSTLCK95:
EEP LONGTERM 'A' TEST
RETURN NOTIFICATION INTO CSR-RETURN-LOCATION.
ERROR-STATUS EQ 5121
THEN NEXT COMMAND.
SE
DB-ANY-ERROR CALL DBERR99.
SE
CSR-RETURN-LOCATION =3D 2 OR
CSR-RETURN-LOCATION =3D 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.
EP LONGTERM 'A' UPGRADE EXCLUSIVE.


---Original Message-----
From: Don Casey <donjcasey@COMCAST.NET>
: IDMS-L@LISTSERV.IUASSN.COM
Sent: Tue, Mar 9, 2010 10:43 pm
Subject: Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?
or completeness' sake: the implicit locks placed by default are NOTIFY
ks, and will not and cannot cause a deadlock or stall condition.
nless
code somewhere does a KEEP... LONGTERM all potentially problematic
ocks
l be released at the end of the task. I believe Linda has already
poken
this issue.
yway; a brute force approach would be to automate a series of DCMT
plays (D AC TA, D RU, D CV, etc) to run every minute or so on a PC
sing
ool that can submit them every minute or so and record the output
e.g.,
ething like Winrunner/Loadrunner). You might be able to correlate the
lls with what's running at the time they occur.
e other, uglier possibility is to use JREPORT8 to fish around in the
rnals looking for signs of a run-unit modifying the DBKEY your rununit
lled on.
n Casey
ncipal Consultant
Right, LLC
---Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM] On
alf Of Cherlet, Gary (JTS)
Sent: Tuesday, March 09, 2010 6:41 PM
IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?
ris is correct - these are ""long term locks"" which can be held across a
udo-converse (when there is no active task), as contrasted to Database
ks which can only be held during an active database run unit (which can
exist when there is no active task).
ADS there are ""implicit locks"" placed automatically by ADS (there are
s to manage this through sysgen and compile options), and explicit long
m locks that can be placed by application code. During the
udo-converse the long term resources are transferred from the active
ask
E) resource chain to the LTERM resource chain.
H - cheers - Gary
ry Cherlet
tice Technology Services
artment of Justice, SA Government
ephone +61 (0)8 8226 5199
simile +61 (0)8 8226 5311
ile +61 (0)41 333 1613
lTo:gary.cherlet@sa.gov.au
is e-mail message and any attachments are qualified as follows:
ressing: If you have received this e-mail in error, please advise by
ly e-mail to the sender. Please also destroy the original transmission
its contents. Confidentiality: This e-mail may contain confidential
ormation which also may be legally privileged. Only the intended
ipient(s) may access, use, distribute or copy this e-mail. Individual
ws: Unless otherwise indicated, the views expressed are those of the
der, not Justice Technology Services. Computer Viruses: It is the
ipient's responsibility to check the e-mail and any attached files for
uses.
---Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM] On
alf Of Chris Hoelscher
Sent: Wednesday, 10 March 2010 11:58
IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: [IDMSVENDOR-L] Access to Lock Data Used in PMRM?
t to muddy the waters further - but I believe that in some cases - a
ser
walk away without logging off (but NOT in the middle of a
nsaction) and STILL hold locks on data resources - in this case i think
holder would be the LTERM - not a program
ris Hoelscher
S/DB2 Database Architect
ana Inc
-476-2538
elscher@humana.com
u only need to test the programs that you want to work correctly
From:
thia Kline <cakask@AOL.COM>

SVENDOR-L@LISTSERV.IUASSN.COM
e:
09/2010 07:57 PM
Subject:
[IDMSVENDOR-L] Access to Lock Data Used in PMRM?
t by:
S 3rd-party providers forum <IDMSVENDOR-L@LISTSERV.IUASSN.COM>
have been offloading Logs - I can work with it either way.=3D20
at I am trying to determine is:=3D20
Which program is holding onto the records and causing a stall in
not=3D
program. =3D20
(since I have been able to execute a TRACE while a STALL is
appening=3D
see the TRACE stop right before an OBTAIN OWNER,=3D20
I figured if I can determine which program is holding onto (loc=3D
g) the record the Stalled program needs, then I can check out THAT
rog=3D
to find out why it won't let go.)=3D20
anks,=3D20
dy Kline

Outcomes