Step 8: Generate the File Pool

Before starting this step, make sure you have your virtual device numbers nearby. Now enter:

fileserv generate

FILESERV GENERATE does the following:

Issues CMS FORMAT and RESERVE commands for the file pool minidisks (including the CRR log minidisks, if this is a CRR recovery server).
Depending on the number and size of your initial minidisks, this could take quite a bit of time.
Initializes the file pool minidisks (including the CRR log minidisks, if this is a CRR recovery server).
FILESERV GENERATE processing places internal control information on the file pool minidisks. This control information is needed for usual server operation.
Creates the POOLDEF file.
The POOLDEF file has a file name that is the same as the file pool ID you picked in the last step. The file type is POOLDEF. FILESERV GENERATE processing creates the file on the first read/write file mode in the server machine's search order, which happens to be the 191 work disk.

During its processing, FILESERV GENERATE calls XEDIT to display a file containing control statements. The file is named $$TEMP $POOLDEF. It is a copy of an IBM-supplied sample POOLDEF file named DMSIBM POOLDEF. (FILESERV GENERATE makes the copy during its processing.) Your screen looks like this:

 $$TEMP   $POOLDEF A1  F 80  Trunc=80 Size=10 Line=0 Col=1 Alt=0
 
 
 
 
 
 
 
 
===== * * * Top of File * * *
      |...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
===== MAXUSERS=1000
===== MAXDISKS=500
===== DDNAME=CONTROL         VDEV=301
===== DDNAME=LOG1            VDEV=302
===== DDNAME=LOG2            VDEV=303
===== DDNAME=BACKUP   DISK   FN=FILEPOOL   FT=BACKUP   FM=*
===== DDNAME=MDK00001        VDEV=304      GROUP=1     BLOCKS=0
===== DDNAME=MDK00002        VDEV=305      GROUP=2     BLOCKS=0
===== DDNAME=CRR1            VDEV=306
===== DDNAME=CRR2            VDEV=307
===== * * * End of File * * *
====> _
                                                            X E D I T  1 File

You need to modify the file to describe your file pool as follows:

Change the MAXUSERS value to the value you chose in Step 1: Estimate the Maximum Number of Users (MAXUSERS). If, for example, you chose a MAXUSERS value of 2000, you would change that line to:
```
MAXUSERS=2000
```
For most repository file pools, the value in the file (1000) is a good choice. For dedicated CRR recovery or FIFO servers, specify a value of 5.

Note: Only one MAXUSERS control statement is allowed in the file.
Do the same for the MAXDISKS value. If, for instance, you chose 175 for MAXDISKS, you would change the line to:
```
MAXDISKS=175
```
For most repository file pools, the value in the file (500) is a good choice. For dedicated CRR recovery or FIFO servers, specify a value of 2.

Note: Only one MAXDISKS control statement is allowed in the file.
Change the virtual device numbers (VDEV=nnnn) for the control minidisk (301), the file pool repository log minidisks (302 and 303), the catalog minidisk (304), and the CRR log minidisks (306 and 307) to the virtual device numbers you used on the MDISK statements, see Step 4: Define a Server Machine.
Note: This example assumes you defined only one catalog minidisk, as was recommended in Step 3D: Determine the Catalog Minidisk Allocation.
If you used virtual device number 250 for the control minidisk, 405 and 406 for the file pool repository log minidisk, 260 for the catalog minidisk, and 505 and 506 for the CRR log minidisks, you would change the file to this:
```
⋮
===== DDNAME=CONTROL        VDEV=250
===== DDNAME=LOG1           VDEV=405
===== DDNAME=LOG2           VDEV=406
===== DDNAME=BACKUP   DISK  FN=FILEPOOL  FT=BACKUP   FM=*
===== DDNAME=MDK00001       VDEV=260     GROUP=1     BLOCKS=0
===== DDNAME=MDK00002       VDEV=305     GROUP=2     BLOCKS=0
===== DDNAME=CRR1           VDEV=505
===== DDNAME=CRR2           VDEV=506
⋮
```
Note: The line containing:
```
===== DDNAME=MDK00002       VDEV=305     GROUP=2     BLOCKS=0
```
has not yet changed. It is for a user data minidisk. This line will be updated in step 5.
The BLOCKS parameter is automatically handled by the server; you do not need to modify it. See FILESERV GENERATE for more information on the BLOCKS parameter.
This example assumes you are backing up the control. If you want to use tape, change the line containing DDNAME=BACKUP to this:
```
DDNAME=BACKUP TAPE VDEV=181
```
If you want to back up to DASD instead, you have a few choices to make regarding the destination of the output file. You also need to ensure there is enough DASD space to contain the backup file. If you have a tape drive available, it might be easier to specify a tape drive for now and switch to DASD later. If, instead, you prefer to use DASD immediately or there is no tape drive available, change the line containing DDNAME=BACKUP to:
```
DDNAME=BACKUP   DISK  FN=FILEPOOL  FT=BACKUP   FM=B
```
The only change made is a replacement of FM=* with FM=B. You can also change the file name and file type if you wish.

