--5) What would be some reasons why this is a good idea (besides the auditors told us to)?
-- "Guaranteed to not screw up the production environment."
I would argue that this "guarantee" is a lot less secure than the average non-IT person might think.
If security is set up poorly on a two box system (TEST / PROD), then a few DDM files or SNDNETF or a change management system can destroy stuff just as quickly as on one box.
If security is set up well, then TEST/PROD on one box can be just as effective imo.
My concern is that boxes are like babies - the first child seems like not too much work. The second child arrives and it is 5 times the workload for some reason!
Same with two Iseries boxes (or LPARS). Now simple stuff like a CPYF takes a significant amount of effort instead of a trivial command.
Simple (one box) is easier to track, police, and control than complex (multi-LPAR) imo.
But auditors and VPs will never see it that way anyways :)
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Anderson, Kurt
Sent: Thursday, September 20, 2012 2:10 PM
To: Midrange Systems Technical Discussion
Subject: RE: development/test/prod environment mini-survey
1) Is dev/test/prod on same LPAR? Yes
2) Is dev/test/prod on same box? Yes
3) How frequently are promotions from dev to test allowed? D.
a. No restrictions
4) Does separating DEV from TEST require more time & effort for a given development project?
This appears to be asking about the time to break dev/test/prod out between boxes or lpars, and we don't do that, so I have no answer.
5) What would be some reasons why this is a good idea (besides the auditors told us to)?
Guaranteed to not screw up the production environment.
For our testing, we use the library list to control our impact. A lot of our testing uses STRDBG as an added measure to not impact any production libraries.