3390-3 DASD Paging devices still needed?
Dear all, We are intending to migrate from a DS8100 to a new DS8700 and consider to quit with 3390-3 DASD addresses during this migration. I remember that there was always the saying that paging devices should reside on 3390-3 since the paging code was specially optimized for those devices, I wanted to verify if this is still valid for z/VM 5.4 and 6.1. In that case we would still need a range of 3390 devices. What would be your recommendation? Thank you very much in advance for your feedback. -- Best regards Florian
Re: 3390-3 DASD Paging devices still needed?
I wouldn't say paging is specially optimized for 3390-3. But, simple example, if you'd need 9GB of paging space, - with 3390/3 you have 3 access paths, CP can do 3 paging operations concurrently - with 3390/9 there is only one access path, hence only 1 paging operation PAV -that assigns more than one address to a given volume- will not halp as CP doesn't se PAV on paging volumes. So, for high paging rates, the more volumes the better. Kris Buelens 2010/6/21, Florian Bilek florian.bi...@gmail.com: Dear all, We are intending to migrate from a DS8100 to a new DS8700 and consider to quit with 3390-3 DASD addresses during this migration. I remember that there was always the saying that paging devices should reside on 3390-3 since the paging code was specially optimized for those devices, I wanted to verify if this is still valid for z/VM 5.4 and 6.1. In that case we would still need a range of 3390 devices. What would be your recommendation? Thank you very much in advance for your feedback. -- Best regards Florian -- Kris Buelens, IBM Belgium, VM customer support
SFS - remove a minidisk
I've found all sorts of information in the CMS file pool planning and admin guide on how to create, and expand a filepool, but I've been unable to figure out how to shrink a filepool. Even with all my years in VM I'm still pretty much a novice with SFS. I added additional minidisk space to a filepool, and then decided afterwards that I had given the space to the wrong filepool. How do I take this space away? I thought FILESERV REORG, but that appears to be only for the catalog space. TIA. -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317
Re: SFS - remove a minidisk
Look in the File Pool Planning Admin manual at 'Removing Space from a File Pool' You can replace a user storage mdisk with a minimally sized mdisk From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mark Pace Sent: Monday, June 21, 2010 9:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: SFS - remove a minidisk I've found all sorts of information in the CMS file pool planning and admin guide on how to create, and expand a filepool, but I've been unable to figure out how to shrink a filepool. Even with all my years in VM I'm still pretty much a novice with SFS. I added additional minidisk space to a filepool, and then decided afterwards that I had given the space to the wrong filepool. How do I take this space away? I thought FILESERV REORG, but that appears to be only for the catalog space. TIA. -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.
Re: SFS - remove a minidisk
Thanks, John. Exactly what I was looking for. On Mon, Jun 21, 2010 at 9:39 AM, Romanowski, John (OFT) john.romanow...@cio.ny.gov wrote: Look in the File Pool Planning Admin manual at 'Removing Space from a File Pool' You can replace a user storage mdisk with a minimally sized mdisk *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On Behalf Of *Mark Pace *Sent:* Monday, June 21, 2010 9:28 AM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* SFS - remove a minidisk I've found all sorts of information in the CMS file pool planning and admin guide on how to create, and expand a filepool, but I've been unable to figure out how to shrink a filepool. Even with all my years in VM I'm still pretty much a novice with SFS. I added additional minidisk space to a filepool, and then decided afterwards that I had given the space to the wrong filepool. How do I take this space away? I thought FILESERV REORG, but that appears to be only for the catalog space. TIA. -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317
Re: what is a 'full pack' minidisk?
I second what Jim Hughes said - essentially that if it doesn't include cylinder 0 it's just a minidisk, no matter what the size. Personally, and as discussed here by others in the distant past, I prefer to not give out the last cylinder of a real volume in order to make it much easier to copy a 1st level volume for 2nd level testing. Doing this is just an extention of the same logic that leaves the last cylinder of the system volumes empty by design (as requested of IBM by user groups). So now you need a term for a 1 to (END-1) minidisk :) On a related note, I don't like using END in the first place because it's not obvious how big it is unless you know the size of the volume. It's an unneeded obfuscation. Brian Nielsen On Fri, 18 Jun 2010 16:45:54 -0600, Scott Rohling scott.rohl...@gmail.com wrote: I like that - it does imply 'almost'.. but now I'm going for '12end'. We'll see if it lasts through the weekend ;-) Tot ziens! Scott Rohling On Fri, Jun 18, 2010 at 4:33 PM, Rob van der Heij rvdh...@gmail.com wrote: On Fri, Jun 18, 2010 at 11:26 PM, Scott Rohling scott.rohl...@gmail.com wrote: Ok -- darn it. a 1 to END minidisk just doesn't have the same ring to it as 'full pack'. And it's another syllable to mumble.. ;-) Care for my pseudo full-pack terminology maybe? (sounds more official than almost full-pack)
IEC606I VTOC INDEX DISABLED
Hello all, I was adding a 2nd page volume LEPG2A (3390-3) to one of our newly installed z/VM 6.1 and I accidentally formatted cylinder 0 PERM. We are now getting alerts about IEC606I VTOC INDEX DISABLED ON 5815,LEPG2A,142,. The new Page volume is working on z/VM. q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- LEPG1A 5814 1 3338 600840 0 0 0% LEPG2A 5815 1 3338 600840 0 0 0% -- -- SUMMARY1174K 0 0% USABLE 1174K 0 0% All our DASD storage is managed from the MVS side and I am guessing that it looks for the VTOC and alerts when it cannot find one. Can I use ICKDSF to put a valid VTOC back on the DASD? Are there any pointers on this subject that I can use to get more information on? Does Device Support facility's user guide all the information that I need to do the above. Thank you, Ashwin Bhemidhi Texas Instruments Inc.
Re: what is a 'full pack' minidisk?
On the other hand, it is possible for 3390-xx devices to be most any size that you want. The -03, -06 etc. designations are almost meaningless. You are not required to define (in the CU) a multiple of 3339 for the disk sizes. In this environment, 0-END is the way to define a full-pack minidisk regardless of the number of cylinders. The other way would be by DEVNO, iff you can count on the hardware people never changing the address. Here, the hardware people have changed the addresses of disks and have redefined capacities upward, but they have never changed a volser of one of the VM packs or created a duplicate of one that I care about; 0-END is best for me. I agree with the idea that a minidisk defined from 1-end is just a minidisk and the full-pack designation is a special case, unique unto itself. Personally, I have never seen the need for a term for an mdisk defined as 1-end, where end is either the word END or a number that is the equal to highest cylinder of the disk. Aside from being lazy, not wanting to periodically (after every h/w activity that includes messing with the dasd controllers) have to enter QUERY DASD DETAILS for every disk that I want protected by an MDISK that covers the entire disk, prefer the use of END instead of 3339, 10016 or whatever the ending cylinder number is. As an aside, I have seen some (physical) disks defined as small as 100 cylinders. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Brian Nielsen Sent: Monday, June 21, 2010 7:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: what is a 'full pack' minidisk? I second what Jim Hughes said - essentially that if it doesn't include = cylinder 0 it's just a minidisk, no matter what the size. Personally, and as discussed here by others in the distant past, I prefer= to not give out the last cylinder of a real volume in order to make it = much easier to copy a 1st level volume for 2nd level testing. Doing this= is just an extention of the same logic that leaves the last cylinder of = the system volumes empty by design (as requested of IBM by user groups). So now you need a term for a 1 to (END-1) minidisk :) On a related note, I don't like using END in the first place because = it's not obvious how big it is unless you know the size of the volume. = It's an unneeded obfuscation. Brian Nielsen On Fri, 18 Jun 2010 16:45:54 -0600, Scott Rohling scott.rohl...@gmail.com wrote: I like that - it does imply 'almost'.. but now I'm going for '12end'. We'll see if it lasts through the weekend ;-) Tot ziens! Scott Rohling On Fri, Jun 18, 2010 at 4:33 PM, Rob van der Heij rvdh...@gmail.com = wrote: On Fri, Jun 18, 2010 at 11:26 PM, Scott Rohling scott.rohl...@gmail.com wrote: Ok -- darn it. a 1 to END minidisk just doesn't have the same = ring to it as 'full pack'. And it's another syllable to mumble.. ;-) Care for my pseudo full-pack terminology maybe? (sounds more official than almost full-pack)
Re: IEC606I VTOC INDEX DISABLED
The problem is that the device was still online to MVS and originally had an indexed VTOC when initialized on that system. If the device is varied offline to MVS, there should be no error messages from MVS. There are some volumes that should not be online to MVS, this includes all CP_Owned volumes. Here, the MVS DASD Storage Management manages VM storage, too. But its only act in this capacity is to insure that the device is offline to MVS before they give it to VM, and will be offline after MVS is IPLed.. After that, it is no longer their responsibility. When you use ICKDSF to format a volume for VM, you should specify that it is a CPVOL. Doing that will guarantee that a dummy VTOC having no free space will be included in cylinder 0. That will prevent error messages if the volume is varied on to MVS and will prevent MVS from accidentally allocating a dataset on the volume. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bhemidhi, Ashwin Sent: Monday, June 21, 2010 8:52 AM To: IBMVM@LISTSERV.UARK.EDU Subject: IEC606I VTOC INDEX DISABLED Hello all, I was adding a 2nd page volume LEPG2A (3390-3) to one of our newly installed z/VM 6.1 and I accidentally formatted cylinder 0 PERM. We are now getting alerts about IEC606I VTOC INDEX DISABLED ON 5815,LEPG2A,142,. The new Page volume is working on z/VM. q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- LEPG1A 5814 1 3338 600840 0 0 0% LEPG2A 5815 1 3338 600840 0 0 0% -- -- SUMMARY1174K 0 0% USABLE 1174K 0 0% All our DASD storage is managed from the MVS side and I am guessing that it looks for the VTOC and alerts when it cannot find one. Can I use ICKDSF to put a valid VTOC back on the DASD? Are there any pointers on this subject that I can use to get more information on? Does Device Support facility's user guide all the information that I need to do the above. Thank you, Ashwin Bhemidhi Texas Instruments Inc.
Re: IEC606I VTOC INDEX DISABLED
Hi, Ashwin. When you formatted and allocated the DASD volume from z/OS, did you specify the CPVOL attribute? That tell ICKDSF to creaet a dummy z/OS style VTOC in cylinder 0 so that to z/OS, the DASD looks full. Also, it's a good idea not to make any of the DASD volumes that z/VM has marked as 'cpowned' available to the z/OS side. DJ On 06/21/2010 10:51 AM, Bhemidhi, Ashwin wrote: Hello all, I was adding a 2nd page volume LEPG2A (3390-3) to one of our newly installed z/VM 6.1 and I accidentally formatted cylinder 0 PERM. We are now getting alerts about IEC606I VTOC INDEX DISABLED ON 5815,LEPG2A,142,. The new Page volume is working on z/VM. q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- LEPG1A 5814 1 3338 600840 0 0 0% LEPG2A 5815 1 3338 600840 0 0 0% -- -- SUMMARY 1174K 0 0% USABLE 1174K 0 0% All our DASD storage is managed from the MVS side and I am guessing that it looks for the VTOC and alerts when it cannot find one. Can I use ICKDSF to put a valid VTOC back on the DASD? Are there any pointers on this subject that I can use to get more information on? Does Device Support facility's user guide all the information that I need to do the above. Thank you, Ashwin Bhemidhi Texas Instruments Inc. -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: 3390-3 DASD Paging devices still needed?
Dear Kris, Thank you very much. This is what I was wondering if z/VM would use PAV b ut is doesn't. Thank you very much. Kind regards, Florian On Mon, 21 Jun 2010 15:15:38 +0200, Kris Buelens kris.buel...@gmail.com wrote: I wouldn't say paging is specially optimized for 3390-3. But, simple example, if you'd need 9GB of paging space, - with 3390/3 you have 3 access paths, CP can do 3 paging operations concurrently - with 3390/9 there is only one access path, hence only 1 paging operati on PAV -that assigns more than one address to a given volume- will not halp as CP doesn't se PAV on paging volumes. So, for high paging rates, the more volumes the better. Kris Buelens 2010/6/21, Florian Bilek florian.bi...@gmail.com: Dear all, We are intending to migrate from a DS8100 to a new DS8700 and consider to quit with 3390-3 DASD addresses during this migration. I remember that there was always the saying that paging devices should reside on 3390-3 since the paging code was specially optimized for tho se devices, I wanted to verify if this is still valid for z/VM 5.4 and 6. 1. In that case we would still need a range of 3390 devices. What would be your recommendation? Thank you very much in advance for your feedback. -- Best regards Florian -- Kris Buelens, IBM Belgium, VM customer support =
Re: what is a 'full pack' minidisk?
I'm NOT advocating the use of END when defining MDISKs!One of the first things I beg my customers to do is stop using END and use the number of cylinders on all MDISK statements. I concur that it's lazy and creates extra work and confusion. Also makes creating DASD usage reports out of a directory from a remote system impossible. My original post was about how to refer to a minidisk that's defined from 1-END -- because that language fits all sizes. Referring to it and actually defining it are two different things. Always use the number of cylinders when defining an MDISK. Never use END. On a DEFINE MDISK command - go ahead and use END -- but NOT in the directory. Scott Rohling On Mon, Jun 21, 2010 at 9:59 AM, Schuh, Richard rsc...@visa.com wrote: On the other hand, it is possible for 3390-xx devices to be most any size that you want. The -03, -06 etc. designations are almost meaningless. You are not required to define (in the CU) a multiple of 3339 for the disk sizes. In this environment, 0-END is the way to define a full-pack minidisk regardless of the number of cylinders. The other way would be by DEVNO, iff you can count on the hardware people never changing the address. Here, the hardware people have changed the addresses of disks and have redefined capacities upward, but they have never changed a volser of one of the VM packs or created a duplicate of one that I care about; 0-END is best for me. I agree with the idea that a minidisk defined from 1-end is just a minidisk and the full-pack designation is a special case, unique unto itself. Personally, I have never seen the need for a term for an mdisk defined as 1-end, where end is either the word END or a number that is the equal to highest cylinder of the disk. Aside from being lazy, not wanting to periodically (after every h/w activity that includes messing with the dasd controllers) have to enter QUERY DASD DETAILS for every disk that I want protected by an MDISK that covers the entire disk, prefer the use of END instead of 3339, 10016 or whatever the ending cylinder number is. As an aside, I have seen some (physical) disks defined as small as 100 cylinders. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Brian Nielsen Sent: Monday, June 21, 2010 7:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: what is a 'full pack' minidisk? I second what Jim Hughes said - essentially that if it doesn't include = cylinder 0 it's just a minidisk, no matter what the size. Personally, and as discussed here by others in the distant past, I prefer= to not give out the last cylinder of a real volume in order to make it = much easier to copy a 1st level volume for 2nd level testing. Doing this= is just an extention of the same logic that leaves the last cylinder of = the system volumes empty by design (as requested of IBM by user groups). So now you need a term for a 1 to (END-1) minidisk :) On a related note, I don't like using END in the first place because = it's not obvious how big it is unless you know the size of the volume. = It's an unneeded obfuscation. Brian Nielsen On Fri, 18 Jun 2010 16:45:54 -0600, Scott Rohling scott.rohl...@gmail.com wrote: I like that - it does imply 'almost'.. but now I'm going for '12end'. We'll see if it lasts through the weekend ;-) Tot ziens! Scott Rohling On Fri, Jun 18, 2010 at 4:33 PM, Rob van der Heij rvdh...@gmail.com = wrote: On Fri, Jun 18, 2010 at 11:26 PM, Scott Rohling scott.rohl...@gmail.com wrote: Ok -- darn it. a 1 to END minidisk just doesn't have the same = ring to it as 'full pack'. And it's another syllable to mumble.. ;-) Care for my pseudo full-pack terminology maybe? (sounds more official than almost full-pack)
Re: what is a 'full pack' minidisk?
What do you do for your reports if an mdisk is defined by DEVNO instead of volser? You have remote access to the directory but cannot get the output from QUERY DASD DETAILS? You have your preferences, which you state as though they are an absolute law. I have mine which are different from yours, so I guess I am breaking the law :-). I hope the offense is not a felony. If I am ever in a position where I have to report on DASD usage by cylinder from a remote location that has access to the directory but not to the system, I might change. Until then, I see no compelling reason why I should switch. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Monday, June 21, 2010 10:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: what is a 'full pack' minidisk? I'm NOT advocating the use of END when defining MDISKs!One of the first things I beg my customers to do is stop using END and use the number of cylinders on all MDISK statements. I concur that it's lazy and creates extra work and confusion. Also makes creating DASD usage reports out of a directory from a remote system impossible. My original post was about how to refer to a minidisk that's defined from 1-END -- because that language fits all sizes. Referring to it and actually defining it are two different things. Always use the number of cylinders when defining an MDISK. Never use END. On a DEFINE MDISK command - go ahead and use END -- but NOT in the directory. Scott Rohling On Mon, Jun 21, 2010 at 9:59 AM, Schuh, Richard rsc...@visa.commailto:rsc...@visa.com wrote: On the other hand, it is possible for 3390-xx devices to be most any size that you want. The -03, -06 etc. designations are almost meaningless. You are not required to define (in the CU) a multiple of 3339 for the disk sizes. In this environment, 0-END is the way to define a full-pack minidisk regardless of the number of cylinders. The other way would be by DEVNO, iff you can count on the hardware people never changing the address. Here, the hardware people have changed the addresses of disks and have redefined capacities upward, but they have never changed a volser of one of the VM packs or created a duplicate of one that I care about; 0-END is best for me. I agree with the idea that a minidisk defined from 1-end is just a minidisk and the full-pack designation is a special case, unique unto itself. Personally, I have never seen the need for a term for an mdisk defined as 1-end, where end is either the word END or a number that is the equal to highest cylinder of the disk. Aside from being lazy, not wanting to periodically (after every h/w activity that includes messing with the dasd controllers) have to enter QUERY DASD DETAILS for every disk that I want protected by an MDISK that covers the entire disk, prefer the use of END instead of 3339, 10016 or whatever the ending cylinder number is. As an aside, I have seen some (physical) disks defined as small as 100 cylinders. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDUmailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Brian Nielsen Sent: Monday, June 21, 2010 7:59 AM To: IBMVM@LISTSERV.UARK.EDUmailto:IBMVM@LISTSERV.UARK.EDU Subject: Re: what is a 'full pack' minidisk? I second what Jim Hughes said - essentially that if it doesn't include = cylinder 0 it's just a minidisk, no matter what the size. Personally, and as discussed here by others in the distant past, I prefer= to not give out the last cylinder of a real volume in order to make it = much easier to copy a 1st level volume for 2nd level testing. Doing this= is just an extention of the same logic that leaves the last cylinder of = the system volumes empty by design (as requested of IBM by user groups). So now you need a term for a 1 to (END-1) minidisk :) On a related note, I don't like using END in the first place because = it's not obvious how big it is unless you know the size of the volume. = It's an unneeded obfuscation. Brian Nielsen On Fri, 18 Jun 2010 16:45:54 -0600, Scott Rohling scott.rohl...@gmail.commailto:scott.rohl...@gmail.com wrote: I like that - it does imply 'almost'.. but now I'm going for '12end'. We'll see if it lasts through the weekend ;-) Tot ziens! Scott Rohling On Fri, Jun 18, 2010 at 4:33 PM, Rob van der Heij rvdh...@gmail.commailto:rvdh...@gmail.com = wrote: On Fri, Jun 18, 2010 at 11:26 PM, Scott Rohling scott.rohl...@gmail.commailto:scott.rohl...@gmail.com wrote: Ok -- darn it. a 1 to END minidisk just doesn't have the same = ring to it as 'full pack'. And it's another syllable to mumble.. ;-) Care for my pseudo full-pack terminology maybe? (sounds more official than almost full-pack)
Re: what is a 'full pack' minidisk?
Ah - well DEVNO isn't supported in the referenced report ;-) (an in house thing from long ago) I didn't mean to state my 'rules' as law -- I always hate it when others do that :-)More like Scott's Rules... Most of my reasons for wanting to see specific cylinders in the directory revolve around avoiding the need for Q DASD DETAILS... whether remote or not.One example is someone who thought the volumes they picked were 3390-9 and but were 3390-54. They coded the MDISK statements 1 to END (from habit) - told the Linux folks they were ready - and now we have a very bloated Linux guest and can't just move the minidisk to another volume (like we could if they had specified the size of 10016). Mostly - specifying the size just avoids confusion and gives an immediate view of the number of cylinders the MDISK requires. END is ambiguous and requires knowledge of the # of cylinders defined on the volume. Avoiding ambiguity goes a long way to eliminating errors... shrug YMMV I consider it a 'best practice' and list it as such for customers.. The exception are 'disk holder' users - like those that define all the volumes on the system as 0 END for the purposes of physical backup, etc. Then END makes sense because you want the whole volume defined regardless of size and it's an 'overlay' disk. Scott Rohling On Mon, Jun 21, 2010 at 1:18 PM, Schuh, Richard rsc...@visa.com wrote: What do you do for your reports if an mdisk is defined by DEVNO instead of volser? You have remote access to the directory but cannot get the output from QUERY DASD DETAILS? You have your preferences, which you state as though they are an absolute law. I have mine which are different from yours, so I guess I am breaking the law :-). I hope the offense is not a felony. If I am ever in a position where I have to report on DASD usage by cylinder from a remote location that has access to the directory but not to the system, I might change. Until then, I see no compelling reason why I should switch. Regards, Richard Schuh -- *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On Behalf Of *Scott Rohling *Sent:* Monday, June 21, 2010 10:53 AM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: what is a 'full pack' minidisk? I'm NOT advocating the use of END when defining MDISKs!One of the first things I beg my customers to do is stop using END and use the number of cylinders on all MDISK statements. I concur that it's lazy and creates extra work and confusion. Also makes creating DASD usage reports out of a directory from a remote system impossible. My original post was about how to refer to a minidisk that's defined from 1-END -- because that language fits all sizes. Referring to it and actually defining it are two different things. Always use the number of cylinders when defining an MDISK. Never use END. On a DEFINE MDISK command - go ahead and use END -- but NOT in the directory. Scott Rohling On Mon, Jun 21, 2010 at 9:59 AM, Schuh, Richard rsc...@visa.com wrote: On the other hand, it is possible for 3390-xx devices to be most any size that you want. The -03, -06 etc. designations are almost meaningless. You are not required to define (in the CU) a multiple of 3339 for the disk sizes. In this environment, 0-END is the way to define a full-pack minidisk regardless of the number of cylinders. The other way would be by DEVNO, iff you can count on the hardware people never changing the address. Here, the hardware people have changed the addresses of disks and have redefined capacities upward, but they have never changed a volser of one of the VM packs or created a duplicate of one that I care about; 0-END is best for me. I agree with the idea that a minidisk defined from 1-end is just a minidisk and the full-pack designation is a special case, unique unto itself. Personally, I have never seen the need for a term for an mdisk defined as 1-end, where end is either the word END or a number that is the equal to highest cylinder of the disk. Aside from being lazy, not wanting to periodically (after every h/w activity that includes messing with the dasd controllers) have to enter QUERY DASD DETAILS for every disk that I want protected by an MDISK that covers the entire disk, prefer the use of END instead of 3339, 10016 or whatever the ending cylinder number is. As an aside, I have seen some (physical) disks defined as small as 100 cylinders. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Brian Nielsen Sent: Monday, June 21, 2010 7:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: what is a 'full pack' minidisk? I second what Jim Hughes said - essentially that if it doesn't include = cylinder 0 it's just a minidisk, no matter what the size. Personally, and as discussed here by others in the
Re: IEC606I VTOC INDEX DISABLED
Hi DJ, I have earlier used CMS CPFMTXA utility to format the DASD. I think CPFMTXA does use ICKDSF for the DASD operations with CPVOL attribute for the format commands. Going forward I will start using ICKDSF instead of cpfmtxa: So the ICKDSF commands for initializing a DASD volume LEPG2A @ 5815 as a page volume will be: ICKDSF console console CPVOL FORMAT UNIT(5815) VFY(LEPG2A) RANGE(0,0) CPVOL FORMAT UNIT(5815) VFY(LEPG2A) RANGE(1,3338) TYPE((PAGE,1, 3338)) I have made note of the point that cpowned VM DASD volumes should be kept offline to MVS. But to check if the dummy VTOC was written: After completing the above format steps, I have detached the volume @ 5815 from VM. I have asked MVS storage support to verify that that appeared ok with the dummy VTOC. They said they got an error trying to read the VTOC. Is this the normal behavior? Thank you, Ashwin Texas Instruments Inc. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dave Jones Sent: Monday, June 21, 2010 11:19 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IEC606I VTOC INDEX DISABLED Hi, Ashwin. When you formatted and allocated the DASD volume from z/OS, did you specify the CPVOL attribute? That tell ICKDSF to creaet a dummy z/OS style VTOC in cylinder 0 so that to z/OS, the DASD looks full. Also, it's a good idea not to make any of the DASD volumes that z/VM has marked as 'cpowned' available to the z/OS side. DJ On 06/21/2010 10:51 AM, Bhemidhi, Ashwin wrote: Hello all, I was adding a 2nd page volume LEPG2A (3390-3) to one of our newly installed z/VM 6.1 and I accidentally formatted cylinder 0 PERM. We are now getting alerts about IEC606I VTOC INDEX DISABLED ON 5815,LEPG2A,142,. The new Page volume is working on z/VM. q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- LEPG1A 5814 1 3338 600840 0 0 0% LEPG2A 5815 1 3338 600840 0 0 0% -- -- SUMMARY 1174K 0 0% USABLE 1174K 0 0% All our DASD storage is managed from the MVS side and I am guessing that it looks for the VTOC and alerts when it cannot find one. Can I use ICKDSF to put a valid VTOC back on the DASD? Are there any pointers on this subject that I can use to get more information on? Does Device Support facility's user guide all the information that I need to do the above. Thank you, Ashwin Bhemidhi Texas Instruments Inc. -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: what is a 'full pack' minidisk?
Another exception might be made for disks used by a system that IPLs both in a virtual machine and on the bare iron and is aware of the full size of each device. Yet another could be devices shared with another system such as z/OS. I have hundreds of disks in these categories, heavily weighted toward the first. And they get changed frequently enough that updating the directory each time would be a real PITA because the changes usually are done in the wee hours of the morning - the directory updates would need to be coordinated with the h/w updates. By specifying 0-END, I prevent my having to make those coordinated directory updates while it is very dark and tired outside, and all of the typos that I would need to correct. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Monday, June 21, 2010 12:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: what is a 'full pack' minidisk? Ah - well DEVNO isn't supported in the referenced report ;-) (an in house thing from long ago) I didn't mean to state my 'rules' as law -- I always hate it when others do that :-)More like Scott's Rules... Most of my reasons for wanting to see specific cylinders in the directory revolve around avoiding the need for Q DASD DETAILS... whether remote or not. One example is someone who thought the volumes they picked were 3390-9 and but were 3390-54. They coded the MDISK statements 1 to END (from habit) - told the Linux folks they were ready - and now we have a very bloated Linux guest and can't just move the minidisk to another volume (like we could if they had specified the size of 10016). Mostly - specifying the size just avoids confusion and gives an immediate view of the number of cylinders the MDISK requires. END is ambiguous and requires knowledge of the # of cylinders defined on the volume. Avoiding ambiguity goes a long way to eliminating errors... shrug YMMV I consider it a 'best practice' and list it as such for customers.. The exception are 'disk holder' users - like those that define all the volumes on the system as 0 END for the purposes of physical backup, etc. Then END makes sense because you want the whole volume defined regardless of size and it's an 'overlay' disk. Scott Rohling On Mon, Jun 21, 2010 at 1:18 PM, Schuh, Richard rsc...@visa.commailto:rsc...@visa.com wrote: What do you do for your reports if an mdisk is defined by DEVNO instead of volser? You have remote access to the directory but cannot get the output from QUERY DASD DETAILS? You have your preferences, which you state as though they are an absolute law. I have mine which are different from yours, so I guess I am breaking the law :-). I hope the offense is not a felony. If I am ever in a position where I have to report on DASD usage by cylinder from a remote location that has access to the directory but not to the system, I might change. Until then, I see no compelling reason why I should switch. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDUmailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Scott Rohling Sent: Monday, June 21, 2010 10:53 AM To: IBMVM@LISTSERV.UARK.EDUmailto:IBMVM@LISTSERV.UARK.EDU Subject: Re: what is a 'full pack' minidisk? I'm NOT advocating the use of END when defining MDISKs!One of the first things I beg my customers to do is stop using END and use the number of cylinders on all MDISK statements. I concur that it's lazy and creates extra work and confusion. Also makes creating DASD usage reports out of a directory from a remote system impossible. My original post was about how to refer to a minidisk that's defined from 1-END -- because that language fits all sizes. Referring to it and actually defining it are two different things. Always use the number of cylinders when defining an MDISK. Never use END. On a DEFINE MDISK command - go ahead and use END -- but NOT in the directory. Scott Rohling On Mon, Jun 21, 2010 at 9:59 AM, Schuh, Richard rsc...@visa.commailto:rsc...@visa.com wrote: On the other hand, it is possible for 3390-xx devices to be most any size that you want. The -03, -06 etc. designations are almost meaningless. You are not required to define (in the CU) a multiple of 3339 for the disk sizes. In this environment, 0-END is the way to define a full-pack minidisk regardless of the number of cylinders. The other way would be by DEVNO, iff you can count on the hardware people never changing the address. Here, the hardware people have changed the addresses of disks and have redefined capacities upward, but they have never changed a volser of one of the VM packs or created a duplicate of one that I care about; 0-END is best for me. I agree with the idea that a minidisk defined from 1-end is just a minidisk and the full-pack
Re: IEC606I VTOC INDEX DISABLED
CPFMTXA is an IBM provided front-end for ICKDSF. There has been a statement posted on this list that support for CPFMTXA will be dropped in the fairly near future. I don't know whether that means that IBM is going to replace ICKDSF or that they just want to get out of the CPFMTXA business. As for the commands, you could use FORMAT RANGE(0,END) TYPE((0,0,PERM)(1,END,PAGE)) parameters instead of using two format commands. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bhemidhi, Ashwin Sent: Monday, June 21, 2010 1:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IEC606I VTOC INDEX DISABLED Hi DJ, I have earlier used CMS CPFMTXA utility to format the DASD. I think CPFMTXA does use ICKDSF for the DASD operations with CPVOL attribute for the format commands. Going forward I will start using ICKDSF instead of cpfmtxa: So the ICKDSF commands for initializing a DASD volume LEPG2A @ 5815 as a page volume will be: ICKDSF console console CPVOL FORMAT UNIT(5815) VFY(LEPG2A) RANGE(0,0) CPVOL FORMAT UNIT(5815) VFY(LEPG2A) RANGE(1,3338) TYPE((PAGE,1, 3338)) I have made note of the point that cpowned VM DASD volumes should be kept offline to MVS. But to check if the dummy VTOC was written: After completing the above format steps, I have detached the volume @ 5815 from VM. I have asked MVS storage support to verify that that appeared ok with the dummy VTOC. They said they got an error trying to read the VTOC. Is this the normal behavior? Thank you, Ashwin Texas Instruments Inc. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dave Jones Sent: Monday, June 21, 2010 11:19 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IEC606I VTOC INDEX DISABLED Hi, Ashwin. When you formatted and allocated the DASD volume from z/OS, did you specify the CPVOL attribute? That tell ICKDSF to creaet a dummy z/OS style VTOC in cylinder 0 so that to z/OS, the DASD looks full. Also, it's a good idea not to make any of the DASD volumes that z/VM has marked as 'cpowned' available to the z/OS side. DJ On 06/21/2010 10:51 AM, Bhemidhi, Ashwin wrote: Hello all, I was adding a 2nd page volume LEPG2A (3390-3) to one of our newly installed z/VM 6.1 and I accidentally formatted cylinder 0 PERM. We are now getting alerts about IEC606I VTOC INDEX DISABLED ON 5815,LEPG2A,142,. The new Page volume is working on z/VM. q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- LEPG1A 5814 1 3338 600840 0 0 0% LEPG2A 5815 1 3338 600840 0 0 0% -- -- SUMMARY 1174K 0 0% USABLE 1174K 0 0% All our DASD storage is managed from the MVS side and I am guessing that it looks for the VTOC and alerts when it cannot find one. Can I use ICKDSF to put a valid VTOC back on the DASD? Are there any pointers on this subject that I can use to get more information on? Does Device Support facility's user guide all the information that I need to do the above. Thank you, Ashwin Bhemidhi Texas Instruments Inc. -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: Query parent z/VM commands?
DIAG 00 shows you the 3rd level CMS user, MAINT, and the 2nd level VM sys
tem, VM2ND. It does
not show you the name of the 1st level VM system, which is what I think w
as meant by parent.
On Tue, 1 Jun 2010 08:13:19 -0500, Frank M. Ramaekers framaek...@ailife.
com wrote:
Okay, got a 2nd level VM up:
diag00
This level of VM
VM: z/VM 5.4.0 0902 64-bit
User: MAINT Time offset: -5
E5D461C5E2C1404045FF *VM/ESA ...*
0010 D4C1C9D5E34040407FC0 *MAINT ..{*
0020 B9B004000386 *...f*
-1 level of VM
VM: z/VM 5.4.0 0903 64-bit LPAR
User: VM2ND Time offset: -5
E5D461C5E2C14040C500 *VM/ESA {...*
0010 E5D4F2D5C44040407FC0 *VM2ND ..{*
0020 B9B004000387 *...g*
Frank M. Ramaekers Jr.
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Michael MacIsaac
Sent: Tuesday, June 01, 2010 7:56 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Query parent z/VM commands?
Alan,
by knowing how deep you are in STSI, you can map it to DIAG 0.
If you say so. I still haven't seen an example, but it is somewhat moot
because I'm still trying to avoid CMS, thus any REXX EXECs.
An instance of CP is determined by cec.lpar[.userid1[.userid2]...]
Yes, I see that now. So the entire hierarchy of info I need *can* be
found in /etc/sysinfo. I'll just need to add a rule that if you want to
know about the second level z/VM at cec1.lpar1.userid1, then you will
have to first pull the info from the first level z/VM at cec1.lpar1, to
include the System_Identifier. Because only one first level z/VM can run
in an LPAR, any z/VM running in cec1.lpar1.*userid* must be the child
of the z/VM running in cec1.lpar1.
Frank,
Thanks for the EXEC, but again it does not appear to show the
System_Identifier of the parent z/VM, and again I'm trying to avoid
using REXX EXECs.
Here is the output on my second level z/VM:
This level of VM
VM: z/VM 5.4.0+ 1001 64-bit
User: MAINT Time offset: -4
E5D461C5E2C1404046FF *VM/ESA ...*
0010 D4C1C9D5E34040407FE0 *MAINT ..\*
0020 C7C0010003E9 *..G{...Z*
-1 level of VM
VM: z/VM 5.4.0+ 0901 64-bit LPAR
User: VM140 Time offset: -4
E5D461C5E2C14040C608 *VM/ESA {...*
0010 E5D4F1F4F04040407FE0 *VM140 ..\*
0020 C7C001000385 *..G{...e*
Thanks to all who replied.
Mike MacIsaac mike...@us.ibm.com (845) 433-7061
_
This message contains information which is privileged and confidential a
nd is solely for the use
of the
intended recipient. If you are not the intended recipient, be aware that
any review, disclosure,
copying, distribution, or use of the contents of this message is strictl
y prohibited. If you have
received this in error, please destroy it immediately and notify us at P
rivacy...@ailife.com.
Re: Query parent z/VM commands?
I don't understand this bit. Could you give us a sample shell script? On Tue, 1 Jun 2010 08:55:53 -0400, Michael MacIsaac mike...@us.ibm.com wrote: An instance of CP is determined by cec.lpar[.userid1[.userid2]...] Yes, I see that now. So the entire hierarchy of info I need *can* be fou nd in /etc/sysinfo. I'll just need to add a rule that if you want to know about the second level z/VM at cec1.lpar1.userid1, then you will have to first pull the info from the first level z/VM at cec1.lpar1, to include the System_Identifier. Because only one first level z/VM can run in an LPAR, any z/VM running in cec1.lpar1.*userid* must be the child of the z/VM running in cec1.lpar1. Alan Ackerman
