Re: MDISK DEFINITION in MAINT DIRECTORY ENTRY

[Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR) (CTR)]

Thanks Kris and all. I understand now! Another learning experience for
me!!!  I am getting there!

 

Thank You,

 

Terry Martin

Lockheed Martin - Information Technology

z/OS & z/VM Systems - Performance and Tuning

Cell - 443 632-4191

Work - 410 786-0386

terry.mar...@cms.hhs.gov  

Telecommuting on Fridays - use my cell phone



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Kris Buelens
Sent: Thursday, March 12, 2009 9:48 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: MDISK DEFINITION in MAINT DIRECTORY ENTRY

 

Please oh please: use DIRMAP iso DISKMAP.  DIRAMP knows how to properly
treat fullpack minidisks, they are not taken as overlap...
In my CP directories, **any** overlap signals a problem, there should be
not a single one, otherwise people will miss a truely unexpected overlap
too.  DIRMAP even signal overlaps with a non-zero return code and
message to the console, but, it ignores fullpack overlays.  
With DIRMAP fullpack definitions are still a very good thing, for
example to learn DIRMAP how many cylinders a volume has; no need to
define a dummy user $END.

I sent Terry Martin the directory wisdom document I wrote for my former
customer.

2009/3/12, Edward M Martin :

Hello Terry,

 

As others have explained, MAINT uses these to do some functions (DDR
backup etc).

The overlay is normal from DISKMAP and is expected (well should be).

 

I have added user ids of $ALLOC$ and $END$ for cylinder 0 and for the
last cylinder on 

all z/VM volumes as a reminder for myself.  

 

Just something that helps me keep track.  (No, we do not have DIRMAINT.)

 

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR)
(CTR)
Sent: Wednesday, March 11, 2009 6:07 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: MDISK DEFINITION in MAINT DIRECTORY ENTRY

 

Hi

 

I did a DISKMAP USER DIRECTORY and while viewing the output I noticed
that I had a few 'OVERLAYS'. 

 

In my MAINT directory entry I have the following:

 

MDISK 122 3390 000 END 530SPL MR 

MDISK 123 3390 000 END 530RES MR 

MDISK 124 3390 000 END 530W01 MR 

MDISK 125 3390 000 END 530W02 MR 

MDISK 126 3390 000 END 530W03 MR

 

Now, I reference these disks I other entries in the directory starting
at location 001 for however many cylinders I need. As you can see the
MDISK entries above start at 000 to END.

 

The output from the DISKMAP shows the following:

 

 


VOLUME   USERID  CUU   DEVTYPE  START ENDSIZE


530SPL   $SPOOL$   B01 3390 0  END
? 

 MAINT 122  3390 0
END   ? *OVE

 

 

530W01   LNXADMIN191  3390  1   00100
00100

   E49L021P 191  3390  00101   00102
2

   E49L054P  191 3390  00103   00104
2

   E49L124P 191  3390  00105   00106
2

   E49L046P 191  3390  00107   00108
2

   MAINT  124 3390   0
END   ? *OVE

 

 

 

530W02   E49L021P  910 3390  1   00200
00200 

   E49L054P  910 3390  00201   00400
00200 

   E49L124P  910 3390  00401   00600
00200 

 


   E49L046P   910 3390 00801   01000
00200 

   MAINT125 3390 0
END   ? *OVE

 

I see what the problem is my question is do I need to have the entries
for these disks in the MAINT directory entry? And what are the
consequences if they are removed from the MAINT entry. This is the way
the DIRECTORY was shipped on the install tape.

 

Thanks for the help!

 

 

Thank You,

 

Terry Martin

Lockheed Martin - Information Technology

z/OS & z/VM Systems - Performance and Tuning

Cell - 443 632-4191

Work - 410 786-0386

terry.ma...@cms.hhs.gov

Telecommuting on Fridays - Use my cell phone

 




-- 
Kris Buelens,
IBM Belgium, VM customer support 

Re: MDISK DEFINITION in MAINT DIRECTORY ENTRY

[Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR) (CTR)]

Yes,  I am using DOENDS. I guess the question is are these overlays anything to 
worry about and normal?

 

Thank You,

 

Terry Martin

Lockheed Martin - Information Technology

z/OS & z/VM Systems - Performance and Tuning

Cell - 443 632-4191

Work - 410 786-0386

terry.mar...@cms.hhs.gov  

Telecommuting on Fridays - use my cell phone



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Brüchmann.Frank FBR
Sent: Thursday, March 12, 2009 9:00 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: SV: MDISK DEFINITION in MAINT DIRECTORY ENTRY

 

