HPlogo Communicator e3000 MPE/iX Release 7.5 PowerPatch 1 > Chapter 3 Technical Articles

TurboIMAGE B-Tree Behavior Clarification

MPE documents

Complete PDF
Table of Contents
Index

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.




Ultra160 SCSIHBA (A6828A/A6829A) Support on MPE/iX


Index