Re: Spool Area Full
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 -- Kris Buelens, IBM Belgium, VM customer support
Re: Spool Area Full
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 KRIS30111 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
Re: Spool Area Full
See suggestions below, prefixed by: sugg-- You left out some specific commands, but it looks as if you are aware of them and just wanted more of an overview. You have the major points covered in good order. Nice memory! (Did I remember to say Nice memory!?). 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:01 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 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 sugg-- COPYFILE SYSTEM CONFIG Z -1SYSTEM CONFIG Z (OLDDATE (Having a backup of the previous SYSTEM CONFIG, with the required filetype CONFIG can be handle in case of a crisis, and as evidence of what it looked like before the change) x system config z slot 1 vol1 slot 2 vol2 slot 3 reserved -- which I will change to spoolz sugg-- FFILE ... :-) sugg-- CPSYNTAX SYSTEM CONFIG Z ( **ALWAYS** check for errors) rel z (det link * cf1 cf1 rr cpacc * cf1 a sr def cpown slot 3 spoolz att cuu system spoolz sugg--- CP START VOLid spoolz ALL sugg--- Prevent MDISKs from be allocated on that volume, mark that volume in use however you do it (perhaps with VM:Secure, perhaps buy adding a disk ot $PAGE$, or some other - just as long as no MDISKs can get allocated thereon). 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 -- 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.
Re: Spool Area Full
One minor thing out of order... You should probably update the first level directory entry for the second level guest before committing the disk to the second level guest's use. Probably not gonna bite you if you do it afterward, but, ... Also, depending upon your volser naming scheme and what you do with volsers at first level IPL time, you may have to change the include/exclude section for volumes in the first level system config, or some vary on/off or other actions in some AUTOLOGx step. This seems to vary from site to site. I think you should also have it in the includes for system volumes on the second level system config. I can't remember if the slot definition reserves it, so the include may only have a documentation effect, but I think it is a good idea. - Original Message - From: James M To: IBMVM@LISTSERV.UARK.EDU Sent: Friday, May 04, 2007 11:01 AM Subject: Re: Spool Area Full snip 2nd level steps 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
Re: Spool Area Full
Rich Greenberg wrote: On: Fri, May 04, 2007 at 11:59:16AM -0400,James M Wrote: } 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. Yes you will. Make sure you detach the 2 disks from the 2nd level system as soon as the DDR is done. Or just do the DDR to tape (unless you have lots of spare DASD). If these disks would duplicate any first level labels, it would be a good idea to re-label them. Do I understand correctly that you want to DDR backup your 1st-level CP owned DASD on a second-level VM? If so, how did you attach them to the 2ndlevel sys? Also, keep in mind that if these CP-vols contain SPOOL, Warm, or CKPT areas, you probably won't get a decent DDR copy unless you run a Standalone DDR. This is because SPOOL pointers are likely to be changing on the running system WHILE you are making you image copy. If you prefer not to run Standalone DDR, you should make sure you have a good SPXTAPE dump of your SPOOL and SDF files.
Re: Spool Area Full
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 KRIS30111 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
Re: Spool Area Full
Thanks for all the help everyone. It's comforting to know there are people out there who care. I've added the spool volume without problems. Before I did... spxtape dump spool all ddr 123 to tape ddr 124 to tape sent user direct diskmap to my id on 1st level sent system config to my 1st level id sent q cpload output to 1st level -James On 5/4/07, Mike Walter [EMAIL PROTECTED] wrote: 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][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] [EMAIL PROTECTED]* * Sent by: The IBM z/VM Operating System [EMAIL PROTECTED]IBMVM@LISTSERV.UARK.EDU 05/04/2007 10:59 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED]IBMVM@LISTSERV.UARK.EDU To [EMAIL PROTECTED] 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] *[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 KRIS30111 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
Re: Spool Area Full
Thanks for the confirmation that you've completed the task. It's not all that often that those offering guidance on the list actually hear back when the task at hand is done. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. --- In reply to: Thanks for all the help everyone. It's comforting to know there are people out there who care. I've added the spool volume without problems. Before I did... spxtape dump spool all ddr 123 to tape ddr 124 to tape sent user direct diskmap to my id on 1st level sent system config to my 1st level id sent q cpload output to 1st level -James 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.
Re: Spool Area Full
James, Kris and others already covered it, but I'll stress it once more: get into the habit of always using MR instead of MW. Then if you realy need MW, you will stop and think. And think again. I agree with George re backing up CF1. Always backup CF1 that has been tested with IPL onto CF2 before doing any change to CF1. To prevent copying already modified CF1, you may compare the time of the last IPL (you can find it from 'Q CPLEVEL') with the timestamp of the newest file on CF1. Make sure that one of the parm disks is always accessed by CP. Otherwise, you will get logon screens without logo etc. If you need a bit of reassurance (as we all do from time to time), here is a sequence of commands that you may use: from MAINT or other authorised user link maint cf1 cf1 rr acc cf1 u q cplevel compare the IPL timestamp and the timestamp of the newest file on the CF1 and decide if you need to backup CF1 cprel b link maint cf2 cf2 mr acc cf2 v copy * * u = = v (oldd repthere shouldn't be any file-mode-zero files on CF1 rel v (det cpacc maint cf2 b sr now you have CF2 as an exact copy of tested CF1 and you can safely do the next command cprel a link maint cf1 cf1 mr acc cf1 z continue updating CF1 as you suggested On the first level, use some sort of standard labelling for the disks and use label ranges in the SYSTEM CONFIG. If you have free disks, label them according to that standard. That way they will get picked up and attached to the first level's system on the next IPL of the first level without any changes to the first level's SYSTEM CONFIG. Just make sure that new labels won't get CPOWNED by the first level. In the directory entry for the second level, define a full-pack minidisk and then link it from the second level instead of dedicating the disk to the second level and you will have a record of that disk being used on the first level's disk map. And it's going to be easier for you to modify second level's parm disk from the first level if need be. If you want to use disk-to-disk backups, define more full-pack minidisks for the second level and mark them somehow (e.g. use vaddrs Bxxx) so you know they are backups, not the real thing. Change the labels of backup disks (and the MDISK entries for those Bxxx minidisks in the first level's directory) after the DDR. Also, as somebody else already said, allocate cyl 0 PERM. It will give you even more peace of mind. But I'm glad you've finished the task even without my lengthy advice. :-) Ivica Brodaric Systems Programmer Tabcorp Sydney
Re: Spool Area Full
My personal note says: /* To add a CP_Owned DASD on the fly do: */ /*1. Make sure the real device is NOT attached to the system.*/ /*2. issue: DEFINE CPOWNED SLOT nn volser OWN */ /*3. ATTACH rdev SYSTEM */ Some people might do SPOL 1-end but 0-end is OK -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of James M Sent: Monday, April 30, 2007 8:52 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Spool Area Full 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 If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: Spool Area Full
On 4/30/07, James M [EMAIL PROTECTED] wrote: Followup question - is there a convenient way to migrate spool files from that volume without cold starting? Nope. Once CP has put spool files there, the only way to get it free is through natural death of spool files living there. So in practice, you will not be able to get it back. If you don't want to spend that extra volume you might do wise and check if some of the large files can be removed to free up space. 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? Apples and pears. One is blocks and the other one is tracks. One included DUMP and the other does not. Any rexx exec's out there that can monitor spool and send me an email if x%? From a class D userid the following quick and dirty plumbing might do: 1) Find spool files of more than 10,000 blocks: pipe cp q rdr exp | locate 77.4 ,K, | cons 2) Find the biggest 10 files 10K blocks pipe cp q rdr exp | sort 77.4 d|take 10|cons -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: Spool Area Full
From a class D userid the following quick and dirty plumbing might do: Too quick ;-) ... repeat for PRT (and maybe PUN) when needed. Rob
Re: Spool Area Full
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 -- Kris Buelens, IBM Belgium, VM customer support
Re: Spool Area Full
Didn't work properly pipe cp q rdr exp|locate 77.4,K,|cons FPLPAT112E Excessive options .4,K, FPLSCA003I ... Issued from stage 2 of pipeline 1 FPLSCA001I ... Running locate 77.4,K, ...is there not a rexx repository similar to cpan or pear? -James On 4/30/07, Rob van der Heij [EMAIL PROTECTED] wrote: On 4/30/07, James M [EMAIL PROTECTED] wrote: Followup question - is there a convenient way to migrate spool files from that volume without cold starting? Nope. Once CP has put spool files there, the only way to get it free is through natural death of spool files living there. So in practice, you will not be able to get it back. If you don't want to spend that extra volume you might do wise and check if some of the large files can be removed to free up space. 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? Apples and pears. One is blocks and the other one is tracks. One included DUMP and the other does not. Any rexx exec's out there that can monitor spool and send me an email if x%? From a class D userid the following quick and dirty plumbing might do: 1) Find spool files of more than 10,000 blocks: pipe cp q rdr exp | locate 77.4 ,K, | cons 2) Find the biggest 10 files 10K blocks pipe cp q rdr exp | sort 77.4 d|take 10|cons -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: Spool Area Full
On 4/30/07, James M [EMAIL PROTECTED] wrote: FPLPAT112E Excessive options .4,K, I'd say something happened to the stage separator (vertical bar) while it transferred from your inbasket to the 3270 session. If you cannot find the right character, replace them by ! and using pipe (stagesep !) q rdr exp ! locate 77.4 ,K, | cons etc.
Re: Spool Area Full
David Boyes wrote: Couple of comments: While no longer absolutely necessary, it's good habit to always allocate cyl 0 as PERM, and then do whatever else you need to do. The requirement to do this went away a while ago, but it's just good practice as it reinforces that cyl 0 is something that you don't wan't the system to clobber for any reason. Excellent advice as always from Dave. Make sure you add another open slot at the END of the CPOwned list when you use one of the slots. I'd go as far to suggest that a safe practice is to ALWAYS use slots at the END of the CPowned list when adding new SPOOL volumes.
Re: Spool Area Full
As Dirty Harry said: Go ahead punk, make my day!. And I extoll the value of going in the opposite direction: reserving SLOTs at the very top of the CP_OWNED list for more than enough SPOOL volumes. Reserved SLOTs are cheap: no software or hardware charges, and very little resource consumption. The alternative is that you place the SPOOL SLOTs somewhere else in the CP_OWNED list, and potentially change the SLOT number some day - thereafter losing all SPOOL files the next time you IPL VM. Here's a cut/paste from my SHARE session: z/VM Installation -- It?s Installed, NOW What? (Or: What we learned ?on the job?) ---snip--- SPOOL volumes in first Slots Any change in existing SPOOL volume SLOT order will result in a loss of all SPOOL files on that and trailing SPOOL volumes. You can always add more SPOOL slots lower down (that?s why it is good to have RESERVED slots up top specifically for future SPOOL volume use. Linux virtual machines will require more SPOOL due to DCSS usage ? plan for it. (DCSS? are stored in SPOOL) You can remove completely-empty SPOOL volumes (difficult to get completely empty), as long as they do not affect the SLOT NUMBER order of the remaining SPOOL volumes. When faced with a file similar to the following, what?s your first impulse? CP_Owned Slot 1 VMPP01 OWN CP_Owned Slot 2 VMR51A OWN CP_Owned Slot 3 VMPP08 OWN CP_Owned Slot 4 VMDUMP DUMP CP_Owned Slot 5 VMTD01 OWN CP_Owned Slot 6 VMPG05 OWN CP_Owned Slot 7 VMPG01 OWN CP_Owned Slot 8 VMPP06 OWN CP_Owned Slot 9 VMPG07 OWN CP_Owned Slot 10 VMPP07 OWN CP_Owned Slot 11 VMR51B OWN CP_Owned Slot 12 VMTD02 OWN CP_Owned Slot 13 VMSP01 OWN CP_Owned Slot 14 VMPG02 OWN CP_Owned Slot 15 VMPP04 OWN CP_Owned Slot 16 VMPP05 OWN CP_Owned Slot 17 VMSP02 OWN CP_Owned Slot 18 RESERVED CP_Owned Slot 19 RESERVED CP_Owned Slot 20 RESERVED Why? sort it by volser, of course! And then change the SLOT numbers back into a nice, neat serially sequential list starting at 1. BAD IDEA! At the next IPL you will lose all SPOOL files! Why? -- You changed the SLOT numbers of the SPOOL volumes (in this case fairly obvious VMSP01, VMSP02 ? but maybe not always so obvious). ---snip--- As Bill Cosby said: Noah, how long can you tread water? I figure you can tread water until one fateful day when you decide to clean things up, making them all nice and neat. We sysprogs are after all rather A.R. At the next IPL you can no longer tread water, Dirty Harry (he *is* your manager, right?) has his day made for him. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. George Haddad [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/30/2007 09:30 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 David Boyes wrote: Couple of comments: While no longer absolutely necessary, it's good habit to always allocate cyl 0 as PERM, and then do whatever else you need to do. The requirement to do this went away a while ago, but it's just good practice as it reinforces that cyl 0 is something that you don't wan't the system to clobber for any reason. Excellent advice as always from Dave. Make sure you add another open slot at the END of the CPOwned list when you use one of the slots. I'd go as far to suggest that a safe practice is to ALWAYS use slots at the END of the CPowned list when adding new SPOOL volumes. 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.
Re: Spool Area Full
And I extoll the value of going in the opposite direction: reserving SLOTs at the very top of the CP_OWNED list for more than enough SPOOL volumes. It's a viable approach. The only concern I'd raise is that no matter how many slots you reserve, the probability of hitting the end of that reserved space is much higher than you might expect, and at that point, there's a lot more data at risk if you do it wrong. If you make it a habit to just add to the end of the list, there's no way you can screw up the ordering, and if you add a reserved slot each time you use one, then you always have at least some headroom when the Big Cheeses suddenly want a detailed crosstabulation report on every business factor SAP maintains across the entire history of the company...8-) When faced with a file similar to the following, what's your first impulse? [snip] Leave it the hell alone and find someone else to mess with it...8-) Why... sort it by volser, of course! And then change the SLOT numbers back into a nice, neat serially sequential list starting at 1. [snip] We sysprogs are after all rather A.R. I think that's just you, Mike8-) Ain't broke, don't fix it. Besides, Dan's not *that* violent highly opinionated, though.
Re: Spool Area Full
On Monday, 04/30/2007 at 11:38 EST, Mike Walter [EMAIL PROTECTED] wrote: As Dirty Harry said: Go ahead punk, make my day!. To put a fine point on it (ouch!): The slot number is encoded in the data structures CP uses to find and read spool files. It's an index into the CP-owned list. Once spool files are created on a spool volume, don't change the slot number. If you ever find yourself needing to change the slot numbers you will need to 1. dump the spool to tape, 2. change the slot numbers in SYSTEM CONFIG 3. re-IPL clean 4. reload the spool files. If you can internalize this design point in CP, managing the CP-owned list becomes a *bit* more intuitive. Alan Altmark z/VM Development IBM Endicott
Re: Spool Area Full
Bit was never intuitive. But performance people never are. :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, April 30, 2007 10:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Spool Area Full On Monday, 04/30/2007 at 11:38 EST, Mike Walter [EMAIL PROTECTED] wrote: As Dirty Harry said: Go ahead punk, make my day!. To put a fine point on it (ouch!): The slot number is encoded in the data structures CP uses to find and read spool files. It's an index into the CP-owned list. Once spool files are created on a spool volume, don't change the slot number. If you ever find yourself needing to change the slot numbers you will need to 1. dump the spool to tape, 2. change the slot numbers in SYSTEM CONFIG 3. re-IPL clean 4. reload the spool files. If you can internalize this design point in CP, managing the CP-owned list becomes a *bit* more intuitive. Alan Altmark z/VM Development IBM Endicott
Re: Spool Area Full
To put a fine point on it (ouch!): The slot number is encoded in the data structures CP uses to find and read spool files. It's an index into the CP-owned list. Once spool files are created on a spool volume, don't change the slot number. Just to be sure Are spool files the ONLY things that depend on position in the CP OWNED list? Shimon
Re: Spool Area Full
On Monday, 04/30/2007 at 10:51 ZE2, Shimon Lebowitz [EMAIL PROTECTED] wrote: Just to be sure Are spool files the ONLY things that depend on position in the CP OWNED list? Technically, paging space, but that data doesn't persist across IPLs so the order of paging volumes isn't important. Alan Altmark z/VM Development IBM Endicott
Re: Spool Area Full
Spool is the only thing you could mess up. And remember that system data files are saved in spool space, so included with spool (and the potential to be messed up) are NSS, DCSS, IMG, UCR, NLS, and TRF files. John Franciscovich z/VM Development
Re: Spool Area Full
Do not forget to CP START the device. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTI) Sent: Monday, April 30, 2007 5:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Spool Area Full My personal note says: /* To add a CP_Owned DASD on the fly do: */ /*1. Make sure the real device is NOT attached to the system.*/ /*2. issue: DEFINE CPOWNED SLOT nn volser OWN */ /*3. ATTACH rdev SYSTEM */ Some people might do SPOL 1-end but 0-end is OK -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of James M Sent: Monday, April 30, 2007 8:52 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Spool Area Full 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 If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here http://www.ml.com/email_terms/ for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
