Thank you all for your constructive comments and critiques. But from this little brainstorming exercise, I believe if I have learned anything at all, I have learned that PR/SM is anything but "free".
Would IBM really give away anything for free? "Here's nothing, grab it well" (Old Hungarian proverb) The easiest path, the path of least resistance, is not always optimum. There is a very hidden, subtle, but quite exorbitant price paid for PR/SM: - Memory for each instance of z/OS replicated, - Performance: wasted CPU cycles especially for handshaking between LPARs doing shared I/O, - Software licensing fees - Inflexibility of fitting workloads into fixed partitions, - complexity: After splitting everything up we bring it all back together again with Parallel Sysplex, CDSes, CFRM policies: List, Cache, and Lock structures, all kinds of plexes: JESPLEX, VTAMPLEX, IMSPLEX, VSAM RLS, CICSPLEX, SHARED DB2, all designed to circumvent the artificial barriers we never needed to erect in the first place. despite: - all efforts of IBM to encourage this with "sub-capacity pricing" - the diminishing need to carve up memory now that paging, Expanded Storage, are history with 64 bit memory. True, there is a place for PR/SM for things like CFCC, AIX, LINUX. But just needlessly replicating z/OS because it is "free" and easy to do is not the answer. One of the oldest marketing devices is: - to first lower the hemline, then raise it; - first bring out "double knit men's suits", then banish them, - first tell everyone to go distributive, then force them to centralize, - and above all: - software sells hardware, so encourage the inefficient use, needless replication, of software so we can sell more hardware. On Fri, Mar 5, 2010 at 8:00 AM, Chase, John <[email protected]> wrote: > > -----Original Message----- > > From: IBM Mainframe Discussion List On Behalf Of George Henke > > > > I think I may have finally come upon a valid justification for a > separate > > UAT, QA LPAR; maybe the only justification. > > > > You can only have one instance of Security, RACF, ACF2, TSS, in an > LPAR, > > z/OS Domain, at any one time. > > > OK so far.... > > > Since, for QA testing, the need is to mirror PROD Security so that the > > security rules for a change being made are tested *before* moving the > change > > to PROD, then there would need to be a separate LPAR to hold a > separate > > Security DB that mirrored the PROD DB. > > > We use "installation-defined classes" for much of that separation, which > works well here because the vast majority of resources for which we > might need to test new security rules are amenable to separate "cloned" > classes (mostly CICS and "FACILITY-like" stuff). > > > Since the DEV LPAR already has a DEV Security DB and there can be only > one > > instance of a Security DB per LPAR, this would preclude the mirroring > of the > > PROD Security DB in a DEV LPAR, and is sufficient reason for creating > a > > separate LPAR for QA, UAT, testing. > > > Actually, we share a RACF database between PROD and DEV/QA. Only the > "sandbox" has a separate RACF database. > > > Of all the justifications, presented thus far, for creating a separate > LPAR > > for QA, UAT testing, this appears to be the only one that cannot be > refuted. > > > If "any exception to the rule" counts as "refutation", this is refuted. > > > However, it still "begs the question", why have LPARs at all, because > > separate Security DBs *can* be configured in separate Virtual Machines > > running separate instances of z/OS under z/VM without LPARs at all. > > > OTOH, if all you run is a relatively stable set of z/OS images, why use > z/VM when PR/SM is "free" (indeed, you can't get a current CPC without > it)? I'll admit that I've not worked with any flavor of VM in over a > decade, but I don't recall any flavor of MVS IPLing any faster under VM > than in an LPAR. > > -jc- > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- George Henke (C) 845 401 5614 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
