Re: Second level VM systems
Was there overlap? I was on VM/370 Release 6 BSE. I left that employer and when I went to another place, a few years later, I installed VM/SP 3. So I want to say that it was: VM/370 Release 1 VM/370 Release 2 VM/370 Release 3 VM/370 Release 4 VM/370 Release 5 VM/370 Release 6 VM/SP 1 VM/SP 2 VM/SP 3 VM/SP 4 VM/SP 5 along with VM/IS 5 and VM/XA Release 1 VM/SP 6 along with VM/IS 6 VM/ESA 370 mode VM/ESA ESA mode I remember BSE (Basic System Extensions), being an option. I don't know if there were other options available or if the option really wasn't optional. Tom Duerbusch THD Consulting Schuh, Richard rsc...@visa.com 2/23/2009 6:15 PM The SPs didn't appear until R4. SP1 had a few problems (take that euphemistically). Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivan Warren Sent: Monday, February 23, 2009 4:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems Schuh, Richard wrote: Nope, I really meant R2. The year was 1973. David, Richard.. Ok.. R2 R3 ! --Ivan
Re: Second level VM systems
There also was VM/IS 4. I had the pleasure of supporting VM in a module replacement only environment. IBM had some great System Engineers that helped the customers back then. Please consider the environment before printing this email. Thank you, Dave Hansen Sr. Systems Programmer Hennepin County Information Technology 300 South 6th Street Minneapolis, MN 55487 Ph: 612.596.1283 FAX: 612.348.4663 Tom Duerbusch duerbus...@stlouiscity.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc 02/24/2009 10:48 AM Subject Re: Second level VM systems Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Was there overlap? I was on VM/370 Release 6 BSE. I left that employer and when I went to another place, a few years later, I installed VM/SP 3. So I want to say that it was: VM/370 Release 1 VM/370 Release 2 VM/370 Release 3 VM/370 Release 4 VM/370 Release 5 VM/370 Release 6 VM/SP 1 VM/SP 2 VM/SP 3 VM/SP 4 VM/SP 5 along with VM/IS 5 and VM/XA Release 1 VM/SP 6 along with VM/IS 6 VM/ESA 370 mode VM/ESA ESA mode I remember BSE (Basic System Extensions), being an option. I don't know if there were other options available or if the option really wasn't optional. Tom Duerbusch THD Consulting Schuh, Richard rsc...@visa.com 2/23/2009 6:15 PM The SPs didn't appear until R4. SP1 had a few problems (take that euphemistically). Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivan Warren Sent: Monday, February 23, 2009 4:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems Schuh, Richard wrote: Nope, I really meant R2. The year was 1973. David, Richard.. Ok.. R2 R3 ! --Ivan Disclaimer: Information in this message or an attachment may be government data and thereby subject to the Minnesota Government Data Practices Act, Minnesota Statutes, Chapter 13, may be subject to attorney-client or work product privilege, may be confidential, privileged, proprietary, or otherwise protected, and the unauthorized review, copying, retransmission, or other use or disclosure of the information is strictly prohibited. If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly delete this message from your computer system.
Re: Second level VM systems
Yes, the SPs overlapped the later Releases, and the HPOs overlapped the later SPs. IIRC, SP1 was based on Release 4. It came out later than the release and wasn't well received because of problems. There was even the famous T-shirt that Jim Bergsten designed and sold at SHARE. It depicted the VM teddy bear skipping down the lane toward a tree where a big vulture was perched. The caption was, IIRC, VM/SP1 is waiting for you. It may have just been VM/SP instead of VM/SP1. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Tuesday, February 24, 2009 8:40 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems Was there overlap? I was on VM/370 Release 6 BSE. I left that employer and when I went to another place, a few years later, I installed VM/SP 3. So I want to say that it was: VM/370 Release 1 VM/370 Release 2 VM/370 Release 3 VM/370 Release 4 VM/370 Release 5 VM/370 Release 6 VM/SP 1 VM/SP 2 VM/SP 3 VM/SP 4 VM/SP 5 along with VM/IS 5 and VM/XA Release 1 VM/SP 6 along with VM/IS 6 VM/ESA 370 mode VM/ESA ESA mode I remember BSE (Basic System Extensions), being an option. I don't know if there were other options available or if the option really wasn't optional. Tom Duerbusch THD Consulting Schuh, Richard rsc...@visa.com 2/23/2009 6:15 PM The SPs didn't appear until R4. SP1 had a few problems (take that euphemistically). Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivan Warren Sent: Monday, February 23, 2009 4:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems Schuh, Richard wrote: Nope, I really meant R2. The year was 1973. David, Richard.. Ok.. R2 R3 ! --Ivan
Re: Second level VM systems
Tom Duerbusch wrote: Was there overlap? I was on VM/370 Release 6 BSE. I left that employer and when I went to another place, a few years later, I installed VM/SP 3. So I want to say that it was: VM/370 Release 1 VM/370 Release 2 VM/370 Release 3 VM/370 Release 4 VM/370 Release 5 VM/370 Release 6 VM/SP 1 VM/SP 2 VM/SP 3 VM/SP 4 VM/SP 5 along with VM/IS 5 and VM/XA Release 1 VM/SP 6 along with VM/IS 6 VM/ESA 370 mode VM/ESA ESA mode I remember BSE (Basic System Extensions), being an option. I don't know if there were other options available or if the option really wasn't optional. IIRC, SEPP BSEPP were optional extensions to VM/370 R6. I think they added stuff like Fullscreen I/O and LDEVs. Also HPO : 4 5 simultaneously with SP 4/5. (there might have been earlier HPOs, but I'm not sure only have worked with HPO 4 5). And the case of the mysteriously disappearing HPO 6 that should have come along with SP 6.. Current (at that time) HPO 5 users received all the HPO 6 manuals only to be told that there would never be an HPO 6 ! We were then told something in the line that HPO 6 *DID* exist, but would never be publicly released (only the U.S. Govt would have access to it). They claim they did this to push VM/XA SP 2.1.. And that the manuals were erroneously shipped ! Which did cause some grief at the shop at was working at that time since VM/XA severly lacked 3270 BSC support Note the list is also missing the VM/XA SF VM/XA SP line of products ;).. But yeah.. I think VM/XA SP1 was with SP 5 and VM/XA SP2 was with SP6 (with a supposedly common version of CMS.. CMS 6.5 ?) --Ivan
Re: Second level VM systems
I think SEPP was available for VM/370 R5. SEPP, if remember correctly, was the "official" version of the Wheeler Scheduler. I don't thing BSEPP included the Wheeler Scheduler. HPO R4 was probably the shortest lived IBM release ever. I supported a shop that was a Beta site (or whatever they called it) for SP4 and HPO4 because it brought "native" mode VM/VTAM. SP4 didn't seem to be too bad, maybe just in comparison to HPO4. HPO4 GA'd in about December of 1985 and was replaced with HPO4.2 in about March of 1986. A good day would mean no more than one CP abend. Barton Robinson, then IBM, lived with us for a few weeks. Jim Ivan Warren wrote: Tom Duerbusch wrote: Was there overlap? I was on VM/370 Release 6 BSE. I left that employer and when I went to another place, a few years later, I installed VM/SP 3. So I want to say that it was: VM/370 Release 1 VM/370 Release 2 VM/370 Release 3 VM/370 Release 4 VM/370 Release 5 VM/370 Release 6 VM/SP 1 VM/SP 2 VM/SP 3 VM/SP 4 VM/SP 5 along with VM/IS 5 and VM/XA Release 1 VM/SP 6 along with VM/IS 6 VM/ESA 370 mode VM/ESA ESA mode I remember BSE (Basic System Extensions), being an option. I don't know if there were other options available or if the option really wasn't optional. IIRC, SEPP BSEPP were optional extensions to VM/370 R6. I think they added stuff like Fullscreen I/O and LDEVs. Also HPO : 4 5 simultaneously with SP 4/5. (there might have been earlier HPOs, but I'm not sure only have worked with HPO 4 5). And the case of the mysteriously disappearing HPO 6 that should have come along with SP 6.. Current (at that time) HPO 5 users received all the HPO 6 manuals only to be told that there would never be an HPO 6 ! We were then told something in the line that HPO 6 *DID* exist, but would never be publicly released (only the U.S. Govt would have access to it). They claim they did this to push VM/XA SP 2.1.. And that the manuals were erroneously shipped ! Which did cause some grief at the shop at was working at that time since VM/XA severly lacked 3270 BSC support Note the list is also missing the VM/XA SF VM/XA SP line of products ;).. But yeah.. I think VM/XA SP1 was with SP 5 and VM/XA SP2 was with SP6 (with a supposedly common version of CMS.. CMS 6.5 ?) --Ivan -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu
Re: Second level VM systems
There also was an HPO R3 (and 3.2?) HPO6 was kind of special bid only in Belgium. I installed it for my customer: we needed 16 Meg real storage and VM/APPC programs talking to OS/2 (hence AVS), VM/XA could not help us, so we got HPO R6 2009/2/24 Jim Bohnsack jab...@cornell.edu I think SEPP was available for VM/370 R5. SEPP, if remember correctly, was the official version of the Wheeler Scheduler. I don't thing BSEPP included the Wheeler Scheduler. HPO R4 was probably the shortest lived IBM release ever. I supported a shop that was a Beta site (or whatever they called it) for SP4 and HPO4 because it brought native mode VM/VTAM. SP4 didn't seem to be too bad, maybe just in comparison to HPO4. HPO4 GA'd in about December of 1985 and was replaced with HPO4.2 in about March of 1986. A good day would mean no more than one CP abend. Barton Robinson, then IBM, lived with us for a few weeks. Jim Ivan Warren wrote: Tom Duerbusch wrote: Was there overlap? I was on VM/370 Release 6 BSE. I left that employer and when I went to another place, a few years later, I installed VM/SP 3. So I want to say that it was: VM/370 Release 1 VM/370 Release 2 VM/370 Release 3 VM/370 Release 4 VM/370 Release 5 VM/370 Release 6 VM/SP 1 VM/SP 2 VM/SP 3 VM/SP 4 VM/SP 5 along with VM/IS 5 and VM/XA Release 1 VM/SP 6 along with VM/IS 6 VM/ESA 370 mode VM/ESA ESA mode I remember BSE (Basic System Extensions), being an option. I don't know if there were other options available or if the option really wasn't optional. IIRC, SEPP BSEPP were optional extensions to VM/370 R6. I think they added stuff like Fullscreen I/O and LDEVs. Also HPO : 4 5 simultaneously with SP 4/5. (there might have been earlier HPOs, but I'm not sure only have worked with HPO 4 5). And the case of the mysteriously disappearing HPO 6 that should have come along with SP 6.. Current (at that time) HPO 5 users received all the HPO 6 manuals only to be told that there would never be an HPO 6 ! We were then told something in the line that HPO 6 *DID* exist, but would never be publicly released (only the U.S. Govt would have access to it). They claim they did this to push VM/XA SP 2.1.. And that the manuals were erroneously shipped ! Which did cause some grief at the shop at was working at that time since VM/XA severly lacked 3270 BSC support Note the list is also missing the VM/XA SF VM/XA SP line of products ;).. But yeah.. I think VM/XA SP1 was with SP 5 and VM/XA SP2 was with SP6 (with a supposedly common version of CMS.. CMS 6.5 ?) --Ivan -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 celljab...@cornell.edu -- Kris Buelens, IBM Belgium, VM customer support
Re: Second level VM systems
I got into VM late in life. My first VM system was HPO 3.6. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Tuesday, February 24, 2009 12:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems There also was an HPO R3 (and 3.2?) HPO6 was kind of special bid only in Belgium. I installed it for my customer: we needed 16 Meg real storage and VM/APPC programs talking to OS/2 (hence AVS), VM/XA could not help us, so we got HPO R6 2009/2/24 Jim Bohnsack jab...@cornell.edu I think SEPP was available for VM/370 R5. SEPP, if remember correctly, was the official version of the Wheeler Scheduler. I don't thing BSEPP included the Wheeler Scheduler. HPO R4 was probably the shortest lived IBM release ever. I supported a shop that was a Beta site (or whatever they called it) for SP4 and HPO4 because it brought native mode VM/VTAM. SP4 didn't seem to be too bad, maybe just in comparison to HPO4. HPO4 GA'd in about December of 1985 and was replaced with HPO4.2 in about March of 1986. A good day would mean no more than one CP abend. Barton Robinson, then IBM, lived with us for a few weeks. Jim Ivan Warren wrote: Tom Duerbusch wrote: Was there overlap? I was on VM/370 Release 6 BSE. I left that employer and when I went to another place, a few years later, I installed VM/SP 3. So I want to say that it was: VM/370 Release 1 VM/370 Release 2 VM/370 Release 3 VM/370 Release 4 VM/370 Release 5 VM/370 Release 6 VM/SP 1 VM/SP 2 VM/SP 3 VM/SP 4 VM/SP 5 along with VM/IS 5 and VM/XA Release 1 VM/SP 6 along with VM/IS 6 VM/ESA 370 mode VM/ESA ESA mode I remember BSE (Basic System Extensions), being an option. I don't know if there were other options available or if the option really wasn't optional. IIRC, SEPP BSEPP were optional extensions to VM/370 R6. I think they added stuff like Fullscreen I/O and LDEVs. Also HPO : 4 5 simultaneously with SP 4/5. (there might have been earlier HPOs, but I'm not sure only have worked with HPO 4 5). And the case of the mysteriously disappearing HPO 6 that should have come along with SP 6.. Current (at that time) HPO 5 users received all the HPO 6 manuals only to be told that there would never be an HPO 6 ! We were then told something in the line that HPO 6 *DID* exist, but would never be publicly released (only the U.S. Govt would have access to it). They claim they did this to push VM/XA SP 2.1.. And that the manuals were erroneously shipped ! Which did cause some grief at the shop at was working at that time since VM/XA severly lacked 3270 BSC support Note the list is also missing the VM/XA SF VM/XA SP line of products ;).. But yeah.. I think VM/XA SP1 was with SP 5 and VM/XA SP2 was with SP6 (with a supposedly common version of CMS.. CMS 6.5 ?) --Ivan -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu -- Kris Buelens, IBM Belgium, VM customer support
Re: Second level VM systems
No, HPO 6 was available in the US as well, because I replaced an HPO 6 system with VM/ESA 1.2.1 in 1994. Jim Kris Buelens wrote: --001636c598448597520463af4eed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There also was an HPO R3 (and 3.2?) HPO6 was kind of special bid only in Belgium. I installed it for my customer: we needed 16 Meg real storage and VM/APPC programs talking to OS/2 (hence AVS), VM/XA could not help us, so we got HPO R6 2009/2/24 Jim Bohnsack jab...@cornell.edu -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu
Re: Second level VM systems
I didn't want to say HPO R6 was for Belgium only. No, I wanted to say: in Belgium a special bid was required to get it. 2009/2/24 Jim Bohnsack jab...@cornell.edu No, HPO 6 was available in the US as well, because I replaced an HPO 6 system with VM/ESA 1.2.1 in 1994. Jim Kris Buelens wrote: --001636c598448597520463af4eed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There also was an HPO R3 (and 3.2?) HPO6 was kind of special bid only in Belgium. I installed it for my customer: we needed 16 Meg real storage and VM/APPC programs talking to OS/2 (hence AVS), VM/XA could not help us, so we got HPO R6 2009/2/24 Jim Bohnsack jab...@cornell.edu -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu -- Kris Buelens, IBM Belgium, VM customer support
Re: Second level VM systems
It was a special everywhere. The HPO features for PERFORMANCE were bundled into SP6 to restore performance lost in the move from SP5 because of all the extra's as confirmed by the announcement letter:- http://www-01.ibm.com/common/ssi/rep_ca/2/877/ENUSZP89-0342/ I hope that works for others As Kris said you only needed HPO6 for machines with 16megs of RAM (or perhaps more than 16 channels).. Dave Wade G4UGM Illegitimi Non Carborundum -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: 24 February 2009 21:33 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems I didn't want to say HPO R6 was for Belgium only. No, I wanted to say: in Belgium a special bid was required to get it. 2009/2/24 Jim Bohnsack jab...@cornell.edu No, HPO 6 was available in the US as well, because I replaced an HPO 6 system with VM/ESA 1.2.1 in 1994. Jim Kris Buelens wrote: --001636c598448597520463af4eed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There also was an HPO R3 (and 3.2?) HPO6 was kind of special bid only in Belgium. I installed it for my customer: we needed 16 Meg real storage and VM/APPC programs talking to OS/2 (hence AVS), VM/XA could not help us, so we got HPO R6 2009/2/24 Jim Bohnsack jab...@cornell.edu -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu -- Kris Buelens, IBM Belgium, VM customer support
Re: Second level VM systems
I got into VM when it was CP/67 in 1970 and it certainly has been a fun ride. One of my first tasks was to use O/S PCP to run multiple O/S jobs under CP to justify the box. This was about the time Aetna started a project to implement O/S MVT. In mid 1971 I moved to Eastern Airlines and lost the use of VM until 1973 when I finally convinced Eastern management VM was the best way to test ACP/TPF. _ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of James Stracka (DHL US) Sent: Tuesday, February 24, 2009 2:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems I got into VM late in life. My first VM system was HPO 3.6. _ From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Tuesday, February 24, 2009 12:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems There also was an HPO R3 (and 3.2?) HPO6 was kind of special bid only in Belgium. I installed it for my customer: we needed 16 Meg real storage and VM/APPC programs talking to OS/2 (hence AVS), VM/XA could not help us, so we got HPO R6 2009/2/24 Jim Bohnsack jab...@cornell.edu I think SEPP was available for VM/370 R5. SEPP, if remember correctly, was the official version of the Wheeler Scheduler. I don't thing BSEPP included the Wheeler Scheduler. HPO R4 was probably the shortest lived IBM release ever. I supported a shop that was a Beta site (or whatever they called it) for SP4 and HPO4 because it brought native mode VM/VTAM. SP4 didn't seem to be too bad, maybe just in comparison to HPO4. HPO4 GA'd in about December of 1985 and was replaced with HPO4.2 in about March of 1986. A good day would mean no more than one CP abend. Barton Robinson, then IBM, lived with us for a few weeks. Jim Ivan Warren wrote: Tom Duerbusch wrote: Was there overlap? I was on VM/370 Release 6 BSE. I left that employer and when I went to another place, a few years later, I installed VM/SP 3. So I want to say that it was: VM/370 Release 1 VM/370 Release 2 VM/370 Release 3 VM/370 Release 4 VM/370 Release 5 VM/370 Release 6 VM/SP 1 VM/SP 2 VM/SP 3 VM/SP 4 VM/SP 5 along with VM/IS 5 and VM/XA Release 1 VM/SP 6 along with VM/IS 6 VM/ESA 370 mode VM/ESA ESA mode I remember BSE (Basic System Extensions), being an option. I don't know if there were other options available or if the option really wasn't optional. IIRC, SEPP BSEPP were optional extensions to VM/370 R6. I think they added stuff like Fullscreen I/O and LDEVs. Also HPO : 4 5 simultaneously with SP 4/5. (there might have been earlier HPOs, but I'm not sure only have worked with HPO 4 5). And the case of the mysteriously disappearing HPO 6 that should have come along with SP 6.. Current (at that time) HPO 5 users received all the HPO 6 manuals only to be told that there would never be an HPO 6 ! We were then told something in the line that HPO 6 *DID* exist, but would never be publicly released (only the U.S. Govt would have access to it). They claim they did this to push VM/XA SP 2.1.. And that the manuals were erroneously shipped ! Which did cause some grief at the shop at was working at that time since VM/XA severly lacked 3270 BSC support Note the list is also missing the VM/XA SF VM/XA SP line of products ;).. But yeah.. I think VM/XA SP1 was with SP 5 and VM/XA SP2 was with SP6 (with a supposedly common version of CMS.. CMS 6.5 ?) --Ivan -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu -- Kris Buelens, IBM Belgium, VM customer support
Re: Second level VM systems
On Mon, Feb 23, 2009 at 5:48 AM, Alan Altmark alan_altm...@us.ibm.com wrote: Excellent. Years of aversive conditioning worked. Those who have shutdownaphobia, having been bitten by it on one or more occasions, are fine. They have developed a healthy fear of something that can hurt them. The problem with most of these protections is that they are also implemented on your test system (to keep things as similar as you can) and you develop the automatism to answer to such prompts and render them useless (like format 100 c#1#TMP100). Maybe the SYSTEM on SHUTDOWN helps, but there's a lot of other things that come pretty close to shutdown. I'd rather avoid high privileges on the individual users and use PROP to do the dangerous things. It could keep a table to define which users on which system may force what users, for example. One of the interesting aspects of block mode terminals is that some session breakage only shows when you press Enter. I had some VPN time-out problems that caused my session to break. So you're interrupted for a while and get back to your 2nd level system, type shutdown reipl and get X-System with your emulator showing the address of the production system... cold shivers over your back. My all-time favorite is the experienced operator trying to lure the rookie operator: tell op2 hey, type #CP shutdown if you dare! When he realized what really happened, he was less amused by the success. -Rob
Re: Second level VM systems
Come on, Alan, They were fun. We were all of the time inventing things that were not in the system. And then there was all of the time coding and; the fun we had working with (or against, in the days of WAD) the Support Center debugging dumps over the phone; fighting to get APARs for problems we were having; the OCO wars. They really were the good old days. Today's VM Sysprog has a dull life, indeed, by comparison. :-) Of course, you were seeing it from the vendor's side, so there may be a perspective issue. Regards, Richard Schuh [Remind me never to refer to those as the good ol' days.] Alan Altmark z/VM Development IBM Endicott
Re: Second level VM systems
To prevent the MDC problem on 2nd level we issue: SET MDCACHE SYSTEM OFF -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Friday, February 20, 2009 4:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems For second level VM: 2. LPAR requires dedicated packs. Second level VM can use dedicated packs and/or minidisks from the 1st level system. (the only dedicated disk space you need for a second level VM system is the CP areas. All CMS minidisks can be shared in R/O mode and you only need to replicate the CMS disks that you intend to update. Beware of MDC when you share CMS disks in R/O mode on the second level system)
Re: Second level VM systems
You may only want to set it off for specific volumes. For example, if you are a heavy SFS user, you probably still want it turned on for your pool servers. Speaking of that, the solution for the problem of dealing with VSWITCHs looks amazingly like VCTCA support. Are we close to being able to do ISFC over a VCTCA on a guest that is coupled to a CP owned VCTCA? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of James Stracka (DHL US) Sent: Monday, February 23, 2009 9:26 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems To prevent the MDC problem on 2nd level we issue: SET MDCACHE SYSTEM OFF -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Friday, February 20, 2009 4:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems For second level VM: 2. LPAR requires dedicated packs. Second level VM can use dedicated packs and/or minidisks from the 1st level system. (the only dedicated disk space you need for a second level VM system is the CP areas. All CMS minidisks can be shared in R/O mode and you only need to replicate the CMS disks that you intend to update. Beware of MDC when you share CMS disks in R/O mode on the second level system)
Re: Second level VM systems
Comments prefixed by ** Tom Duerbusch THD Consulting Ivan Warren i...@vmfacility.fr 2/20/2009 5:25 PM Tom Duerbusch wrote: For second level VM: 2. LPAR requires dedicated packs. Second level VM can use dedicated packs and/or minidisks from the 1st level system. (the only dedicated disk space you need for a second level VM system is the CP areas. All CMS minidisks can be shared in R/O mode and you only need to replicate the CMS disks that you intend to update. Beware of MDC when you share CMS disks in R/O mode on the second level system) Nothing prevents one from putting CP stuff on a minidisk (just makes it difficult to IPL it 1st level afterward though). ** I didn't say dedicated disk...I said dedicated disk space. The point was that where you can share CMS minidisks (not in multiple write mode, you can't share CP areas). 3. LPAR requires real hardware for communications. Second level VM can use VCTCA, IUCV, VSWITCH for communications. IUCV ? I didn't know CP knew how to exploit an underlying IUCV framework ! (but then, I might have missed something). ** Of course, CP can't, I was thinking CMS based programs, but IUCV can't cross CP boundries. You caught me on that one G. 6. In the old days of LPAR, you couldn't share channels. Dedicated 3274/3174 for each LPAR. Two channel switches for dasd/tape. Dedicated communication channels. VM is much cheaper. How about MIF/EMIF ? ** I don't recall the we had MIF/EMIF in the old days. Yes, we do now, but mainframes have a lot of history behind them. 7. On an IBM 370/168 1 MB of memory ran about $1 million. VM/370 Rel 6 BSE could run in about 150 K. Err.. Even with a small CP nucleus.. I don't think you could ever run VM/370 R6 with less than 512K ** Maybe. We had VM running on and IBM 370/158. And it didn't have much storage on it. But I don't recall how much. 8. Second level VM is for REAL VM SYSTEM PROGRAMMERS. Here, I'm with you :P For running in a LPAR: 1. It is hard to accidently shutdown your production VM system from another LPAR. At one time, we have all shutdown the production VM system when we thought we were on test. And don't you *EVER* give class A to a virtual machine running a 2nd level VM (.. Yeah.. I've done it..shutdown.. uh oh.. did that go 1st level ??) 2. A second level VM system may impact the first level paging subsystem. Can't happen with LPAR. I'll have to disagree here :P.. If your box as so much main storage, if you run 2 partitions, you're going to indirectly affect paging because each LPAR will have to split whatever storage is available.. 3. LPAR is a simpler concept. Both VM systems are running at the same level. You don't have to think about which level you are issuing commands to. But nowadays, your workstation is probably going to be running multiple 3270 sessions.. you may very well issue a command to the wrong system - and I'm sure that's how most errors in those cases are made. 4. You get better performance of a second level system, then when running a third level system. Depending on what you are testing, this can be important. 5. LPAR does take less VM knowledge. .. But much more careful planning ! Just my €.02 --Ivan
Re: Second level VM systems
We did it to test a new version or ptf's or apars that we applied. We also used it to test modifications to CMS or CP or even waterloo updates. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Owen, Jerry W. (AITC) Sent: Thursday, February 19, 2009 8:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Second level VM systems For all of you old timers that have used VM since it landed on Plymouth Rock, what are the pros and cons of using a second level VM system? Thanks in advance. == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Second level VM systems
We do the same, Second level machine has all ptfs applied, tested, then it becomes the current system. Online backup is available. You will have to handle the volid problem. Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ward, Mike S Sent: Monday, February 23, 2009 4:41 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems We did it to test a new version or ptf's or apars that we applied. We also used it to test modifications to CMS or CP or even waterloo updates. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Owen, Jerry W. (AITC) Sent: Thursday, February 19, 2009 8:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Second level VM systems For all of you old timers that have used VM since it landed on Plymouth Rock, what are the pros and cons of using a second level VM system? Thanks in advance. == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Second level VM systems
Tom Duerbusch wrote: ** I didn't say dedicated disk...I said dedicated disk space. The point was that where you can share CMS minidisks (not in multiple write mode, you can't share CP areas). Good point ! Although you can share the config disk I think (Maint CFx disks).. IIRC, SYSTEM CONFIG has provision for being used by multiple systems.. But yes, I misconstrued your statement. ** I don't recall the we had MIF/EMIF in the old days. Yes, we do now, but mainframes have a lot of history behind them. AFAIK, MIF/EMIF came pretty early with LPAR. I think even the 3090 S or J models had MIF/EMIF. Err.. Even with a small CP nucleus.. I don't think you could ever run VM/370 R6 with less than 512K ** Maybe. We had VM running on and IBM 370/158. And it didn't have much storage on it. But I don't recall how much. I think the smallest S/370 you could run VM/370 R6 was the 370/138 Model 1 (with 512K) - and that was pretty much borderline.. You probably weren't left with much more than 30 or 40 pages for virtual machines at that point.. The 370/138 Mod II already had 1MB.. Not sure about the 158, but it must've had at least 1MB. --Ivan
Re: Second level VM systems
That sounds about right. I never worked on R6, and I never had that small of a system. My first exposure was R2 on an 8M 168. I upgraded to R3 as soon as it came out. Regards, Richard Schuh I think the smallest S/370 you could run VM/370 R6 was the 370/138 Model 1 (with 512K) - and that was pretty much borderline.. You probably weren't left with much more than 30 or 40 pages for virtual machines at that point.. The 370/138 Mod II already had 1MB.. Not sure about the 158, but it must've had at least 1MB. --Ivan
Re: Second level VM systems
Schuh, Richard wrote: That sounds about right. I never worked on R6, and I never had that small of a system. My first exposure was R2 on an 8M 168. I upgraded to R3 as soon as it came out. I'm assuming you're meaning SP2 SP3 (not R2 R3).. --Ivan
Re: Second level VM systems
No, I think Richard is correct; I worked on VM/370 Version 1 Release 3 and up. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivan Warren Sent: Monday, February 23, 2009 7:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems Schuh, Richard wrote: That sounds about right. I never worked on R6, and I never had that small of a system. My first exposure was R2 on an 8M 168. I upgraded to R3 as soon as it came out. I'm assuming you're meaning SP2 SP3 (not R2 R3).. --Ivan Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Second level VM systems
Nope, I really meant R2. The year was 1973. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivan Warren Sent: Monday, February 23, 2009 4:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems Schuh, Richard wrote: That sounds about right. I never worked on R6, and I never had that small of a system. My first exposure was R2 on an 8M 168. I upgraded to R3 as soon as it came out. I'm assuming you're meaning SP2 SP3 (not R2 R3).. --Ivan
Re: Second level VM systems
Schuh, Richard wrote: Nope, I really meant R2. The year was 1973. David, Richard.. Ok.. R2 R3 ! --Ivan
Re: Second level VM systems
The SPs didn't appear until R4. SP1 had a few problems (take that euphemistically). Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivan Warren Sent: Monday, February 23, 2009 4:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems Schuh, Richard wrote: Nope, I really meant R2. The year was 1973. David, Richard.. Ok.. R2 R3 ! --Ivan
Re: Second level VM systems
Schuh, Richard wrote: Nope, I really meant R2. The year was 1973. To explain my confusion : You stated you never worked on R6.. When I read this I *assumed* (wrongly) that you experience *post* dated VM/370 R6, especially since you mentioned you hadn't worked with anything smaller than a 370/168.. At this point, my mind got date warped, hence my confusion ;) So R2 R3 it is (man.. we're talking time when CMS could still be IPL'ed standalone !) --Ivan
Re: Second level VM systems
I never did use SP6. We were well into the HPOs by then. We went from HPO4 to HPO5 as soon as we could, and from there to VM/XA. We never did try CMS on the bare iron, we were too busy trying to make PARS behave in a virtual machine. That took a lot of modification to VM (mods to 80 CP modules) and a little to PARS. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ivan Warren Sent: Monday, February 23, 2009 4:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems Schuh, Richard wrote: Nope, I really meant R2. The year was 1973. To explain my confusion : You stated you never worked on R6.. When I read this I *assumed* (wrongly) that you experience *post* dated VM/370 R6, especially since you mentioned you hadn't worked with anything smaller than a 370/168.. At this point, my mind got date warped, hence my confusion ;) So R2 R3 it is (man.. we're talking time when CMS could still be IPL'ed standalone !) --Ivan
Re: Second level VM systems
On Friday, 02/20/2009 at 06:04 EST, Tom Duerbusch duerbus...@stlouiscity.com wrote: 1. It is hard to accidently shutdown your production VM system from another LPAR. At one time, we have all shutdown the production VM system when we thought we were on test. Good news is that z/VM 5.4 included a SYSTEM option on SHUTDOWN. An option in SYSTEM CONFIG decides if it is required or optional. If your test image and your production image have the same System_identifier, then you will find the safety net is there, but is laying directly on the ground. Be careful. Alan Altmark z/VM Development IBM Endicott
Re: Second level VM systems
We've talked about this before and I think that I mentioned or complained, at least 10 years ago, that SHUTDOWN should not have ever been permitted in any IBM program but CP. SHUTDOWN is used in RSCS and, I think, PVM. I know that I've SHUTDOWN CP "one" time when I thought I was talking to RSCS. Every systems programmer with whom I have ever worked has shutdown CP "once". Jim Alan Altmark wrote: On Friday, 02/20/2009 at 06:04 EST, Tom Duerbusch duerbus...@stlouiscity.com wrote: 1. It is hard to accidently shutdown your production VM system from another LPAR. At one time, we have all shutdown the production VM system when we thought we were on test. Good news is that z/VM 5.4 included a SYSTEM option on SHUTDOWN. An option in SYSTEM CONFIG decides if it is required or optional. If your test image and your production image have the same System_identifier, then you will find the safety net is there, but is laying directly on the ground. Be careful. Alan Altmark z/VM Development IBM Endicott -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu
Re: Second level VM systems
Yup - and DIRMAINT also uses SHUTDOWN as the command to bring it down. I suppose there's a consistency here at least ;-) I agree consistency in the case of mimicing the OS command is not the best approach. Maybe we should immediately create a NWODTUHS command to bring down CP and make SHUTDOWN an unknown CP command. Said at half in jest.. Scott On Sun, Feb 22, 2009 at 6:46 PM, Jim Bohnsack jab...@cornell.edu wrote: We've talked about this before and I think that I mentioned or complained, at least 10 years ago, that SHUTDOWN should not have ever been permitted in any IBM program but CP. SHUTDOWN is used in RSCS and, I think, PVM. I know that I've SHUTDOWN CP one time when I thought I was talking to RSCS. Every systems programmer with whom I have ever worked has shutdown CP once. Jim Alan Altmark wrote: On Friday, 02/20/2009 at 06:04 EST, Tom Duerbusch duerbus...@stlouiscity.com duerbus...@stlouiscity.com wrote: 1. It is hard to accidently shutdown your production VM system from another LPAR. At one time, we have all shutdown the production VM system when we thought we were on test. Good news is that z/VM 5.4 included a SYSTEM option on SHUTDOWN. An option in SYSTEM CONFIG decides if it is required or optional. If your test image and your production image have the same System_identifier, then you will find the safety net is there, but is laying directly on the ground. Be careful. Alan Altmark z/VM Development IBM Endicott -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 celljab...@cornell.edu
Re: Second level VM systems
Aaaahhh - now I get it.. thanks for explaining that, Alan! Guess I blew by that earlier.. Scott On Sun, Feb 22, 2009 at 7:35 PM, Alan Altmark alan_altm...@us.ibm.comwrote: On Sunday, 02/22/2009 at 09:16 EST, Scott Rohling scott.rohl...@gmail.com wrote: Maybe we should immediately create a NWODTUHS command to bring down CP and make SHUTDOWN an unknown CP command. Said at half in jest.. Excellent idea! In fact, it's so good that we'll implement it in RSCS, DIRMAINT, and all the other subsystems! (the other half of the jest) If you update SYSTEM CONFIG to *require* SHUTDOWN SYSTEM systemid (Features Enable Validate_Shutdown), then the SHUTDOWNs of other subsystems won't accidentally take down CP. Alan Altmark z/VM Development IBM Endicott
Re: Second level VM systems
I've probably seen all of the aforementioned safeguards mentioned. Back in the '80's when 3270PC's, or were they PC3270's, were in vogue, the hard disk was so sensitive that to protect your PC from the cleaning crew bumping the PC stand, one of my co-workers, after shutting down the system rather than the 3270PC, which had a SHUTDOWN command to park the head on the hard disk, put a SHUTDOWN EXEC on the S-disk that said "You don't really want to do that, do you?". Cornell has SHUTDOWN set as a class Z or something in SYSTEM CONFIG. Wonder why? Nevertheless, I still hate to type in SHUTDOWN. Jim Scott Rohling wrote: --000e0cd3107ed5760d04638d16c0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Aaaahhh - now I get it.. thanks for explaining that, Alan! Guess I blew by that earlier.. Scott On Sun, Feb 22, 2009 at 7:35 PM, Alan Altmark alan_altm...@us.ibm.comwrote: On Sunday, 02/22/2009 at 09:16 EST, Scott Rohling scott.rohl...@gmail.com wrote: Maybe we should immediately create a NWODTUHS command to bring down CP and make SHUTDOWN an unknown CP command. Said at half in jest.. Excellent idea! In fact, it's so good that we'll implement it in RSCS, DIRMAINT, and all the other subsystems! (the other half of the jest) If you update SYSTEM CONFIG to *require* "SHUTDOWN SYSTEM systemid" (Features Enable Validate_Shutdown), then the SHUTDOWNs of other subsystems won't accidentally take down CP. Alan Altmark z/VM Development IBM Endicott --000e0cd3107ed5760d04638d16c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aaaahhh - now I get it..nbsp;nbsp; thanks for explaining that, Alan!nbsp= ; Guess I blew by that earlier..nbsp;nbsp; brbrScottbrbrdiv clas= s=3D"gmail_quote"On Sun, Feb 22, 2009 at 7:35 PM, Alan Altmark span dir= =3D"ltr"lt;a href="" class="moz-txt-link-rfc2396E" href="mailto:alan_altm...@us.ibm.com">"mailto:alan_altm...@us.ibm.com"alan_altm...@us.ibm= .com/agt;/span wrote:br blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"On Sunday, 02/22/= 2009 at 09:16 EST, Scott Rohlingbr div class=3D"Ih2E3d"lt;a href="" class="moz-txt-link-rfc2396E" href="mailto:scott.rohl...@gmail.com">"mailto:scott.rohl...@gmail.com"scott.= rohl...@gmail.com/agt; wrote:br br gt; Maybe we should immediately create a NWODTUHS nbsp;command to bring d= own CPbr andbr gt; make SHUTDOWN an unknown CP command.br gt;br gt; Said at half in jest..br br /divExcellent idea! nbsp;In fact, it#39;s so good that we#39;ll implem= ent it in RSCS,br DIRMAINT, and all the other subsystems!br br (the other half of the jest)br br If you update SYSTEM CONFIG to *require* quot;SHUTDOWN SYSTEM systemidquo= t;br (Features Enable Validate_Shutdown), then the SHUTDOWNs of otherbr subsystems won#39;t accidentally take down CP.br divdiv/divdiv class=3D"Wj3C7c"br Alan Altmarkbr z/VM Developmentbr IBM Endicottbr /div/div/blockquote/divbr --000e0cd3107ed5760d04638d16c0-- -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu
Re: Second level VM systems
On Sunday, 02/22/2009 at 11:22 EST, Jim Bohnsack jab...@cornell.edu wrote: Cornell has SHUTDOWN set as a class Z or something in SYSTEM CONFIG. Wonder why? Nevertheless, I still hate to type in SHUTDOWN. Excellent. Years of aversive conditioning worked. Those who have shutdownaphobia, having been bitten by it on one or more occasions, are fine. They have developed a healthy fear of something that can hurt them. For the newbies who haven't haven't Been There and Done That, yet, the Validate_Shutdown feature provides a measure of protection. Would that we had such luxuries back in the Olden Days, where danger lurked around every corner, and all corners had sharp edges! (And SET PRIVCLASS didn't exist, either!) [Remind me never to refer to those as the good ol' days.] Alan Altmark z/VM Development IBM Endicott
Re: Second level VM systems
I did that once bringing down RSCS, with the old IRMA emulator cards. They had a tendency to refresh the command line if you typed a lot and quickly, so one time I was typing SM RSCS SHUTDOWN, and it refreshed just in time to turn the command into SHUTDOWN. I've always solved the problem since then with redefining the SHUTDOWN command to class z, and no one gets it. But certain people have the ability to do the SET PRIVCLASS command and get it when needed. For second level systems we don't do the redefine until we are ready to put it into production. That way it's always a different process for second level, than for first. It's usually only one or two system programmers on the second level machine, it's not to much trouble to do this. Robert Reuscher Mainframe Network Development/Support (214) 477-7091 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Adam Thornton Sent: Sunday, February 22, 2009 8:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Second level VM systems On Feb 22, 2009, at 8:16 PM, Scott Rohling wrote: Yup - and DIRMAINT also uses SHUTDOWN as the command to bring it down. I suppose there's a consistency here at least ;-) I agree consistency in the case of mimicing the OS command is not the best approach. Maybe we should immediately create a NWODTUHS command to bring down CP and make SHUTDOWN an unknown CP command. Said at half in jest.. Put SHUTDOWN in its own privilege class, and have no one in that class by default. Require a Class A user to add himself to that class before running SHUTDOWN. This is more effort than I usually go to. I just put a SHUTDOWN EXEC on MAINT and OPERATOR's 191-disks (my OPERATOR runs CMS). /* Shutdown ? */ say No. Adam This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
Re: Second level VM systems
Last time I tried 3rd level guests it was fairly painful not sure what subsystem to blame. Not that I'm a z/VM guru by any means, but ... I have found the peformance of 3rd level Linux systems to be anywhere from perfectly acceptable to lethargic/downright annoying. When I'm on a system that is approaching annoying I will often do a top. Now that the steal percentage (%st) is reported, the values can be very telling. I will see steal rates in the 70-85% range. As I understand it from people who are z/VM gurus, this happens when the system is doing a lot of I/O and the third level guest has to go in and out of SIE constantly. On second level Linux systems, the steal percentage usually maxes out in the mid-single-digits. Mike MacIsaac mike...@us.ibm.com (845) 433-7061
Re: Second level VM systems
Hi, We use 2nd level VM for test, preparation of VM upgrades, etc. - in respect to that it is a VERY strong capability, which also shows the maturity of the System z virtualization. But personally I would on the other hand never consider running production in 2nd level. According to my measurement a 2nd level guest risk running many magnitudes slower than a first level guest. But it depends on the workload characteristic. If you want to see some measurements, you can refer to section 5.4 in my masters thesis: http://www2.imm.dtu.dk/pubdb/views/edoc_download.php/5483/pdf/imm5483.pdf . You'll probably find some factual inaccuracies in the thesis (it was never reviewed by VM/zLinux experts), but the measurements and numbers are correct. /Klaus Owen, Jerry W. (AITC) wrote: For all of you old timers that have used VM since it landed on Plymouth Rock, what are the pros and cons of using a second level VM system? Thanks in advance.
Re: Second level VM systems
On Fri, Feb 20, 2009 at 12:51 PM, Michael MacIsaac mike...@us.ibm.com wrote: Last time I tried 3rd level guests it was fairly painful not sure what subsystem to blame. Not that I'm a z/VM guru by any means, but ... I have found the peformance of 3rd level Linux systems to be anywhere from perfectly acceptable to lethargic/downright annoying. When I'm on a system that is approaching annoying I will often do a top. Now that the steal percentage (%st) is reported, the values can be very telling. I will see steal rates in the 70-85% range. As I understand it from people who are z/VM gurus, this happens when the system is doing a lot of I/O and the third level guest has to go in and out of SIE constantly. On second level Linux systems, the steal percentage usually maxes out in the mid-single-digits. Nor am I. The trick with V/SIE hardware support is that popular scenario's can be done with a virtual SIE exception and thus remain entirely within (the outer) SIE. When it does not, you get a real SIE intercept and outer CP gets the overhead. I plan to attend session 9273 at SHARE, that might have some data about this :-) I question the idea to blame I/O. After all, CP is already involved with I/O. And we see that doing CMS is not bad at all in a 2nd level z/VM in LPAR. The performance problem shows when you do Linux for example - I am looking at data where CP overhead is 2 seconds for each second of virtual time. When you play with virtual addressing beyond the 2 supported layers in SIE, first level CP ends up doing the old game of shadow tables etc, like what you had in the early days with VM/SP. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: Second level VM systems
For second level VM: 1. Less dedicated resources. Another LPAR requires dedicated memory. Second level VM only requires real memory when needed. 2. LPAR requires dedicated packs. Second level VM can use dedicated packs and/or minidisks from the 1st level system. (the only dedicated disk space you need for a second level VM system is the CP areas. All CMS minidisks can be shared in R/O mode and you only need to replicate the CMS disks that you intend to update. Beware of MDC when you share CMS disks in R/O mode on the second level system) 3. LPAR requires real hardware for communications. Second level VM can use VCTCA, IUCV, VSWITCH for communications. 4. LPAR requires IOCP updates to configure the LPAR, if needed. Second level VM requires a USER DIRECT update on the 1st level system. 5. In the old days, the LPAR concept was two physically different boxes. VM is much cheaper. 6. In the old days of LPAR, you couldn't share channels. Dedicated 3274/3174 for each LPAR. Two channel switches for dasd/tape. Dedicated communication channels. VM is much cheaper. 7. On an IBM 370/168 1 MB of memory ran about $1 million. VM/370 Rel 6 BSE could run in about 150 K. 8. Second level VM is for REAL VM SYSTEM PROGRAMMERS. For running in a LPAR: 1. NONE (okI'm a VM bigot) 1. It is hard to accidently shutdown your production VM system from another LPAR. At one time, we have all shutdown the production VM system when we thought we were on test. 2. A second level VM system may impact the first level paging subsystem. Can't happen with LPAR. 3. LPAR is a simpler concept. Both VM systems are running at the same level. You don't have to think about which level you are issuing commands to. 4. You get better performance of a second level system, then when running a third level system. Depending on what you are testing, this can be important. 5. LPAR does take less VM knowledge. Tom Duerbusch THD Consulting Owen, Jerry W. (AITC) jerry.o...@va.gov 2/19/2009 8:49 PM For all of you old timers that have used VM since it landed on Plymouth Rock, what are the pros and cons of using a second level VM system? Thanks in advance.
Re: Second level VM systems
Owen, Jerry W. (AITC) wrote: For all of you old timers that have used VM since it landed on Plymouth Rock, what are the pros and cons of using a second level VM system? Thanks in advance. I'd naively say that it depends on your intent purpose. --Ivan
Re: Second level VM systems
hey I arrived on the scene way after Plymouth Rock 2nd level systems are great for testing, buidling, servicing, playing, etc. And training. I do a lot of my builds and service from 2nd level guest. Also for staging new versions, etc. Due to double SIE emulation do not run 3rd level guest in production; i.e. do not use a 2nd level vm system as a home for production linux servers of any sort. linux production servers belong under vm in an lpar production = any services wanted by anyone but you David From: The IBM z/VM Operating System on behalf of Owen, Jerry W. (AITC) Sent: Thu 2/19/2009 9:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Second level VM systems For all of you old timers that have used VM since it landed on Plymouth Rock, what are the pros and cons of using a second level VM system? Thanks in advance.
Re: Second level VM systems
lpar is undoubtedly some sort of SIE. Last time I tried 3rd level guests it was fairly painful not sure what subsystem to blame. David From: The IBM z/VM Operating System on behalf of Ivan Warren Sent: Thu 2/19/2009 10:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Second level VM systems David Kreuter wrote: Due to double SIE emulation do not run 3rd level guest in production; i.e. do not use a 2nd level vm system as a home for production linux servers of any sort. linux production servers belong under vm in an lpar production = any services wanted by anyone but you Double SIE emulation ? AFAIK, the penalty for running a 3rd level VM is minimal. z/VM doesn't *emulate* SIE.. It just alters the SIEBK and redrives the SIE to the underlying level... You could be running 15 levels - and you're SIE will eventually be executed by the lowest level.. no emulation there.. no 'software' SIE ! It's even possible current implementation don't even intercept SIE (there is nothing precluding SIE from executing SIE.. SIE was never itself subject to a mandatory intercept). That was especially true for preferred guests.. *was* because we're no longer allowed preferred guests anyway.. but when they existed, even some I/Os didn't get an intercept (assuming you had SIE I/O Assist, your device was dedicated, etc, etc..). For all I know, when running in an LPAR, you're already running under SIE anyway (no doubt PR/SM uses SIE to run its LPARs !) Now.. The problem with running n Levels is probably more with I/Os.. and those privileged instructions that SIE can't handle.. --Ivan
Re: Second level VM systems
David Kreuter wrote: lpar is undoubtedly some sort of SIE. Last time I tried 3rd level guests it was fairly painful not sure what subsystem to blame. David Yeah.. Possibly.. I'd say I/O.. maybe having to deals with multiple levels of paging.. And emulating those instructions SIE can't handle.. --Ivan
