Communicator e3000 MPE/iX Release 7.5 PowerPatch 2 (Software Release C.75.02) (30216-90352)

Chapter 3

Technical Articles

TurboIMAGE B-Tree Behavior Clarification

by Tien You Chen, MPE/iX Lab

Possible Confusing Behavior

TurboIMAGE has supported B-Tree indices since C.07.00. Even though a user can create a B-Tree index only

on the master data set’s key item, s/he can perform index searches using all of its corresponding detail data

set search items as well. Users can now call DBFIND to perform a generic key search on a master data set, then

chained DBGETs to return all the qualified records. Confusion arises when a user calls DBFIND on a master

data set but, before or between the chained DBGETs of those qualified records, s/he calls another DBFIND on a

detail data set using a search item linked to the master currently being accessed chained. This DBFIND will

reposition the chain pointer on the master. As a result the user may get an ‘end of chain’ status for the next

DBGET to the master data set. Since these two DBFINDs are finding against two different data sets, the user is

amazed at the interference between these two.

What to Expect and How to Solve

Because only one KSAM/iX file is attached to each master data set, all B-Tree access for related detail data

sets also goes, via the master data set, to the same KSAM file. Since there is only one logical record pointer in

the KSAM file, a new DBFIND, which positions the logical record pointer, affects the current reading. In

addition, the internal runtime data structure, though allocated one per data set, is still affected. Therefore,

even if the second DBFIND on the detail data set is not a B-Tree DBFIND, many flags in the runtime data

structure are reset. The next DBGET to the master data set acts as though there was no previous B-tree

DBFIND to the master.

This combination of access methods, mixing DBFIND/chain DBGET to a master with DBFIND/chain DBGET to a

detail using a path to that same master, is not common. We suggest the user call a second DBOPEN to handle

the second DBFIND. However, please remember the second DBOPEN is needed only when calling DBFIND on a

detail chain while still performing chained DBGETs on the related master data set.