Thanks to All! I now have a better understanding. Yes, we already run SMS on all four lpars; Maybe only for USS on TEST lpar.
I will have to check if GRS is required, ring I think. I have been bitten by that before. A Sysplex might be required for a Star GRS. An SMSplex would be one file (common? shared?) for all four lpars? I must go learn more about SMS and SMSplex! Again, Thanks to ALL! John Cullen On Wed, 20 Sep 2006 08:34:46 -0400, Richards.Bob <[EMAIL PROTECTED]> wrote: >Zaromil, > >Under these conditions, I agree with you. But Mr. Cullen wanted to >allocate from all sides and not DISNEW anything. > >As Seymour would say, "Not my dog". > >Bob Richards > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >Behalf Of TISLER Zaromil >Sent: Wednesday, September 20, 2006 7:51 AM >To: [email protected] >Subject: Re: SMS question - sharing DASD but not SMS environment > ><snip> >We want to share a few DASD among our four Lpars and have SMS >doing allocation. Each Lpar runs z/OS as a monoplex seperate >from the others. Two are 1.4 and two are 1.7 right now. >We do not have any kind of sysplex. Nor do we have an SMSplex, >whatever that is. > >We would update SMS rules in every Lpar to indicate these >volsers in an SMS storage group and set up storageclass, dataclass >& mgmtclass. Each high level qualifier would be setup in every >Lpar's master catalog using an existing ucat on a non-SMS dasd >that is online to all lpars. > >Would SMS for lpar-P get confused if SMS for lpar-D was allocating >a file on those dasd at the same time she was? Does SMS from one >lpar need to know what SMS from the other lpar is doing? ><snip> > > >Our example: >- sysplex A (production) with 5 systems z/OS 1.7, GRS star >- sysplex B (test) with 1 system z/OS 1.7, GRS star > >The volumes used to transfer data from sysplex A to sysplex B are SMS >managed, defined in both SMSes. > >Allocation of datasets containing data to be transfered is possible >only in >the sysplex A (source). In the sysplex B (test) shared volumes are >defined >with DISABLENEW attribute, so it is not possible to allocate them. The >usercatalog is on one of the shared volumes (SMS managed). > >It works like this for some years now. > >If you want to be able to transfer data in different directions, you >could >control the allocation the way we do, or using security definitions, or >ASC >routines. > > ---------------------------------------------------------------------- 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
