I agree with Rainer, Fastpath and ADACache are different and complementary. I also agree that they use different system resources. Fastpath uses ECSA; ADACache usually uses the 64-bit area these days.
Both products cache data, in different ways.
Fastpath caches outside of Adabas. Therefore the data it caches is decompressed; it has already been through all the format translation, decompression, IO, thread-scheduling, ADACache, etc processing. Therefore any element cached by Fastpath, and then reused to service another command gives a vast amount of savings, nsmely all of the processing I mentioned already. This is a very positive return from the Fastpath cache (called optimization). This is high-value cache usage. Think of Fastpath as the front-line cache, if it services a command things are really great. But Fastpath can’t do everything, some things have to fall through to Adabas of course.
The remaining commands (traffic) that hit Adabas can then be made more efficient if ADACache can service IO requests rather than going to disk. This is a back-end cache; as Rainer says it saves IO. Anything ADACache saves still has to go through decompression, format translation etc. And again Rainer is correct, ADACache will be much more likely to use greater amounts of different resource; so if real memory is short then it will potentially contribute to paging. So real-memory is the first thing to make available, but not by reducing the different resources used by Fastpath.