There are two distinct flavors of "test": system maintenance testing
and application development testing. Doing initial systems maintenance
testing or testing significant system configuration changes on a
production system is NOT recommended - you really need a separate LPAR
and independent z/OS system for that. but you only need it when you are
doing such testing. Applications testing is another matter. In a
properly configured system with reasonable naming standards and
RACF-enforced barriers, with TEST CICS runing with test DB2 subsystems
and PROD CICS running with a prod DB2 subsystem you can achieve a
separation which should be sufficient unless your production environment
deals with highly classified material that justifies, or has a
government requirement for, a higher level of paranoia.
If we had a separate applications test LPAR we would still not do
initial systems maintenance testing there because this is the
"production" environment for applications development.
There is no way your installation can test enough combinations of events
to insure no bugs are introduced by maintenance But, with the unified
z/OS testing strategy, RSU PTF philosophy, and fairly comprehensive
Migration manusals, z/OS maintenance is much less of an "adventure" than
it was 15 years ago, when encountering problems that could seriously
impact production for your site after going live was not that rare, even
when testing was done. Our experience in the last decade has been that
when you observe maintenance strategies that don't put you on the
bleeding edge, resolve known PE holds, and check out basic functionality
of all major subsystems and vendor products that may have been affected
by maintenance in a maintenance LPAR, then installation in production
does not tend to uncover new problems that would be major enough to
force a back-out or be seriously disruptive. And of course when going
live, you do so by swapping volumes or datasets at IPL in a way that is
quickly reversible to minimize exposure to "Murphy's Law".
Having a separate test LPAR into which new maintenance could be staged
after initial testing would give another "warm fuzzy" that the
maintenance at least performs under a "test" load before introduction
into the prod LPAR; but some of the bugs that we eventually do find
after going live tend to be ones that only show up under a heavy
production load, so absence of problems in a lighter test load is really
no guarantee.
My personal feeling is that if there is enough paranoia to not trust
your RACF and other security conventions from keeping test and prod data
properly isolated on the same LPAR, then shared DASD would be out of the
question as well, because there is no reason to assume that having
shared DASD between separate LPARs would be any less prone to
cross-system data corruption or exposure than sharing within a single
LPAR, and if things aren't properly configured it could even be less secure.
If there are other reasons that already force the overhead of a SYSPLEX
just to support multiple production LPARs, then splitting application
development testing to its own LPAR would involve less additional
overhead, and there could be some software cost advantages if compilers
were only licensed with sub-capacity licensing to the development LPAR.
Then rolling IPLs could be used to gradually stage in maintenance
across both test and production LPARs.
Joel C Ewing
Lizette Koehler wrote:
I think that by having one LPAR run both test and prod will impact the down
time for your Prod applications to doing system maintenance testing.
Realize that when you share everything in on LPAR then all things at risk
when doing system maint.
For example, CATALOG maint, DFHSM maint, anything hitting LPA or Nuc will
probably require an IPL. If your environment is such that the production
systems must be available, then you will not be able to do system maint that
requires an IPL very frequently. Next you have to setup a testing window
and have PROD down so you can verify your system maint without causing a
problem to prod. This can be tricky depending on what maint is to go in.
They you have to back it out after testing to ensure that prod is the same
as before the test. And you also have to consider your application test and
development folks for your testing windows as well. You cannot keep them
from their work for very long.
By having separate LPARs for test and prod you can test on the TEST lpar
more easily. Especially if you keep the catalogs (especially MCAT)
separate, and possible have separate HSM and network connections.
Auditors do not like having a TEST and PROD system share anything. That
could allow someone with bad intent to compromise your production data by
having access to it. By keeping it as separated as possible, then your
reduce the risk to your production processes.
Some questions you should consider are:
1) If they are on the same LPAR what is
a) My test window going to be like. How do I affect production and
application dev/test?
b) When do I roll maint for my system or subsystems
c) What are the risks when installing new function
d) What are my SLAs or Management requirements
e) What is the roll out process from TEST to PROD? How many system
files should be shared and which ones should not be shared.
2) If they are on 2 LPARs what are:
a) How separated can I make the LPARs
1) Separate DASD?
2) Separate Network connection
3) Separate Subsystems (CA1, SMS, DFHSM, Catalog)
b) Will TEST have PROD dasd online
c) Will TEST be part of a Shared Catalog (Both use the same MasterCat)
d) Will there be application devl/test groups in this LPAR
e) Will there be sufficient usage of this TEST LPAR to justify it
(licenses costs, CPU utilization)
f) Will the TEST lpar have an impact on Prod LPAR if there is a run
away task?
I am sure others will have many more thoughts than these.
Personally, if I can keep it separate and management is okay with costs and
such, then I prefer separate. Otherwise maint and testing can be very
challenging.
Lizette
gsg wrote:
Can everyone share some Pros/Cons on having seperate LPARs for Prod and
Test and also Pros/Cons for having a single LPAR that Prod and Test will
share. All feedback is welcome.
TIA
--
Joel C. Ewing, Fort Smith, AR [email protected]
----------------------------------------------------------------------
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
