Hi Brian. The fact you are planning on using HATS (Host Access Transformation services?) means you will be accessing 3270 screens, from a browser (IE or Firefox). This also means you are also running conventional (1 or more CP processors) for your CICS? (z/OS or z/VSE) system. You mentioned that you are now supporting two z/VM systems. I'm guessing management wants to buy one z9 with one or more CP engines to replace your old equipment running your conventional OS and at the same time purchase 4 IFL for new z/LINUX workload.
HATS is a WebSphere application and in your case WebSphere will be running in LINUX on an LPAR with 1 or more IFL engines. The number of IFLs will depend on the number of concurrent 3270 session you plan to support. You can run LINUX on bare metal (LPAR) without VM but that would NOT be my first choice. I'm guessing that NOT all IFL engines are planned for HATS but rather for future consolidation of LINUX or UNIX servers to z/VM LINUX. If you plan to have general z/LINUX servers on z/VM than you may create one LPAR and one VM for the remaining 3 IFL engines. BUT more than likely you'll want to run DB2, ORACLE or other applications and then the license charges for those applications come in play which if I recall is based on the number of IFLs in an LPAR. Now you need to decide (create business case to see which is more cost effective) how many LPARs and VM images you wish to run. The VM price will always be the same for 3 LPARS with one dedicated IFL each or 1 LPAR with 3 IFL engines. Most vendors will now consider an LPAR as a physical box and only charge you for the engines dedicated to it. If you start sharing engines between LPARs consider being charged for all shared engines too. You have an interesting opportunity here and you have received a lot of comments from the list. It's a lot to digest in one day but keep asking. Good luck. Hans Rempel _____ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Brian France Sent: November 21, 2007 2:47 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IFL's, VM, Suse, OH MY... Tom, Yes, I have forwarded Malcoms' info and links to management to look at. We are still way to new to VM to consider what I know as qualified but alas, I am the systems programmer for better or worse. SO, I must ask, are you stating below that I can share a RES vol with multiple VM LPARs? I have no idea what you mean by the CP areas being what I need multiple copies of. I have to ass/u/me you are referring to some minidisks. I currently maintain two VM systems, one on each frame. They are kept completely separate since one is prod and one is test. I learned from an IBM'er how to rename vols and change parms to have a 520res, 520spl, and 520pag along with a VM7RES, VM7SPL, and VM7PAG. I figured I'd have to create another set of these. So, if I understood you correctly, would you please point me to some RTFM material that I could peruse and hopefully put to use. At 02:28 PM 11/21/2007, Tom Duerbusch wrote: >From a VM dasd side....it is a trade off between having a qualified VM Systems Programmer available, vs the costs of the additional packs. The vast majority of RES and WK1 packs are used to build and maintain VM. You only need 1 copy of that. The CP areas is the only areas that you need a copy per copy of VM running. (you might want to add a copy of MAINT's 191 to that, but it really isn't necessary). Now, is it worth it? Not really. DASD is really cheap nowadays. But if you don't have the dasd available, then the next pack is rather expensive <G>. However, based on what Malcolm sent about subcapacity licensing for zLinux, that looks like the way to go and it will solve your concerns about multiple VM systems. Tom Duerbusch THD Consulting Law of Cat Stretching A cat will stretch to a distance proportional to the length of the nap just taken. >>> Brian France <[EMAIL PROTECTED]> 11/21/2007 12:51 PM >>> At 12:54 PM 11/21/2007, you wrote: >Some of us to complain about that. That is, those of us that only >use a part of an engine. > >On the other side, the cost of HATS on an IFL, on a per engine >basis, is the same as the cost of an Intel engine (right?). So, in >other words, the costs are the same... You just get more on our >platform <G>. Management is use to it. Costs I don't care much about. BUT from an admin point of view, IF I have to run this product on it's own z/VM lpar, now I have to create a another VM system using at least 3 volumes JUST for VM. I have to set up another set of volumes for my shared root system instead of being able to use my existing setup. NOT that I'm trying to support the moped environment, but to run on a mainframe I should be afforded the ability to run as suggested, limiting a machine to one IFL virtually. >The bigger problem is as you scale up the number of IFLs in a single >box. And if you also scale up the number of packages >used. Eventually, you need to buy separate boxes to keep software >costs down as you add IFL engines. BUT here again, building more VM's using up more dasd and from to me a maint nightmare. BUT, it still beats the moped world... >That is where talking to the venders so you don't get charged for >every engine "can" come into play. I've heard it works, but I have >no direct experience. I'll try to let y'all know how my management makes out. >Tom Duerbusch >THD Consulting > > >Law of Cat Stretching > > A cat will stretch to a distance proportional to the length of > the nap just taken. > > > >>> "McKown, John" <[EMAIL PROTECTED]> 11/21/2007 10:49 AM >>> >My mistake. The OP did says "keep costs down". Which the MACHINE >directive will not do. It would only keep the CPU used by the HATS guest >from exceeding a single IFL. The only way to "keep the costs down" (i.e. >software licensing fees) is to remove an IFL entirely. I don't think >that having multiple z/VMs in separate LPARs would reduce the software >cost either. > >One of my main complaints about licensing by number of processors or >"power" of the processor is this. The HATS license (and most others) >will be the same given the same hardware configuration, even if it only >use 5% of the CPU resource (with the other 95% being used by in-house >applications). I would prefer a "consumption" license based on usage. Or >perhaps a base license price for the product, irrespective of the >processor, then an "add on" cost for normally scheduled maintenance, >then perhaps a "per incident" cost for ad-hoc support. But people would >complain about that as well, I guess. > > >-- >John McKown >Senior Systems Programmer >HealthMarkets >Keeping the Promise of Affordable Coverage >Administrative Services Group >Information Technology > >This message (including any attachments) contains confidential >information intended for a specific individual and purpose, and its >content is protected by law. If you are not the intended recipient, you >should delete this message and are hereby notified that any disclosure, >copying, or distribution of this transmission, or taking any action >based on it, is strictly prohibited. > > > -----Original Message----- > From: The IBM z/VM Operating System >[ <mailto:IBMVM@LISTSERV.UARK.EDU> mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Wednesday, November 21, 2007 10:39 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: IFL's, VM, Suse, OH MY... > > > > Note that although this works from a technical point of view, >from a product licensing point of view, it likely would not. Vendors >tend to be very picky when it comes to money, and would likely only be >happy if the product was running in an LPAR with one IFL assigned to it. >If the vendor is not too familiar with mainframes, I wouldn't be >surprised to have them insist it be installed on a z9 equipped with only >1 IFL. > > > > Peter > > > > -----Original Message----- > From: The IBM z/VM Operating System >[ <mailto:IBMVM@LISTSERV.UARK.EDU> mailto:[EMAIL PROTECTED] On Behalf Of McKown, John > Sent: November 21, 2007 11:32 > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: IFL's, VM, Suse, OH MY... > > > > Correct. > > > > USER HATS > > MACHINE ESA 1 > > ... other stuff > > > > will define a z/VM guest called HATS which only has a single CPU >assigned to it. > > > > ref: > > > > > <http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/hcsg0b20/3.2> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/hcsg0b20/3.2 . >35 > > > > > > > > -- > John McKown > Senior Systems Programmer > HealthMarkets > Keeping the Promise of Affordable Coverage > Administrative Services Group > Information Technology > > This message (including any attachments) contains confidential >information intended for a specific individual and purpose, and its >content is protected by law. If you are not the intended recipient, you >should delete this message and are hereby notified that any disclosure, >copying, or distribution of this transmission, or taking any action >based on it, is strictly prohibited. > > > -----Original Message----- > From: The IBM z/VM Operating System >[ <mailto:IBMVM@LISTSERV.UARK.EDU> mailto:[EMAIL PROTECTED] On Behalf Of Brian France > Sent: Wednesday, November 21, 2007 10:27 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: IFL's, VM, Suse, OH MY... > > John, > Yes, HATS run on MainFrameLinux using WAS. So, do I >understand you in that I can assign two IFL's to my VM, and most of my >MFL's could have access to both IFL's except for the MFL that runs HATS? >I somehow assign a cpu to it in my USER DIRECT statements? > > At 11:03 AM 11/21/2007, McKown, John wrote: > > > > If HATS runs on Linux, then you could have a dedicated >Linux guest for HATS. And in z/VM, you could assign a single virtual CPU >to that Linux instance. That would restrict the HATS Linux system to run >on a single CPU at a time (might switch from CPU to CPU, but only use >one). > > > > -- > John McKown > Senior Systems Programmer > HealthMarkets > Keeping the Promise of Affordable Coverage > Administrative Services Group > Information Technology > > This message (including any attachments) contains >confidential information intended for a specific individual and purpose, >and its content is protected by law. If you are not the intended >recipient, you should delete this message and are hereby notified that >any disclosure, copying, or distribution of this transmission, or taking >any action based on it, is strictly prohibited. > > > -----Original Message----- > > From: The IBM z/VM Operating System [ > <mailto:IBMVM@LISTSERV.UARK.EDU> mailto:IBMVM@LISTSERV.UARK.EDU < mailto:IBMVM@LISTSERV.UARK.EDU <mailto:IBMVM@LISTSERV.UARK.EDU> > ] On >Behalf Of Brian France > > Sent: Wednesday, November 21, 2007 10:00 AM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: IFL's, VM, Suse, OH MY... > > Folks, > > I've done about a 45 minute search and I think my >answer is that I'd have to run multiple VM's per frame but wanted to >ensure I was right. My management wants to run some product called HATS >on our VM/MFL world. We recently upgraded from our z/890's with 1 IFL >each to z9BC's with 2 IFL's each. I guess to keep costs down they want >to run on one IFL this HATS worlds so the question to me was can I run a >single VM with BOTH IFL's allocated but alot the HATS world only 1 IFL. >Is this possible with VM config parms or some other way like maybe my >HMC which I just thought of but haven't looked at yet. I know we have to >lic Suse for more engines. Just more interested in is it even doable. >THANX!!!! > > Brian W. France > > Systems Administrator (Mainframe) > > Pennsylvania State University > > Administrative Information Services - Infrastructure/S >YSA RC > > Rm 25 Shields Bldg., University Park, Pa. 16802 > > 814-863-4739 > > [EMAIL PROTECTED] > > "To make an apple pie from scratch, you must first >invent the universe." > > Carl Sagan > > > > > > Brian W. France > Systems Administrator (Mainframe) > Pennsylvania State University > Administrative Information Services - Infrastructure/S >YSA RC > Rm 25 Shields Bldg., University Park, Pa. 16802 > 814-863-4739 > [EMAIL PROTECTED] > > "To make an apple pie from scratch, you must first >invent the universe." > > Carl Sagan > > > > > > >________________________________ > > The information transmitted is intended only for the person or >entity to which it is addressed and may contain confidential and/or >privileged material. Any review retransmission dissemination or other >use of or taking of any action in reliance upon this information by >persons or entities other than the intended recipient or delegate is >strictly prohibited. If you received this in error please contact the >sender and delete the material from any computer. The integrity and >security of this message cannot by guaranteed on the Internet. The >Sender accepts no liability for the content of this e-mail or for the >consequences of any actions taken on basis of the information provided. >The recipient should check this e-mail and any attachments for the >presence of viruses. The sender accepts no liability for any damage >caused by any virus transmitted by this e-mail. This disclaimer is the >property of the TTC and must not be altered or circumvented in any >manner. > > Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 [EMAIL PROTECTED] "To make an apple pie from scratch, you must first invent the universe." Carl Sagan Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/S YSA RC Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 [EMAIL PROTECTED] "To make an apple pie from scratch, you must first invent the universe." Carl Sagan