Hi Terry.

 

Are you using the (doends option when running diskmap? I only get these 
overlays when using (doends, otherwise they're supressed.

 

Regards 

Frank Bruchmann.

 



Fra: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] På vegne af 
Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR) (CTR)
Sendt: 11. marts 2009 23:07
Til: IBMVM@LISTSERV.UARK.EDU
Emne: MDISK DEFINITION in MAINT DIRECTORY ENTRY

Hi

 

I did a DISKMAP USER DIRECTORY and while viewing the output I noticed that I 
had a few 'OVERLAYS'. 

 

In my MAINT directory entry I have the following:

 

MDISK 122 3390 000 END 530SPL MR 

MDISK 123 3390 000 END 530RES MR 

MDISK 124 3390 000 END 530W01 MR 

MDISK 125 3390 000 END 530W02 MR 

MDISK 126 3390 000 END 530W03 MR

 

Now, I reference these disks I other entries in the directory starting at 
location 001 for however many cylinders I need. As you can see the MDISK 
entries above start at 000 to END.

 

The output from the DISKMAP shows the following:

 

  

VOLUME   USERID  CUU   DEVTYPE  START ENDSIZE 

530SPL   $SPOOL$   B01 3390 0  END   ?  
   

 MAINT 122  3390 0  END 
  ? *OVE

 

 

530W01   LNXADMIN191  3390  1   00100   00100   
 

   E49L021P 191  3390  00101   00102   
2

   E49L054P  191 3390  00103   00104   
2

   E49L124P 191  3390  00105   00106   
2

   E49L046P 191  3390  00107   00108   
2

   MAINT  124 3390   0 END  
 ? *OVE

 

 

 

530W02   E49L021P  910 3390  1   00200   00200  
   

   E49L054P  910 3390  00201   00400   
00200 

   E49L124P  910 3390  00401   00600   
00200 

  

   E49L046P   910 3390 00801   01000   
00200 

   MAINT125 3390 0 END  
 ? *OVE

 

I see what the problem is my question is do I need to have the entries for 
these disks in the MAINT directory entry? And what are the consequences if they 
are removed from the MAINT entry. This is the way the DIRECTORY was shipped on 
the install tape.

 

Thanks for the help!

 

 

Thank You,

 

Terry Martin

Lockheed Martin - Information Technology

z/OS & z/VM Systems - Performance and Tuning

Cell - 443 632-4191

Work - 410 786-0386

terry.ma...@cms.hhs.gov

Telecommuting on Fridays - Use my cell phone

 

__
KMD A/S, Lautrupparken 40-42, DK-2750 Ballerup, CVR-nr. 26911745 

KMD er medlem af IT-Branchen og Dansk Erhverv samt anmeldt til Datatilsynet som 
edb-servicevirksomhed. KMD er certificeret i henhold til ISO 9001:2000, med 
Dansk Standard som certificerende organ og er desuden Microsoft Gold Certified 
Partner og Certificeret SAP Hosting Center.

www.kmd.dk www.kundenet.kmd.dk www.e-Boks.dk www.organisator.dk 
www.kmdinternational.com

Hvis du har modtaget denne e-mail ved en fejl, bedes du venligst give mig 
besked herom og slette den.
If you received this e-mail by mistake, please notify me and delete it. Thank 
you.

unsubscribe

[Brandt, Mark H]

Unsubscribe 

Mantissa

[Gentry, Stephen]

So, SHARE is over, MANTISSA was supposed to be announced on Mar. 6th
What happened?  When will z/VOS be available to the masses?
Steve G

Re: SLES 9.0 SP3 SPACE PROBLEM

[Mark Post]

>>> On 3/12/2009 at  3:58 PM, clifford jackson  
>>> wrote:


> Mark, that make sense, how do I restructure my file systems so that not 
> everything is lumped into "/"

Well, you're going to need some extra disk space, at least temporarily, and 
probably permanently, since your volume is almost completely full.  It will be 
a bit of a chore, but take a look at http://linuxvm.org/Info/HOWTOs/movefs.html 
and apply that technique to /home, /opt, /tmp, /usr, /var, and /srv if you 
actually put stuff in there for web or FTP servers.

