BTS 'corruption' after ontape restore

[This is a re-post from last week. More testing was done, but still no results. Last attempt before turning over to IBM Support] Hi All, We just installed BTS on a Production server. We backed up the instance using ontape, and restored on a different machine. When we tried to use the BTS blade, it always returns Zero rows found. (select * from name where bts_contains(full_name,'TOM');) Trying the same query with LIKE returns hundreds of rows. On the Production server, the bts_contains query also returns hundreds of rows. Specifics: Server: SunOS gravity2 5.10 Generic_150400-20 sun4u sparc (uname -a) Informix: IBM Informix Dynamic Server Version 11.50.FC9 -- On-Line Blade: {fp_tcp} gravity2:/staff/dba> blademgr fp_tcp>list music DataBlade modules registered in database music: bts.2.00 Index Creation: create index bts_name_full on name (full_name bts_varchar_ops) using bts (stopwords='(a,an,as,at,be,by,if,in,is,it,no,of,on,or,s,t,to)' ) in bts_sbspace; Backup/Restore: ontape -s -L 0; ontape -r All onconfigs have SBSPACETEMP = bts_temp and SBSPACENAME = bts_sbspace There are no errors on screen or in the message log during either backup or restore. Has anyone else had this problem with ontape Restores? At first I thought it might be due to the index rowids being in different places, but ontape is a binary restore, so all page layouts should be identical to Production. Thanks, Michael Hoffman