I am in the  middle of researching  bcheck for repairing possible corrupt future c-isam files.  I am not even sure it can do that.

Anyway I came across this:

this is from http://support.proiv.com/V6_Help/environmentguide/syntax.htm

Trail: PROIV Documentation > Administration > Environment Guide > Syntax

bcheck -[ i | l | y | n | q | s ] filename

where filename does not have suffix .idx or .dat.

Options

-i             Check index file only
-l             List entries in B+ trees
-n            Answer no to all questions
-y             Answer yes to all questions
-q             Suppress printing of the program banner
-s             Resize the index file node size

Unless you use the -n or -y option, bcheck is interactive, waiting for you to 
respond to each error it finds.

...
When running bcheck -s, the index created on a UNIX platform will have an uppercase extension.  This will cause subsequent BCHECKs of the file to display the message ‘Error
 linking .IDX to .idx’.  To avoid this situation, delete the file name with the lowercase extension, and rename the remaining file, changing only the case of the file exten
sion.

here is a testing using bcheck -s :

~/tmp $ ll
total 8
-rw-r--r-- 1 rob pro 1024 2018-04-15 07:53 dm_trfle.dat
-rw-r--r-- 1 rob pro 3072 2018-04-15 07:53 dm_trfle.idx
localhost pro4 ~/tmp $ 
localhost pro4 ~/tmp $ 
localhost pro4 ~/tmp $ bcheck -s dm_trfle

BCHECK  C-ISAM B-tree Checker version 7.24.UC5  
Copyright (C) 1981-1997 Informix Software, Inc.
Software Serial Number UMD#J999999


C-ISAM File: dm_trfle

Old index node size = 1024
Key node size = 18
Checking dictionary and file sizes.
Index file node size = 1024
Current C-ISAM index file node size = 1024
Checking data file records.
Checking indexes and key descriptions.
Index 1 = unique key  (0,2,0) 
    1 index node(s) used -- 1 index b-tree level(s) used

ERROR: 10 missing data record pointer(s)
Delete index ? yes

Remake index ? yes

Checking data record and index node free lists.
Recreating index 1.
3 index node(s) used, 0 free -- 10 data record(s) used, 25 free.


localhost pro4 ~/tmp $ ll
total 12
-rw-r--r-- 1 rob pro 1024 2018-04-15 07:53 dm_trfle.dat
-rw-r--r-- 1 rob pro 3072 2018-04-15 07:54 dm_trfle.idx
-rw-r--r-- 1 rob pro 3072 2018-04-15 07:53 dm_trfle.IDX

Questions

-  what is the purpose of  "bcheck -s "   ?      I hope it is not to repair a file as there are a few file renaming steps to do after fixing a file.

- is there a way to name files in pro4 to be compatible with  bcheck  [ using upper case ?]   I'll test further however  pro4  seems to always name .dat and .odx lower case.

- is Rob D's  'defrag' utility a replacement for 'bcheck -s ' ?

best regards, rob

HI Rob,

If you don't have the C-ISAM manual, there's an older one online here: http://informixsoftw... Version 50.pdf

Mostly it's aimed at C programmers but bcheck is covered by Appendix A at page 270.

bcheck cannot repair data files, but the structure of C-ISAM data files is trivial provided you are using fixed length records, there is no real sense in which they could be repaired, only restored from your backup!

bcheck also cannot "repair" indexes but what it can do is entirely replace any damaged indexes by rebuilding them from scratch from the data file (if you answer relevant prompts in the affirmative presumably).

I don't think the purpose of bcheck -s is to repair anything, it appears to be to perform some obscure resizing operation within indexes (I have never used it and am merely reading the manual.)

I think the uppercase .IDX thing is purely an "staging" output of bcheck -s where, for some reason, the final step of the resizing requires you to manually replace the 'old' .idx file by renaming the 'new' .IDX as '.idx'

Best I recall, everything is always lowercase .dat and .idx and I don't think you need to worry about uppercase unless you use this obscure -s option and I'm not clear when/why one needs to do that.

thanks for the reply.  i already have the manual , will read that section sometime soon.

> bcheck cannot repair data files, but the structure of C-ISAM data files is trivial provided you are using fixed length records, there is no real sense in which they could be repaired, only restored from your backup!

 that is amazing.   

   i realize now that our backup and restore strategy needs an update .   for instance payroll , accounts receivable are all backed up together.  separate data directories are needed for sub systems for manageable restores.

 using zfs snapshots  and something like napp-it  to manage restores may make this semi easy.

Richard got most of it...

As for my defrag, this is what it does:

Reads the file in key order, and then writes out a new file in that order.

What this does is remove any 'deleted' records that haven't been overwritten yet, puts the .dat file in key order so makes accessing seq records quicker (and possibly in the same block read), and reduce the size of the .idx file as it is packed better if its in order and reduces BTREE levels, which makes indexing faster.

All of this helps performance and also reduce the size of the files.

As far as I am aware, there is no other util that does this, and I would strongly recommend that this is done on the whole system every 6 months or so. (Note: System must be 'offline' to do this)

The bcheck -s thing resizes the index node. I looked into this some years ago, and could not find any particular increase in performance changing this. The biggest saving is defragging. 

we've been using your defrag utility since 2007  .   it just works great.

I have another question.

As Richard stated we should not compress the .dat files.      that in order for potential non pro4 programs to read the files.

Does the same hold true for the index files?

 Or to guarantee compatibility with other programs should we leave all uncompressed?

Great!

I would use compress on indexes, yes.

If any external system is also referencing the compressed files, then they should be using the standard C-ISAM routines, which will allow them to access them fine with the COMPRESS flags set.