On the physical level we shared all DASD volumes. On the logical level we
had a separate spool, sms groups, etc. between prod and test. Security
should be handled by your security package (RACF, ACF2, etc.). Performance
has never been an issue. The advantage to sharing is that dev and qa can
read production files for testing. They cannot, however, write to the
production SMS group.
----- Original Message -----
From: "Frank Swarbrick" <[email protected]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Wednesday, August 05, 2009 1:40 PM
Subject: DASD: to share or not to share
As part of our migration to z/OS from z/VSE we have started a discussion
on what DASD, if any, should be shared between our production z/OS LPAR
and our development z/OS LPAR. For what it's worth, on VSE here is what
we have right now...
When both PROD and DEV are at the same OS level they both share the same
OS "system residence" library. Also shared are things like the DB2 "load
library", the DL/I "load library", the CICS "load library", etc. In
addition we also share the "load library" that contains all of our
application "load modules". (I use these quotes because the VSE term is
not "load modules / load libraries" etc, but I can't think of a good
generic name. Executables, maybe.)
What we do not share is the disk volumes that contain production datasets
(VSAM files, DL/I databases, sequential files, etc.). [Actually that's
not quite true, because we actually have two PROD VSE guests which have
some DASD shared between the two, though not between them and DEV.] If a
developer needs production data then he can either restore from a nightly
backup (backups are on shared DASD) or can run a process that 1) copies
from the production unshared volume to a shared volume (job run in PROD),
and 2) copies from the shared volume to a DEV volume (job run in DEV).
As an applications developer I've never been to happy with the unshared
data, but I can certainly understand why it is done. Security of
production data (perceived or actual risk I am not sure...) and
performance (shared DASD has performance implications) being the main
issues.
Now the discussion has "blown up" in that there are now questions by our
CIO as to if we really should be sharing even the "executable" libraries.
Not only at the applications level, but also at the systems level. He's
thought is that if two LPARs share the same OS executables that their use
in DEV could possibly hinder performance of PROD.
Theoretically I can see this possibility, but is it really a concern?
What do others do for:
1) System executables
2) System parameter libraries
3) Applications executables
4) Application data
I should note that this is not the case of an uneducated manager trying to
make technical decisions. But he is from the "distributed systems" world,
and even though he's worked here for 15+ years, much of that as CIO over
both distributed and mainframe systems, he still has a bit of a
"distributed systems" mindset. In that world they don't share "system" or
"application" data at all (or very little). But to me that doesn't mean
that it's wrong in the mainframe world.
Thoughts?
Thanks!
Frank
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation
Lakewood, CO USA
P: 303-235-1403
F: 303-235-2075
The information contained in this electronic communication and any
document attached hereto or transmitted herewith is confidential and
intended for the exclusive use of the individual or entity named above.
If the reader of this message is not the intended recipient or the
employee or agent responsible for delivering it to the intended recipient,
you are hereby notified that any examination, use, dissemination,
distribution or copying of this communication or any part thereof is
strictly prohibited. If you have received this communication in error,
please immediately notify the sender by reply e-mail and destroy this
communication. Thank you.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
