Standalone DDR hardware assigns question
My searches haven't found anything that answers this question, and perhap s only Alan will know the answer, so here goes: Does Standalone DDR (directly in an LPAR, not under z/VM) do a hardware assign release for the 3590 tape drive addresses it uses? I'm thinking ahead to an upcoming DR exercise in which while I'm running DDR native in one LPAR some z/OS images are being IPL'd in other LPARs that also have access to the same tape drive ranges. I know z/OS does th e hardware assign when it varies the drive online, and I'm wondering if tha t will negatively impact Standalone DDR's access to the tape drive it is using. Once I'm far enough along that I can run DDR under z/VM I know it won't be an issue because z/VM will do the assign when the drive is attached to a virtual machine. Brian Nielsen
Re: Standalone DDR hardware assigns question
On Monday, 04/05/2010 at 01:19 EDT, Brian Nielsen bniel...@sco.idaho.gov wrote: Does Standalone DDR (directly in an LPAR, not under z/VM) do a hardware assign release for the 3590 tape drive addresses it uses? Yes. When running standalone, drives are assigned on first use and unassigned at EOJ. I'm thinking ahead to an upcoming DR exercise in which while I'm running DDR native in one LPAR some z/OS images are being IPL'd in other LPARs that also have access to the same tape drive ranges. I know z/OS does the hardware assign when it varies the drive online, and I'm wondering if that will negatively impact Standalone DDR's access to the tape drive it is using. Once I'm far enough along that I can run DDR under z/VM I know it won't be an issue because z/VM will do the assign when the drive is attached to a virtual machine. Yes, it will be an impact; MVS has to unassign the drives that DDR wants to use, if he has already assigned them (first one up wins). If you have z/VM up and a good quality tape management product running, it can talk to z/OS and get the drives unassigned, depending on what tape management software you have running on z/OS. For SA DDR, you will have to manually take them offline from MVS before you run DDR. Alan Altmark z/VM Development IBM Endicott
Re: acm/vmware
Gabe, you know how much I hate getting pulled into these discussions. :-) First, I totally agree that both the zJournal and IBM's S.M. provide a lot of information and support for the mainframe. I also appreciate how difficult it is to get customers to discuss their efforts due to their own internal restrictions, which is one of the reasons that I have a lot of respect for the staff at both publications. They do a lot of good for this business (customers and vendors). However, I feel we (IBM included) could be doing some things a little better. I see very little IBM involvement or investment in selling the mainframe - z/VM story. The publications are completely separate operations non-IBM entities. Outside of conferences and other user meetings/councils, you seldom hear anything about the z/VM - Linux message.When you do see an article about Linux on System z (IBM's mainframe strategy), you must search for the line that mentions z/VM as the platform supporting Linux. For example, check the latest edition of IBM System Magazine (March/April). One article is titled zOS Storage the Omegamon Way. Conversely, in the Linux on z story, z/VM is mentioned on the bottom of the last page as almost an oh by the way. What I find unfortunate, yet consistent, is IBM's business-as-usual approach when it comes to z/VM and the often feeble (if any) attempt of connecting it with whatever is being sold as today's mainframe message. Involvement is another issue. Very few VM types are permited to attend conferences. Like Barton mentioned, I find it more than a little odd when you show up at predominantly mainframe events and find several sessions for VMWare and none for z/VM or even System z. You gotta wonder what's going on when that happens. We hear a lot these days about virtualization, dynamic infrastructure, cloud, and whatever else is being touted as this weeks razzle dazzle phrase. All too often it's from chart pushers that learned a week ago what it was and how to spell it. Outside of some very knowledgeable customers, there were fewer than 6 IBMers at the Seattle SHARE that could present virtualization-cloud-mainframe and how they all fit into IBM's strategy. Very few people have that unique understanding, history, and passion for the platform. We need more of them present at conferences like CMG. Frankly, we need more of them... period. Maybe I missed it some place, but I'd like to see more substance and less razzle dazzle. (Speaking of razzle dazzle, I'd appreciate it if you guys didn't mention any of my presentations..) Anyway, I haven't seen that direction/substance/whatever in any recent key notes or journal articles. But, it could be I need to dig further than the last paragraph of the last page. Regards, Len Diegel In a message dated 4/4/2010 1:07:11 P.M. Central Daylight Time, g...@gabegold.com writes: Right. Mainframe stories (profiles, business cases, success stories, white papers, they have many names) appear in such places as z/Journal (with a technical slant), Mainframe Executive (aimed at management), IBM's Web site, IBM's Systems Magazine (Mainframe Edition), and other industry publications. For a while, I edited and wrote IBM's magazine S/390 VM and VSE Solutions Journal (subtitled Success stories for today's business). And of course, hardware/software vendors sometimes commission customer writeups highlighting their products' contributions to the (successful, long-lived, cost-effective, blah, blah, but still valid) mainframe ecosystem. But it's generally tough recruiting profile subjects, even though the process isn't burdensome or threatening. Sites can give enough detail to convincingly demonstrate (not describe or explain, there's a difference) why mainframes have been valuable to them. But proprietary/competitive/sensitive information need not be included. It's not investigative journalism and profile authors aren't 60 Minutes' Mike Wallace. The key to a good profile is simply a good story -- describing a problem solved, economies achieved, growth sustained, reliability maintained, industry leadership developed, etc. Or, simply nuts-and-bolts, bread-and-butter (insert your own cliche here...) company operation supported by mainframes. Profiles work for small/medium/large companies; they need diversity (geographic, industry, products/services, customers, etc.). There's usually an angle that works for story hooks; what matters is being willing to step up and be visible as a success story. So the next time an industry journalist calls for volunteers, step forward. So, Barton -- which of YOUR customers need profiling today? ;-) Barton opined, wisely: It doesn't matter if our mousetrap is better if nobody is out there trying to get mindshare (marketing). Preaching/grumbling to the choir doesn't change anything.
Re: Standalone DDR hardware assigns question
On Mon, 5 Apr 2010 14:01:32 -0400, Alan Altmark alan_altm...@us.ibm.com wrote: On Monday, 04/05/2010 at 01:19 EDT, Brian Nielsen bniel...@sco.idaho.go V wrote: Does Standalone DDR (directly in an LPAR, not under z/VM) do a hardwar e assign release for the 3590 tape drive addresses it uses? Yes. When running standalone, drives are assigned on first use and unassigned at EOJ. Thanks. Exactly what I needed to know, and as I hoped. Brian Nielsen
Re: acm/vmware
No argument here. One reason it is so tough is that some shops would require that every word pass through a legal department filter. His makes the real burden one of distinguishing between dragons and windmills. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Gabe Goldberg Sent: Sunday, April 04, 2010 11:07 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: acm/vmware But it's generally tough recruiting profile subjects, even though the process isn't burdensome or threatening. Sites can give enough detail to convincingly demonstrate (not describe or explain, there's a difference) why mainframes have been valuable to them. But proprietary/competitive/sensitive information need not be included. It's not investigative journalism and profile authors aren't 60 Minutes' Mike Wallace.
HiperSocket UCBs
Hi I have a bit of a delima. We do a lot of talking from our z/OS system over to our z/VM z/Linux systems via HiperSockets. We have a request for about 20 more z/Linux guests all of which will have two HiperSockets CHPIDs (3 UCBS per guest off of the different CHPIDS). The issue is that I am using pretty much the max number of UCBs allowed. So I was wondering what folks are doing when they have these requirements but are at the max of allowable addresses within the HiperSockets CHPIDs. I know that I can share the spanned HiperSockets CHPIDs across different LPARS using the same UCBs as the other LPARS as long as I do not re-use them on the same LPAR I am ok. So maybe the way to go is to create another LPAR or two I don't know? Any help would be appreciated. Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191
Re: HiperSocket UCBs
Create a Linux guest as a L2 bridge between a VSWITCH and the hipersocket. Only one HS UCB used, and you still get separation. You can use VLANs to separate traffic.
Re: HiperSocket UCBs
David, Are there any performance implications with doing it this way as opposed to HiperSocket directly to each guest? Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Monday, April 05, 2010 4:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSocket UCBs Create a Linux guest as a L2 bridge between a VSWITCH and the hipersocket. Only one HS UCB used, and you still get separation. You can use VLANs to separate traffic.
Re: HiperSocket UCBs
Why not put the z/Linux systems on a VSWITCH with the z/OS system? No more UCB problems. One set of UCBs to the VSWITCH in each guest. Oh, z/OS is not under z/VM. Well, VSWITCH the z/Linux systems along with the z/VM TCPIP stack, then hipersocket the z/VM TCPIP stack with z/OS. I'm not too familar with this, but I'm sure that this, or something close to it, would address your needs. The only minus is the single point of failure in the z/VM TCPIP stack. But that is fairly low risk. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-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 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Monday, April 05, 2010 2:52 PM To: IBMVM@LISTSERV.UARK.EDU Subject: HiperSocket UCBs Hi I have a bit of a delima. We do a lot of talking from our z/OS system over to our z/VM z/Linux systems via HiperSockets. We have a request for about 20 more z/Linux guests all of which will have two HiperSockets CHPIDs (3 UCBS per guest off of the different CHPIDS). The issue is that I am using pretty much the max number of UCBs allowed. So I was wondering what folks are doing when they have these requirements but are at the max of allowable addresses within the HiperSockets CHPIDs. I know that I can share the spanned HiperSockets CHPIDs across different LPARS using the same UCBs as the other LPARS as long as I do not re-use them on the same LPAR I am ok. So maybe the way to go is to create another LPAR or two I don't know? Any help would be appreciated. Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 [cid:image002.jpg@01CAD4D7.09654790]
Re: HiperSocket UCBs
Are there any performance implications with doing it this way as opposed to HiperSocket directly to each guest? Yes - I'll leave it to others to quantify it exactly, but it will use a non-zero amount of 390 CPU to do the packet forwarding between interfaces. Since there is no external connection to the hipersocket, you can't offload the routing or switching to a non-390 CPU. (Another reason IBM should have convinced Cisco/Nortel to produce a bus-attached router similar to the chassis router module they developed for the BladeCenter to put in a Z. ) Another option is to use a dedicated 10G OSA for this traffic on both LPARs and connect the two physical ports to an external dedicated switch. That has a much smaller internal CPU overhead, but it's certainly not cheap. The CPU used to drive the adapters and do the data moving is accounted against CP, not a individual virtual machine, AFAICT. Hipersockets (and any attached device strategy) doesn't work well for massive scale. You just can't install enough of them for a big farm, so you have to start using virtual tricks. You're probably on a z10, so here's another idea - try defining a L2 VSWITCH using a hipersocket device - I faintly remember reading somewhere that hipersockets got L2 capabilities at some point. I don't know if it'll work(never tried it), but if if will, then use that instead of individual UCBs attached to guests. Define 2-3 UCBs to the VSWITCH just in case (although if a HS device fails, you're already in deep something), and use VLANs to separate the traffic. n Db n
Re: HiperSocket UCBs
On Monday, 04/05/2010 at 03:55 EDT, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: I have a bit of a delima. We do a lot of talking from our z/OS system over to our z/VM z/Linux systems via HiperSockets. We have a request for about 20 more z/Linux guests all of which will have two HiperSockets CHPIDs (3 UCBS per guest off of the different CHPIDS). The issue is that I am using pretty much the max number of UCBs allowed. So I was wondering what folks are doing when they have these requirements but are at the max of allowable addresses within the HiperSockets CHPIDs. I know that I can share the spanned HiperSockets CHPIDs across different LPARS using the same UCBs as the other LPARS as long as I do not re-use them on the same LPAR I am ok. So maybe the way to go is to create another LPAR or two I don?t know? Any help would be appreciated. You have - 16 HiperSocket chpids available - 64 control units per chpid - 256 devices (subchannels) per control unit - Providing up to 12K devices, spread across 16 chpids or all in one. - Yielding up to 4096 NICs Are you sure you're up against a HiperSocket maximum? If you have 4096 NICs, consider using VLANs. Alan Altmark z/VM Development IBM Endicott
Re: HiperSocket UCBs
-Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Monday, April 05, 2010 3:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSocket UCBs snip You have - 16 HiperSocket chpids available - 64 control units per chpid - 256 devices (subchannels) per control unit - Providing up to 12K devices, spread across 16 chpids or all in one. - Yielding up to 4096 NICs Are you sure you're up against a HiperSocket maximum? If you have 4096 NICs, consider using VLANs. Alan Altmark z/VM Development IBM Endicott Probably running into a limitation on the number of UCBs in a single z/OS LPAR. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-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: HiperSocket UCBs
On Monday, 04/05/2010 at 04:24 EDT, David Boyes dbo...@sinenomine.net wrote: You?re probably on a z10, so here?s another idea ? try defining a L2 VSWITCH using a hipersocket device ? I faintly remember reading somewhere that hipersockets got L2 capabilities at some point. I don?t know if it?ll work(never tried it), but if if will, then use that instead of individual UCBs attached to guests. Define 2-3 UCBs to the VSWITCH just in case (although if a HS device fails, you?re already in deep something), and use VLANs to separate the traffic. The VSWITCH does not support attachment of HiperSockets. Alan Altmark z/VM Development IBM Endicott
Re: HiperSocket UCBs
Not sure about using it with z/OS -- but wonder if a 'disconnected' OSA could be shared across the LPARs? We went this route to provide a 'backup network' across several z/VM LPARs.. the advantage over hipersockets being: - Less management of UCB's (just connect to the vswitch) - Overhead for network traffic is offloaded to the OSA rather than using CPU Scott Rohling On Mon, Apr 5, 2010 at 2:23 PM, David Boyes dbo...@sinenomine.net wrote: Are there any performance implications with doing it this way as opposed to HiperSocket directly to each guest? Yes – I’ll leave it to others to quantify it exactly, but it will use a non-zero amount of 390 CPU to do the packet forwarding between interfaces. Since there is no external connection to the hipersocket, you can’t offload the routing or switching to a non-390 CPU. (Another reason IBM should have convinced Cisco/Nortel to produce a bus-attached router similar to the chassis router module they developed for the BladeCenter to put in a Z. ) Another option is to use a dedicated 10G OSA for this traffic on both LPARs and connect the two physical ports to an external dedicated switch. That has a much smaller internal CPU overhead, but it’s certainly not cheap. The CPU used to drive the adapters and do the data moving is accounted against CP, not a individual virtual machine, AFAICT. Hipersockets (and any attached device strategy) doesn’t work well for massive scale. You just can’t install enough of them for a big farm, so you have to start using virtual tricks. You’re probably on a z10, so here’s another idea – try defining a L2 VSWITCH using a hipersocket device – I faintly remember reading somewhere that hipersockets got L2 capabilities at some point. I don’t know if it’ll work(never tried it), but if if will, then use that instead of individual UCBs attached to guests. Define 2-3 UCBs to the VSWITCH just in case (although if a HS device fails, you’re already in deep something), and use VLANs to separate the traffic. n Db n
Re: HiperSocket UCBs
-Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Monday, April 05, 2010 3:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSocket UCBs snip The VSWITCH does not support attachment of HiperSockets. Alan Altmark z/VM Development IBM Endicott So you'd need a router machine to talk between the hipersocket to z/OS and the VSWITCH, right? -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-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: HiperSocket UCBs
The VSWITCH does not support attachment of HiperSockets. You should fix that. Where's my requirement pad? 8-) -- d b
Re: HiperSocket UCBs
Hi, Terry. You might want to take a look at the SHARE presentation Sharing the Wealth Using Vlans on Vswitch. It discusses how to set up VSWITCH and hipersockets configuration similar to what you are describing. If you can't snag a copy, I can send it to you. Have a good one. On 04/05/2010 02:51 PM, Martin, Terry R. (CMS/CTR) (CTR) wrote: Hi I have a bit of a delima. We do a lot of talking from our z/OS system over to our z/VM z/Linux systems via HiperSockets. We have a request for about 20 more z/Linux guests all of which will have two HiperSockets CHPIDs (3 UCBS per guest off of the different CHPIDS). The issue is that I am using pretty much the max number of UCBs allowed. So I was wondering what folks are doing when they have these requirements but are at the max of allowable addresses within the HiperSockets CHPIDs. I know that I can share the spanned HiperSockets CHPIDs across different LPARS using the same UCBs as the other LPARS as long as I do not re-use them on the same LPAR I am ok. So maybe the way to go is to create another LPAR or two I don't know? Any help would be appreciated. Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: HiperSocket UCBs
On Monday, 04/05/2010 at 04:35 EDT, McKown, John john.mck...@healthmarkets.com wrote: So you'd need a router machine to talk between the hipersocket to z/OS and the VSWITCH, right? Yes, which undoes all the performance benefit of HiperSockets by funneling all the traffic through a single guest. z/OS needs only 3 addresses per HiperSocket chpid, so I don't understand why adding more guests to existing chpids is creating a z/OS problem. Alan Altmark z/VM Development IBM Endicott
Re: HiperSocket UCBs
Dave, If have a copy that would great! Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dave Jones Sent: Monday, April 05, 2010 4:47 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSocket UCBs Hi, Terry. You might want to take a look at the SHARE presentation Sharing the Wealth Using Vlans on Vswitch. It discusses how to set up VSWITCH and hipersockets configuration similar to what you are describing. If you can't snag a copy, I can send it to you. Have a good one. On 04/05/2010 02:51 PM, Martin, Terry R. (CMS/CTR) (CTR) wrote: Hi I have a bit of a delima. We do a lot of talking from our z/OS system over to our z/VM z/Linux systems via HiperSockets. We have a request for about 20 more z/Linux guests all of which will have two HiperSockets CHPIDs (3 UCBS per guest off of the different CHPIDS). The issue is that I am using pretty much the max number of UCBs allowed. So I was wondering what folks are doing when they have these requirements but are at the max of allowable addresses within the HiperSockets CHPIDs. I know that I can share the spanned HiperSockets CHPIDs across different LPARS using the same UCBs as the other LPARS as long as I do not re-use them on the same LPAR I am ok. So maybe the way to go is to create another LPAR or two I don't know? Any help would be appreciated. Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -- Dave Jones V/Soft www.vsoft-software.com Houston, TX 281.578.7544
Re: HiperSocket UCBs
Yes this is correct Probably running into a limitation on the number of UCBs in a single z/OS LPAR. Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of McKown, John Sent: Monday, April 05, 2010 4:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSocket UCBs -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Monday, April 05, 2010 3:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSocket UCBs snip You have - 16 HiperSocket chpids available - 64 control units per chpid - 256 devices (subchannels) per control unit - Providing up to 12K devices, spread across 16 chpids or all in one. - Yielding up to 4096 NICs Are you sure you're up against a HiperSocket maximum? If you have 4096 NICs, consider using VLANs. Alan Altmark z/VM Development IBM Endicott Probably running into a limitation on the number of UCBs in a single z/OS LPAR. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-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: acm/vmware
Well we have to all remember that z/VM, z/OS and the like are all niche markets. I love to go the MVMUG (NYC area) and hear IBM people tell us about the wonderful things that z/VM is doing and what it will do in the future, but we all have to keep in mind that relatively speaking mainframes are few and far between. However, after MVMUG IBM presentations, some how it still gives me hope that z/VM will survive well into the future in one form or another. --- On Mon, 4/5/10, Schuh, Richard rsc...@visa.com wrote: From: Schuh, Richard rsc...@visa.com Subject: Re: acm/vmware To: IBMVM@LISTSERV.UARK.EDU Date: Monday, April 5, 2010, 3:11 PM No argument here. One reason it is so tough is that some shops would require that every word pass through a legal department filter. His makes the real burden one of distinguishing between dragons and windmills. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Gabe Goldberg Sent: Sunday, April 04, 2010 11:07 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: acm/vmware But it's generally tough recruiting profile subjects, even though the process isn't burdensome or threatening. Sites can give enough detail to convincingly demonstrate (not describe or explain, there's a difference) why mainframes have been valuable to them. But proprietary/competitive/sensitive information need not be included. It's not investigative journalism and profile authors aren't 60 Minutes' Mike Wallace.
Re: HiperSocket UCBs
It is not a z/OS problem it is that I am running out of UCBs on the HiperSockets CHPID on an individual LPAR. Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Monday, April 05, 2010 4:48 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSocket UCBs On Monday, 04/05/2010 at 04:35 EDT, McKown, John john.mck...@healthmarkets.com wrote: So you'd need a router machine to talk between the hipersocket to z/OS and the VSWITCH, right? Yes, which undoes all the performance benefit of HiperSockets by funneling all the traffic through a single guest. z/OS needs only 3 addresses per HiperSocket chpid, so I don't understand why adding more guests to existing chpids is creating a z/OS problem. Alan Altmark z/VM Development IBM Endicott
Re: HiperSocket UCBs
-Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Monday, April 05, 2010 3:48 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSocket UCBs On Monday, 04/05/2010 at 04:35 EDT, McKown, John john.mck...@healthmarkets.com wrote: So you'd need a router machine to talk between the hipersocket to z/OS and the VSWITCH, right? Yes, which undoes all the performance benefit of HiperSockets by funneling all the traffic through a single guest. z/OS needs only 3 addresses per HiperSocket chpid, so I don't understand why adding more guests to existing chpids is creating a z/OS problem. Alan Altmark z/VM Development IBM Endicott My brain has apparently left, leaving no forwarding address. grin/ You're right. There should only be a need for one set of z/OS UCB addresses to connect to each hipersocket CHPID. For some reason my brain was [not]thinking it was one set per z/Linux connection. But a hipersocket acts like a LAN connection, so everybody on the same CHPID cross communicates. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-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: HiperSocket UCBs
On Mon, Apr 5, 2010 at 10:47 PM, Alan Altmark alan_altm...@us.ibm.com wrote: On Monday, 04/05/2010 at 04:35 EDT, McKown, John john.mck...@healthmarkets.com wrote: So you'd need a router machine to talk between the hipersocket to z/OS and the VSWITCH, right? Yes, which undoes all the performance benefit of HiperSockets by funneling all the traffic through a single guest. And don't forget that talking to a virtual NIC is more expensive than to a real subchannel. z/OS needs only 3 addresses per HiperSocket chpid, so I don't understand why adding more guests to existing chpids is creating a z/OS problem. Right. And giving z/OS access to an OSA chpid takes approximately the same number of UCB's... There's several other situations where you should not use hipersockets, but this can't be an issue. Looks to me someone is trying to find a problem for his solution... Rob
Re: HiperSocket UCBs
On 4/5/2010 at 04:51 PM, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Yes this is correct Probably running into a limitation on the number of UCBs in a single z/OS LPAR. If you're thinking you need to define a new HiperSocket triplet to z/OS for each Linux guest added to your z/VM LPAR, that's not correct. Mark Post
Re: CP's Parm Disks
Sorry to be late on this but Mikethis one is a keeper. Thanks for the bits... --- On Fri, 3/5/10, Mike Walter mike.wal...@hewitt.com wrote: From: Mike Walter mike.wal...@hewitt.com Subject: Re: CP's Parm Disks To: IBMVM@LISTSERV.UARK.EDU Date: Friday, March 5, 2010, 10:45 AM There any many ways to do this, each with their own merits. Understanding how SERVICE and PUT2PROD silently update the CF1 and CF2 disks is important. I prefer to think of CF2 as a resource to be used only if CF1 gets trashed (my human, hardware, or any other error). I wrote a local EXEC to keep CF1 and CF2 synched (other that SYSTEM CONFIG there are not a lot of frequent changes),. Instead of making he CF2 the regular backup, I COPY the old SYSTEM CONFIG to -1SYSTEM CONFIG (with rolling renames up to -9SYSTEM CONFIG so we can go back up to 9 changes). Same with CPLOAD MODULE as -1CPLOAD MODULE, and any other changes files although they are handled manually since there are far fewer changes to them. That local exec also automatically runs CPSYNTAX on the new SYSTEM CONFIG file before exiting, providing clear warnings if it did not end normally. Hint: you *do* faithfully run CPSYNTAX after *every* SYSTEM CONFIG file change, even 1-lines', right? If the Operator needs to back out for some reason, they are instructed to call z/VM support first. We don't want them blindly backing out an important change without involving someone who might instead take corrective action. If they need to back out a changed file, we explain how to do so by IPLing with LOADPARM rdev and using SALIPL to select from the various backup -nSYSTEM CONFIG or -nCPLOAD MODULEs. IBM's method of copying CF1 to CF2 (SERVICE (?) and PUT2PROD) only provides one backout layer. So far our operators have never needed to use the CF2 disk. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. Lesseg, Jon jon.les...@pacificorp.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/05/2010 09:11 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: CP's Parm Disks Bill, Thanks for clarifying this. The SERVICE and PUT2PROD is still a black box for me at this time. I'll keep my own copies of SYSTEM CONFIG pre changes also. It's nice to know there are knowledgeable folks with real world experience out there to bounce questions to. This may be just the beginning of a bunch of questions to the list as I work to get my head around this VM creature. Thanks again. Jon L -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bill Munson Sent: Friday, March 05, 2010 5:03 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CP's Parm Disks Jon, When you update anything on CF1 it is CURRENT for the next IPL. the parm disks CF2 and CF3 are backup disks that you can IPL from if you need to GO BACK for any reason. I would not copy anything from CF1 to CF2 or CF3 myself. When you apply SERVICE and PUT2PROD this will copy CF1 to CF2 to be used as the new back up and CF2 is copied to CF3. I believe that is the correct order anyway it is copied for you by the Service process and that is the answer to your original question. good luck Bill Munson Sr. z/VM Systems Programmer Brown Brothers Harriman CO. 525 Washington Blvd. Jersey City, NJ 07310 201-418-7588 President - MVMUA http://www2.marist.edu/~mvmua/ VM Project Officer - SHARE http://seattle.share.org/joinme http://www.linkedin.com/in/BillMunson Lesseg, Jon jon.les...@pacificorp.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/04/2010 05:28 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject CP's Parm Disks This is probably a bonehead question, so please have patience as I?m new to VM. When I update SYSTEM CONFIG on MNTCF1 after releasing and linking and setting access, am I responsible to update the copies on MNTCF2 MNTCF3 after I?m comfortable with the results using something like COPYFILE or is it maintained for me? Q CPD Label Userid Vdev Mode Stat Vol-ID Rdev Type StartLoc EndLoc MNTCF1 MAINT 0CF1 A R/O 520RES FF0C CKD 39 158 MNTCF2 MAINT 0CF2 B R/O 520RES FF0C CKD 159 278 MNTCF3 MAINT 0CF3 C R/O 520RES FF0C CKD 279 398 THX, Jon L. -- This email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe
Brett Walker/WLG/BNZ/NAG_AP is out of the office.
I will be out of the office starting 06/04/2010 and will return on 12/04/2010. CAUTION - This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. This email was sent by the Bank of New Zealand. You can contact us on 0800 ASK BNZ (0800 275 269). Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Bank of New Zealand.
Re: HiperSocket UCBs
No, that is not what I was thinking. I have been using HiperSockets extensively and I am familiar with how they work. Each guest that needs to talk to z/OS needs a Triplet UCB definition on a HiperSocket CHPID defined to it. The more guest I have that require this the more UCBs I need to use, eventually I hit the max UCBs allowed on a CHPID. For the best performance a HiperSocket interface is defined on the z/Linux guest without going through the VLAN. This interface connects to the HiperSocket network defined on the z/OS system and data is passed at memory speeds. To get around this I could create another LPAR since the same spanned HiperSockets UCB can be used on different LPARS just not on the same LPAR. I am still on a z9 but our new z10 was just delivered and I understand that the z10 allows for more HiperSocket UCBs so maybe this will be a non issue with the z10. I am still trying to nail this down. Thanks for the responses. I will try to pursue this with my IBM representatives and will let the list know what I find! Thank You, Terry Martin Lockheed Martin - Citic z/OS and z/VM Performance Tuning and Operating Systems Support Office - 443 348-2102 Cell - 443 632-4191 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mark Post Sent: Monday, April 05, 2010 5:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: HiperSocket UCBs On 4/5/2010 at 04:51 PM, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Yes this is correct Probably running into a limitation on the number of UCBs in a single z/OS LPAR. If you're thinking you need to define a new HiperSocket triplet to z/OS for each Linux guest added to your z/VM LPAR, that's not correct. Mark Post
Re: HiperSocket UCBs
On Monday, 04/05/2010 at 10:42 EDT, Martin, Terry R. (CMS/CTR) (CTR) terry.mar...@cms.hhs.gov wrote: Each guest that needs to talk to z/OS needs a Triplet UCB definition on a HiperSocket CHPID defined to it. The more guest I have that require this the more UCBs I need to use, eventually I hit the max UCBs allowed on a CHPID. For the best performance a HiperSocket interface is defined on the z/Linux guest without going through the VLAN. This interface connects to the HiperSocket network defined on the z/OS system and data is passed at memory speeds. Terry, I'm still having trouble believing that you have 4096 NICs (12,228 UAs/subchannels/UCBs) defined for your HiperSockets chpids. Can you confirm? To get around this I could create another LPAR since the same spanned HiperSockets UCB can be used on different LPARS just not on the same LPAR. If you *have* maxed out HiperSockets, new LPARs aren't going to help. You can't have more than 12K HiperSocket subchannels on the box. I suspect your problem is that you're wasting subchannels across all LPARs. (1) Make sure you are coding PARTITION= on the CHPID to limit subchannel definition to only the LPARs that are permitted to use the chpid. (2) Create as many CNTLUNITs for your HiperSocket chpids as you need. Remember that all the devices on a single CU must be shared or unshared. z/OS will need access to one CNTLUNIT per HiperSocket chpid it needs access to. The other 48 control units will be given to z/VM. (3) On the CUs for z/OS, use PARTITION= on the IODEVICE to limit the definition to z/OS. (4) For the remaining HiperSocket CUs, use PARTITION= (5) Define only 3 IODEVICEs for each z/OS CNTLUNIT Do the UNITADD math. I am still on a z9 but our new z10 was just delivered and I understand that the z10 allows for more HiperSocket UCBs so maybe this will be a non issue with the z10. I am still trying to nail this down. z9 and z10 are the same, both having 16 HiperSocket chpids. When in doubt, check the Machine Limits appendix in the IOCP book. Alan Altmark z/VM Development IBM Endicott
