The clearest exposure is that different systems (LPARs) performing different enterprise roles may well treat like-named data sets differently. For example, if SYSA is a development/test/sandbox system while SYSB is a production system, the access rules on SYSA may well be much looser in general than on SYSB for a data set that has the same name but different content. For systems that have historically been nonshared, this situation can easily evolve over time. By suddenly combining systems with different historical roles, security exposure is highly likely.
I strongly recommend *against* simply bolting disparate systems together. Any convenience that may be gained by having a larger '3.4' view of volumes could easily be crushed by security exposures. My experience in merging systems suggests that it is far more complex and riskier than separating systems into multiple images. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: "Staller, Allan" <[email protected]> To: [email protected], Date: 03/25/2013 07:35 AM Subject: Re: Making DASD shared - IODF Sent by: IBM Mainframe Discussion List <[email protected]> How would this be possible? Image A looks at database A for access rules. Image B looks at database B for access rules. Even if they are the same name, they cannot be cataloged "concurrently". i.e. each must exist in a separate catalog. What would cause the exposure? <snip> Do you share the security system database? It does not matter if it is ACF2, RACF or Top Secret. But, if you have different security system databases, you are opening yourself to unauthorized access to sensitive datasets. This could result in PCI, HIPAA, SOX, etc. violations. Barry Schrager </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
