WARM and CKPT cylinders are described by "SYSTEM CONFIG".  E.g.
System_Residence, 
  Checkpoint  Volid ESP54A   From CYL 21  For 9 ,
  Warmstart   Volid ESP54A   From CYL 30  For 9  

The USER DIRECT (or whatever you're using for Directory Management) 
describes where MAINT's CF1, CF2, and CF3 disks, and everything lives. 
It's a good thing to know where the disk containing USER DIRECT lives, too 
(usually on unmodified systems: MAINT 2CC).  Not just for this change, but 
*always* know where those disks live.  Print something that has the 
current locations - you'll be glad you have it if something goes "dead in 
the dark".

Your old VM sysprog (hey... I resemble that remark!) probably has userid 
entries in USER DIRECT to describe where some things are located so that 
no other MDISKs can be allocated over them.  The IBM-defined way is to 
install IDs beginning ending with $-signs, such as:
USER $ALLOC$  NOLOG
USER $DIRECT$ NOLOG
USER $SYSCKP$ NOLOG
USER $SYSWRM$ NOLOG
USER $PAGE$   NOLOG
USER $SPOOL$  NOLOG
USER $TDISK$  NOLOG 
If you're adding a SPOOL volume, it would be a GOOD IDEA to update $SPOOL$ 
to include that full-pack disk so no minidisk gets allocated over your 
SPOOL files at a later date.

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.



"James M" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
05/04/2007 11:46 AM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Spool Area Full






I thought of that already. I ran spxtape dump.
Good idea about the parm disks.
should i get the info from cpload or user direct or both?

On 5/4/07, Mike Walter <[EMAIL PROTECTED]> wrote:

Unless that target system is SHUTDOWN before using DDR, and because of 
lots of things that can change on those two SPOOL DASD and CKPT and WARM 
start areas, you're really much better off using: 
SPXTAPE DUMP tape_vdev SPOOL ALL                                      to 
backup ALL (including types of files: RDR, PRT, PUN, IMG, NLS, NSS, UCR, 
SDF, etc.) 

The if something goes drastically wrong (as it could have it you use "MW" 
on the CPACC, and as Kris observantly pointed out), you can always IPL 
that system CLEAN, fix the problem and SPXTAPE LOAD the files back to 
SPOOL. 

Another consideration: know on what DASD and at what cylinders ranges your 
second level MAINT CF1, CF2 disks reside.  That gives our 1st level system 
a change to change those files if the 2nd level system won't IPL.  It's a 
GOOD THING to know where those disks live (and your directory source disk, 
DRCT cyls, etc. anyway), as well as having experimented with SPXTAPE DUMP 
and LOAD before a crisis. 

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates. 


"James M" <[EMAIL PROTECTED] > 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 
05/04/2007 10:59 AM 

Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>




To
IBMVM@LISTSERV.UARK.EDU 
cc

Subject
Re: Spool Area Full








Ok will do. thanks
another question..
Because I'm paranoid and have no idea what type of backup the vm guy has 
on this system I've decided to ddr the two cpowned volumes to a backup 
disk defore adding the spool. 
I have the disks attached to maint 2nd level
when i copy all maints 123 to the backup vol will that cause problems ?- 
i.e. I won't end up with two sysres volumes with tha same label - right - 
just checking.
-James

On 5/4/07, Kris Buelens <[EMAIL PROTECTED] > wrote: 
It seems all right for the spool.... 

Ough, but what do I see?
  link * cf1 cf1 mw
You should never link in MW mode if you like the data on a CMS minidisk, 
never, never, never (or almost never).
So, change that into
 link * cf1 cf1 m
of
 link * cf1 cf1 mr
The advantage of linking MR is that you the the mindisk in RO mode when 
someone else has it RW, and then a Q LINKS vdev allows you to see the 
virtual address of who prohibits the RW link:
  link maint 193 999 m 
  HCPLNM105E MAINT 0193 not linked; R/W by KRIS3 
  link maint 193 999 mr 
  HCPLNM102E DASD 0999 forced R/O; R/W by KRIS3 
  q links 999 
  KRIS3    0111 R/W, KRIS     0999 R/O 
  cp send cp kris3 DET 111 

"never, never, never (or almost never)":  The only exception I see for an 
MW link to a CMS formatted minidisk is when you are 100% certain that the 
R/W linker has not ACCESSed that minidisk.  Example: the 191 minidisk of a 
Linux guest that when it has not IPLed CMS.

Kris

2007/5/4, James M <[EMAIL PROTECTED] >: 
Now I must put all this theory to work. (my heart's thumping)
I've been ordered to add more spool to a critical second level guest 
because of a rscs problem I reported in a new message today.

Before I do it I want to double check to make sure I've got everything 
right. (It's been years since I did vm - early esa). 

Here's what I think i must do.....PLEASE correct me

att free cuu to 2nd level vm

on 2nd level maint att cuu *
cpfmtxa
label (i.e. spoolz)
format
allocate
0-end spol

Update sysconfig---> 

cprel a
link * cf1 cf1 mw
acc cf1 z
x system config z
  slot 1 vol1
  slot 2 vol2
  slot 3 reserved --> which I will change to spoolz
rel z(det
link * cf1 cf1 rr
cpacc * cf1 a sr

def cpown slot 3 spoolz

att cuu system spoolz

on the first level system I must..
update direct entry for 2nd level guest adding dedicate cuu
I don't believe I need to update 1st level system config for dedicated 
disks - right? 

Did I miss anything - any gotchas?

Thanks for any and all help
-James


On 4/30/07, Kris Buelens < [EMAIL PROTECTED]> wrote: 
Murphy's law dictates a small change in the order of things. 

With the order you propose there is a time window where the SYSTEM CONFIG 
does not know the new spool volume, but CP uses it for new spool files. If 
CP goes down in that window, all spool files with some parts of the new 
volume will be lost after the restart.

The good order to be 100% safe is:
1. Format & allocate (like you say)
2. Update SYSTEM CONFIG
3. DEFINE CPOWNED 
4. ATTACH to SYSTEM

To find which spool files have parts on a given volume, get this tool
    http://www.vm.ibm.com/download/packages/descript.cgi?SPOOLCHN 

2007/4/30, James M <[EMAIL PROTECTED] >: 
z/VM 5.2

I'm backing up the vm sys prog and sure enough - bing - a problem 
immediately.
Problem solved but I have a couple of questions. 

adding a new spool full volume steps - is this correct..
att cuu * as vdev 
cpfmta vdev
label vmspxx
done...
format
done..
allocate
spol 0-end
done...
end
Once cpfmtxa ends - att  cuu system vmspxx  & update cpowned list in 
config file.
...and I'm off and running. 

Followup question - is there a convenient way to migrate spool files from 
that volume without cold starting?

Another spool followup question.
If I query alloc and do the math on the spool numbers I get 80% 
If I q alloc spool I get 53%
How come?

Any rexx exec's out there that can monitor spool and send me an email if > 
x%?

Thanks
James 


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. 


 
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.


Reply via email to