You may not even have security rules in place on the foreign system (accessing) than the native system (creator). I. E. a production HLQ that is not defined on the test system. You could set Security to not allow access to datasets without a security definition.
On Mon, Mar 25, 2013 at 12:08 PM, Skip Robinson <[email protected]> wrote: > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