In your case, there's going to be additional steps necessary, if you want to 
keep your root file system on the same volume it is now.  You'll need to boot 
the system from something like the installation kernel/ramdisk, and do an 
offline file system resize, then use fdasd to delete and redefine your 
partition table so that you can create a second partition that can be given to 
LVM for parceling out the space to those other file systems you broke out.  
That's going to be quite a bit of work, and complex, so it might be easier to 
install a new system using the new scheme, and just copy over the parts that 
aren't part of the OS.


Mark

Re: Merging DirMaint?

[David Kreuter]

Hi Dave:
for the directories on each system what I would do:
1. DIRM USER WITHPASS
2. RECEIVE the spool file as  WITHPASS - so you have a good copy of 
each systems directoy
3. Record by hand the volser where each directory is getting loaded onto
4. for each system run a DIRM SCAN USER and figure out which users you want to 
merge, mdisks, etc.
5. copy the file you want to gerrymander and place your diretory entries in 
there. Very carefully.
6. on the system you want to place the new directory:
6a. from maint: link dirmaint 1df 1df mr
6b: from MAINT: ac 1df l
6c: From MAINT: ERASE USER DIRECT L
6d. copy from maint your gerrymandered directory: COPY GMANDER DIRECT A USER 
INPUT L2
it is important to copy it onto dirmaint 1df as fn= user ft= input
7. rel l(det
8.hope for the best!
 
David Kreuter



From: The IBM z/VM Operating System on behalf of Dave Keeton
Sent: Thu 3/12/2009 12:20 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] Merging DirMaint?


I have a question regarding DirMaint and how to migrate/merge from one release 
to another. Here's the scenario:

I have z/VM 5.2 running in production with DirMaint. I have 20+ instances of 
SLES9 & 10 and everything is running great.

I also have z/VM 5.4 running in a test LPAR which also has DirMaint, 2 
instances of SLES10, as well as several CA products. I want to bring 5.4 into 
production.

I'm trying to determine how to merge all the directory entries for my 
production systems into the test directory prior to IPL'ing z/VM 5.4 as 
production. My first concern is the EXTENT CONTROL. Each instance of DirMaint 
has its own DASD pool, separate from the other. I am concern about things 
getting mucked up by consolidating the pools. What's the most effective way to 
do this?

When z/VM 5.4 is up and running correctly, the plan is to rebuild the test LPAR 
with the latest release of z/VM so we can stay on top of the releases.

Thanks in advance,

Dave

Re: SLES 9.0 SP3 SPACE PROBLEM

[clifford jackson]

Mark, that make sense, how do I restructure my file systems so that not 
everything is lumped into "/"
 
> Date: Tue, 10 Mar 2009 17:19:56 -0600
> From: mp...@novell.com
> Subject: Re: SLES 9.0 SP3 SPACE PROBLEM
> To: IBMVM@LISTSERV.UARK.EDU
> 
> >>> On 3/10/2009 at 5:51 PM, Tom Duerbusch  
> >>> wrote: 
> > As you are removing/deleting things, and the space still shows 0%
> > available, that shows me that you have some process that is using up
> > space quickly.
> 
> Probably not. That 0% only applies to non-root users, because of the (by 
> default 5%) space reservation for the root user, just in case a file system 
> gets filled up. In Clifford's case, he has about 23MB of free space on that 
> volume. Not a whole lot, and awfully close to having his system die on him 
> from the root file system filling up. Whether or not he frees up enough 
> space, he really needs to restructure his file systems so that not everything 
> is lumped into "/".
> 
> 
> Mark Post

_
Windows Live™: Life without walls.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009

Re: Incremental Flashcopy backups.

[Crispin Hugo]

Eric,
You are the man. Just what I wanted !. Many thanks
 
 
Crispin Hugo
Systems Programmer, Macro 4
<  http://www.macro4.com/>
Macro 4 plc, The Orangery, Turners Hill Road, Worth, Crawley, RH10 4SS
Direct Line: +44 (0)1293 872121 Switchboard: +44 (0) 1293 872000
Fax: +44 (0) 1293 872001
This message contains confidential information and is intended only for
the individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message which arise as a
result of e-mail transmission. If verification is required please
request a hard-copy version. This message is provided for informational
purposes and should not be construed as a solicitation, offer or
acceptance of any offer.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Eric R Farman
Sent: 12 March 2009 17:49
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Incremental Flashcopy backups.
 
Hi Crispin, 

Take a look at z/VM 5.4 APAR VM64449.  It expands the existing Class B
FLASHCopy command to allow privileged users to establish and manage
Persistent Flashcopy relationships.  (The existing command creates
point-in-time copies, where the relationships are destroyed as soon as
the copy completes.)  If I understand what you're looking for, it would
be a persistent relationship with change recording enabled (this is an
option on FLASHCopy ESTABLISH), followed by periodic FLASHCopy RESYNC
commands to bring the target up to the state of the current source,
since the last Flashcopy command was issued. 

