Re: local filepools
Kris; Doing the SCOMDIR NAMES trick worked perfectly. The only surprise was having to rename the LUNAMEs on the CRR recovery servers as well, as they are also global resources and were the same on all three nodes. I was able to rename the global filepools to be unique on each node, and didn't have to change any of the code that still referred to the old names. Once that was done, and the CRR LUNAMEs were changed, we were able to join all three nodes to the ISFC collection without error. The processes for renaming these resources are both in the z/VM Planning and Administration guide. I was able to follow them pretty well despite knowing little about SFS when starting. 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
Re: local filepools
On Wed, May 6, 2009 at 1:58 AM, C. Lawrence Perkins vmwiz...@ix.netcom.com wrote: Be sure to also check the DMSPARMS files for the filepools and pull any REMOTE statement that might be in them. If REMOTE is not specified, you can't access the data from another system in the collection. But it does not free you from the requirement that the resource names must be unique.The other names are still visible and prevent you from having a local resource with the same name. And you also need to look at the CRR server resource name. Rob
Re: local filepools
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
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
Re: local filepools
Not exactly. Any filepool that does not start with VMSYS is eligible to be made global, but it doesn't have to be. You have to specify REMOTE in the DMSPARMS file before it becomes global. Without that, it is local. You think that IBM would not allow user created filepools that are local? Have you been borrowing cough syrup from Adam again? Adam, check your supply. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Wednesday, May 06, 2009 1:31 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: local filepools By selecting a name that doesn't begin with VMSYS you have instructed SFS to define the filepool as global resource.
Re: local filepools
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
local filepools
Folks; I would like to join three VM nodes to an existing ISFC collection, with the intent to grant access to an already-existing remote filepool. This seems straightforward enough except the three new VM nodes each are configured with two identically-named filepools. The three new nodes are not part of any ISFC collection now, so there is no problem there. I understand it is possible to rename these filepools so that the names are unique across all three nodes, and then it would be simple to join the ISFC collection. However, I would prefer to leave the existing filepools alone. 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. Why is this? 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? 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. Thanks! ok r.
Re: local filepools
The documentation is meant to say that VMSYSbanana cannot be anything but local while any other name not beginning with VMSYS can be either local or global. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Stricklin, Raymond J Sent: Tuesday, May 05, 2009 1:21 PM To: IBMVM@LISTSERV.UARK.EDU Subject: local filepools Folks; I would like to join three VM nodes to an existing ISFC collection, with the intent to grant access to an already-existing remote filepool. This seems straightforward enough except the three new VM nodes each are configured with two identically-named filepools. The three new nodes are not part of any ISFC collection now, so there is no problem there. I understand it is possible to rename these filepools so that the names are unique across all three nodes, and then it would be simple to join the ISFC collection. However, I would prefer to leave the existing filepools alone. 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. Why is this? 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? 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. Thanks! ok r.
Re: local filepools
Be sure to also check the DMSPARMS files for the filepools and pull any REMOTE statement that might be in them. On Tue, 5 May 2009 13:20:46 -0700, Stricklin, Raymond J raymond.j.strick...@boeing.com wrote: Folks; I would like to join three VM nodes to an existing ISFC collection, with the intent to grant access to an already-existing remote filepool. This seems straightforward enough except the three new VM nodes each are configured with two identically-named filepools. The three new nodes are not part of any ISFC collection now, so there is no problem there. I understand it is possible to rename these filepools so that the names are unique across all three nodes, and then it would be simple to join the ISFC collection. However, I would prefer to leave the existing filepools alone. 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. Why is this? 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? 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. Thanks! ok r. = ===
