The overall storage allocation within one MUF (without shadow) is therefore neutral. However, with just this one set of buffer pool definitions, MUF start-up is significantly slower and CPU usage (general processor) is high (CPU spinning to 80%+ for both primary and shadow start-up).

Alternate buffer pools add some overhead to the process and that is expected due to acquiring additional storage for each buffer pool content one defines. As MUF starts up the MUF acquires the storage pools in junks.

Resolution:

Since the concern is about GP CPU usage, what you can do to move from GP/CP time to zIIP time:1. Code small values for buffer content…for number of buffers like 1 or 2 or 10 during MUF startup.2. Once MUF enable use the MUF console API to add to the buffer content pool .That action will run under zIIP CPU.

We cannot define the buffer pool after MUF startup but you can control the number of buffers and what DBID share that buffer pool through the MUF Console API This process above of adding buffer pools can run as soon as MUF enables so you can use MVS OPS to drive this activity to grow the buffer pools under zIIP. All of this is predicated you do not mind using zIIP CPU and want to reduce GP/CP time.You see the console commands running under zIIP engines (SRB’s) when this runs.