John Alleyn-Day writes:

> I am presuming that none of these are considerations with NM KSAM except
>  for 2, but it would be nice to know for sure.
>
>  It seems to me that there will be subtle performance hits.  Sorted lists
of
>  names were often done with a KSAM file that used detail set record numbers
>  to find the record.  Any use of Image B-trees will necessititate a
separate
>  master record for each unique name and could result in many more master
>  records being created.  Any file on which you want to create a B-tree must
>  first be given a new automatic master which will add to the overhead on
>  every new record added.  As they say, "there is no free lunch".  Superdex
>  avoids this by creating B-trees on details as well, and I believe that
>  Omnidex operates similarly.  Neither of these require the use of the Posix
>  name-space either.
>
>  Another major performance hit that occurred in CM KSAM was the creation
and
>  deletion of branches, leaves and levels.  I don't think you can have a
>  B-tree without these processes and they can have some VERY significant
>  effects on performance.  This was of particular concern if the dataset was
>  very volatile as one of mine was.  Does anyone know how the B-trees work
in
>  Image and can make a comment about that?  CM KSAM had some esoteric
>  parameters that could be adjusted so that these kinds of changes
>  (particularly level creation and deletion) were reduced to a minimum. Does
>  one have the same considerations in Image B-trees?
>
>  P.S.  This was actually written several days ago, but got stuck unnoticed
>  in my out-box.  The questions are still relevant however.

I wholly agree; the questions are still relevant. But as to performance, I
can only say that: (i) as I earlier outlined, the theoretical performance
should be quite excellent, and (ii) wait and try it out yourself against real
datasets -- and judge for yourself.

As to putting an automatic master on every detail item that you would like to
have a b-tree appear on, Superdex and Omnidex do the equivalent, it's just
that you don't see them explicitly outlined in the schema. Worse yet, the TPI
indexes aren't shareable, dataset-to-dataset, in the way that the new
master-oriented b-tree datasets inherently are. If you index a new dataitem
in one detail dataset, using Adager (or similar) and add a b-tree to that
newly created master, you can feel somewhat free to index that same dataitem
in other datasets as well (so long as you use the same automatic master). The
indexes in these additional datasets are only costing you a very little
additional load. The first dataset pays almost all of the price -- but that
price alone, as you'll see, will tend to be rather low.

Wirt Atmar