There is also a Class B Query command that lets you interrogate the
state of all your Flashcopy relationships, beyond the existing command
(Class G Query Virtual) that queries those relationships inside a
virtual machine. 

Regards,
   Eric

Eric Farman
z/VM I/O Development
IBM Endicott, NY


The IBM z/VM Operating System  wrote on
03/12/2009 11:29:12 AM:

> From: 
> 
> Crispin Hugo  
> 
> To: 
> 
> IBMVM@LISTSERV.UARK.EDU 
> 
> Date: 
> 
> 03/12/2009 11:29 AM 
> 
> Subject: 
> 
> Incremental Flashcopy backups. 
> 
> Am I missing something !
> Under z/OS I can do incremental copies of packs on our DS6800. I can't
> seem to find the same function under z/VM. Can someone confirm my
worst
> fears that it can't be done under z/VM or make me very happy by
showing
> me where I have gone wrong. 
> 
> Crispin Hugo
> Systems Programmer
> Macro 4
> 
> 
>  
> 
> 
>

> This email has been scanned for all known viruses by the MessageLabs
> Email Security Service and the Macro 4 plc internal virus protection
system.
>



This email has been scanned for all known viruses by the MessageLabs
Email Security Service and the Macro 4 plc internal virus protection
system.



This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.

Re: Incremental Flashcopy backups.

[Eric R Farman]

Hi Crispin,

Take a look at z/VM 5.4 APAR VM64449.  It expands the existing Class B 
FLASHCopy command to allow privileged users to establish and manage 
Persistent Flashcopy relationships.  (The existing command creates 
point-in-time copies, where the relationships are destroyed as soon as the 
copy completes.)  If I understand what you're looking for, it would be a 
persistent relationship with change recording enabled (this is an option 
on FLASHCopy ESTABLISH), followed by periodic FLASHCopy RESYNC commands to 
bring the target up to the state of the current source, since the last 
Flashcopy command was issued.

There is also a Class B Query command that lets you interrogate the state 
of all your Flashcopy relationships, beyond the existing command (Class G 
Query Virtual) that queries those relationships inside a virtual machine.

Regards,
Eric

Eric Farman
z/VM I/O Development
IBM Endicott, NY


The IBM z/VM Operating System  wrote on 
03/12/2009 11:29:12 AM:

> From:
> 
> Crispin Hugo 
> 
> To:
> 
> IBMVM@LISTSERV.UARK.EDU
> 
> Date:
> 
> 03/12/2009 11:29 AM
> 
> Subject:
> 
> Incremental Flashcopy backups.
> 
> Am I missing something !
> Under z/OS I can do incremental copies of packs on our DS6800. I can't
> seem to find the same function under z/VM. Can someone confirm my worst
> fears that it can't be done under z/VM or make me very happy by showing
> me where I have gone wrong. 
> 
> Crispin Hugo
> Systems Programmer
> Macro 4
> 
> 
> 
> 
> 
> 
> This email has been scanned for all known viruses by the MessageLabs
> Email Security Service and the Macro 4 plc internal virus protection 
system.
> 

Merging DirMaint?

[Dave Keeton]

I have a question regarding DirMaint and how to migrate/merge from one
release to another. Here's the scenario:

I have z/VM 5.2 running in production with DirMaint. I have 20+
instances of SLES9 & 10 and everything is running great.

I also have z/VM 5.4 running in a test LPAR which also has DirMaint, 2
instances of SLES10, as well as several CA products. I want to bring 5.4
into production.

I'm trying to determine how to merge all the directory entries for my
production systems into the test directory prior to IPL'ing z/VM 5.4 as
production. My first concern is the EXTENT CONTROL. Each instance of
DirMaint has its own DASD pool, separate from the other. I am concern
about things getting mucked up by consolidating the pools. What's the
most effective way to do this?

When z/VM 5.4 is up and running correctly, the plan is to rebuild the
test LPAR with the latest release of z/VM so we can stay on top of the
releases.

Thanks in advance,

Dave

Incremental Flashcopy backups.

[Crispin Hugo]

Am I missing something !
Under z/OS I can do incremental copies of packs on our DS6800. I can't
seem to find the same function under z/VM. Can someone confirm my worst
fears that it can't be done under z/VM or make me very happy by showing
me where I have gone wrong. 

