> Seems nice, but, why not
>USER -540RES- xxxxxxxx 64M 1G
>MDISK A00 3390 00000 00001 540RES RR * Access to Allocation Bitmap
>MDISK F00 3390 00000 10016 540RES RR * Access to full volume
>One line less, same effort.
Because those records causes an "*OVERLAP*" warning message. OK, I admit
that I just discovered that after trying your suggestion.
We we had been using A00 and F00 MDISK statements for many years. I only
recently began adding MDISK FFFF statements to ensure that the actual GAP
free space was clearly marked in the reports produced on a system where
there is no directory management product installed (few DASD changes)
installed and we manually XEDIT USER DIRECT (gasp!!!). :-)
>But, then comes the day you get for example a good backup SW and you need
to exclude all these users=volser.
I've been using VM:Backup since early 1985. Adding DASD to VM:Secure
requires changing the VM:Secure "DASD CONFIG" file anyway, adding IGNORE
records for F00 and A00 is not a big deal.
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"Kris Buelens" <kris.buel...@gmail.com>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
10/04/2010 01:36 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: How DIRMAINT Work ?
Seems nice, but, why not
USER -540RES- xxxxxxxx 64M 1G
MDISK A00 3390 00000 00001 540RES RR * Access to Allocation Bitmap
MDISK F00 3390 00000 10016 540RES RR * Access to full volume
One line less, same effort.
But, then comes the day you get for example a good backup SW and you need
to exclude all these users=volser. That's why we used use FULLPACK, and
only that user had FULLPACK mdisks, FULLPACK's MDISK addresses correspond
to the rdevno.
Other fullpack requirements where fullfilled with a LINK FULLPACK instead
of an MDISK. The resident was defined twice: MDISK 123 and MDISK rdevaddr,
so DIRMAINT simply had LINK FULLPACK 123 123 MW, not LINK FULLPACK rdev
123 MW.
For VM:BACKUP, only FULLPACK had to be excluded (fully described in the
document I happily send to anyone requesting it).
2010/10/4 Mike Walter <mike.wal...@hewitt.com>
What if you made it a consistent practice to always allocate a minidisk at
the highest cylinder address?
e.g. MDISK FFFF 3390 10016 00001 540RES RR
Actually, for every non-spare VM DASD at our site we make it a practice to
create a userid in the format: -volser-
For 540RES (the label of which we keep only long enough to complete the
installation, after which it is immediately re-labeled), that would look
like:
USER -540RES- xxxxxxxx 64M 1G
MDISK A00 3390 00000 00001 540RES RR * Access to Allocation Bitmap
MDISK F00 3390 00000 END 540RES RR * Access to full volume
MDISK FFFF 3390 10016 00001 540RES RR * Help out DISKMAP and DIRMAP
DISKMAP then reports:
VOLUME USERID CUU DEVTYPE START END SIZE
540RES -540RES- A00 3390 00000 00000 00001
1 398 398
GAP
MAINT 0190 3390 00399 00505 00107
...many mdisks omitted to save lots'a lines...
someuser 01F6 3390 09978 10002 00025
10003 10015 13
GAP
-VMR54I- FFFF 3390 10016 10016 00001
Being able to LINK to any VM volume in the shop can be of great value to
sysprogs who know what they are doing with admin utility EXECs.
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
"Scott Rohling" <scott.rohl...@gmail.com>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
10/04/2010 11:21 AM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: How DIRMAINT Work ?
Because the DISKMAP utility is unaware of the size of the 'real' disk - so
END is meaningless to it.
I always encourage folks to not use END except under specific
circumstances. If there is a reason other than laziness to specify END --
then use it. Otherwise, list the number of cylinders specifically.
Oh - and it can pose a danger if you rely on DISKMAP to tell you what is
already allocated and these disks don't show up.
You might want to try DIRMAINT FREE and DIRMAINT USED commands instead of
DISKMAP. (The thread is about DIRMAINT after all ;-)
Scott Rohling
On Mon, Oct 4, 2010 at 10:10 AM, George Henke/NYLIC <
george_he...@newyorklife.com> wrote:
Minidisks with the END option specified are not included in a DISKMAP when
the command, DISKMAP USER is entered.
What is the reason for this?
Does this pose a danger when updating the directory directly, no pun
intended? :-)
Ray Waters <ray.wat...@opensolutions.com>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
10/04/2010 09:06 AM
Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: How DIRMAINT Work ?
I AGREE with Scott. Sometimes it is just simpler and faster to use XEDIT
to make multiple changes to the VM Directory. My exec performs a syntax
check of the directory: DIRECTXA &DIRNAME DIRECT A (EDIT and then checks
the RC. If bad RC, we go back into XEDIT to correct. Also the exec
performs DISKMAP to check for overlaps and go back to the Directory if
overlaps occurred. Once everything looks good, the exec takes you
document your directory changed via: XEDIT DIRMCHNG LOG A. I have DIRMAINT
perform the real DIRECTXA.
We like having the audit and reasons for the directory updates and who
performed the changes.
Ray Waters
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Scott Rohling
Sent: Friday, October 01, 2010 4:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How DIRMAINT Work ?
There are times when using DIRMAINT commands isn't practical.. for
example - doing DASD volume relabelling. I suppose you could do a bunch
of GET/REP commands -- or maybe DMDISK NOCLEAN and AMDISK using the same
extents and the new volid? But I have found the best thing to do is
update the monolithic directory with some simple plumbing and then give it
back to DIRMAINT. I concede the loss of an audit trail, but for most
customers that can be resolved by having a change record indicating what
was done.
Scott Rohling
On Fri, Oct 1, 2010 at 2:50 PM, Alan Altmark <alan_altm...@us.ibm.com>
wrote:
On Friday, 10/01/2010 at 10:24 EDT, Ray Waters
<ray.wat...@opensolutions.com> wrote:
> We use all the ?DIRMAINT ? or ?DIRM? commands and also are able to use
XEDIT
> to make our major directory changes. I wrote an EXEC to ?DIRMAINT
OFFLINE?,
> ?DIRMAINT BACKUP?, DIRMAINT SHUTDOWN?, then ?COPY USER BACKUP B &DIRNAME
DIRECT
> A (OLDD ? , followed by ?XEDIT &DIRNAME DIRECT A?.
>
> Once my EXDIT changes are made and I ?FILE?, I ?COPY &DIRNAME DIRECT A
USER
> INPUT C (OLDD? to the DIRMAINT 1DF mdisk,? CP XAUTOLOG DIRMAINT?, ?EXEC
> DIRMAINT ONLINE?.
>
> Anyway you get the idea. There are precautions and sleeps and performed
by the
> EXEC, but that is the general idea.
Any procedure that has you editing the monolithic directory and replacing
it as a whole means you have no audit trail (except for "directory
replaced") and the holodeck safeties are turned off. All major directory
changes should be made with DIRM commands. If you're making a bunch of
changes at the same time, use DIRM NODIRECT xxxx to suppress the
DIRECTXA, and then when you're done use DIRM DIRECT to bring all the
changes online at the same time.
Alan Altmark
z/VM and Linux on System z Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott
NOTICE:
This e-mail is intended solely for the use of the individual to whom it is
addressed and may contain information that is privileged, confidential or
otherwise exempt from disclosure. If the reader of this e-mail is not the
intended recipient or the employee or agent responsible for delivering the
message to the intended recipient, you are hereby notified that any
dissemination, distribution, or copying of this communication is strictly
prohibited. If you have received this communication in error, please
immediately notify us by replying to the original message at the listed
email address. Thank You.
The information contained in this e-mail and any accompanying documents
may contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if
this message has been addressed to you in error, please immediately alert
the sender by reply e-mail and then delete this message, including any
attachments. Any dissemination, distribution or other use of the contents
of this message by anyone other than the intended recipient is strictly
prohibited. All messages sent to and from this e-mail address may be
monitored as permitted by applicable law and regulations to ensure
compliance with our internal policies and to protect our business. E-mails
are not secure and cannot be guaranteed to be error free as they can be
intercepted, amended, lost or destroyed, or contain viruses. You are
deemed to have accepted these risks if you communicate with us by e-mail.
--
Kris Buelens,
IBM Belgium, VM customer support
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if this
message has been addressed to you in error, please immediately alert the sender
by reply e-mail and then delete this message, including any attachments. Any
dissemination, distribution or other use of the contents of this message by
anyone other than the intended recipient is strictly prohibited. All messages
sent to and from this e-mail address may be monitored as permitted by
applicable law and regulations to ensure compliance with our internal policies
and to protect our business. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
