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
