ca.portal.admin

""Decompilation"" of IDD table load modules.

Discussion created by ca.portal.admin on Oct 10, 2007
Latest reply on Oct 10, 2007 by ca.portal.admin
<snip>
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: [IDMSVENDOR-L] Space Reserved on a Page
"Adding to Chris's statement of IBC on indexes. I have the impressing you have indexes, CALC and Via in this area. Keep in mind if your CALC keys are skewed and not really uniform spreading out (some Calc data can cause this to happen) then again trying to distribute your data will be difficult. If the via's off of your CALC keys are skewed in the number of VIA's stored off the CALC key then this will make even distribution impossible as well, for you will again have ""hot spots"".

Edward A. Timm
Sallie Mae, Senior Database Analyst
ETIMM@salliemae.com
(317) 596-1182
Fax (317) 595-1494
Chris Hoelscher <choelscher@HUMANA.COM> 10/10/2007 12:35:20 PM >>>
well, let me add my thoughts:
depending on the IBC of the index (and the number of sr8s) it may be
impossible to get a good distribution. SR8s are VIA records to the SR7, so
the will always be some clumps
suggestions?
if spread out is what you really want, increase page reserve until the SR8s
are forced off the target page, and/or make the SR8s smaller (and more of
them) so that placement of 1 on a page does not drastically skew its %full

i am not sure either of these suggestions are good, but since i am not sure
why even distribution is overriding everytthing else, these are the onyl
suggestions I can make

thanks
chris hoelscher








I have been working reorging an area and trying to get a uniform
distribution of data across the pages. What I am ending up with is that
35 percent of the pages have less than 10 percent space left on them. I
have tried page-reserve and displacement (because there is an index in
the area), but still DBAN shows that 35 percent of the pages have less
than 10 percent space left on them. I am using CA's Reorg tool and have
53 percent free space after the reorg. I can't do an unload/reload due
to the number of pointers in the area.

Any ideas?

Will Hathcock
Database Administrator

We are what we repeatedly do. Excellence then, is not an act but a
habit. - Aristotle


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.

This E-Mail has been scanned for viruses.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Not A Runaway ?
"
An IDMS online task used over 9 hours of CPU time before abending at our nightly cycle time. This occurred even though we have RUNAWAY INTERVAL IS 15 in the sysgen. I understand that the runaway timer is reset each time a database call is made, but only 6 DB calls were made (see below).

The field user said his whole PC locked up and he rebooted. He got the ""user already signed on"" message for a while but said that later he was able to sign back on and continue processing.

So how could this happen without being detected as a runaway, and what can be done to stop this in the future? (Short of sitting someone in front of an OPER session all night!)


CPU WAIT
DIALOG VER TASK C START STORAGE STORAGE TIME TIME
NAME NUM NUM C TIME ACTIVE KEPT (SECS) (SECS)

WKCI410D 1 808881 X 16:04:46 23808 28800 5,262.8409 5,863.3967


TP TP NUM NUM NUM NUM NUM
READ WRITE OF OF OF OF OF
LNGTH LNGTH I/O DBCLS LVLS DBLVLS BUFS

0 0 0 6 1 0 1
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Not A Runaway ?
"My bet is on a corrupted database and the cpu time is idms looping
through a broken chain. Run IDMSDBAN on the areas in the dialog and
their index areas.


Lutz Petzold

This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Not A Runaway ?
"One possibiity:

IDMS typically won't abend a task while it is executing in system mode. It
waits to kill it when it returns to the user program. If it never returns
to user state, it never dies.

In certain cases you can get a loop entirely within system mode (internal
bug in IDMS, or broken chain).

In these cases external monitors (such as Pre-Alert) MAY be able to detect
and kill this sort of runaway.

Don Casey
Run Right, LLC

Outcomes