> So while I appreciate the frustration of having to worry about SFS when > you haven't in the past, the time has come for us to exploit something we > introduced over 20 years ago in VM/SP Release 6.
While I agree in principle, I think that if this is to be the case, there needs to be some fairly major work done on the management and configuration interfaces of SFS servers before SFS exploitation becomes a Big Stinking Deal. The current interfaces and configuration methods are fairly arcane even for experienced CMS admins, and I dread having to explain any of the current stuff to total z/VM newbies. There's just too much embedded history there for the current approach to be understandable to someone who just wants to run Linux guests and doesn't have any other CMS workload than maintaining CP. I'd like to see something like an Aperi (www.eclipse.org/aperi) agent for SFS servers, or at least a better interface in IBM Director for managing SFS before you start forcing it on people. Even a simple exec to build a new pool configuration and do some basic sanity checking would be an improvement over the current setup. There also needs to *always always always* be a way to redirect the location of files for any product that needs SFS services to a user-specified SFS filepool -- I think one of the things that's so annoying about the SFS requirement for DFSMS is that it CAN'T be moved out of VMSYS: without doing some really incredibly arcane stuff with APPC configuration, which gets clobbered/rebuilt with new releases of the code. I know I'd be a lot less irritated with it if I could build a separate SFS server for "Configuration Stuff" -- putting the configs for a product in VMSYS: violates Mother's First Law, IMHO. -- db
