By "test" do you mean "sysprog test" or "application test"?
I'm a firm believer that you need a sysprog sandbox to install the latest releases and try out new things. We actually have a separate sandbox sysplex so any sysplex-wide things we might need to play with won't affect production. However, it's less clear from an application perspective, and in fact we do it both ways. We have one production 2 member sysplex where application dev/test and prod are on both members. We have another 4 member plex where 2 are supposedly "production" and the other two are supposedly "dev/test". However, in reality, over time, the functions shift around such that that's not such a pure distinction: there's user training that goes on in the "dev/test" systems and there's application testing that goes on in the "production" systems. WLM can do a good job of keeping the dev/test users from hurting the production users, and fewer systems imply fewer fixed overheads. So my preference is to do application dev/test and production on the same systems. The most significant negative to that strategy is that the application teams will feel better if you can give them a new version of the OS in just their test environment first. But that's really only an issue for OS releases--all the major application subsystem software (CICS, DB2, MQ) rolls through dev/test before production anyways. And when we roll out new OS releases, we do them one side of the production sysplex at a time, about a week apart for the sysplex that has dev/test and production on the same systems. Scott Chapman ---------------------------------------------------------------------- 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
