You don't exactly tell what you deleted to get rid of the overlaps.
Probably you deleted DIRMAINT's 123 minidisk. If you carefully look
at a CP directory, the first statement is something like:
DIRECTORY 123 3390 ZV54RS
This tells the DIRECTXA command where to write the object directory.
Above thus:
- write to virtual address 123
- as check: the 123 disk must be labeled ZV54RS
The 123 can be anything you like, as long as it is a virtual address
pointing to the disk where you want the object directory to be
written.
Fixing your problem means updating the CP directory, but DIRMAINT can
no longer do that. Catch22?
- If you still have a minidisk is a fullpack overlay on the disk with
the object directory (probably the resident 540RES).
Make DIRMAINT LINK to it.
A good candidate is MAINT 123 (but you may have deleted that too)
-If you don't have an ESM, that minidisk must have a mult pass, but
the default zVM directory contains no password for MAINT 123!
DIRM CP LINK MAINT 123 123 MW multpswd
-With an ESM, give DIRMAINT link permission
DIRM CP LINK MAINT 123 123 MW
Now DIRMAINT can update the directory (as long as you don't log it
off) so add DIRMAINT's 123 again
DIRM EXTNCHK OFF
DIRM FOR DIRMAINT AMDISK 123 3390 0 3339 540RES MW
DIRM EXTNCHK ON
- If you can't execute the above (no fullpack definition remains, or
no ESM and none with a mult password), use the following.
1. From a user authorized in DIRMAINT (eg MAINT)
DIRM USER BACKUP
DIRM SEND USER BACKUP
Now you have USER BACKUP in your reader;
RECEIVE it
XEDIT it and insert "MDISK 123 ...." in user DIRMAINT
2. Find a user that
A. has the CP class to update the directory (classes A, B or C),
B. and that has a fullpack overlay
C. or that can use DEFINE MDISK
(i.e. it has CP class A and OPTION DEVMAINT, or is OPERATOR)
By default MAINT is OK for A. and B., but not for C.
If MAINT is has a 123 overlay issue DIRECTXA USER BACKUP
else, probably OPERATOR is OK,
- SENDFILE the changed USER BACKUP to it
- logon to it and execute:
DEFINE MDISK 123 0 END 540RES
Receive the USER BACKUP file
DIRECTXA USER BACKUP
Then restart DIRMAINT and give it a 123 again:
DIRM EXTNCHK OFF
DIRM FOR DIRMAINT AMDISK 123 3390 0 3339 540RES MW
DIRM EXTNCHK ON
As to avoid the overlaps. You have to tell DIRMAINT to exclude some
minidisks (using EXTENT CONTROL).
DIRMAINT also automatically makes some pseudo minidisks to protect
some CP areas, like .DCRT. and .TDISK. If you have the corresponding
$DIRECT$, $TDISK$ and friends, this creates an overlap too.
I do **not** recommend to remove the $xxx$ users (on the contrary: be
sure to maintain them), but to avoid the overlap reporting via EXTENT
CONTROL. Entering the .xxxx. users in EXTENT CONTROL seems not to
work, so you must enter the $xxxx$ entries. This is an extract of my
EXTENT CONTROL.
:EXCLUDE.
* USERID ADDRESS
MAINT 0123 * EXCLUDE FULL PACK
MAINT 0124 * EXCLUDE FULL PACK
MAINT 0125 * EXCLUDE FULL PACK
MAINT 0126 * EXCLUDE FULL PACK
MAINT 0127 * EXCLUDE FULL PACK
*** Added by Kris Buelens
* Note: adding the .xxxx. users that DIRMAINT automatically creates to
* protect CP areas doesn't help. So we exclude $xxxx$ users
* .DRCT. * * Created by DIRMAINT
$DIRECT$ * * Dirmaint uses .DRCT. userid
$TDISK$ * * Dirmaint uses .TDISK. userid
.....
At last: in stead of using DIRM DIRMAP, use the CMS DIRMAP command. Why?
DIRM DIRMAP still signal overlaps for items you asked to exclude. The
CMS DIRMAP command will not report them (it has no .xxxx. pseudo
minidisks), and it excludes fullpack overlays automatically.
With the CMS DIRMAP command you can (and probably should) make an
EXCLUDE VOLSERS file to exlude the $$$$$$ volser that DIRMAINT (and
DFSMS) use to park work minidisks on and that probably are in overlap
with each other.
My DRM package makes this easier.
- issue DRMAC to look at Ditmaint's last USER BACKUP
- press PF16 to have the MDISKMAP rebuilt (if required) and XEDITed
- To ask DIRMAINT for a fresh USER BACKUP and a new MDISKMAP
type "DIRM" in XEDIT's cmd area and press PF4
2009/4/15 Huegel, Thomas <thue...@kable.com>
>
> Val,
> Just a guess, but is MAINT's 123 disk linked R/W by someone other than
> DIRMAINT?
> DIRMAINT needs R/W to that volume so DIRECTXA can write the new directory.
> Tom
>
> -----Original Message-----
> From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on
> Behalf Of Le Grande Valerie
> Sent: Wednesday, April 15, 2009 3:29 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Dirmaint Broken?
>
>
> Hi all,
> I thought I was getting the hang of using DIRMAINT, but now I think I =
>
> shot myself in the foot. I am wondering now how to fix the wound.
>
> Yesterday I made some changes that appeared to be successful. After some=
>
> searches of the list archives, I thought I did something good but now I a=
> m
> thinking it may be what is causing my problem.
>
> Backing up, I had followed the steps in Chapter 4 of Getting Started with=
>
> Linux on System z.
>
> I ran a DIRMAP report before I started making changes and noted that
> several items that had overlaps also had 3390 (3390-01) lengths associate=
> d
> with them. Since I only have 3390-09s, I thought the USER files should =
>
> reflect that. So... I changed $SPOOL$, $PAGE$, MAINT and SYSDUMP1 0123 =
>
> (the last two which I am assuming came out of my EXTENT CONTROL
> definitions) to all have the 3390-09 lenghths. Those overlaps all went =
>
> away.
> THere was something called .DRCT. from 1-20 on 540RES which still had on =
>
> overlap listed when I was done, but it was there to start with so I
> thought nothing of it.
> All the updates seemed to work as far as I could tell.
>
> Today I reipled to test some changes I made in AUTOLOG1 PROFILE suggested=
>
> by the RH Virtualization Cookbook. I did a dirmaint get and made some
> changes for another user, and tried to do a replace.
>
> The scene is not good; I am getting errors:
>
> DVHDRC3212E Unexpected RC= 28, from DVHUPDIR 123 1DE
> :
> :
> DVHDRC6213E z/VM USER DIRECTORY CREATION PROGRAM - VERSION 5 RELEASE 4.0
> DVHDRC6213E HCPDIR750I RESTRICTED PASSWORD FILE NOT FOUND
> DVHDRC6213E HCPDIR784E I/O ERROR 0123 DEVICE NOT ATTACHED
> DVHDRC6213E EOJ DIRECTORY NOT UPDATED
>
> after which DIRECTXA attempts to re-IPL and restart adn the whole error =
>
> process happens again.
>
>
> I could restore the 540RES volume, but now that I have made this problem =
>
> for myself, it might serve me better to know how to fix it(if there is a =
>
> way).I could try to undo my changes, but I would really like to know how =
>
> to debug this problem. Since I see the virtual address 123 in the error =
>
> message, I am led to believe that it might have something to do with the =
>
> DASD size changes I made that relate to virtual device 123. I could undo =
>
> them all, but I would rather find out if this is the right path to take. =
> I
> am concerned that they might not get updated if I DO try to change them i=
> f
> DIRMAINT is not working correctly.
>
> Since I am just starting out, this is unfortunately my first level system=
> .
> Someone suggested getting a second level up and running, but I did not do=
>
> that before messing with DIRMAINT.
>
>
>
>
--
Kris Buelens,
IBM Belgium, VM customer support
