MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » September 2012

RE: development/test/prod environment mini-survey



fixed

And for non-ILE RPG create a DDM file pointing back to the system with the source. Voilà you now have source available to your production system. In STRISDB (press F10) the source file and library become your DDM file and its library. For example: SRCF(QTEMP/DDMRPGSRC).



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Anderson, Kurt
Sent: Thursday, September 20, 2012 1:17 PM
To: Midrange Systems Technical Discussion
Subject: RE: development/test/prod environment mini-survey

Good point, Joel. Where I worked, it was all very secure and as a programmer an accidental update wasn't a possibility (at least that I ever encountered).

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Thursday, September 20, 2012 2:50 PM
To: Midrange Systems Technical Discussion
Subject: 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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


________________________________________________________________________
This inbound email has been scanned for all viruses by the MessageLabs SkyScan service.
________________________________________________________________________

______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact