On 03-Feb-2014 10:57 -0800, Alan Campin wrote:
<<SNIP>> If you delete a record, does the index size decrease?
I am getting indications both way, that it keeps the deleted record
in index and logical indexes and other stuff that seems to say it
deletes the record from the indexes.
Any links to share what apparently so muddles the issue? However
depending on the wording, both may be true. A delete record is not
tracked to the index, but the actual tracking of the since-deleted row
also is not purged entirely from the index.
Create a simple scenario, dump the index in STRSST D/A/D, delete a
record, then dump the index again; review the difference.
I found IBM's information on calculating index size but it only says
number of records and nothing about deleted record.
It would seem logical that it would not keep an entry in the index.
When a dataspace index is built, deleted records are ignored; i.e. no
data, no index entry.
Effectively, a DataSpace Index [*QDDSI] object can only grow. A
deleted record is no longer tracked to the index. The node that
formerly tracked the RRN is defunct; at least until that key value is
That is effectively the same situation for all index object types,
because the underlying LIC IX index object, upon which other "index"
object types are built, provides no method to decrease the size. An
index object [with a visible manifestation to a user] will appear to
decrease in size when the interface to that index enables a means to
effect something like a rebuild, truncate, or reorganize feature for its
underlying IX implementation object.
For a Library (*LIB) object [implementation object is a LIC IX
object], that rebuild is available only with Create Library (CRTLIB).
Having created a new IX index for the LIC Context [aka Library] object,
into which objects can be created, restored, and moved, the index is
filled [via INSOBJ] with each new object name\type\subtype combination
as a new entry in that index.
For the database dataspace index [implementing the keyed Access
Path], changing the index maintenance to *REBLD and then back to *IMMED
should re-create a new underlying index [though the *QDDSI is the same
object], thus decreasing the size. Similarly the old-style Reorganize
Physical File Member (RGZPFM) [with ALWCANCEL(*NO)] will rebuild the
non-unique index\access-paths. I expect also, the Force rebuild of
access path (FRCRBDAP) on Change Logical File (CHGLF). For sure,
creating a new index [that does not share] will create the index with
what is effectively its minimal size [although like a dataspace, likely
there is room-for-growth implicitly created, to avoid the need for
adding more space when the first or first few entries are added].