Thanks, Kris, this actually looks like exactly what we want to accomplish. I'll give it a shot and follow up with how it all ends.
I'm learning a lot. And isn't that the point? ok r. > -----Original Message----- > From: Kris Buelens [mailto:kris.buel...@gmail.com] > Sent: Wednesday, May 06, 2009 1:23 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: local filepools > > By using an entry in the SCOMDIR NAMES file, you can assign a > real, unique, filepoolid to each server, but keep the name > the users are used too. > E.g; > > :nick.oldpool :tpn.uniquepool > > But, it is then required that during an IPL CMS session, you > use the same name to refer to the pool, either the unique > one, either the old name. At my customer's installation we > lived like that for about 20 > years: each system had an SFSnn (real poolID), but it was > normally referred to as SFSD: No problems whatsoever. > > 2009/5/6 Alan Altmark <alan_altm...@us.ibm.com>: > > On Tuesday, 05/05/2009 at 04:23 EDT, "Stricklin, Raymond J" > > <raymond.j.strick...@boeing.com> wrote: > > > >> It seems like I should be able to make these filepools local only, > >> but the documentation is pretty unequivocal that unless the > >> repository filepool names begin with VMSYS that they are to be > >> configured as global pools. > >> > >> Is there anything that is really stopping me from changing > the IUCV > >> *IDENT GLOBAL to IUCV *IDENT LOCAL for the two filepools on these > >> three nodes, and then moving on? > > > > Yes. You will cause SFS server initialization failures (message > > DMS3135E). Any filepool whose name does not begin with > "VMSYS" will > > be a global filepool. If you don't authorize the server to > do the thing that > > it has been configured to do, it will complain and die. > By selecting a > > name that doesn't begin with "VMSYS" you have instructed > SFS to define > > the filepool as global resource. > > > >> I ask because I notice that VMBACKUP owns a filepool that has IUCV > >> *IDENT LOCAL set, with a name that does not begin with VMSYS. I > >> haven't been able yet to learn anything about this > particular pool, > >> though, or how it's used, so I accept that it is possible > for it to > >> have some operational characteristic that makes this > possible, where > >> it wouldn't otherwise be generally. > > > > Whatever VMBACKUP owns, then, it isn't a filepool. Not all > resource > > names (QUERY RESOURCE) are SFS filepools. > > > > Alan Altmark > > z/VM Development > > IBM Endicott > > > > > > -- > Kris Buelens, > IBM Belgium, VM customer support >
