Discussion created by ca.portal.admin on Sep 30, 2008
I feel there is a need to clear up some confusion circulating about the
effect of the latest apars related to VIA clustering by the

Prior to the apars the first three fields within the key used to sort
the intermediate file passed to the IDMSDBL2 step were the new target
page, a sequence number, and the record's old dbkey. For VIA records
not stored VIA a system-owned index, the sequence number field was not
used meaning that all VIA records targeting to a particular page were
sorted within the new target page number by their old dbkey. VIA
clusters for multiple owners targeting to the same page could be
intermixed and if all the VIA records targeting to one page do not fit
on the target page there is no guarantee that any one owner's cluster
would not experience some overflow occurrences. (A part of the sequence
number field is used to insure that CALC and DIRECT records get sorted
ahead of VIA records to increase the probability of them being stored on
their target page.)

As a result the physical sequence of the VIA records stored within the
new database did not match the set's logical sequence. This had no
effect on the overall number of pages needed to contain a page's VIA
records. However when walking a long set it could result in the need to
move between the pages containing the records multiple times. This
could increase a run-unit's PAGES REQUESTED statistic. Each count to
PAGES REQUESTED means that module IDMSDBMS needed to call module
IDMSDBIO to look for the requested page within a buffer. This overhead
is generally very small when the page resides in a buffer but it is none
the less some additional CPU cycles.

The recent apars cause the unload processing to place a sequence number
into the sort key. The sequence number is assigned for a cluster
relative to the owner of the set. For example if record A is a CALC
record which owns record B as a VIA record and record B owns record C as
a VIA record the sequence would be kept through the processing of all of
the record occurrences as the unload process walked the sets. If record
A also owned record D as a VIA record the sequence number would be
restarted for the D record occurrences. This does mean that the sorted
file passed to IDMSDBL2 could still have occurrences of record D
interspersed with occurrences of record types B and C. As prior to the
apars it is also still possible for VIA occurrences for multiple owners
targeting to a specific page to be interspersed.

It should also be noted that records stored VIA a user-owned index have
always been treated in the same manner as records stored VIA a chained
set. Prior to the apars the sequence number field was not used for
these VIA records. The apars will now insert the sequence number into
their sort key as is done for records stored VIA a chained set.

The number of pages required to contain all of the records targeting to
a particular page will not change with the implementation of the apars.
The only difference will be that the order the records will be stored
into the database will match the logical order of their VIA set. This
should allow a better physical progression through the database when
walking the set(s) and possibly reduce the number of calls from IDMSDBMS
to IDMSDBIO when a record is accessed thereby reducing a bit of CPU
overhead. I do not expect the CPU reduction to be anything particularly
significant but any possible improvement in performance is something we
will always be willing to investigate.

Dick Weiland


Senior Sustaining Engineer

CA-IDMS Level-II Support
IDMS Public Discussion Forum


"Hello Dick:

Thank you for the clear and concise explanation.

William M. Allen, Jr.
ARCH Consulting Associates, Ltd.
(704) 641-0296