Ranga, It can be somewhat confusing at first. However, it is simpler than you think. Regions are a holdover from older disk devices, as Alan mentioned. However, they are still useful. If you are going to allocate minidisks on disk volumes (as opposed to dedicating full volumes), you need to define the volumes in the region list in EXTENT CONTROL. There is no way to add these using a dynamic command. However, you can predefine volumes in the list and then just not use them. So, it is safe to put a lot of volumes in the list and then you don't have to change it very often.
The "type" colume of the regions section refers to what kind of disk volume it is. There are predefined "types" in the Defaults section of the EXTENT CONTROL file, at the bottom. This is helpful if you have different size volumes. For example, one of our Sharks has 3390 volumes that are standard 3339 cylinders and others that are much larger and smaller. I use the "types" to tell DIRMAINT the size of these weird volumes so that I don't allocate a minidisk in an area that doesn't really exist. There is also a "start" column. I usually set this to 1 for all my volumes, not 0. The reason for this is that you do not want to allocate a real minidisk over top of cylinder 0 of any VM volume. If you do, you'll wipe out the label, allocation information, etc. So, by setting this value to 1, when you add a minidisk using the AUTOV or AUTOG options of AMDISK, DIRMAINT will never even try to use cylinder 0. Just a little trick I've picked up over the years. You mentioned adding a minidisk to $ALLOC$. Again, this is a convention that started many years ago, and is still a good idea. $ALLOC$ is a "dummy" account that is used to hold minidisks that cover the allocation cylinder (cylinder 0) of VM volumes. It is not an account that is ever logged onto in fact, it's password should always be NOLOG. It simply holds the minidisks so that DIRMAINT will not allow you to accidentily allocate over them. This is another trick to protect yourself from doing a "bad thing". It is also helpful because your backup software, such as VMBACKUP will make a copy of these minidisks on tape. That can be handy if you are in a disaster recovery situation. (I have hundreds of volumes on my Sharks, so I wouldn't want to have to reallocate them all by hand.) I suspect that what happened to you was that DIRMAINT did not initially know about your new volume because you had not added it to the REGIONS section of EXTENT CONTROL. However, when you manually added the minidisk to $ALLOC$, that forced DIRMAINT to build the control files it needed for the volume. It is a way around EXTENT CONTROL, but is messy as you saw. Changing EXTENT CONTROL isn't really that bad. Alan mentioned the commands, here is the basic procedure: - Retrieve current copy from DIRMAINT: dirm send extent control - Receive file onto your A disk: receive xxxxx - Use Xedit to update file xedit extent control - Send new file back to DIRMAINT: dirm file extent control - Force DIRMAINT to process new file: dirm rldextn Groups are just collections of volumes that you want to relate logically. For example, if you a group of accounts that belong to a particular project and you only want their disks to reside on certain volumes, create a group for them. Then, when you do a disk command such as AMDISK, use the AUTOG option and the name of the group. DIRMAINT will find space on one of the disks and allocate the minidisk. If you are only supporting Linux guests where you are allocating whole volumes to them, then GROUP isn't that useful. You don't have to use it if you don't need to. You didn't mention EXCLUDE, but since I'm doing a "brain dump" about DIRMAINT, I might as well mention it. Minidisks occupy a physical location on a disk volume. Normally, you would never want more than 1 minidisk to occupy the same location on the same volume. Especially if the two minidisks belong to two different virtual machines who didn't know about each other. That would cause the data from one machine to be wiped out in favor of the other, and vice versa. By default, DIRMAINT will prevent you from creating this situation, as it can be a "very bad thing". There are certain conditions, however, where having more than 1 minidisk overlap an area of a disk volume is desireable. We do it, for example, to allow our z/OS guests to share volumes. In these cases, you have to tell DIRMAINT to allow these specific disks using the EXCLUDE section of the EXTENT CONTROL file. You have to be very careful when doing this, and be sure that what you specify is what you really want. (You can get in trouble with the wildcard characters.) So, in general, you probably won't use this section of the file, unless there is a very specific reason to do so. Sorry to bore the Linux list with DIRMAINT stuff, but I hope it is helpful. If you want to continue the conversation on all things DIRMAINT, you might want to bring it over to the VMESA-L list. There's a lot of us who can help you there. Martha ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
