Stephen, Do I understand the formula and definitions correctly? > > You do, but that's just to get you started. It really all depends on how many objects are going to be created in that file pool. So, take that formula as an attempt to predict the future.
MAXUSERS determines the logical size of the catalog and that formula is MAXUSERS * 85 (and that's a real formula). Half of that goes to data blocks and half to index blocks. The physical size of the catalog (number of blocks in group 1) can initially be much smaller than that. That smaller space would again be divided equally to data and index blocks. It is much easier to add another minidisk to group 1 (when you hit physical limit) than to do regenerate file pool (when you hit logical limit). Therefore, allocate MAXUSERS generously, so that you don't have to do this again soon. In your case, you have 640 cylinders in group 1 (16 * 40 cyl), which equates to 115200 blocks. You may have over-allocated group 1, but to decrease that now would be a pain, so leave it. To be able to use all that space, the logical size of the catalog has to be at least that much, so MAXUSERS must be at least 1356, which is 115200 / 85, rounded up. I would suggest that you use at least 5000 if not 10000 for MAXUSERS. Over-allocating MAXUSERS is not harmful, it just takes a bit of space in control minidisk. Size of control minidisk (or of the rest of it) determines the number of potentially addressable blocks in the file pool (maximum size to which the file pool can grow to). You can see that number if you do QUERY FILEPOOL OVERVIEW, but roughly, it is a bit less than one million addressable blocks for each control disk cylinder. There is no formula for this, because other things go to control disk as well (MAXDISKS has a hand in it too), but for example (roughly again), with a 50-cylinder control disk you will be left with at least 45 million potentially addressable blocks, which equates to around 75 3390 mod3's. That's the maximum size of disk space that you will ever be able to have in the file pool before having to regenerate it. While regenerating file pool, you will have to increase the size of the control disk. You have to do this to allow for the increase of MAXUSERS in order to maintain at least the same number of potentially addressable blocks. Increase it by 25-33% to be sure, but do *not* over-allocate control disk. Whenever the file pool server performs control data backup (and it does it automatically when log disks fill up more than 80%), the file pool will be unavailable to end users for the duration of the backup. You want that backup to be quick especially if your log disks are small and the backup is run often. Control data backup backs up *entire* control disk and *used* blocks in group 1 (catalog). Therefore, over-allocating group 1 is OK, but over-allocating control disk is not. Follow the procedure to regenerate a repository file pool to which you have been pointed to already and you'll be fine. One final word of advice though: before doing anything like this, make sure that you also have a reliable backup of the whole file pool (storage groups 2 and above) handy. Ivica Brodaric BNZ