Crispin Hugo
Systems Programmer
Macro 4


 



This email has been scanned for all known viruses by the MessageLabs Email 
Security Service and the Macro 4 plc internal virus protection system.

Re: MDISK DEFINITION in MAINT DIRECTORY ENTRY

[August Carideo]

can also run diskmap w/  DOENDS parm



   
 Edward M Martin   
To 
 Sent by: The IBM  IBMVM@LISTSERV.UARK.EDU 
 z/VM Operating cc 
 System
   Re: MDISK DEFINITION in MAINT   
   DIRECTORY ENTRY 
   
 03/12/2009 09:55  
 AM
   
   
 Please respond to 
   The IBM z/VM
 Operating System  
   
   
   




Hello Kris,

I use both DIRMAP and DISKMAP.  For me, keeping the $END$ and $ALLOC$ in
help me keep everything straight.
I am sure there are other techniques that work for others.

Ed Martin
Aultman Health Foundation
330-588-4723
ext 40441

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Kris Buelens
Sent: Thursday, March 12, 2009 9:48 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: MDISK DEFINITION in MAINT DIRECTORY ENTRY

Please oh please: use DIRMAP iso DISKMAP.  DIRAMP knows how to properly
treat fullpack minidisks, they are not taken as overlap...
In my CP directories, **any** overlap signals a problem, there should be
not a single one, otherwise people will miss a truely unexpected overlap
too.  DIRMAP even signal overlaps with a non-zero return code and message
to the console, but, it ignores fullpack overlays.
With DIRMAP fullpack definitions are still a very good thing, for example
to learn DIRMAP how many cylinders a volume has; no need to define a dummy
user $END.

I sent Terry Martin the directory wisdom document I wrote for my former
customer.
2009/3/12, Edward M Martin :


Hello Terry,





As others have explained, MAINT uses these to do some functions (DDR backup
etc).


The overlay is normal from DISKMAP and is expected (well should be).





I have added user ids of $ALLOC$ and $END$ for cylinder 0 and for the last
cylinder on


all z/VM volumes as a reminder for myself.





Just something that helps me keep track.  (No, we do not have DIRMAINT.)








Ed Martin


Aultman Health Foundation


330-588-4723


ext 40441



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR)
(CTR)
Sent: Wednesday, March 11, 2009 6:07 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: MDISK DEFINITION in MAINT DIRECTORY ENTRY





Hi





I did a DISKMAP USER DIRECTORY and while viewing the output I noticed that
I had a few ‘OVERLAYS’.





In my MAINT directory entry I have the following:





MDISK 122 3390 000 END 530SPL MR


MDISK 123 3390 000 END 530RES MR


MDISK 124 3390 000 END 530W01 MR


MDISK 125 3390 000 END 530W02 MR


MDISK 126 3390 000 END 530W03 MR





Now, I reference these disks I other entries in the directory starting at
location 001 for however many cylinders I need. As you can see the MDISK
entries above start at 000 to END.





The output from the DISKMAP shows the following:








VOLUME   USERID  CUU   DEVTYPE  START ENDSIZE


530SPL   $SPOOL$   B01 3390 0  END
?


 MAINT 122  3390 0  END
? *OVE








530W01   LNXADMIN191  3390  1   00100
00100


   E49L021P 191  3390  00101   00102
2


   E49L054P  191 3390  00103   00104
2


   E49L124P 191  3390  00105   00106
2


   E49L046P 191  3390  00107   00108
2


   MAINT  124 3390   0 END
? *OVE











530W02   E49L021P  910 3390  1   00200
00200


   E49L054P  910 3390  00201   00400
00200


   E49L124P  910 3390  00401   00600
00200





   E49L046P   910 3390 00801   01000
00200


   MAINT 

Re: MDISK DEFINITION in MAINT DIRECTORY ENTRY

[Edward M Martin]

Hello Kris,

 

I use both DIRMAP and DISKMAP.  For me, keeping the $END$ and $ALLOC$ in
help me keep everything straight.

I am sure there are other techniques that work for others.

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Kris Buelens
Sent: Thursday, March 12, 2009 9:48 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: MDISK DEFINITION in MAINT DIRECTORY ENTRY

 

Please oh please: use DIRMAP iso DISKMAP.  DIRAMP knows how to properly
treat fullpack minidisks, they are not taken as overlap...
In my CP directories, **any** overlap signals a problem, there should be
not a single one, otherwise people will miss a truely unexpected overlap
too.  DIRMAP even signal overlaps with a non-zero return code and
message to the console, but, it ignores fullpack overlays.  
With DIRMAP fullpack definitions are still a very good thing, for
example to learn DIRMAP how many cylinders a volume has; no need to
define a dummy user $END.