The control statement above identifies FILEPOOL BACKUP B as the file that is to contain the control data backup. You can specify any file mode letter for *, so long as there is sufficient space on that file mode to contain two copies of the control data backup. Do not leave *, in the file—replace it with some file mode letter. (Global file ID characters are not supported for the definition of the backup file.) This will allow you to get through file pool generation, but you should refer to Backing Up The Control Data for DASD considerations before attempting to back up the control data. (The destination file can be easily changed after the file pool is generated.)

Note: For a CRR recovery server, IBM recommends you do not back up control data and therefore you would delete the line containing DDNAME=BACKUP. But, in this example, the server shown is performing both repository file pool server and CRR recovery server functions, which is not recommended. Therefore, you would keep the line containing DDNAME=BACKUP for this server's repository file pool functions.
If you have allocated only one user data minidisk, change the virtual device number in the line containing DDNAME=MDK00002 to the one you specified on the MDISK statement. If you allocated more than one, as in this example, you need to duplicate this line. Suppose you defined four user minidisks. You would enter:
```
=3"== DDNAME=MDK00002       VDEV=305     GROUP=2      BLOCKS=0
```
Then press enter. You see:
```
===== DDNAME=MDK00002       VDEV=305     GROUP=2      BLOCKS=0
===== DDNAME=MDK00002       VDEV=305     GROUP=2      BLOCKS=0
===== DDNAME=MDK00002       VDEV=305     GROUP=2      BLOCKS=0
===== DDNAME=MDK00002       VDEV=305     GROUP=2      BLOCKS=0
```
Now change the virtual device numbers to match those in your MDISK statements. You should also change the MDK00002 value to ascend in sequential numeric order (MDK00002, MDK00003, MDK00004,. . . , MDKnnnnn). Suppose you used virtual device numbers 310 to 313 for the user data minidisks. You would modify the statements to look like this:
```
===== DDNAME=MDK00002       VDEV=310     GROUP=2      BLOCKS=0
===== DDNAME=MDK00003       VDEV=311     GROUP=2      BLOCKS=0
===== DDNAME=MDK00004       VDEV=312     GROUP=2      BLOCKS=0
===== DDNAME=MDK00005       VDEV=313     GROUP=2      BLOCKS=0
```
Note: For a CRR recovery server, you would only want to allocate one user data minidisk. In this example, four user data minidisks were allocated because it is for the generation of the not recommended combined repository file pool server and CRR recovery server.

Finally, you should decide whether you want to assign the minidisks to different storage groups. The primary reason for doing this is to make recovery procedures more convenient. Storage groups are the units used when you need to back up user data. If you assign all your user minidisks to a single storage group, you must back up all the user data at the same time. For a large file pool, this is not desirable. Many people prefer to keep the amount of DASD assigned to a storage group to a manageable size.

Another reason you might want to assign minidisks to different storage groups is to control where the user data resides. Storage groups provide the only mechanism of control over where file pool data resides on physical volumes. When users are enrolled, they are given space in a particular storage group. If you know only IBM 3380s are assigned to that storage group, you know all users assigned to that group are using those 3380s. One reason for doing this is to separate fast devices from slower ones.

One last consideration for storage groups is that it lets you cluster, in the file pool, groups of related users or applications. If, for example, your file pool was to serve a set of inventory control applications, a few personnel departments, and a few design departments, you might consider using three storage groups—one for each.
Suppose minidisks 310 and 312 are defined on IBM 3390s while 311 and 313 are defined on IBM 3380s. You have a set of engineering applications you would like to support that logically belong together and you would like to use the IBM 3390s. You decide to put minidisks 310 and 312 in one storage group, and minidisks 311 and 313 in another. You would modify the GROUP operand on the statements to reflect this:
```
===== DDNAME=MDK00002       VDEV=310     GROUP=5     BLOCKS=0
===== DDNAME=MDK00003       VDEV=311     GROUP=2     BLOCKS=0
===== DDNAME=MDK00004       VDEV=312     GROUP=5     BLOCKS=0
===== DDNAME=MDK00005       VDEV=313     GROUP=2     BLOCKS=0
```
Remember storage group 1 is reserved for the catalog data. Do not assign user minidisks to storage group one. Also notice that storage groups do not need to be used in ascending numeric sequence. You can use storage group 5 without having first used storage groups 3 and 4.

For repository file pool servers, when it is time to enroll users, the administrator of this file pool would give space in storage group 5 to those using the engineering applications. Other users would be given space in storage group 2.

After making your changes, enter:

file

FILESERV GENERATE processing continues using the control statements you specified.