>No, I'm saying that it's preposterous for you to say such a thing, >because I do not believe it is prevalent. . . . 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. IBM owes you money.
On Fri, Mar 5, 2010 at 11:59 AM, Scott Rowe <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 < > [email protected]>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 [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 > > > > > > -- > 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 > > > > 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 [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
