Re: z/VM 5.4 RSU 1002
A 3 digit CMS service level existed before PUT and/or RSU tapes existed. With the arrival of PUT/RSU, and their 4 digit number, CP was enhanced with a Q CPLEVEL command, but CMS remained compatible with its past. 2010/9/29 Alan Ackerman alan.acker...@bankofamerica.com HELP says: Responses The format of the response is: CMS Level nn, Service Level nnn I guess the 'nnn' must mean it is 3 digits. To my memory, it has always been 3 digits. Alan Ackerman On Tue, 28 Sep 2010 11:21:06 -0500, Frank M. Ramaekers framaek...@ailife.com wrote: q cplevel z/VM Version 5 Release 4.0, service level 1002 (64-bit) Generated at 09/16/10 07:14:22 CDT IPL at 09/28/10 07:45:54 CDT Ready; T=0.01/0.01 11:19:58 q cmslevel CMS Level 24, Service Level 002 Ready; T=0.01/0.01 11:20:02 Is that right? CMS Service level is 002 (instead of 1002)? Frank M. Ramaekers Jr. Systems Programmer MCP, MCP+I, MCSE RHCE American Income Life Insurance Co. Phone: (254)761-6649 1200 Wooded Acres Dr. Fax: (254)741-5777 Waco, Texas 76701 -- Kris Buelens, IBM Belgium, VM customer support
Re: Is there a JAVA implementation for CMS?
In the Redbook I mentioned, I wrote a chapter to compare NetRexx with Rexx. And, as opposed to OO-Rexx, NetRexx is not upward compatible with REXX. I didn't visit NetRexx recently, but as NetRexx is in Java, NetRexx runs on all Java platforms (this too should appear in this redbook) 2010/9/29 Alan Ackerman alan.acker...@bankofamerica.com Unfortunately, if you find the old CMS JAVA, I'm sure it will NOT use IEEE floating point. A decent CMS Java Virtual Machine with a JIT would perhaps run very well. But who is going to write it? It's not going to come from Sun/Oracle. Sun doesn't even provide one for the Macintosh -- Apple does. There are a heck of a lot more Macs than copies of CMS. I don't know whether CMS JAVA truly supported multi-threading, though, while Java does. Could lead to problems porting Java to CMS. Does anyone know? I gather that with NetRexx, Mike Cowlishaw tried to fix the mistakes in REXX. At least he replaced do/end with loop/end. (For the looping cases of 'do'.) In other ways he significantly enhanced REXX. I don't think NetRexx is upwardly compatible with REXX, though. I suspect there are far more programmers literate in Java than in REXX. Perhaps not among mainframers, though. Does anyone know how much NetRexx is used in z/OS? My employer's standard language is Java. Another strike against CMS. Alan Ackerman On Tue, 28 Sep 2010 06:38:35 -0700, Barton Robinson bar...@vm1.velocity-software.com wrote: Right, so even better chance that java on cms would be more than acceptable. Too bad there's no business case. John P. Hartmann wrote: Barton, you overlook the lack of IEEE floating point in the hardware in those days. On 28 September 2010 04:08, Barton Robinson bar...@vm1.velocity-software.com wrote: === == -- Kris Buelens, IBM Belgium, VM customer support
Re: Applying Maintenance - Best Practice
On Wed, Sep 29, 2010 at 11:27 AM, Kris Buelens kris.buel...@gmail.com wrote: And, if the 2'nd level system has enough free spool space, you could let this 2'nd level run without page packs: CP will page in the spool when paging is full (or not-existing). **NOT** recommended for a production system, or a 2nd level system that you use every day. Or with a VDISK taken from 1st level. My PROFILE EXEC runs ICKDSF against it to format allocate one before IPL. | Rob
Re: Applying Maintenance - Best Practice
As always, Alan, ty for the good advice. I have renamed with CPFMTXA the 2nd Level disks to 54O(Oh)RES, 54O(Oh)W01, adn 54O(Oh)W02 and will copy the 2 page and 2 spool disks just for simplicity, neatness counts. Alan Altmark alan_altm...@us.ibm.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 09/28/2010 11:59 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice On Tuesday, 09/28/2010 at 04:35 EDT, George Henke/NYLIC george_he...@newyorklife.com wrote: Can I bring up z/VM Level 2 wiith the same cloned volser's, directory, and CF parm disks as z/VM Level 1 as long as I point to the cloned 540RES and FORCE start when I IPL? I have DDRed my 540RES, 540W01, 540W02, Level 1 disks to separate disks and they now have the same volsers. Do I need to also DDR the PAG and SPL disks or can I just FORCE start with empty disks. You need to copy the disks or CPFMTXA them. The directory and CF parm disks came over with 540RES. Since the names have not changed Is their referential integrity still intact? Unless you follow my previously posted advice about using OFFLINE_AT_IPL, duplicate volids create the potential for bad things to happen. I suggest you change the volsers (which means changing SYSTEM CONFIG and USER DIRECT). Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
Re: Applying Maintenance - Best Practice
That's then to confuse everyone 0 and O, who can tell the difference unless having a very good font, and even then. If you change, change it better, not more work Why not 54TRES, 54TW01 etc 2010/9/29 George Henke/NYLIC george_he...@newyorklife.com As always, Alan, ty for the good advice. I have renamed with CPFMTXA the 2nd Level disks to 54O(Oh)RES, 54O(Oh)W01, adn 54O(Oh)W02 and will copy the 2 page and 2 spool disks just for simplicity, neatness counts. *Alan Altmark alan_altm...@us.ibm.com* Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 09/28/2010 11:59 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice On Tuesday, 09/28/2010 at 04:35 EDT, George Henke/NYLIC george_he...@newyorklife.com wrote: Can I bring up z/VM Level 2 wiith the same cloned volser's, directory, and CF parm disks as z/VM Level 1 as long as I point to the cloned 540RES and FORCE start when I IPL? I have DDRed my 540RES, 540W01, 540W02, Level 1 disks to separate disks and they now have the same volsers. Do I need to also DDR the PAG and SPL disks or can I just FORCE start with empty disks. You need to copy the disks or CPFMTXA them. The directory and CF parm disks came over with 540RES. Since the names have not changed Is their referential integrity still intact? Unless you follow my previously posted advice about using OFFLINE_AT_IPL, duplicate volids create the potential for bad things to happen. I suggest you change the volsers (which means changing SYSTEM CONFIG and USER DIRECT). Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: Is there a JAVA implementation for CMS?
But who is going to write it? It's not going to come from Sun/Oracle. Sun doesn't even provide one for the M acintosh -- Apple does. There are a heck of a lot more Macs than copies of CMS. If you want it enough to contribute to the development, let's talk offlist. We've done Java ports enough times now that we should be able to do it fairly efficiently. I don't know whether CMS JAVA truly supported multi-threading, though, wh ile Java does. Could lead to problems porting Java to CMS. Does anyone know? I fired up a old 4.4 system that has it installed. No references in the help about it, but I didn't try running any code to verify it. I suspect it did something with CMS MT to fake it since IBM wouldn't have been able to call it Java if it didn't pass the Java language tests, which have multithreading in there.
Re: Applying Maintenance - Best Practice
On Wed, Sep 29, 2010 at 4:11 PM, Kris Buelens kris.buel...@gmail.com wrote: That's then to confuse everyone 0 and O, who can tell the difference unless having a very good font, and even then. If you change, change it better, not more work Why not 54TRES, 54TW01 etc I guess my background of multi-image installation shows... we never ran production systems with the IBM sample volume names, but had the owning system name in the volser (independent of the release installed). Less risky when someone forgets to change the labels (or worse: picks the wrong volume to change the label). The kind of surprises that don't show until the weekend IPL... Like our RACF-person doing major changes and then remembered his dentist appointment on Friday afternoon (which ran late, so he did not go back to the office to finish his updates...). | Rob
Re: Is there a JAVA implementation for CMS?
-Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Wednesday, September 29, 2010 9:30 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Is there a JAVA implementation for CMS? But who is going to write it? It's not going to come from Sun/Oracle. Sun doesn't even provide one for the M acintosh -- Apple does. There are a heck of a lot more Macs than copies of CMS. If you want it enough to contribute to the development, let's talk offlist. We've done Java ports enough times now that we should be able to do it fairly efficiently. I don't know whether CMS JAVA truly supported multi-threading, though, wh ile Java does. Could lead to problems porting Java to CMS. Does anyone know? I fired up a old 4.4 system that has it installed. No references in the help about it, but I didn't try running any code to verify it. I suspect it did something with CMS MT to fake it since IBM wouldn't have been able to call it Java if it didn't pass the Java language tests, which have multithreading in there. Would this be true JAVA? I.e. from licensed source? Or a port of OpenJDK? Which I take it is somewhat different. Or am I, once again, out of my mind (please leave a voice message at the tone)? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Re: Applying Maintenance - Best Practice
ty all, I will change the volser's to 54XRES, 54XW01, 54XW02. It is not as poetic but neither is a disaster. Kris Buelens kris.buel...@gmail.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 09/29/2010 10:11 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice That's then to confuse everyone 0 and O, who can tell the difference unless having a very good font, and even then. If you change, change it better, not more work Why not 54TRES, 54TW01 etc 2010/9/29 George Henke/NYLIC george_he...@newyorklife.com As always, Alan, ty for the good advice. I have renamed with CPFMTXA the 2nd Level disks to 54O(Oh)RES, 54O(Oh)W01, adn 54O(Oh)W02 and will copy the 2 page and 2 spool disks just for simplicity, neatness counts. Alan Altmark alan_altm...@us.ibm.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 09/28/2010 11:59 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice On Tuesday, 09/28/2010 at 04:35 EDT, George Henke/NYLIC george_he...@newyorklife.com wrote: Can I bring up z/VM Level 2 wiith the same cloned volser's, directory, and CF parm disks as z/VM Level 1 as long as I point to the cloned 540RES and FORCE start when I IPL? I have DDRed my 540RES, 540W01, 540W02, Level 1 disks to separate disks and they now have the same volsers. Do I need to also DDR the PAG and SPL disks or can I just FORCE start with empty disks. You need to copy the disks or CPFMTXA them. The directory and CF parm disks came over with 540RES. Since the names have not changed Is their referential integrity still intact? Unless you follow my previously posted advice about using OFFLINE_AT_IPL, duplicate volids create the potential for bad things to happen. I suggest you change the volsers (which means changing SYSTEM CONFIG and USER DIRECT). Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: Question about DFSMS/VM - RMS
Hello, Thanks very much from your help. I'm starting my work with this now, and of course, have some questions. How you can see, this list, is very useful, and also help a lot. Let me learn few more about this, and later let you know. Thanks again, and Best Regards, Sergio Date: Tue, 28 Sep 2010 21:04:16 -0500 From: t...@us.ibm.com Subject: Re: Question about DFSMS/VM - RMS To: IBMVM@LISTSERV.UARK.EDU On Tue, 28 Sep 2010 22:58:07 +0300, Sergio Lima sergiovm...@hotmail.com= wrote: We already spoke here with IBM for see if have the Tape Manager product,= because not sure, and this is new for us. I am the IBM product manager for Tape Manager for z/VM. Let me know if y= ou have any questions about it, including how it can work with DFSMS/VM RMS = to manage tape volumes, and tape mounts in your tape library. Tracy Dean, IBM
Re: Is there a JAVA implementation for CMS?
Would this be true JAVA? I.e. from licensed source? Or a port of OpenJDK? Which I take it is somewhat different. Or am I, once again, out of my mind (please leave a voice message at the tone)? If you want the licensed source, then the price obviously goes up. The technical problem is pretty much identical.
Re: Is there a JAVA implementation for CMS?
On Wednesday, 09/29/2010 at 10:39 EDT, McKown, John john.mck...@healthmarkets.com wrote: Would this be true JAVA? I.e. from licensed source? Or a port of OpenJDK? Which I take it is somewhat different. Or am I, once again, out of my mind (please leave a voice message at the tone)? The CMS version was a port of (IIRC) the IBM JDK at the 1.4 level. It existed within the framework of the CMS support for POSIX, which is layered upon CMS' native multitasking support. In a former life, ca. 1998, I had the privilege of doing system-level testing of it, primarily driving it using multithreaded NetRexx apps. In addition to the (at the time) relatively poor performance, it also suffered from some (apparent) fundamental design issues in CMS multitasking which caused multithreaded JVMs to mysteriously hang. Those issues were never solved and it became clear that, esp. with the appearance of Linux on the mainframe, that CMS was not going to be a strategic application development platform. XEDIT and COMPILE were no longer viable app development tools and the machines were too slow for a good GUI. Not to mention that sw investment in MVS gave middleware an available on the mainframe checkbox. Develop for z/OS *and* z/VM? I think not. And so the business requirement for Java on CMS disappeared, and the whole thing was scrapped. The lack of servlet support from the vendors of then-extant CMS-based webservers didn't help. The rise and fall of Java on CMS happened with incredible speed. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott
z/VSE dispatch of multi-CPU under VM
This was stated on the z/VSE LISTSERV, can someone confirm (or deny) it? Here is a quick tip. When running under VM with multiple VSE's it is usually NOT a good idea to define multiple CPU's to VSE and expect turbo dispacher to handle them. Why? Because z/VM will not dispach a VSE unless it has ALL requested CPU available. Often VSE could be running but is waiting for z/VM to find a secind free CPU. Frank M. Ramaekers Jr. Systems Programmer MCP, MCP+I, MCSE RHCE American Income Life Insurance Co. Phone: (254)761-6649 1200 Wooded Acres Dr. Fax: (254)741-5777 Waco, Texas 76701 _ This message contains information which is privileged and confidential and 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 strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: z/VSE dispatch of multi-CPU under VM
On Wed, Sep 29, 2010 at 7:30 PM, Frank M. Ramaekers framaek...@ailife.com wrote: This was stated on the z/VSE LISTSERV, can someone confirm (or deny) it? Here is a quick tip. When running under VM with multiple VSE's it is usually NOT a good idea to define multiple CPU's to VSE and expect turbo dispacher to handle them. Why? Because z/VM will not dispach a VSE unless it has ALL requested CPU available. Often VSE could be running but is waiting for z/VM to find a secind free CPU. As stated here, we can simply conclude and demonstrate that this claim is not true. The more interesting part is to understand which statement *is* true and how that led to this rumor ;-) In general, it's a bad idea to have more virtual CPUs than you can get from z/VM when you have workload to use them. The total number of logical CPUs in z/VM is an upper bound for what you can get, but when you run 100 Linux guests on 5 IFLs, it's unlikely you find a guest have all its 5 virtual CPUs dispatched at the same time. One of the challenges with virtualized multi-processor guests is about locking. When the virtual CPU holding the lock is not dispatched, the other virtual CPU ends up spinning waiting for the other virtual CPU to free the lock (which does not happen because you're burning a CPU spinning). To avoid that, the guest OS uses a voluntary time slice end DIAG44 to give up running and expect the other virtual CPU to get time to free the lock. Linux is even using a later version of that to tell z/VM which virtual CPU should be put in front of the queue (with more than 2 virtual CPUs other is a bit vague). I don't know how much locking is done in VSE. Another aspect is about SMP. Linux is symmetrical and does not care which virtual CPU runs what. Some Operating Systems deal with serialization by master only tasks. z/VM used to have a lot of that in ancient past, and got rid of almost all now. When the guest OS needs some work to run on one particular CPU (the master) but dispatches work on both virtual CPUs, you can't pick which one is dispatched first by z/VM. The question would be whether VSE has much master only work. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: z/VSE dispatch of multi-CPU under VM
I know you are a smart guy Rob, but I beg to differ with you on this point. At least where VSE is concerned. I have done this and can reproduce results at will (that is if I stilled worked there). Environment: 4 CPU z890. 8 gig real memory. z/VM 5.4 7 production VSE's VSE 2.7 z/VSE 3.1 With VSE's using only 1 CPU (non-dedicated) I carfully selected a one hour job mix. Giving VSE's 4 CPU's (non-dedicated) the same job mix ran close to 1hr 20min... This is wall clock time, which in final analysis is the only one that counts. On Wed, Sep 29, 2010 at 11:16 AM, Rob van der Heij rvdh...@velocitysoftware.com wrote: On Wed, Sep 29, 2010 at 7:30 PM, Frank M. Ramaekers framaek...@ailife.com wrote: This was stated on the z/VSE LISTSERV, can someone confirm (or deny) it? Here is a quick tip. When running under VM with multiple VSE's it is usually NOT a good idea to define multiple CPU's to VSE and expect turbo dispacher to handle them. Why? Because z/VM will not dispach a VSE unless it has ALL requested CPU available. Often VSE could be running but is waiting for z/VM to find a secind free CPU. As stated here, we can simply conclude and demonstrate that this claim is not true. The more interesting part is to understand which statement *is* true and how that led to this rumor ;-) In general, it's a bad idea to have more virtual CPUs than you can get from z/VM when you have workload to use them. The total number of logical CPUs in z/VM is an upper bound for what you can get, but when you run 100 Linux guests on 5 IFLs, it's unlikely you find a guest have all its 5 virtual CPUs dispatched at the same time. One of the challenges with virtualized multi-processor guests is about locking. When the virtual CPU holding the lock is not dispatched, the other virtual CPU ends up spinning waiting for the other virtual CPU to free the lock (which does not happen because you're burning a CPU spinning). To avoid that, the guest OS uses a voluntary time slice end DIAG44 to give up running and expect the other virtual CPU to get time to free the lock. Linux is even using a later version of that to tell z/VM which virtual CPU should be put in front of the queue (with more than 2 virtual CPUs other is a bit vague). I don't know how much locking is done in VSE. Another aspect is about SMP. Linux is symmetrical and does not care which virtual CPU runs what. Some Operating Systems deal with serialization by master only tasks. z/VM used to have a lot of that in ancient past, and got rid of almost all now. When the guest OS needs some work to run on one particular CPU (the master) but dispatches work on both virtual CPUs, you can't pick which one is dispatched first by z/VM. The question would be whether VSE has much master only work. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: z/VSE dispatch of multi-CPU under VM
VSE's turbo dispatcher is known not to be the best in avoiding MP overhead, the VSE lab published tables with its MP overhead. So, never draw conclusions from VSE tests in MP situations to apply them to other environments. And, I don't see where your measurement would disagree with what Rob often spreads: don't give more engines than required for the job. In fact, your test proved this very well. Your VSE didn't need it, and with 4 CP's only additional overhead is introduced. 2010/9/29 Tom Huegel tehue...@gmail.com I know you are a smart guy Rob, but I beg to differ with you on this point. At least where VSE is concerned. I have done this and can reproduce results at will (that is if I stilled worked there). Environment: 4 CPU z890. 8 gig real memory. z/VM 5.4 7 production VSE's VSE 2.7 z/VSE 3.1 With VSE's using only 1 CPU (non-dedicated) I carfully selected a one hour job mix. Giving VSE's 4 CPU's (non-dedicated) the same job mix ran close to 1hr 20min... This is wall clock time, which in final analysis is the only one that counts. On Wed, Sep 29, 2010 at 11:16 AM, Rob van der Heij rvdh...@velocitysoftware.com wrote: On Wed, Sep 29, 2010 at 7:30 PM, Frank M. Ramaekers framaek...@ailife.com wrote: This was stated on the z/VSE LISTSERV, can someone confirm (or deny) it? Here is a quick tip. When running under VM with multiple VSE's it is usually NOT a good idea to define multiple CPU's to VSE and expect turbo dispacher to handle them. Why? Because z/VM will not dispach a VSE unless it has ALL requested CPU available. Often VSE could be running but is waiting for z/VM to find a secind free CPU. As stated here, we can simply conclude and demonstrate that this claim is not true. The more interesting part is to understand which statement *is* true and how that led to this rumor ;-) In general, it's a bad idea to have more virtual CPUs than you can get from z/VM when you have workload to use them. The total number of logical CPUs in z/VM is an upper bound for what you can get, but when you run 100 Linux guests on 5 IFLs, it's unlikely you find a guest have all its 5 virtual CPUs dispatched at the same time. One of the challenges with virtualized multi-processor guests is about locking. When the virtual CPU holding the lock is not dispatched, the other virtual CPU ends up spinning waiting for the other virtual CPU to free the lock (which does not happen because you're burning a CPU spinning). To avoid that, the guest OS uses a voluntary time slice end DIAG44 to give up running and expect the other virtual CPU to get time to free the lock. Linux is even using a later version of that to tell z/VM which virtual CPU should be put in front of the queue (with more than 2 virtual CPUs other is a bit vague). I don't know how much locking is done in VSE. Another aspect is about SMP. Linux is symmetrical and does not care which virtual CPU runs what. Some Operating Systems deal with serialization by master only tasks. z/VM used to have a lot of that in ancient past, and got rid of almost all now. When the guest OS needs some work to run on one particular CPU (the master) but dispatches work on both virtual CPUs, you can't pick which one is dispatched first by z/VM. The question would be whether VSE has much master only work. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/ -- Kris Buelens, IBM Belgium, VM customer support
Re: z/VSE dispatch of multi-CPU under VM
On Wed, Sep 29, 2010 at 8:54 PM, Tom Huegel tehue...@gmail.com wrote: With VSE's using only 1 CPU (non-dedicated) I carfully selected a one hour job mix. Giving VSE's 4 CPU's (non-dedicated) the same job mix ran close to 1hr 20min... This is wall clock time, which in final analysis is the only one that counts. If you think we disagree, then I was obviously not clear enough. With 7 VSE guests, the amount of resources each could get at any time will be (far) less than 400% (all 4 CPUs). If more than 4 of them working, each gets even less than one CPU worth of cycles. So one virtual CPU will do. The drawback is that with just one virtual CPU you can not get more than 100% of a CPU, not even when all the others are idle. That may or may not be a true concern. While you're right that wall clock time is what counts, performance measurements help you understand the difference between two experiments and allow you to improve performance other than through trial and error. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Hillgang meeting - October 13
The z/VM and Linux on z user group ³Hillgang² will meet on October 13 in Herndon Virginia at the CA offices. The agenda has been updated and may be found at http://www.vm.ibm.com/events/hill1013.pdf The PDF also contains logistical information regarding registering and directions. Neale Ferguson
Re: z/VSE dispatch of multi-CPU under VM
Also... you haven't mentioned whether you adjusted the share value when you added virtual cpus to your VSE guest. Remember that each v-cpu will get only 1/n of the userid's share, which may place them at a disadvantage if competing with the virtual cpus of your other guests. So if I'm running most guests with one v-cpu at the default share of relative 100, then I'd give a 4-cpu guest a share of 400 (to put all v-cpus on an equal footing). -- Mike Harding z/VM System Support mhard...@us.ibm.com mike.b.hard...@kp.org mikehard...@mindless.com (925) 926-3179 (w) (925) 323-2070 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 09/29/2010 02:52:15 PM: From: Rob van der Heij rvdh...@velocitysoftware.com To: IBMVM@LISTSERV.UARK.EDU Date: 09/29/2010 02:52 PM Subject: Re: z/VSE dispatch of multi-CPU under VM Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU On Wed, Sep 29, 2010 at 8:54 PM, Tom Huegel tehue...@gmail.com wrote: With VSE's using only 1 CPU (non-dedicated) I carfully selected a one hour job mix. Giving VSE's 4 CPU's (non-dedicated) the same job mix ran close to 1hr 20min... This is wall clock time, which in final analysis is the only one that counts. If you think we disagree, then I was obviously not clear enough. With 7 VSE guests, the amount of resources each could get at any time will be (far) less than 400% (all 4 CPUs). If more than 4 of them working, each gets even less than one CPU worth of cycles. So one virtual CPU will do. The drawback is that with just one virtual CPU you can not get more than 100% of a CPU, not even when all the others are idle. That may or may not be a true concern. While you're right that wall clock time is what counts, performance measurements help you understand the difference between two experiments and allow you to improve performance other than through trial and error. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Mixed page volume sizes
On of our z/VM 5.4.0 systems is about to grow to 140 GB of storage. Given our target overcommit ratio of 3:1, and IBM's advice to keep paging space no more than 50% full, this should just about fit onto 240 or 248 3390-3 sized volumes. My question is what will happen the next time we add storage. Clearly, we'll have to start using 3390-9 sized volumes for paging. Would we be better off converting only enough volumes to satisfy the space requirement, which would maximize the number of devices, or should we convert all volumes to 3390-9 to keep them the same size? My concern is that if we mix sizes, CP will try to allocate the same amount of space on each volume, and the 3390-3's will get more than half full. On the other hand, maximizing the number of devices maximizes the number of concurrent I/O's. Our Storage people aren't going to give me 240 3390-9's if I don't need them, so if I add another 32 GB of storage, my choice would be something like 212 3390-3's and 28 3390-9's, or 100 3390-9's. Which would be a better choice? Dennis Decision is not a verb.
Re: z/VSE dispatch of multi-CPU under VM
IBM has said many, many times to never, never use more than 3 CPU's with VSE, and even 3 is be bad with most work loads. This is due to the overhead of the Turbo-Dispatcher. With 4 you were spinning the dispatcher more than servicing the jobs. Try your job with just 2 CPUs. Tony Thigpen -Original Message - From: Tom Huegel Sent: 09/29/2010 02:54 PM I know you are a smart guy Rob, but I beg to differ with you on this point. At least where VSE is concerned. I have done this and can reproduce results at will (that is if I stilled worked there). Environment: 4 CPU z890. 8 gig real memory. z/VM 5.4 7 production VSE's VSE 2.7 z/VSE 3.1 With VSE's using only 1 CPU (non-dedicated) I carfully selected a one hour job mix. Giving VSE's 4 CPU's (non-dedicated) the same job mix ran close to 1hr 20min... This is wall clock time, which in final analysis is the only one that counts. On Wed, Sep 29, 2010 at 11:16 AM, Rob van der Heij rvdh...@velocitysoftware.com mailto:rvdh...@velocitysoftware.com wrote: On Wed, Sep 29, 2010 at 7:30 PM, Frank M. Ramaekers framaek...@ailife.com mailto:framaek...@ailife.com wrote: This was stated on the z/VSE LISTSERV, can someone confirm (or deny) it? Here is a quick tip. When running under VM with multiple VSE's it is usually NOT a good idea to define multiple CPU's to VSE and expect turbo dispacher to handle them. Why? Because z/VM will not dispach a VSE unless it has ALL requested CPU available. Often VSE could be running but is waiting for z/VM to find a secind free CPU. As stated here, we can simply conclude and demonstrate that this claim is not true. The more interesting part is to understand which statement *is* true and how that led to this rumor ;-) In general, it's a bad idea to have more virtual CPUs than you can get from z/VM when you have workload to use them. The total number of logical CPUs in z/VM is an upper bound for what you can get, but when you run 100 Linux guests on 5 IFLs, it's unlikely you find a guest have all its 5 virtual CPUs dispatched at the same time. One of the challenges with virtualized multi-processor guests is about locking. When the virtual CPU holding the lock is not dispatched, the other virtual CPU ends up spinning waiting for the other virtual CPU to free the lock (which does not happen because you're burning a CPU spinning). To avoid that, the guest OS uses a voluntary time slice end DIAG44 to give up running and expect the other virtual CPU to get time to free the lock. Linux is even using a later version of that to tell z/VM which virtual CPU should be put in front of the queue (with more than 2 virtual CPUs other is a bit vague). I don't know how much locking is done in VSE. Another aspect is about SMP. Linux is symmetrical and does not care which virtual CPU runs what. Some Operating Systems deal with serialization by master only tasks. z/VM used to have a lot of that in ancient past, and got rid of almost all now. When the guest OS needs some work to run on one particular CPU (the master) but dispatches work on both virtual CPUs, you can't pick which one is dispatched first by z/VM. The question would be whether VSE has much master only work. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: z/VSE dispatch of multi-CPU under VM
OK .. maybe Cathrine M. will chime in I can't remember everything we tried, but she takes notes. If I remember correctly nothing worked better than 1 CPU. I set share manually and let VMRMSVM do it dynamically. I think VMRMSVM did a better job overalll than I did manually. On Wed, Sep 29, 2010 at 5:59 PM, Tony Thigpen t...@vse2pdf.com wrote: IBM has said many, many times to never, never use more than 3 CPU's with VSE, and even 3 is be bad with most work loads. This is due to the overhead of the Turbo-Dispatcher. With 4 you were spinning the dispatcher more than servicing the jobs. Try your job with just 2 CPUs. Tony Thigpen -Original Message - From: Tom Huegel Sent: 09/29/2010 02:54 PM I know you are a smart guy Rob, but I beg to differ with you on this point. At least where VSE is concerned. I have done this and can reproduce results at will (that is if I stilled worked there). Environment: 4 CPU z890. 8 gig real memory. z/VM 5.4 7 production VSE's VSE 2.7 z/VSE 3.1 With VSE's using only 1 CPU (non-dedicated) I carfully selected a one hour job mix. Giving VSE's 4 CPU's (non-dedicated) the same job mix ran close to 1hr 20min... This is wall clock time, which in final analysis is the only one that counts. On Wed, Sep 29, 2010 at 11:16 AM, Rob van der Heij rvdh...@velocitysoftware.com mailto:rvdh...@velocitysoftware.com wrote: On Wed, Sep 29, 2010 at 7:30 PM, Frank M. Ramaekers framaek...@ailife.com mailto:framaek...@ailife.com wrote: This was stated on the z/VSE LISTSERV, can someone confirm (or deny) it? Here is a quick tip. When running under VM with multiple VSE's it is usually NOT a good idea to define multiple CPU's to VSE and expect turbo dispacher to handle them. Why? Because z/VM will not dispach a VSE unless it has ALL requested CPU available. Often VSE could be running but is waiting for z/VM to find a secind free CPU. As stated here, we can simply conclude and demonstrate that this claim is not true. The more interesting part is to understand which statement *is* true and how that led to this rumor ;-) In general, it's a bad idea to have more virtual CPUs than you can get from z/VM when you have workload to use them. The total number of logical CPUs in z/VM is an upper bound for what you can get, but when you run 100 Linux guests on 5 IFLs, it's unlikely you find a guest have all its 5 virtual CPUs dispatched at the same time. One of the challenges with virtualized multi-processor guests is about locking. When the virtual CPU holding the lock is not dispatched, the other virtual CPU ends up spinning waiting for the other virtual CPU to free the lock (which does not happen because you're burning a CPU spinning). To avoid that, the guest OS uses a voluntary time slice end DIAG44 to give up running and expect the other virtual CPU to get time to free the lock. Linux is even using a later version of that to tell z/VM which virtual CPU should be put in front of the queue (with more than 2 virtual CPUs other is a bit vague). I don't know how much locking is done in VSE. Another aspect is about SMP. Linux is symmetrical and does not care which virtual CPU runs what. Some Operating Systems deal with serialization by master only tasks. z/VM used to have a lot of that in ancient past, and got rid of almost all now. When the guest OS needs some work to run on one particular CPU (the master) but dispatches work on both virtual CPUs, you can't pick which one is dispatched first by z/VM. The question would be whether VSE has much master only work. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: z/VSE dispatch of multi-CPU under VM
With most workloads, IBM says to get the largest UNI you can. Remember, with z/VSE, only one CPU can be used by a single partition at a time. If you have a heavy CPU usage partition, like CICS, that uses up all the cycles it can, then adding another CPU just adds overhead. The only time I really saw z/VSE use 2 CPUs well was when CICS was using all it could of one CPUand the database server was using the other CPU. But, those were small engines many years ago. Now, I would just throw a large UNI at such a shop. Tony Thigpen -Original Message - From: Tom Huegel Sent: 09/29/2010 07:48 PM OK .. maybe Cathrine M. will chime in I can't remember everything we tried, but she takes notes. If I remember correctly nothing worked better than 1 CPU. I set share manually and let VMRMSVM do it dynamically. I think VMRMSVM did a better job overalll than I did manually. On Wed, Sep 29, 2010 at 5:59 PM, Tony Thigpen t...@vse2pdf.com mailto:t...@vse2pdf.com wrote: IBM has said many, many times to never, never use more than 3 CPU's with VSE, and even 3 is be bad with most work loads. This is due to the overhead of the Turbo-Dispatcher. With 4 you were spinning the dispatcher more than servicing the jobs. Try your job with just 2 CPUs. Tony Thigpen -Original Message - From: Tom Huegel Sent: 09/29/2010 02:54 PM I know you are a smart guy Rob, but I beg to differ with you on this point. At least where VSE is concerned. I have done this and can reproduce results at will (that is if I stilled worked there). Environment: 4 CPU z890. 8 gig real memory. z/VM 5.4 7 production VSE's VSE 2.7 z/VSE 3.1 With VSE's using only 1 CPU (non-dedicated) I carfully selected a one hour job mix. Giving VSE's 4 CPU's (non-dedicated) the same job mix ran close to 1hr 20min... This is wall clock time, which in final analysis is the only one that counts. On Wed, Sep 29, 2010 at 11:16 AM, Rob van der Heij rvdh...@velocitysoftware.com mailto:rvdh...@velocitysoftware.com mailto:rvdh...@velocitysoftware.com mailto:rvdh...@velocitysoftware.com wrote: On Wed, Sep 29, 2010 at 7:30 PM, Frank M. Ramaekers framaek...@ailife.com mailto:framaek...@ailife.com mailto:framaek...@ailife.com mailto:framaek...@ailife.com wrote: This was stated on the z/VSE LISTSERV, can someone confirm (or deny) it? Here is a quick tip. When running under VM with multiple VSE's it is usually NOT a good idea to define multiple CPU's to VSE and expect turbo dispacher to handle them. Why? Because z/VM will not dispach a VSE unless it has ALL requested CPU available. Often VSE could be running but is waiting for z/VM to find a secind free CPU. As stated here, we can simply conclude and demonstrate that this claim is not true. The more interesting part is to understand which statement *is* true and how that led to this rumor ;-) In general, it's a bad idea to have more virtual CPUs than you can get from z/VM when you have workload to use them. The total number of logical CPUs in z/VM is an upper bound for what you can get, but when you run 100 Linux guests on 5 IFLs, it's unlikely you find a guest have all its 5 virtual CPUs dispatched at the same time. One of the challenges with virtualized multi-processor guests is about locking. When the virtual CPU holding the lock is not dispatched, the other virtual CPU ends up spinning waiting for the other virtual CPU to free the lock (which does not happen because you're burning a CPU spinning). To avoid that, the guest OS uses a voluntary time slice end DIAG44 to give up running and expect the other virtual CPU to get time to free the lock. Linux is even using a later version of that to tell z/VM which virtual CPU should be put in front of the queue (with more than 2 virtual CPUs other is a bit vague). I don't know how much locking is done in VSE. Another aspect is about SMP. Linux is symmetrical and does not care which virtual CPU runs what. Some Operating Systems deal with serialization by master only tasks. z/VM used to have a lot of that in ancient past, and got rid of almost all now. When the guest OS needs some work to run on one particular CPU (the master) but dispatches work on both virtual CPUs, you can't pick which one is dispatched first by z/VM. The question would be whether VSE has much master only work.
Re: z/VSE dispatch of multi-CPU under VM
I agree with IBM on this one. Long ago the powers-that-were brought in a 6-way with not-too-fast processors. This was when turbo dispatcher was first GA. The experiment was only marginally successful. Great perf on CMS, not so good on VSE - Original Message - From: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU IBMVM@LISTSERV.UARK.EDU Sent: Wed Sep 29 18:55:45 2010 Subject: Re: z/VSE dispatch of multi-CPU under VM With most workloads, IBM says to get the largest UNI you can. Remember, with z/VSE, only one CPU can be used by a single partition at a time. If you have a heavy CPU usage partition, like CICS, that uses up all the cycles it can, then adding another CPU just adds overhead. The only time I really saw z/VSE use 2 CPUs well was when CICS was using all it could of one CPUand the database server was using the other CPU. But, those were small engines many years ago. Now, I would just throw a large UNI at such a shop. Tony Thigpen -Original Message - From: Tom Huegel Sent: 09/29/2010 07:48 PM OK .. maybe Cathrine M. will chime in I can't remember everything we tried, but she takes notes. If I remember correctly nothing worked better than 1 CPU. I set share manually and let VMRMSVM do it dynamically. I think VMRMSVM did a better job overalll than I did manually. On Wed, Sep 29, 2010 at 5:59 PM, Tony Thigpen t...@vse2pdf.com mailto:t...@vse2pdf.com wrote: IBM has said many, many times to never, never use more than 3 CPU's with VSE, and even 3 is be bad with most work loads. This is due to the overhead of the Turbo-Dispatcher. With 4 you were spinning the dispatcher more than servicing the jobs. Try your job with just 2 CPUs. Tony Thigpen -Original Message - From: Tom Huegel Sent: 09/29/2010 02:54 PM I know you are a smart guy Rob, but I beg to differ with you on this point. At least where VSE is concerned. I have done this and can reproduce results at will (that is if I stilled worked there). Environment: 4 CPU z890. 8 gig real memory. z/VM 5.4 7 production VSE's VSE 2.7 z/VSE 3.1 With VSE's using only 1 CPU (non-dedicated) I carfully selected a one hour job mix. Giving VSE's 4 CPU's (non-dedicated) the same job mix ran close to 1hr 20min... This is wall clock time, which in final analysis is the only one that counts. On Wed, Sep 29, 2010 at 11:16 AM, Rob van der Heij rvdh...@velocitysoftware.com mailto:rvdh...@velocitysoftware.com mailto:rvdh...@velocitysoftware.com mailto:rvdh...@velocitysoftware.com wrote: On Wed, Sep 29, 2010 at 7:30 PM, Frank M. Ramaekers framaek...@ailife.com mailto:framaek...@ailife.com mailto:framaek...@ailife.com mailto:framaek...@ailife.com wrote: This was stated on the z/VSE LISTSERV, can someone confirm (or deny) it? Here is a quick tip. When running under VM with multiple VSE's it is usually NOT a good idea to define multiple CPU's to VSE and expect turbo dispacher to handle them. Why? Because z/VM will not dispach a VSE unless it has ALL requested CPU available. Often VSE could be running but is waiting for z/VM to find a secind free CPU. As stated here, we can simply conclude and demonstrate that this claim is not true. The more interesting part is to understand which statement *is* true and how that led to this rumor ;-) In general, it's a bad idea to have more virtual CPUs than you can get from z/VM when you have workload to use them. The total number of logical CPUs in z/VM is an upper bound for what you can get, but when you run 100 Linux guests on 5 IFLs, it's unlikely you find a guest have all its 5 virtual CPUs dispatched at the same time. One of the challenges with virtualized multi-processor guests is about locking. When the virtual CPU holding the lock is not dispatched, the other virtual CPU ends up spinning waiting for the other virtual CPU to free the lock (which does not happen because you're burning a CPU spinning). To avoid that, the guest OS uses a voluntary time slice end DIAG44 to give up running and expect the other virtual CPU to get time to free the lock. Linux is even using a later version of that to tell z/VM which virtual CPU should be put in front of the queue (with more than 2 virtual CPUs other is a bit vague). I don't know how much locking is done in VSE. Another aspect is about SMP. Linux is symmetrical and does not care which virtual
Re: z/VSE dispatch of multi-CPU under VM
One was best in our atypical environment with an atypical workload. We were an ADABAS shop and that skewers things a bit with all its SVC's. We did test with rel share set equally. No limitsoft or set absolutes. From: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU IBMVM@LISTSERV.UARK.EDU Sent: Wed Sep 29 18:48:43 2010 Subject: Re: z/VSE dispatch of multi-CPU under VM OK .. maybe Cathrine M. will chime in I can't remember everything we tried, but she takes notes. If I remember correctly nothing worked better than 1 CPU. I set share manually and let VMRMSVM do it dynamically. I think VMRMSVM did a better job overalll than I did manually. On Wed, Sep 29, 2010 at 5:59 PM, Tony Thigpen t...@vse2pdf.com wrote: IBM has said many, many times to never, never use more than 3 CPU's with VSE, and even 3 is be bad with most work loads. This is due to the overhead of the Turbo-Dispatcher. With 4 you were spinning the dispatcher more than servicing the jobs. Try your job with just 2 CPUs. Tony Thigpen -Original Message - From: Tom Huegel Sent: 09/29/2010 02:54 PM I know you are a smart guy Rob, but I beg to differ with you on this point. At least where VSE is concerned. I have done this and can reproduce results at will (that is if I stilled worked there). Environment: 4 CPU z890. 8 gig real memory. z/VM 5.4 7 production VSE's VSE 2.7 z/VSE 3.1 With VSE's using only 1 CPU (non-dedicated) I carfully selected a one hour job mix. Giving VSE's 4 CPU's (non-dedicated) the same job mix ran close to 1hr 20min... This is wall clock time, which in final analysis is the only one that counts. On Wed, Sep 29, 2010 at 11:16 AM, Rob van der Heij rvdh...@velocitysoftware.com mailto:rvdh...@velocitysoftware.com wrote: On Wed, Sep 29, 2010 at 7:30 PM, Frank M. Ramaekers framaek...@ailife.com mailto:framaek...@ailife.com wrote: This was stated on the z/VSE LISTSERV, can someone confirm (or deny) it? Here is a quick tip. When running under VM with multiple VSE's it is usually NOT a good idea to define multiple CPU's to VSE and expect turbo dispacher to handle them. Why? Because z/VM will not dispach a VSE unless it has ALL requested CPU available. Often VSE could be running but is waiting for z/VM to find a secind free CPU. As stated here, we can simply conclude and demonstrate that this claim is not true. The more interesting part is to understand which statement *is* true and how that led to this rumor ;-) In general, it's a bad idea to have more virtual CPUs than you can get from z/VM when you have workload to use them. The total number of logical CPUs in z/VM is an upper bound for what you can get, but when you run 100 Linux guests on 5 IFLs, it's unlikely you find a guest have all its 5 virtual CPUs dispatched at the same time. One of the challenges with virtualized multi-processor guests is about locking. When the virtual CPU holding the lock is not dispatched, the other virtual CPU ends up spinning waiting for the other virtual CPU to free the lock (which does not happen because you're burning a CPU spinning). To avoid that, the guest OS uses a voluntary time slice end DIAG44 to give up running and expect the other virtual CPU to get time to free the lock. Linux is even using a later version of that to tell z/VM which virtual CPU should be put in front of the queue (with more than 2 virtual CPUs other is a bit vague). I don't know how much locking is done in VSE. Another aspect is about SMP. Linux is symmetrical and does not care which virtual CPU runs what. Some Operating Systems deal with serialization by master only tasks. z/VM used to have a lot of that in ancient past, and got rid of almost all now. When the guest OS needs some work to run on one particular CPU (the master) but dispatches work on both virtual CPUs, you can't pick which one is dispatched first by z/VM. The question would be whether VSE has much master only work. Rob -- Rob van der Heij Velocity Software
Re: Mixed page volume sizes
CP will page out to the disk with the best performance, so yes, the mdl3's may be filled too much when mixing sizes. 2010/9/30 O'Brien, Dennis L dennis.l.o'br...@bankofamerica.comdennis.l.o%27br...@bankofamerica.com On of our z/VM 5.4.0 systems is about to grow to 140 GB of storage. Given our target overcommit ratio of 3:1, and IBM's advice to keep paging space no more than 50% full, this should just about fit onto 240 or 248 3390-3 sized volumes. My question is what will happen the next time we add storage. Clearly, we'll have to start using 3390-9 sized volumes for paging. Would we be better off converting only enough volumes to satisfy the space requirement, which would maximize the number of devices, or should we convert all volumes to 3390-9 to keep them the same size? My concern is that if we mix sizes, CP will try to allocate the same amount of space on each volume, and the 3390-3's will get more than half full. On the other hand, maximizing the number of devices maximizes the number of concurrent I/O's. Our Storage people aren't going to give me 240 3390-9's if I don't need them, so if I add another 32 GB of storage, my choice would be something like 212 3390-3's and 28 3390-9's, or 100 3390-9's. Which would be a better choice? Dennis Decision is not a verb. -- Kris Buelens, IBM Belgium, VM customer support
