Routing DFSMS to some other filepool that VMSYS is very very easy: Create a file UCOMDIR NAMES on the A-disk of all DFSMS machines, (I think all servers link to SMSMASTR 191 as 191) In the UCOMDIR NAMES, add 1 line: :nick.VMSYS :tpn.mySFSsrv No more, no less.
When this file is activated (by SYSPROF EXEC at IPL CMS), whne DFSMS tries to use something in VMSYS:DFSMS.xxxx CMS will rerpoute it to mySFSsrv:DFSMS. I was one of the people exploiting SFS from day one when VM/SP R6 came out. We had indeed some bugs, but never lost any data; my customer depended heavily on SFS: no SFS meant no batch load at night. One did not need to stay away from it. But, one needs to take care of it, and look at how one need to back it up (a plain DDR while it runs is not suited). 2008/5/6 David Boyes <[EMAIL PROTECTED]>: > > > 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 > -- Kris Buelens, IBM Belgium, VM customer support
