ca.portal.admin

IDMS 16 test Apars T5B0169/T5B0171 for Unload/Reload and

Discussion created by ca.portal.admin on Sep 24, 2008
Latest reply on Sep 27, 2008 by ca.portal.admin
T5B0170 for Reorg

Hi,

=20

T5B0169 talks about poor VIA clustering when using Unload/Reload for 16
SP2/3/4/5/6/7. It implies that the clustering of chained VIA sets could
have a performance hit especially if the set is large. T5B0171 is for
SP0/1. T5B0170 is the equivalent for using the Reorg utility introduced
by SP4.=20

=20

Did anyone on the list get these fixes raised and if so could I get an
idea of how bad the problem might be?

=20

Thanks

=20

Chris Wood

Alberta Department of Energy

CANADA
*****JuliusBaer Disclaimer***** This e-mail is for the intended =
recipient only and may contain confidential or privileged information. =
If you have received this e-mail by mistake, please contact us =
immediately and completely delete it (and any attachments) and do not =
forward it or inform any other person of its contents. If you send us =
messages by e-mail, we take this as your authorization to correspond =
with you by e-mail, however, we will not accept the electronic =
transmission of orders/instructions without a specific agreement being =
in place to govern the same. If you do not wish to receive any further =
e-mail correspondence please let us know. E-mail transmission cannot be =
guaranteed to be secure or error-free as information could be =
intercepted, amended, corrupted, lost, destroyed, arrive late or =
incomplete, or contain viruses. Neither the Julius Baer Group nor the =
sender accept liability for any errors or omissions in the content of =
this message which arise as a result of its e-mail transmission. Please =
note that all e-mail communications to and from the Julius Baer Group =
may be monitored. This communication is for informational purposes only. =
It is not intended as an offer or solicitation for the purchase or sale =
of any financial instrument or as an official confirmation of any =
transaction.
"
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.

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

Outcomes