ca.portal.admin

Re:RLEs Increased, then BOOM!

Discussion created by ca.portal.admin on Feb 26, 2010
We received the RLE messages below just before our CV crashed. The CV
was humming along happily before this problem and it warmstarted fine
afterward. Neither task 550832 nor 551906 appear in any of the logs.
The other tasks listed in the messages look like innocent bystanders.
Any suggestions on where to begin the hunt for the perp?

--------------------
Our Typical Counts: (we are ""always"" within the safe zone!)

INTERNAL: RLEs RCEs DPEs Stack
10534 9248 3956 1235 HWM
16300 14500 4400 2000 Sysgen Threshold
0 0 0 Times Exceeded
--------------------
From the Job Log:

13.28.29 +IDMS DC010007 V2 T550832 THE NUMBER OF RLE'S HAS BEEN
INCREASED TO 20400.
13.28.33 +IDMS DC010007 V2 T551016 THE NUMBER OF RLE'S HAS BEEN
INCREASED TO 24480.
13.28.38 +IDMS DC010007 V2 T551127 THE NUMBER OF RLE'S HAS BEEN
INCREASED TO 28560.
13.28.45 +IDMS DC010007 V2 T550832 THE NUMBER OF RLE'S HAS BEEN
INCREASED TO 32640.
13.28.52 +IDMS DC010007 V2 T551409 THE NUMBER OF RLE'S HAS BEEN
INCREASED TO 36720.
13.29.03 +IDMS DC010007 V2 T550832 THE NUMBER OF RLE'S HAS BEEN
INCREASED TO 40800.
13.29.14 +IDMS DC010007 V2 T550832 THE NUMBER OF RLE'S HAS BEEN
INCREASED TO 44880.
13.29.21 +IDMS DC027006 V2 T551906
13.29.59 IEA995I SYMPTOM DUMP OUTPUT 186
186 USER COMPLETION CODE=3970
186 TIME=13.29.21 SEQ=41595 CPU=0000 ASID=0085
186 PSW AT TIME OF ERROR 078D1E00 8000C6A2 ILC 2 IN
186 ACTIVE LOAD MODULE ADDRESS=000079A0 OFF
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
"Re: RLEs Increased, then BOOM!"
"Point taken - but depending on READY mode locks might have been placed that=
were not UPDATE locks. This might be impacted by RETRIEVAL LOCK/NOLOCK in =
sysgen. If there were lots of retrieval locks the lock tables could still u=
se lots of storage - but without updates there would be no need for a Rollb=
ack. While this is a possibility it is starting to stretch the limits a bit=
- so there is likely something else happening.

What about a runaway SQL query chewing lots of secondary scratch allocation=
s - no updates to Rollback? Are you an IDMS/SQL user? Of course it wouldn't=
need to be SQL - could be a user program too?

Also - ADS tasks that get into a tight LINK to DIALOG loop will chew up lot=
s of storage - but only if MAX LINK levels in ADSO statement is set very hi=
gh!

Sure there are no other messages that night indicate what the problem was?

HTH - cheers - Gary=20



Gary Cherlet
Justice Technology Services
Department of Justice, SA Government
Telephone +61 (0)8 8226 5199
Facsimile +61 (0)8 8226 5311
Mobile +61 (0)41 333 1613
MailTo:gary.cherlet@sa.gov.au

This e-mail message and any attachments are qualified as follows: Addressin=
g: If you have received this e-mail in error, please advise by reply e-mai=
l to the sender. Please also destroy the original transmission and its con=
tents. Confidentiality: This e-mail may contain confidential information w=
hich also may be legally privileged. Only the intended recipient(s) may ac=
cess, use, distribute or copy this e-mail. Individual Views: Unless otherw=
ise indicated, the views expressed are those of the sender, not Justice Tec=
hnology Services. Computer Viruses: It is the recipient's responsibility t=
o check the e-mail and any attached files for viruses.

Outcomes