__________________________________________
Ranga Nathan / CSG
Systems Programmer - Specialist; Technical Services;
BAX Global Inc. Irvine-California
Tel: 714-442-7591 Fax: 714-442-2840
Martha McConaghy <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[EMAIL PROTECTED]>
12/01/2004 06:51 AM
Please respond to Linux on 390 Port
To: [EMAIL PROTECTED]
cc:
Subject: Re: DIRMAINT questions - how to add volumes
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 documentation states that Region is unique and if you use the same
region on subsequent lines, these are ignored! So I have one region for
each volume! Here are some of the lines I have:
00037 :REGIONS.
00038 *RegionId VolSer RegStart RegEnd Dev-Type Comments
00039 LINUX01 LIN022 1 END 3390-03 LINUX DISK
00040 LINUX02 LIN023 1 END 3390-03 LINUX DISK
00041 LINUX03 LIN024 1 END 3390-03 LINUX DISK
00042 LINUX04 LIN025 1 END 3390-03 LINUX DISK
00043 LINUX05 LIN026 1 END 3390-03 LINUX DISK
00044 LINUX06 LIN027 1 END 3390-03 LINUX DISK
00045 LINUX07 LIN028 1 END 3390-03 LINUX DISK
and
00084 :GROUPS.
00085 *GroupName RegionList
00086 GRPLNX (ALLOCATE ROTATING)
00087 GRPLNX LINUX01 LINUX02 LINUX03 LINUX04 LINUX05 LINUX06 LINUX07
I remember that we had to code unique values under RegionId to make it
work, when we set up DIRMAINT initially.
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.
I declared the type to be 3390-3 but DIRMAINT is taking it to be 3390
(assumed model 1) and thinks that it only has 1112 cyls.
Here is a VCONTROL file for a volume I tried to add ....
LIN045 VCONTROL Z1 V 80 Trun
00000 * * * Top of File * * *
00001 DEVTYPE= 3390
00002 MAXBLK= 1112
00003 ARCH= CKD
00004 ENTRY= 0 0 $ALLOC$ 0A1B *
00005 * * * End of File * * *
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.
This was an idea from our consultant. I am not sure why we need to fiddle
with this if DIRMAINT provides high level interface, or does it?
$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.
I thought this was a main reason to use DIRMAINT.
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
Ah, this is what I needed. Now the VCONTROL file looks good!
LIN045 VCONTROL Z1 V 80 Tr
00000 * * * Top of File * * *
00001 DEVTYPE= 3390-03
00002 MAXBLK= 3338
00003 ARCH= CKD
00004 ENTRY= 0 0 $ALLOC$ 0A1B *
00005 * * * End of File * * *
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
Very kind of you to have taken the time for a detailed reply. I am hoping
that there will be a DIRMAINT class at Share @ Anaheim.
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
