Hillgang reminder
A gentle reminder that the next meeting of Hillgang will take place on Friday 26 March, in Herndon Virginia at the CA office. The meeting¹s agenda and directions are found at http://www.vm.ibm.com/events/hill0326.pdf.
initializing z/Linux disks
Hi I have a question. What I have been doing up to this point for a new z/Linux guest build is, not necessarily in this order and does not necessarily include all steps but, Crave out the DASD for the z/Linux guest Init the DASD using CPFMTXA putting a label on the disk Setting up the Directory entry for the new guest, which includes specifying the MDISK for all of the DASD for the guest. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? If not I assume then I would replace the MDISK statements in the Directory entry with DEDICATE statements for each one of the DISKS. We do not share DASD between guests here so what is defined to the guest belongs to that guest only. Is there anything to be aware of by changing to DEDICATE statements from MDISK statements? My only concern is with the DFDSS backups that I do on the z/OS for the guests. I am not sure if it matters or not to DFDSS whether the pack was initialized via CPFMTXA or z/Linux during the kick start process? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191
Re: initializing z/Linux disks
I have meant to bring this up to the list before now, but since you mention it... I use the clone a golden image methodology. I've used DDR, which always works, and I've used dasdfmt and dd, which sometimes results in an unstable system. I can't pin it down exactly, but I think it happens when I repurpose minidisks that have had Linux filesystems on them previously. The first symptom I see is segmentation faults in YaST. When I CPFMTXA the minidisk before using the dasdfmt and dd cloning method, I don't have the problem. Therefore, I always CPFMTXA the dasd first. Terry, I would not use DEDICATE. I like to preserve cyl 0 because I know z/VM and z/OS understand it. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Wednesday, March 24, 2010 1:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: initializing z/Linux disks Hi I have a question. What I have been doing up to this point for a new z/Linux guest build is, not necessarily in this order and does not necessarily include all steps but, Crave out the DASD for the z/Linux guest Init the DASD using CPFMTXA putting a label on the disk Setting up the Directory entry for the new guest, which includes specifying the MDISK for all of the DASD for the guest. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? If not I assume then I would replace the MDISK statements in the Directory entry with DEDICATE statements for each one of the DISKS. We do not share DASD between guests here so what is defined to the guest belongs to that guest only. Is there anything to be aware of by changing to DEDICATE statements from MDISK statements? My only concern is with the DFDSS backups that I do on the z/OS for the guests. I am not sure if it matters or not to DFDSS whether the pack was initialized via CPFMTXA or z/Linux during the kick start process? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 cid:image001.jpg@01C97FB5.5EAFD6C0
Re: initializing z/Linux disks
Use LXFMT from z/VM, no need to reformat the disk under Linux. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. From an earlier post: Date: Mon, 28 Jan 2008 15:50:31 -0500 Reply-To: r...@vsoftsys.com Sender: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU From: Rick Bourgeois r...@vsoftsys.com Organization: VSSI Subject: Free CMS utilities for Linux and Tape Comments: To: Linux on 390 Port linux-...@vm.marist.edu Content-Type: text/plain; charset=us-ascii Hi all, We have just made available on our website www.vsoftsys.com three free CMS utilities. LXFMT V2.1: LXFMT is a CMS utility that provides the functions of both the DASDFMT and FDASD Linux utilities. LXFMT can be used for ECKD and FBA devices. TBROWSE: TBROWSE is a CMS utility that allows you scan a real or virtual tape in a full screen browse like format. TAPSENSE: TAPSENSE displays sense information for an attached real or defined virtual tape drive. Using the current CSL-WAVV comments on the Linux-390 list of give to get I have included the following as general information. Please feel free to ignore it as we had planned to make these utilities available anyway. An earlier version of our LXFMT utility was made available on the Sinenomine.net website last year. While at our website feel free to browse information on our VM virtualization products VTAPE (Virtual TAPE) and VPARS (Virtual Private Active Record Shadowing for TPF and Linux). I will be presenting technical information on both VPARS and VTAPE at SHARE in Orlando, Session 9155 Tuesday 2/26 at 8am and a Vendor Session Wednesday 2/27 at 4:30pm in Laredo 1. We will also be available at booth 322 at the SHARE Technology Expo with demos, I hope (if all the internet stuff works to get to our mainframe ;-). Our FLEX-ES laptop expired 2/2007 making us dependant on the internet for demos ;-(. We will also be at WAVV in Chattanooga in April. Having been a member of SHARE since the early 1970's but not attending in several years I look forward to renewing many old friendships, making new ones and thanking the VM Group members for my Knighthood at the last SHARE. Thanks and best regards, Sir Rick of PARS Rick Bourgeois r...@vsoftsys.com Virtual Software Systems, Inc. www.vsoftsys.com 770-781-3200 Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/24/2010 12:53 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject initializing z/Linux disks Hi I have a question. What I have been doing up to this point for a new z/Linux guest build is, not necessarily in this order and does not necessarily include all steps but, Crave out the DASD for the z/Linux guest Init the DASD using CPFMTXA putting a label on the disk Setting up the Directory entry for the new guest, which includes specifying the MDISK for all of the DASD for the guest. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? If not I assume then I would replace the MDISK statements in the Directory entry with DEDICATE statements for each one of the DISKS. We do not share DASD between guests here so what is defined to the guest belongs to that guest only. Is there anything to be aware of by changing to DEDICATE statements from MDISK statements? My only concern is with the DFDSS backups that I do on the z/OS for the guests. I am not sure if it matters or not to DFDSS whether the pack was initialized via CPFMTXA or z/Linux during the kick start process? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks
Re: initializing z/Linux disks
The disks are formatted during the Kick Start not sure if there is a choice there to init or not during the Kick Start process Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Wednesday, March 24, 2010 2:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: initializing z/Linux disks Use LXFMT from z/VM, no need to reformat the disk under Linux. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. From an earlier post: Date: Mon, 28 Jan 2008 15:50:31 -0500 Reply-To: r...@vsoftsys.com Sender: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU From: Rick Bourgeois r...@vsoftsys.com Organization: VSSI Subject: Free CMS utilities for Linux and Tape Comments: To: Linux on 390 Port linux-...@vm.marist.edu Content-Type: text/plain; charset=us-ascii Hi all, We have just made available on our website www.vsoftsys.com three free CMS utilities. LXFMT V2.1: LXFMT is a CMS utility that provides the functions of both the DASDFMT and FDASD Linux utilities. LXFMT can be used for ECKD and FBA devices. TBROWSE: TBROWSE is a CMS utility that allows you scan a real or virtual tape in a full screen browse like format. TAPSENSE: TAPSENSE displays sense information for an attached real or defined virtual tape drive. Using the current CSL-WAVV comments on the Linux-390 list of give to get I have included the following as general information. Please feel free to ignore it as we had planned to make these utilities available anyway. An earlier version of our LXFMT utility was made available on the Sinenomine.net website last year. While at our website feel free to browse information on our VM virtualization products VTAPE (Virtual TAPE) and VPARS (Virtual Private Active Record Shadowing for TPF and Linux). I will be presenting technical information on both VPARS and VTAPE at SHARE in Orlando, Session 9155 Tuesday 2/26 at 8am and a Vendor Session Wednesday 2/27 at 4:30pm in Laredo 1. We will also be available at booth 322 at the SHARE Technology Expo with demos, I hope (if all the internet stuff works to get to our mainframe ;-). Our FLEX-ES laptop expired 2/2007 making us dependant on the internet for demos ;-(. We will also be at WAVV in Chattanooga in April. Having been a member of SHARE since the early 1970's but not attending in several years I look forward to renewing many old friendships, making new ones and thanking the VM Group members for my Knighthood at the last SHARE. Thanks and best regards, Sir Rick of PARS Rick Bourgeois r...@vsoftsys.com Virtual Software Systems, Inc. www.vsoftsys.com 770-781-3200 Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/24/2010 12:53 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject initializing z/Linux disks Hi I have a question. What I have been doing up to this point for a new z/Linux guest build is, not necessarily in this order and does not necessarily include all steps but, Crave out the DASD for the z/Linux guest Init the DASD using CPFMTXA putting a label on the disk Setting up the Directory entry for the new guest, which includes specifying the MDISK for all of the DASD for the guest. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? If not I assume then I would replace the MDISK statements in the Directory entry with DEDICATE statements for each one of the DISKS. We do not share DASD between guests here so what is defined to the guest belongs to that guest only. Is there anything to be aware of by changing to DEDICATE statements from MDISK statements? My only concern is with the DFDSS backups that I do on the z/OS for the guests. I am not sure if it matters or not to DFDSS whether the pack was initialized via CPFMTXA or z/Linux during the kick start process? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 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,
Re: initializing z/Linux disks
On 3/24/10 1:53 PM, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Hi I have a question. What I have been doing up to this point for a new z/Linux guest build is, not necessarily in this order and does not necessarily include all steps but, Crave out the DASD for the z/Linux guest Init the DASD using CPFMTXA putting a label on the disk Setting up the Directory entry for the new guest, which includes specifying the MDISK for all of the DASD for the guest. Unless you are giving the guest the real cyl 0, you need to do the format for at least real cyl 0 with ICKDSF (what CPFMTXA runs under the covers) to put a real volume id on the pack. I find that even if you are giving the guest the real cyl 0, the extra step of running DSF on the entire real volume eliminates any past uses that may confuse system operation later on (think about what would happen if you accidentally gave a guest what used to be a VM paging pack, and forgot to clip the allocation bitmap to remove the page space. Bad Things Ensue. Kickstart and VM paging space are NOT compatible. Things Go Boom. Trust Me.) So, if you are giving the guest the full physical volume, you don't HAVE to do the DSF run, but it's an extra safety measure that it doesn't cost much to do, and you'll be grateful for if you ever need it. If not I assume then I would replace the MDISK statements in the Directory entry with DEDICATE statements for each one of the DISKS. We do not share DASD between guests here so what is defined to the guest belongs to that guest only. Is there anything to be aware of by changing to DEDICATE statements from MDISK statements? DEDICATEs tie you very firmly to specific physical configurations. Does your DR configuration have exactly the same device addresses for real devices? If not, then you'll have to update the directory when you move to to DR vs just changing volume labels which aren't bound to specific device addresses. You can do search/replace in both cases, but it's a lot easier to relabel packs when you restore your stuff on them than have to screw around with addresses, especially if it's a REAL emergency and you may not get your normal DR configuration because of a sudden influx of companies needing DR. My only concern is with the DFDSS backups that I do on the z/OS for the guests. I am not sure if it matters or not to DFDSS whether the pack was initialized via CPFMTXA or z/Linux during the kick start process? It shouldn't, but why introduce another variable? CP and z/OS have been getting along well for decades now. It's a one-time step, and it doesn't take that much longer. You can also shortcut the process (if you have Flashcopy) by keeping a blank formatted volume around, flashcopy it to the new disks, and then just run DSF on cyl 0 to relabel the pack. That's almost instantaneous, and you get the best of both worlds. -- db
Re: initializing z/Linux disks
You can DEDICATE by label rather than by real address. But I still don't like Linux having cyl 0 :) Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Wednesday, March 24, 2010 11:20 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] initializing z/Linux disks On 3/24/10 1:53 PM, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Hi I have a question. What I have been doing up to this point for a new z/Linux guest build is, not necessarily in this order and does not necessarily include all steps but, Crave out the DASD for the z/Linux guest Init the DASD using CPFMTXA putting a label on the disk Setting up the Directory entry for the new guest, which includes specifying the MDISK for all of the DASD for the guest. Unless you are giving the guest the real cyl 0, you need to do the format for at least real cyl 0 with ICKDSF (what CPFMTXA runs under the covers) to put a real volume id on the pack. I find that even if you are giving the guest the real cyl 0, the extra step of running DSF on the entire real volume eliminates any past uses that may confuse system operation later on (think about what would happen if you accidentally gave a guest what used to be a VM paging pack, and forgot to clip the allocation bitmap to remove the page space. Bad Things Ensue. Kickstart and VM paging space are NOT compatible. Things Go Boom. Trust Me.) So, if you are giving the guest the full physical volume, you don't HAVE to do the DSF run, but it's an extra safety measure that it doesn't cost much to do, and you'll be grateful for if you ever need it. If not I assume then I would replace the MDISK statements in the Directory entry with DEDICATE statements for each one of the DISKS. We do not share DASD between guests here so what is defined to the guest belongs to that guest only. Is there anything to be aware of by changing to DEDICATE statements from MDISK statements? DEDICATEs tie you very firmly to specific physical configurations. Does your DR configuration have exactly the same device addresses for real devices? If not, then you'll have to update the directory when you move to to DR vs just changing volume labels which aren't bound to specific device addresses. You can do search/replace in both cases, but it's a lot easier to relabel packs when you restore your stuff on them than have to screw around with addresses, especially if it's a REAL emergency and you may not get your normal DR configuration because of a sudden influx of companies needing DR. My only concern is with the DFDSS backups that I do on the z/OS for the guests. I am not sure if it matters or not to DFDSS whether the pack was initialized via CPFMTXA or z/Linux during the kick start process? It shouldn't, but why introduce another variable? CP and z/OS have been getting along well for decades now. It's a one-time step, and it doesn't take that much longer. You can also shortcut the process (if you have Flashcopy) by keeping a blank formatted volume around, flashcopy it to the new disks, and then just run DSF on cyl 0 to relabel the pack. That's almost instantaneous, and you get the best of both worlds. -- db
Re: initializing z/Linux disks
On 3/24/10 2:40 PM, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: You can DEDICATE by label rather than by real address. But I still don't like Linux having cyl 0 :) Nice to know. I'd missed that in the help files. Still, safer to let CP and z/OS duke that one out, and let Linux get on with doing useful stuff.
Re: initializing z/Linux disks
Terry -- You have to init the DASD when using minidisks- using CPFMTXA to put a label on -- and you also want to format cylinder 0 to ensure it's seen as a CP volume. When the zLinux guest does an 'init' -- it is doing a format of the whole disk - not just an 'init' and label. You can preformat minidisks in Linux format if you want to avoid the time Linux takes to do it at kickstart... if that's what you're looking for. I would not recommend using DEDICATE -- why would you do that rather than use minidisks? What you need to be aware of is that if you DEDICATE -- Linux will label the DASD -- and that's what you'll see at the z/VM level -- and are likely to see duplicate labels. (to things like 0x0200 and 0x0300, etc...).Also - if you dedicate - you can't use things like DIRMAINT do manage your dasd and keep things in pools, etc -- you have to manage it all yourself. I'm not sure how DFDSS reacts to Linux formatted volumes, offhand .. it does fine with CPVOL volumes and minidisks. Anyway - I'm not a fan of dedicate's - as you can tell ;-) Scott Rohling On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Hi I have a question. What I have been doing up to this point for a new z/Linux guest build is, not necessarily in this order and does not necessarily include all steps but, Crave out the DASD for the z/Linux guest Init the DASD using CPFMTXA putting a label on the disk Setting up the Directory entry for the new guest, which includes specifying the MDISK for all of the DASD for the guest. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? If not I assume then I would replace the MDISK statements in the Directory entry with DEDICATE statements for each one of the DISKS. We do not share DASD between guests here so what is defined to the guest belongs to that guest only. Is there anything to be aware of by changing to DEDICATE statements from MDISK statements? My only concern is with the DFDSS backups that I do on the z/OS for the guests. I am not sure if it matters or not to DFDSS whether the pack was initialized via CPFMTXA or z/Linux during the kick start process? *Thank You,* * * *Terry Martin* *Lockheed Martin - Citic* *z/OS and z/VM Performance Tuning and Operating Systems Support* *Office - 443 348-2102* *Cell - 443 632-4191* * * *[image: cid:image001.jpg@01C97FB5.5EAFD6C0]***
Re: initializing z/Linux disks
On Wednesday, 03/24/2010 at 03:22 EDT, David Boyes dbo...@sinenomine.net wrote: On 3/24/10 2:40 PM, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: You can DEDICATE by label rather than by real address. But I still don't like Linux having cyl 0 :) Nice to know. I'd missed that in the help files. Still, safer to let CP and z/OS duke that one out, and let Linux get on with doing useful stuff. When giving guests access to real cyl 0, I suggest: 1. If using a full-pack mindisk, use the DEVNO version instead of volser. That way it doesn't matter if the guest changes the label. 2. Use the various xxx_AT_IPL options in SYSTEM CONFIG to control the RDEVs that your system will use for CP-owned and user volumes listed in SYSTEM CONFIG. Once the system is up, have AUTOLOG1 bring any remaining dasd volumes online. The purpose of these actions is to prevent CP from grabbing the wrong volume at IPL. Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
On 3/24/2010 at 03:38 PM, Scott Rohling scott.rohl...@gmail.com wrote: I'm not sure how DFDSS reacts to Linux formatted volumes, offhand .. it does fine with CPVOL volumes and minidisks. It looks like a regular OS volume with no free space on it. That was the whole reason the CDL was invented back in the early 2.4 kernels. Like you, however, I don't normally recommend using DEDICATEd DASD volumes. Mark Post
Re: initializing z/Linux disks
why would you do that rather than use minidisks Just curious, if XRC is wanted, VM doesn't timestamp I/Os, but linux does? If you use dedicates, isn't the data movers happier? like 0x0200 and 0x0300 You can use CDL and specify the volume label; dasdfmt -p -b 4096 -l LNX012 -dcdl -f /dev/dasdd and DFDSS and VM are happy. You may need to redo the CPFMTXA to use it as a volume to contain minidisk, but mount it on zOS, and use DFDSS to backup as a CPVOL. kickstart does not do the -l flag on dasdfmt, or I have not been able to find a way for it to do it, so volsers like 0x0200 and 0x0300 are the outcome. Thanks From: Scott Rohling scott.rohl...@gmail.com To: IBMVM@LISTSERV.UARK.EDU Date: 03/24/2010 02:39 PM Subject: Re: initializing z/Linux disks Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Terry -- You have to init the DASD when using minidisks- using CPFMTXA to put a label on -- and you also want to format cylinder 0 to ensure it's seen as a CP volume. When the zLinux guest does an 'init' -- it is doing a format of the whole disk - not just an 'init' and label. You can preformat minidisks in Linux format if you want to avoid the time Linux takes to do it at kickstart... if that's what you're looking for. I would not recommend using DEDICATE -- why would you do that rather than use minidisks? What you need to be aware of is that if you DEDICATE -- Linux will label the DASD -- and that's what you'll see at the z/VM level -- and are likely to see duplicate labels. (to things like 0x0200 and 0x0300, etc...).Also - if you dedicate - you can't use things like DIRMAINT do manage your dasd and keep things in pools, etc -- you have to manage it all yourself. I'm not sure how DFDSS reacts to Linux formatted volumes, offhand .. it does fine with CPVOL volumes and minidisks. Anyway - I'm not a fan of dedicate's - as you can tell ;-) Scott Rohling On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Hi I have a question. What I have been doing up to this point for a new z/Linux guest build is, not necessarily in this order and does not necessarily include all steps but, Crave out the DASD for the z/Linux guest Init the DASD using CPFMTXA putting a label on the disk Setting up the Directory entry for the new guest, which includes specifying the MDISK for all of the DASD for the guest. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? If not I assume then I would replace the MDISK statements in the Directory entry with DEDICATE statements for each one of the DISKS. We do not share DASD between guests here so what is defined to the guest belongs to that guest only. Is there anything to be aware of by changing to DEDICATE statements from MDISK statements? My only concern is with the DFDSS backups that I do on the z/OS for the guests. I am not sure if it matters or not to DFDSS whether the pack was initialized via CPFMTXA or z/Linux during the kick start process? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 - Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: initializing z/Linux disks
z/OS duke that one out, and let Linux get on with doing useful stuff. When giving guests access to real cyl 0, I suggest: 1. If using a full-pack mindisk, use the DEVNO version instead of volser. That way it doesn't matter if the guest changes the label. Unless you use mirroring and move to the secondaries and get a new address. GDPS doc says use volser. :) Marcy
Re: initializing z/Linux disks
why would you do that rather than use minidisks Just curious, if XRC is wanted, VM doesn't timestamp I/Os, but linux does? If you use dedicates, isn't the data movers happier? only a wee bit happier for the cyl 0 VM writes on. Linux will still timestamp on minidisks. and if you need VM timestamped, call IBM. marcy
Re: Capping info
No CP command as far as I know, STSI: I don't think so. But, performance monitors report this in their LPAR reports. If you've got Perfkit: PIPE VMC PERFSVM |. Hence you could use a PIPE to listen to the monitor records and analyse it yourself. You must be prepared to unravel raw monitor records 2010/3/24 Alain Benveniste a.benveni...@free.fr Is there a way to get the info if my VM lpar is capped or not and what is weight ? Could be great to see these info with the indicate cmd...? This info is needed for us to avoid to run licenced products with more power than we pay for using them...not to be lawfull... Alain Benveniste -- Kris Buelens, IBM Belgium, VM customer support
Re: Capping info
the perfkit FCX126 LPAR screen shows LPAR weight. one way to display it is run this to see menu choice 8 - the FCX126 LPAR screen PERFKIT FCONAPPC FCXRES00 8 From: The IBM z/VM Operating System [ib...@listserv.uark.edu] On Behalf Of Alain Benveniste [a.benveni...@free.fr] Sent: Wednesday, March 24, 2010 4:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Capping info Is there a way to get the info if my VM lpar is capped or not and what is weight ? Could be great to see these info with the indicate cmd...? This info is needed for us to avoid to run licenced products with more power than we pay for using them...not to be lawfull... Alain Benveniste 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: Capping info
On Wednesday, 03/24/2010 at 04:55 EDT, Alain Benveniste a.benveni...@free.fr wrote: Is there a way to get the info if my VM lpar is capped or not and what is weight ? Could be great to see these info with the indicate cmd...? This info is needed for us to avoid to run licenced products with more power than we pay for using them...not to be lawfull... Since you're talking about caps and pricing, you must be talking about standard engines, not IFLs. In that case, look at DIAGNOSE 0x2E0. As mentioned in the Prog. Services book, you'll be wanting the IRAQVS macro in the HCPGPI maclib. Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
On Wednesday, 03/24/2010 at 04:51 EDT, Ward, Mike S mw...@ssfcu.org wrote: I thought there was overhead in specifying it as a minidisk rather than a dedicated full disk. The overhead would be in the translation of the I/O addresses and such. You know like linux reading cyl 0 when it's really cyl 1 etc Is there still that type of overhead in VM? Back in the native-mode days, there would be I/O assist for dedicated devices that wouldn't be provided to a full-pack minidisk. In an LPAR, the I/O assist isn't available to CP (LPAR is using it), so CP is already handling the guest I/O. Eric or Steve will have the definitive answer, but I speculate that full-pack minidisks and dedicated dasd generally take the same shortcuts for geometry issues. E.g. no need to modify cylinder numbers. I'm guessing one of big differences, however, is the lack of minidisk cache (MDC) for dedicated devices. In some cases that's a help and others a hinderance. If it hurts, we give you the ability to turn off MDC for a minidisk. Alan Altmark z/VM Development IBM Endicott
Re: initializing z/Linux disks
Thanks all for the information. As far as DEDICATING the volume is concerned I thought that the I/O overhead was cheaper that is why I was wondering about this. I am fine with doing the way I have always done it (MDISK) but someone had suggested this to me and I wanted to find out more about the pros and cons. In terms of the INIT I just thought since z/Linux was doing the Initialization at Kick Start time in my case that it did not make sense to init the DASD twice. I did not think about Cyl0. Thanks again for all the help as always it has been enlightening! Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Wednesday, March 24, 2010 3:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: initializing z/Linux disks Terry -- You have to init the DASD when using minidisks- using CPFMTXA to put a label on -- and you also want to format cylinder 0 to ensure it's seen as a CP volume. When the zLinux guest does an 'init' -- it is doing a format of the whole disk - not just an 'init' and label. You can preformat minidisks in Linux format if you want to avoid the time Linux takes to do it at kickstart... if that's what you're looking for. I would not recommend using DEDICATE -- why would you do that rather than use minidisks? What you need to be aware of is that if you DEDICATE -- Linux will label the DASD -- and that's what you'll see at the z/VM level -- and are likely to see duplicate labels. (to things like 0x0200 and 0x0300, etc...).Also - if you dedicate - you can't use things like DIRMAINT do manage your dasd and keep things in pools, etc -- you have to manage it all yourself. I'm not sure how DFDSS reacts to Linux formatted volumes, offhand .. it does fine with CPVOL volumes and minidisks. Anyway - I'm not a fan of dedicate's - as you can tell ;-) Scott Rohling On Wed, Mar 24, 2010 at 11:53 AM, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Error! Filename not specified. Hi I have a question. What I have been doing up to this point for a new z/Linux guest build is, not necessarily in this order and does not necessarily include all steps but, Crave out the DASD for the z/Linux guest Init the DASD using CPFMTXA putting a label on the disk Setting up the Directory entry for the new guest, which includes specifying the MDISK for all of the DASD for the guest. We back up our z/Linux guests on the z/OS side with DFDSS. My question is since when we Kick Start the new z/Linux guest and it initializes the DASD during this process is there any compelling reason for me to initialize the DASD up front before the guest is Kick Started for the first time basically doing a double INIT? If not I assume then I would replace the MDISK statements in the Directory entry with DEDICATE statements for each one of the DISKS. We do not share DASD between guests here so what is defined to the guest belongs to that guest only. Is there anything to be aware of by changing to DEDICATE statements from MDISK statements? My only concern is with the DFDSS backups that I do on the z/OS for the guests. I am not sure if it matters or not to DFDSS whether the pack was initialized via CPFMTXA or z/Linux during the kick start process? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 Error! Filename not specified.
Re: z/VM/ Linux Systems Programmer Opportunity with Compuware Corporation top Mainframe z/VM Systems Programmer
Should everyone be precluded from seeing help wanted ads here because of some (a few, I hope) companies' (silly, IMHO) policies? Do those companies also forbid their employees from reading newspaper classified sections or visiting help wanted sites on their home computers? Do the companies assign minders to monitor all lists subscribed by employees, or analyze all incoming email for forbidden thoughts and topics? Do they really think policies like that HELP employee retention? More people likely see these notices here than would on Velocity's Web site, so this seems a better place for them. A better solution seems to be for people working at companies which think they can censor information their employees see to read the list on home computers. I don't have a dog in this fight; I'm neither hiring nor looking to be hired, but companies attempting to impose discussion list restrictions like this seem ... foolish, and that's being kind. Mike Walter said An additional note: some companies forbid their employees from subscribing to listserves which display Help Wanted ads. In the current economic environment (actually, at ANY time) it would be a shame for any subscribers to be forced to unsubscribe from this list. -- Gabriel Goldberg, Computers and Publishing, Inc. (703) 204-0433 3401 Silver Maple Place, Falls Church, VA 22042g...@gabegold.com LinkedIn: http://www.linkedin.com/in/gabegold
Re: z/VM/ Linux Systems Programmer Opportunity with Compuware Corporation top Mainframe z/VM Systems Programmer
On Wed, Mar 24, 2010 at 11:19 PM, Gabe Goldberg g...@gabegold.com wrote: Should everyone be precluded from seeing help wanted ads here because of some (a few, I hope) companies' (silly, IMHO) policies? Do those companies also forbid their employees from reading newspaper classified sections or visiting help wanted sites on their home computers? Do the companies assign minders to monitor all lists subscribed by employees, or analyze all incoming email for forbidden thoughts and topics? Do they really think policies like that HELP employee retention? More people likely see these notices here than would on Velocity's Web site, so this seems a better place for them. A better solution seems to be for people working at companies which think they can censor information their employees see to read the list on home computers. I don't have a dog in this fight; I'm neither hiring nor looking to be hired, but companies attempting to impose discussion list restrictions like this seem ... foolish, and that's being kind. Sure, but pointing out that it's foolish is as, um, pointless as pointing out that email disclaimers saying If you aren't the intended recipient, please claw your eyes out and kill yourself are pointless (he pointed out pointedly). If nothing else, Mike's warning makes it clear to any PHBs reading this that this sort of thing is not the norm and that they shouldn't suddenly forbid reading a useful technical list because of a single posting.
Moderator comment Re: [IBMVM] z/VM/ Linux Systems Programmer Opportunity ...
It's not just an issue of narrow-minded corporate management on theoretical remote systems. Please bear in mind that we are hosted, for free, by a state-run, tax-supported institution. For better or ill, UARK has a long-standing policy about not using their infrastructure for that type of traffic. It happens rarely enough that the occasional trivial, though potentially conspicuous breach of protocol hasn't caused us any grief. I am, understandably, motivated to ensure that it does not become a point of pain for our gracious hosts. I don't pretend to understand why the rules are there, nor do I care to engage in debate on the topic. It's UARK's hardware, their network, and their rules. Silly-seeming policies at third-party organizations are my favorite kind of problem: Problems for other people. Admittedly, this isn't necessarily clear at present to drive-by subscribers like the individual who posted the announcement. It's not feasible to put the list on full moderation. I don't have the bandwidth available to eyeball-inspect every single post and bounce the rare exceptional case back to the sender. However, here's what I *can* do: Another list hosted by U. Arkansas (SAG-L -- Software AG products discussion) has a long-standing FAQ which includes policy statements regarding this sort of posting. I'm acquainted with the list owner, and will obtain his permission to grab a copy of that FAQ as a starting template -- and then I'll file off the serial numbers, strip out the stuff that's specific to ADABAS / NATURAL / etc, and adapt the rest for use on IBMVM. While I can't force anybody to actually *read* it, LISTSERV provides a way to deliver an FAQ to all new subscribers. Interested parties are welcome to send me suggestions for VM-specific FAQ items - but please bear in mind that much of the heavy lifting on this matter is already addressed via http://www.vm.ibm.com, and it seems pointless to duplicate the resources already available there. -dan.
