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:[EMAIL PROTECTED] *On Behalf Of [EMAIL PROTECTED]
*Sent:* Wednesday, November 21, 2007 10:39 AM
*To:* [email protected]
*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 wouldnt 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:[EMAIL PROTECTED] *On Behalf Of *McKown, John
*Sent:* November 21, 2007 11:32
*To:* [email protected]
*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.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:[EMAIL PROTECTED] *On Behalf Of *Brian France
*Sent:* Wednesday, November 21, 2007 10:27 AM
*To:* [email protected]
*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:[EMAIL PROTECTED] On Behalf Of Brian France
Sent: Wednesday, November 21, 2007 10:00 AM
To: [email protected]
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.
