Alan,
The may way is to compile with DBGVIEW *LIST
which includes the source in the program object.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Shore
Sent: Thursday, September 20, 2012 2:42 PM
To: Midrange Systems Technical Discussion
Subject: RE: development/test/prod environment mini-survey
Hi Joel
I feel like my question has been answered before, but I cannot find anything on it so here goes.
If you have no source on the production system, how can a programmer use debug when something goes wrong at 1:42 a.m.?
Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, September 20, 2012 4:00 PM
To: Midrange Systems Technical Discussion
Subject: RE: development/test/prod environment mini-survey
Joel,
You're point has some merit. There is extra work in keeping up the OS, PTF's and what not in a two box (or lpar) system. Some of that extra work has extra benefit - like testing your application under the new OS before loading the new OS on production.
We do NOT put source on production. The only reason we even have the RPG compiler on the production box was because one applications report writer generated RPG and compiled that. Which gets me to thinking, we aren't using that anymore...
I feel though that a separate machine reduces some boo boos due to job descriptions and what not which may be overlooked in creating test data and may have a production library in them.
Your points about DDM files and what not are valid. I brought them up in an earlier email.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Stone, Joel" <Joel.Stone@xxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 09/20/2012 03:49 PM
Subject: RE: development/test/prod environment mini-survey
Sent by: midrange-l-bounces@xxxxxxxxxxxx
--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.
Disclaimer: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
midrange.com
