In my previous summary of arguments thus far, I forgot to note this one: *Pro: *LPARs eliminate single points of failure. *Con:* XRC, PPRC-XD, FLASH/COPY, METRO/MIRROR, GLOBAL/ MIRROR, now provide recovery from instantaneous to anywhere around 4 hours and just effectively than LPARs, if not more, because offsite. Having LPARs for this purpose now just creates needless redundancy and expense.
I came across the following from the "horse's mouth" itself: z/OS V1R9.0 Planning for Installation GA22-7504-17 z/OS*®* (program number 5694-A01). Some highlights of z/OS are: - The 64-bit z/Architecture™ implemented by z/OS eliminates bottlenecks associated with the lack of addressable memory. *64-bit real (central) storage support eliminates expanded storage, helps eliminate paging, and may allow you to consolidate** your current systems into fewer logical partitions (LPARs) or to a single native image.* I never considered "storage fencing" as a possible justification for LPARs, but maybe that is it? If so, then even that justification has now been eliminated with 64-bit central storage. It does fit the history of the evolution of operating systems. In the old MFT days, did not we have "core" and quite limited memory? Then that was replaced with integrated circuits which according to Moore's Law doubles every 2 years. And what happened? No more MFT, nor more partitions, but MVT, then SVS and MVS. So now that we have 64-bit addressable memory, does this presage the fading away again of partitioning, of LPARs and create an "urge to merge"? I am astounded and humbled at the depth and breadth of IT knowledge, intelligence, and thinking of the contributors in this trail; it is awesome. Thank you all very much. But, in Hans Christian Anderson's story, the tailors needed to be paid a lot of money because the fabric was very expensive. But, of course, only the very wise could see it. So in my sublime ignorance let me now also exclaim, "The Emperor is naked". "Where ignorance is bliss, tis folly to be wise" (Thomas Gray) On Wed, Feb 24, 2010 at 1:33 AM, Alan Altmark <alan_altm...@us.ibm.com>wrote: > On Tue, 23 Feb 2010 12:30:25 -0500, Scott Rowe <scott.r...@joann.com> > wrote: > > >I don't know that I would say that running QA in a different LPAR > >than DEV is "best practices", I certainly run them in the same > >LPAR here, and at nearly every site I have ever worked at. > > All PCI-compliant installations > (a) Must have separate DEV/TEST/QA and PRODUCTION environments > (b) Must have Separation of Duties for the two environments > (c) Cannot give DEV/TEST access to PRODUCTION PANs > > And rather than micro-manage the ACLs, it is far simpler to create another > LPAR. Having done it once, you replicate your success in order to separate > QA from DEV/TEST. (QA really is a different environment than DEV/TEST, > IMO.) > > My point is that the level of separation is, more often than not, dictated > not by the capabilities of the OS, but by > (1) regulatory considerations > (2) in-house politics (appl owner, security, turf wars, ...) > (3) system programmer convenience > > >I certainly have no desire to spend time on VM if I don't need the > >functionality, I simply don't have the time. I have worked on VM > >before, and rather like it, but if the tool doesn't fit I have no desire > >to use it. > > That's the real nugget of Truth. Do what you need to do. Just do it with > your eyes wide open and use the right tool for the job. > > Alan Altmark > z/VM Development > IBM > > ---------------------------------------------------------------------- > 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 > -- George Henke (C) 845 401 5614 ---------------------------------------------------------------------- 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
