It makes sense to share DASD. It makes sense to keep it separate. About the only real issue I can see is one of synchronization. That is, the instant you create a duplicate, the data starts to drift apart and requires vast amounts of The Force to force it back into sync. The farther apart you separate the storage media, the more Force you need.
May The Force be with you, and in plentiful supply :-) -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Frank Swarbrick Sent: Wednesday, August 05, 2009 12:40 PM To: [email protected] 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. ---------------------------------------------------------------------- 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