I sent Terry Martin the directory wisdom document I wrote for my former
customer.

2009/3/12, Edward M Martin :

Hello Terry,

 

As others have explained, MAINT uses these to do some functions (DDR
backup etc).

The overlay is normal from DISKMAP and is expected (well should be).

 

I have added user ids of $ALLOC$ and $END$ for cylinder 0 and for the
last cylinder on 

all z/VM volumes as a reminder for myself.  

 

Just something that helps me keep track.  (No, we do not have DIRMAINT.)

 

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR)
(CTR)
Sent: Wednesday, March 11, 2009 6:07 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: MDISK DEFINITION in MAINT DIRECTORY ENTRY

 

Hi

 

I did a DISKMAP USER DIRECTORY and while viewing the output I noticed
that I had a few 'OVERLAYS'. 

 

In my MAINT directory entry I have the following:

 

MDISK 122 3390 000 END 530SPL MR 

MDISK 123 3390 000 END 530RES MR 

MDISK 124 3390 000 END 530W01 MR 

MDISK 125 3390 000 END 530W02 MR 

MDISK 126 3390 000 END 530W03 MR

 

Now, I reference these disks I other entries in the directory starting
at location 001 for however many cylinders I need. As you can see the
MDISK entries above start at 000 to END.

 

The output from the DISKMAP shows the following:

 

 


VOLUME   USERID  CUU   DEVTYPE  START ENDSIZE


530SPL   $SPOOL$   B01 3390 0  END
? 

 MAINT 122  3390 0
END   ? *OVE

 

 

530W01   LNXADMIN191  3390  1   00100
00100

   E49L021P 191  3390  00101   00102
2

   E49L054P  191 3390  00103   00104
2

   E49L124P 191  3390  00105   00106
2

   E49L046P 191  3390  00107   00108
2

   MAINT  124 3390   0
END   ? *OVE

 

 

 

530W02   E49L021P  910 3390  1   00200
00200 

   E49L054P  910 3390  00201   00400
00200 

   E49L124P  910 3390  00401   00600
00200 

 


   E49L046P   910 3390 00801   01000
00200 

   MAINT125 3390 0
END   ? *OVE

 

I see what the problem is my question is do I need to have the entries
for these disks in the MAINT directory entry? And what are the
consequences if they are removed from the MAINT entry. This is the way
the DIRECTORY was shipped on the install tape.

 

Thanks for the help!

 

 

Thank You,

 

Terry Martin

Lockheed Martin - Information Technology

z/OS & z/VM Systems - Performance and Tuning

Cell - 443 632-4191

Work - 410 786-0386

terry.ma...@cms.hhs.gov

Telecommuting on Fridays - Use my cell phone

 




-- 
Kris Buelens,
IBM Belgium, VM customer support 

Re: MDISK DEFINITION in MAINT DIRECTORY ENTRY

[Kris Buelens]

Please oh please: use DIRMAP iso DISKMAP.  DIRAMP knows how to properly
treat fullpack minidisks, they are not taken as overlap...
In my CP directories, **any** overlap signals a problem, there should be not
a single one, otherwise people will miss a truely unexpected overlap too.
DIRMAP even signal overlaps with a non-zero return code and message to the
console, but, it ignores fullpack overlays.
With DIRMAP fullpack definitions are still a very good thing, for example to
learn DIRMAP how many cylinders a volume has; no need to define a dummy user
$END.

I sent Terry Martin the directory wisdom document I wrote for my former
customer.

