ca.portal.admin

Re:Delete Users?

Discussion created by ca.portal.admin on Sep 25, 2008
In cleaning up some old users in OCF, I found these three that I'm not
sure about. Are these part of IDMS's internals, or can I delete them? =20
TIA - Jerry

'CULL DBA'
'PROD DBA'
'SYSTEM '
"
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: IDMS 16 test Apars T5B0169/T5B0171 for Unload/Reload and T5B0170 for Reorg
"Hi Listies

It was me.

Before I explain can I just ask that we don't start a long discussion
about why the physical design is not optimal.

Anyway, we have a structure whcih is a simple CALC owner and a member
which is stored VIA in the same area. The set is a sorted set and new
records come in in a random manner. Originally the expectation was for
the cluster size to be about 30 records whcih all fit on the same page
as the owner.

Later somebody had the bright idea of using the structure for an
occurrence which was vastly different from the original concept. In this
occurrence the set contained about 10,000 records. In this occurrence
the via set spread down the area over about 700 pages. This would be
Ok'ish if the set was physically stored in the logical order. In this
case you would obtain the owner and then walk the set which would be
similar to an area sweep.=20

But as the records were stored randomly IDMSDBAN showed that the Chain
Length was 10,000 and the Page Change statistic was around the same. So
Pages requested to read the set was 10,000 even though only 700 pages
had records. I thought by doing an Unload/reload on it that it would
reload back to the optimal situation and so I could get back to 700
Pages Requested. I was wrong.

Unload reads the records in the set in the existing physical order of
the set and puts the suggested new dbkey of the owner record in the
unloaded record. But it doesn't put a sequence number within the set
into the unloaded record. This sequence number field already exists but
is only implemented for system-owned indexes.

The result of not having the sequence number results in the sort before
IDMSDBL2 treating all members of the set as duplicate keys and so it
leaves them in the same order. IDMSDBL2 then stores them in the area
almost exactly how they were - only backwards. A post Reload DBAN shows
10,000 page changes still.

I didn't want this so I reported it. In the meantime I wrote a Sort-Exit
to post process the Unload SYS002 file and put the sequence number in.
Reload then ran perfectly and DBAN reported 700 Page Changes for the
set.

My solution worked but it meant writing a sort exit for each unload. A
PITA. Dick Weiland created the T5B0170 fix to put the sequence number in
and now it works just fine, I can throw my sort exit away.

So this affects very long Via clusters which spread over multiple pages
and are stored in a Sorted order. If you store First or Last then it
isn't a problem. Also if your buffer is big enough to hold the whole
cluster then it isn't so bad but you still generate more CPU than you
would like.

I hope that clears it up.

Chris Trayler =20

Outcomes