Peter, Make sure you are not converting reserves for the devices that will be defined as shared in the IOCDS.
If the LPARs sharing the devices are not in a common sysplex or GRSplex then the hardware reserves converted to an ENQ will not be seen by the other system. If you don't let RESERVE do its thing in the hardware you could be opening a Pandora's box of problems. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of mf db > Sent: Saturday, March 23, 2013 9:06 AM > To: [email protected] > Subject: Re: [IBM-MAIN] Making DASD shared - IODF > > Hello Groups, > > Thanks for an awesome reply. Apologies for not giving a deep description > about the environment, ours is not sysplex and we are not sharing catalog. > Just want to share the volumes, so that the datasets are visible across the > system.(I mean accessible via 3.4 with volumes) > > > /Peter > > On Sat, Mar 23, 2013 at 8:45 PM, Joel C. Ewing <[email protected]> wrote: > > > On 03/23/2013 02:07 AM, mf db wrote: > > > >> Hello Group, > >> > >> We have two machines Z800 and Z9 both use the same storage unit as > >> ESS800 for storage purpose. Currently Z800 and Z9 machines don't share > the dasd. > >> Could Someone Please provide some pointers or URL which can help me > >> to make the DASD across the two machines. > >> > >> Any Ideas would be much appreciated. Right now I am reading the HCD > >> configuration guide but I am unable to find a topic which talks about > >> sharing the DASD across. > >> > >> > >> /Peter > >> > >> ... > >> > >> A lot depends on your goals. > > > > If the object is to be able to access a single volume from multiple > > systems, but only have a volume on-line to one system at a time, then > > you can get by with IODFs that define physical paths to the device > > from both systems and define a device as initially off-line to all but > > one system, together with rigid operating procedures that demand the > > device be placed off-line on any other system before it is brought > > on-line to a different system. We have used this with a test/recovery > > system that is restricted-use and which might need to access > > production volumes for restores, but only when production z/OS is > > dead, and where production might need to access test system volumes, > > but only when the test system is down and being being rebuilt or > > reconfigured. If you have this type of environment, you have to be > > very careful about accidentally getting a volume on-line to two > > systems, as updates while on-line to two systems can destroy a shared > > catalog, shared dataset, make cached information held by the other system > invalid, etc. > > > > If your object is to concurrently share and potentially update data on > > volumes shared among multiple systems without corrupting the data, > > this is much more complicated and you need to do much research on > > defining devices as "shared" to z/OS in IODF and GRS and/or Sysplex > > concepts to insure that destructive concurrent updates and > > inconsistent cached copies of data are prevented. Without properly > > implementing the inter-z/OS communication needed for coordination > > among the systems, all sort of random nasty things can happen: broken > > catalogs, missing datasets, broken datasets, corrupted data. I haven't > > looked recently, but there surely must be some Redbooks out there that > address these concepts. > > > > Unless all access to an alternate system with the independent security > > database and shared DASD is sufficiently restricted, you must also use > > some automatic or manual technique to sync the security databases > > across the systems, at least to the extent that sensitive data or > > critical datasets belonging to all systems are always protected from > > inappropriate access on all systems with access. > > > > -- > > Joel C. Ewing, Bentonville, AR [email protected] > > > > ------------------------------**------------------------------**------ > > ---- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