2009/3/12, Edward M Martin :
>
>  Hello Terry,
>
>
>
> As others have explained, MAINT uses these to do some functions (DDR backup
> etc).
>
> The overlay is normal from DISKMAP and is expected (well should be).
>
>
>
> I have added user ids of $ALLOC$ and $END$ for cylinder 0 and for the last
> cylinder on
>
> all z/VM volumes as a reminder for myself.
>
>
>
> Just something that helps me keep track.  (No, we do not have DIRMAINT.)
>
>
>
>
>
> Ed Martin
>
> Aultman Health Foundation
>
> 330-588-4723
>
> ext 40441
>   --
>
> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
> Behalf Of *Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR)
> (CTR)
> *Sent:* Wednesday, March 11, 2009 6:07 PM
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* MDISK DEFINITION in MAINT DIRECTORY ENTRY
>
>
>
> Hi
>
>
>
> I did a DISKMAP USER DIRECTORY and while viewing the output I noticed that
> I had a few ‘OVERLAYS’.
>
>
>
> In my MAINT directory entry I have the following:
>
>
>
> MDISK 122 3390 000 END 530SPL MR
>
> MDISK 123 3390 000 END 530RES MR
>
> MDISK 124 3390 000 END 530W01 MR
>
> MDISK 125 3390 000 END 530W02 MR
>
> MDISK 126 3390 000 END 530W03 MR
>
>
>
> Now, I reference these disks I other entries in the directory starting at
> location 001 for however many cylinders I need. As you can see the MDISK
> entries above start at 000 to END.
>
>
>
> The output from the DISKMAP shows the following:
>
>
>
>
>
> VOLUME   USERID  CUU   DEVTYPE  START ENDSIZE
>
> 530SPL   $SPOOL$   B01 3390 0
>  END   ?
>
>  MAINT 122  3390 0
>   END   ? *OVE
>
>
>
>
>
> 530W01   LNXADMIN191  3390  1   00100
> 00100
>
>E49L021P 191  3390  00101
> 00102   2
>
>E49L054P  191 3390  00103
> 00104   2
>
>E49L124P 191  3390  00105
> 00106   2
>
>E49L046P 191  3390  00107
> 00108   2
>
>MAINT  124 3390   0
> END   ? *OVE
>
>
>
>
>
>
>
> 530W02   E49L021P  910 3390  1   00200
> 00200
>
>E49L054P  910 3390  00201
> 00400   00200
>
>E49L124P  910 3390  00401
> 00600   00200
>
>
>
>E49L046P   910 3390 00801
> 01000   00200
>
>MAINT125 3390 0
> END   ? *OVE
>
>
>
> I see what the problem is my question is do I need to have the entries for
> these disks in the MAINT directory entry? And what are the consequences if
> they are removed from the MAINT entry. This is the way the DIRECTORY was
> shipped on the install tape.
>
>
>
> Thanks for the help!
>
>
>
>
>
> *Thank You,*
>
>
>
> *Terry** Martin*
>
> *Lockheed** Martin** - Information Technology*
>
> *z/OS & z/VM Systems - Performance and Tuning*
>
> *Cell - 443 632-4191*
>
> *Work - 410 786-0386*
>
> *terry.ma...@cms.hhs.gov*
>
> *Telecommuting on Fridays - Use my cell phone*
>
>
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: MDISK DEFINITION in MAINT DIRECTORY ENTRY

[Edward M Martin]

Hello Terry,

 

As others have explained, MAINT uses these to do some functions (DDR
backup etc).

The overlay is normal from DISKMAP and is expected (well should be).

 

I have added user ids of $ALLOC$ and $END$ for cylinder 0 and for the
last cylinder on 

all z/VM volumes as a reminder for myself.  

 

Just something that helps me keep track.  (No, we do not have DIRMAINT.)

 

 

Ed Martin

Aultman Health Foundation

330-588-4723

ext 40441



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR)
(CTR)
Sent: Wednesday, March 11, 2009 6:07 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: MDISK DEFINITION in MAINT DIRECTORY ENTRY

 

Hi

 

I did a DISKMAP USER DIRECTORY and while viewing the output I noticed
that I had a few 'OVERLAYS'. 

 

In my MAINT directory entry I have the following:

 

MDISK 122 3390 000 END 530SPL MR 

MDISK 123 3390 000 END 530RES MR 

MDISK 124 3390 000 END 530W01 MR 

MDISK 125 3390 000 END 530W02 MR 

MDISK 126 3390 000 END 530W03 MR

 

Now, I reference these disks I other entries in the directory starting
at location 001 for however many cylinders I need. As you can see the
MDISK entries above start at 000 to END.

 

The output from the DISKMAP shows the following:

 

 


VOLUME   USERID  CUU   DEVTYPE  START ENDSIZE


530SPL   $SPOOL$   B01 3390 0  END
? 

 MAINT 122  3390 0
END   ? *OVE

 

 

530W01   LNXADMIN191  3390  1   00100
00100

   E49L021P 191  3390  00101   00102
2

   E49L054P  191 3390  00103   00104
2

   E49L124P 191  3390  00105   00106
2

   E49L046P 191  3390  00107   00108
2

   MAINT  124 3390   0
END   ? *OVE

 

 

 

