-----Original Message-----
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Joel Wolpert
Sent: Friday, August 07, 2009 12:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: DASD: to share or not to share
You can configure it so that it is not always polling, and therefore
not
soaking up the CPU. In addition, you can set up an lpar weight and cap
the
Does not "cap it CF LPAR" ask for or equal "hang production LPAR(s)"
waiting for CF response?
ICF lpar. This will also prevent the ICF from consuming more of the
CEC
than
you want. All of this being said: I would not recommend that you share
a
CF
with the production lpars. If someone changes the config of the CF you
might
end up with a performance problem.
----- Original Message -----
From: "Gibney, Dave" <gib...@wsu.edu>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@bama.ua.edu>
Sent: Friday, August 07, 2009 2:12 PM
Subject: Re: DASD: to share or not to share
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]
On
>> Behalf Of Scott Rowe
>> Sent: Friday, August 07, 2009 8:51 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: DASD: to share or not to share
>>
>> Heck, I just use a CF partition running on my shared CP. As long
as
> you
>
> I've heard lots of scary stories about sharing CPs for CF. I
understood
> the CF code was basically a non-terminating loop.
>
> I've even heard of folks using a CF lpar as a MSU soaker to keep
z/OS
> MSU's down for SCRT purposes.
>
> I certainly don't want any hang of my production system because I
shared
> with a CF.
>
>
>> are only doing GRS, and maybe HSM CRQm etc, there is no problem.
My
> two
>> CF partitions combined average about 0.2% of my CPUs. It may not
be
> as
>> fast as dedicated CPs, but it is still faster than GRS ring.
>>
>> >>> "Gibney, Dave" <gib...@wsu.edu> 08/06/09 5:23 PM >>>
>> When ICF's are free, maybe we'll consider it :) I share resvols and
>> other volumes with software load and other read only type
operational
>> data between some or all of our 4 LPARs with no appreciable impact.
>>
>> Dave Gibney
>> Information Technology Services
>> Washington State University
>>
>>
>> > -----Original Message-----
>> > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]
On
>> > Behalf Of Chase, John
>> > Sent: Thursday, August 06, 2009 12:32 PM
>> > To: IBM-MAIN@bama.ua.edu
>> > Subject: Re: DASD: to share or not to share
>> >
>> > > -----Original Message-----
>> > > From: IBM Mainframe Discussion List On Behalf Of McKown, John
>> > >
>> > > [ snip ]
>> > >
>> > > A basic SYSPLEX (what we are running) does not require a
Coupling
>> > Facility (CF). With a CF, you have a
>> > > Parallel Sysplex, which has some better facilities. If you only
> have
>> > an single CEC (box), then you
>> > > don't need a Sysplex Timer, either. And, if you're on a single
> box,
>> > you could get an CFL speciality
>> > > engine and run a single CF in a separate LPAR. In this case,
there
>> is
>> > no cabling required - it used
>> > > "pseudo cabling" via the PR/SM hipervisor. Much like
hipersockets.
>> >
>> > You must be wishing really hard for an IFL. :-)
>> >
>> > The "Integrated Coupling Facility" engine is an "ICF" (more
overload
>> > for
>> > ICF).
>> >
>> > -jc-
>> >
>> >
>
----------------------------------------------------------------------
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> INFO
>> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
>>
>>
----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>>
>>
>>
>> CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission
> contains
>> confidential and privileged information intended only for the
> addressee.
>> If you are not the intended recipient, please be advised that you
have
>> received this material in error and that any forwarding, copying,
>> printing, distribution, use or disclosure of the material is
strictly
>> prohibited. If you have received this material in error, please
(i)
> do
>> not read it, (ii) reply to the sender that you received the message
in
>> error, and (iii) erase or destroy the material. Emails are not
secure
> and
>> can be intercepted, amended, lost or destroyed, or contain viruses.
> You
>> are deemed to have accepted these risks if you communicate with us
by
>> email. Thank you.
>>
>>
----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
INFO
>> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>
----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
