We run an R&D LPAR with 7 different complete copies of Production, each copy serves a unique purpose.
The problem we have is that certain processes cannot be run in the test environment.
Most of the time those processes are identified if they communicate in any way to the outside world.
FTP, SFTP, Credit Card Processing, IVR processing, Email blasts, etc.
The most difficult thing we are currently experiencing is how to identify and/or skip these processes if NOT production.
What we have done thus far, is include and retrieve the system name.
If the process communicates externally, the process/code is skipped if NOT production.
0029.01 DCL VAR(&SYSNAME) TYPE(*CHAR) LEN(8)
0029.02 RTVNETA SYSNAME(&SYSNAME)
0029.04 /* Only FTP if the system running the command is PENCOR05 - Production */
0029.05 IF COND(&SYSNAME *EQ 'PENCOR05') THEN(DO)
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Monday, May 12, 2014 3:42 PM
To: Midrange Systems Technical Discussion
Subject: Re: Test libraries on Test Partitions !?!?
Even test lpars don't isolate you from everything.
Send an electronic deposit request to the bank.
Send an EDI request to order 1,000,000 stock items.
Fax request to ...
Automated email which will ...
yeah, removing production libraries to ensure a safe test sounds draconian.
modifying library lists to insert a test library is not unheard of.
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
Kendallville, IN 46755
From: Gary Thompson <gthompson@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/12/2014 03:33 PM
Subject: Test libraries on Test Partitions !?!?
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
This is a RANT, reasonable persons should disregard.
We are involved with, for us, a BIG project.
1,000's of man-hours, 1,000,000's of $...
We are using our test lpars in what I think is a perverse and
1) changing production library lists to use test libraries
2) in some cases, removing a production library from the lpar
3) not taking the trouble to: a) discuss or advertise this b) not
taking the trouble to ensure all test libraries are ready for
My advice to anyone contemplating use of test lpars is to "forget"
the "test library concept" and maybe consider purging them from the
BTW, I started attempting to be a "programmer" before computers
had lpars and started with the test library concept as the only "test
environment" available to me. Actually I started on a COBOL/MVS
system that had only the production and test MVS instances but, if
memory serves, only one instance of program objects.