Let me get this straight: You think this is a valid argument when applied to security, but somehow thought that the same argument applied to OS maintenance/release was somehow refuted?
>>> George Henke <gahe...@gmail.com> 03/04/10 6:22 PM >>> 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. 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. 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. 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. 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. On Mon, Mar 1, 2010 at 1:16 PM, Rick Fochtman <rfocht...@ync.net> wrote: > --------------------------------------<snip>----------------------------------- > > > FORTRAN H and FORTH are two very different languages. I don't know if there > was ever a FORTH implementation for OS/360. > > -----------------------------------<unsnip>----------------------------------- > I was completely unaware of a FORTH processor/language. > > ---------------------------------------<snip>------------------------------------ > > > BTW, FORTRAN H was written in FORTRAN H, a much uglier language than BSL > and its descendants. > > ---------------------------------------<unsnip>------------------------------------- > Parts of the FORTRN H compiler were written in FORTRAN; other parts were > written in Assembler. > > -------------------------------------- > Rick > > > ---------------------------------------------------------------------- > 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 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
