Just making a separate non-plxed LPAR always seems simpler .. is my
answer..  but it never is.

Too many processes with dependencies.

Change control is usually an easy way to illustrate the beginnings of "the
rabbit hole".

Basic sysplex should work well.  Reserves, XCF, GRS, JES2, SMS ...
Security... Naming conventions, ...automation.  Catalogs..are a few that
come to mind.

But it still sounds like the right choice.

Rob Schramm
 On Sep 13, 2013 11:59 AM, "Peter Bishop" <[email protected]> wrote:

> Hi,
>
> I have to ask - why a sysplex when two separate LPARs that don't share
> anything may be simpler?  It shouldn't cost any more to have separate LPARs
> if you're running VWLC, especially since you sound like you're running the
> same products in both LPARs.   Sysplexes are great if you need them, but a
> pain if you don't.
>
> Just a thought.
>
> thanks
> Peter
>
>
> On Fri, 13 Sep 2013 10:24:39 -0400, Jim Blalock <[email protected]> wrote:
>
> >Hi folks,
> >
> >We have a single z10, and would like to split its main partition into
> >production and developer partitions.  Capacity should be ok. We're
> >looking at all the stuff we need to worry about sharing, like GRS,
> >spool, RACF, RMM, HSM, catalogs, virtual tape, etc etc.  But underneath
> >it all, we probably need to set up a sysplex.
> >
> >Keep in mind that we've never set up a sysplex before or done any real
> >sharing beyond shared DASD, so there will be dumb questions.
> >
> >I think a basic sysplex will be enough, that way we won't need a
> >coupling facility.  We will need a way for them to talk to each other
> >(and probably with one or two sandbox lpars), so I'm looking into CTCs.
> >The question I haven't found an answer to is how to use CTCs without an
> >escon or ficon switch;  we have spare channels and I want to do this on
> >the cheap if I can.
> >
> >I'm still reading about it, but any insight would be appreciated. Thanks!
> >
> >--
> >-- Jim Blalock
> >    z/OS Support Manager
> >    CCIT, Clemson University
> >    (864) 656-3680
> >
> >----------------------------------------------------------------------
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to