No, I'm saying that it's preposterous for you to say such a thing, because I do not believe it is prevalent. I have never seen such a situation in any shop where I have worked, nor have I heard any reliable source explain that such a situation exists elsewhere. I recently was involved in situation where management was desiring to do such a thing, through their own ignorance of the technology, but I was able to defeat it.
>>> George Henke <gahe...@gmail.com> 3/5/2010 11:50 AM >>> >You seem to be implying that companies use PR/SM on a whim to >multiply their z/OS images for no good reason, which I think is >preposterous. You're right it is preposterous. The only thing the PR/SM LPAR paradigm lacks is a nice Escher painting to hang over it. On Fri, Mar 5, 2010 at 11:04 AM, George Henke <gahe...@gmail.com> wrote: > Auditors don't like anything they can't stub their toe on. > > I have the scares to prove it. > > On Fri, Mar 5, 2010 at 10:52 AM, Staller, Allan > <allan.stal...@kbm1.com>wrote: > >> At the end of the day, this discussion comes down to business >> requirements. Many institutions, due to audit, regulatory, or industry >> standards need to separate SANDBOX/DEV/TEST/QA/PROD. This can be done at >> the administrative level (1 big LPAR with all information(os testing >> excluded)), or the image level(separate LPARS for each), z/VM guests, or >> anything in between. >> >> The trick in the single image environment is proving that the >> non-production user CANNOT access production data, which will be a >> concern for even the most incompetent of auditors. Yes this can be >> accomplished, but how many auditors will understand the nuances of >> RACF/ACF2/TS enough to even test the premise. Not to mention the >> administrative overhead required to establish, document, and maintain >> the separation of the environments within a single image. >> >> A separate LPAR(or guest) can be easily defended (with backup doc from >> IBM and others) by saying "This LPAR cannot access that LPAR's data >> unless explicitly allowed". Most auditors can understand and test that >> premise, even if they are not security experts. >> >> In other words, whatever works best for your business is the method you >> should use. >> >> Just my 0.02 USD worth, >> >> ---------------------------------------------------------------------- >> 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 > -- 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 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