530W02   E49L021P  910 3390  1   00200
00200 

   E49L054P  910 3390  00201   00400
00200 

   E49L124P  910 3390  00401   00600
00200 

 


   E49L046P   910 3390 00801   01000
00200 

   MAINT125 3390 0
END   ? *OVE

 

I see what the problem is my question is do I need to have the entries
for these disks in the MAINT directory entry? And what are the
consequences if they are removed from the MAINT entry. This is the way
the DIRECTORY was shipped on the install tape.

 

Thanks for the help!

 

 

Thank You,

 

Terry Martin

Lockheed Martin - Information Technology

z/OS & z/VM Systems - Performance and Tuning

Cell - 443 632-4191

Work - 410 786-0386

terry.ma...@cms.hhs.gov

Telecommuting on Fridays - Use my cell phone

 

SV: MDISK DEFINITION in MAINT DIRECTORY ENTRY

[Brüchmann.Frank FBR]

Hi Terry.
 
Are you using the (doends option when running diskmap? I only get these
overlays when using (doends, otherwise they're supressed.
 
Regards 
Frank Bruchmann.



Fra: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] På
vegne af Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR)
(CTR)
Sendt: 11. marts 2009 23:07
Til: IBMVM@LISTSERV.UARK.EDU
Emne: MDISK DEFINITION in MAINT DIRECTORY ENTRY



Hi

 

I did a DISKMAP USER DIRECTORY and while viewing the output I noticed
that I had a few 'OVERLAYS'. 

 

In my MAINT directory entry I have the following:

 

MDISK 122 3390 000 END 530SPL MR 

MDISK 123 3390 000 END 530RES MR 

MDISK 124 3390 000 END 530W01 MR 

MDISK 125 3390 000 END 530W02 MR 

MDISK 126 3390 000 END 530W03 MR

 

Now, I reference these disks I other entries in the directory starting
at location 001 for however many cylinders I need. As you can see the
MDISK entries above start at 000 to END.

 

The output from the DISKMAP shows the following:

 

 
VOLUME   USERID  CUU   DEVTYPE  START ENDSIZE
530SPL   $SPOOL$   B01 3390 0  END
? 

 MAINT 122  3390 0
END   ? *OVE

 

 

530W01   LNXADMIN191  3390  1   00100
00100

   E49L021P 191  3390  00101   00102
2

   E49L054P  191 3390  00103   00104
2

   E49L124P 191  3390  00105   00106
2

   E49L046P 191  3390  00107   00108
2

   MAINT  124 3390   0
END   ? *OVE

 

 

 

530W02   E49L021P  910 3390  1   00200
00200 

   E49L054P  910 3390  00201   00400
00200 

   E49L124P  910 3390  00401   00600
00200 

 
E49L046P   910 3390 00801   01000   00200
MAINT125 3390 0 END   ?
*OVE

 

I see what the problem is my question is do I need to have the entries
for these disks in the MAINT directory entry? And what are the
consequences if they are removed from the MAINT entry. This is the way
the DIRECTORY was shipped on the install tape.

 

Thanks for the help!

 

 

Thank You,

 

Terry Martin

Lockheed Martin - Information Technology

z/OS & z/VM Systems - Performance and Tuning

Cell - 443 632-4191

Work - 410 786-0386

terry.ma...@cms.hhs.gov

Telecommuting on Fridays - Use my cell phone

 


__
KMD A/S, Lautrupparken 40-42, DK-2750 Ballerup, CVR-nr. 26911745 

KMD er medlem af IT-Branchen og Dansk Erhverv samt anmeldt til
Datatilsynet som edb-servicevirksomhed. KMD er certificeret i henhold
til ISO 9001:2000, med Dansk Standard som certificerende organ og er
desuden Microsoft Gold Certified Partner og Certificeret SAP Hosting
Center.

www.kmd.dk www.kundenet.kmd.dk www.e-Boks.dk www.organisator.dk
www.kmdinternational.com

Hvis du har modtaget denne e-mail ved en fejl, bedes du venligst give
mig besked herom og slette den.
If you received this e-mail by mistake, please notify me and delete it.
Thank you.

Re: SHARE attendees - Any Update on the Live Guest Migration?

[James Vincent]

Weekly?!  You must have accumulated some of the service and waited to only
do it weekly. :-)

-- Jim


On Wed, Mar 11, 2009 at 7:13 PM, Marcy Cortes  wrote:

> You forgot
> (l) would like to practice SERVICE and PUT2PROD weekly!
>
>
> Marcy
>