On Thursday, 06/23/2011 at 05:12 EDT, Marcy Cortes <marcy.d.cor...@wellsfargo.com> wrote: > Out of the box, RMSMASTR behaves very badly on a signal shutdown of your VM > system. > > We have to use this to mount tapes in the VTS. > > RMSMASTR has files in VMSYSU: and VMSYS:, which both use signal shutdown by > default. > > RMSMASTR hangs up the shutdown of VMSYS: until your system default shutdown > time is up. That could be very long time. Or not, but not getting all the way > down has required us to need FORCE starts on some systems on occasions, so a > shorter time isn't even helpful. > > So we wrote our own SHUTTRAP thing to issue a DMSMSRM STOP command. > This doesn't reliably work either. It's very timing dependent since this > service machine gets the signal at the same time as VMSERVR and VMSERVS and if > they beat it, the DFSMSRM STOP says not authorized (the auth file is in VMSYSU:) > > I opened a PMR once upon a time and it was rejected. > > We're trying to get things automated enough so that operations does nothing on > the VM side and GDPS which signals the processor controller to shutdown the > LPAR is sufficient. > > > Does anyone else think this should be considered a defect?
I do! I do! Sadly, that doesn't mean much. As pointed out by Kris on prior occasions, you can use UCOMDIR NAMES to redirect RMSMASTER to another server. That private little SFS server, solely to hold the configuration file, would be configured with NOSHUTDOWNSIGNAL. After CA:Operator shuts down RMSMASTER, it can then shut down the SFS. If it doesn't get shutdown normally, no biggie, since you would match this with a change to RMSMASTER's PROFILE EXEC to copy the REAL config file from a minidisk of your choosing into SFS before initializing the server. Then, if you should have to rebuild Private Little SFS from scratch, it doesn't matter - the config file is safe. Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
