There is a noticeable CPU increase after applying FIC in our database, and I have heard of increases of CPU in the order of 6% with FIC at other sites.
Whether this has an impact on elapsed times for real user work would depend on whether any elapsed time savings due to reduction in I/O were greater or less than the CPU cost. Any idea how to assess this retrospectively?
If I had thought about it in advance I would have set up a standard job as a benchmark and would have tested before and afterwards… but now it is too late.
Forward Index Compression (FIC) exists now for many years in Adabas and so far nobody has shown to Software AG that it was accompanied by a measurable increase in CPU consumption.
Software AG and many customer have done a lot of tests to proove this point.
We had a few claims in this direction a couple of years ago, all of them could not be substantiated and some of them could actually to be proven to be outright wrong.
It is not that FIC can be done without any instructions, but the implementation was done very carefully and efficiently and the savings in instructions at other places (e.g. less references to blocks to get to a specific RABN for a record on average) counterbalanced this effect.
Even the 6% rumour is wrong and certainly far too high.
If course if you exactly knew how the implementation works internally you could probably set up a very specific job, which might encounter a 6% CPU overhead in Adabas. But this is not what happens in reality.
If you still believe you have a point set up two dedicated test databases, idential except for FIC, and run some indentical tests on both of them.
Adabas does record the CPU consumption in its shutdown statistics.
Please sent them to me
We had a few claims in this direction a couple of years ago, all of them could not be substantiated and some of them could actually to be proven to be outright wrong.
Natural’s LIST COUNT command should give you the first two answers (per Natural library).
ps You should have posted your question as a new thread in a Natural forum, such as Natural on Mainframes, rather than attach to an existing Adabas thread.