RE: development/test/prod environment mini-survey

--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 :)





-----Original Message-----
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.

-Kurt Anderson