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!)=20

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

13.28.29 +IDMS DC010007 V2 T550832 THE NUMBER OF RLE'S HAS BEEN INCREASED T=
O 20400.
13.28.33 +IDMS DC010007 V2 T551016 THE NUMBER OF RLE'S HAS BEEN INCREASED T=
O 24480.
13.28.38 +IDMS DC010007 V2 T551127 THE NUMBER OF RLE'S HAS BEEN INCREASED T=
O 28560.
13.28.45 +IDMS DC010007 V2 T550832 THE NUMBER OF RLE'S HAS BEEN INCREASED T=
O 32640.
13.28.52 +IDMS DC010007 V2 T551409 THE NUMBER OF RLE'S HAS BEEN INCREASED T=
O 36720.
13.29.03 +IDMS DC010007 V2 T550832 THE NUMBER OF RLE'S HAS BEEN INCREASED T=
O 40800.
13.29.14 +IDMS DC010007 V2 T550832 THE NUMBER OF RLE'S HAS BEEN INCREASED T=
O 44880.
13.29.21 +IDMS DC027006 V2 T551906
13.29.59 IEA995I SYMPTOM DUMP OUTPUT 186
186 USER COMPLETION CODE=3D3970
186 TIME=3D13.29.21 SEQ=3D41595 CPU=3D0000 ASID=3D0085
186 PSW AT TIME OF ERROR 078D1E00 8000C6A2 ILC 2 IN
186 ACTIVE LOAD MODULE ADDRESS=3D000079A0 OFF
"
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: 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 use lots of storage - but without updates there would be no need for a Rollback. 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 allocations - 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 lots of storage - but only if MAX LINK levels in ADSO statement is set very high!

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

HTH - cheers - Gary



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: Addressing: If you have received this e-mail in error, please advise by reply e-mail to the sender. Please also destroy the original transmission and its contents. Confidentiality: This e-mail may contain confidential information which also may be legally privileged. Only the intended recipient(s) may access, use, distribute or copy this e-mail. Individual Views: Unless otherwise indicated, the views expressed are those of the sender, not Justice Technology Services. Computer Viruses: It is the recipient's responsibility to check the e-mail and any attached files for viruses.

Outcomes