On 5 Aug 2009 11:36:23 -0700, in bit.listserv.ibm-main you wrote: >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.
In these days of HIPPA, Sarbanes-Oxley (in the US), PIPEDA (in Canada) and various other privacy acts, do you want applications people able to read production data? On the other hand how do you re-create production problems in test when the obfuscation may also eliminate the problem? > > >----- 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 ---------------------------------------------------------------------- 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
