Hello Rob,
I agree that FORCE would not be an option. In case of the linux machine
IBM advised (see below) to setup a secondary console user to shutdown a
linuxmachine and still have the option of communicating with the guest
in case of problems during shutdown. This could also be used in a wakeup
where some wakeup machine issues a shutdown -r on a linux console.
But for the restart triggered by signal, are you sure you could do that?
A SIGNAL SHUTDOWN LINUX01 WITHIN 300 will log off LINUX01 after 300
seconds or before that if the user reports a successfull shutdown. So a
SIGNAL SHUTDOWN will eventually force the user anyway. When the user is
rebooting, is the signal then canceled somehow?
I had a discussion with IBM on that some time ago. I'd liked to see an
option in signal to prevent the shutdown of guests when they do not
shutdown within the timeout period. But IBM did not follow me on that.
When a forced user in not acceptable (databases or jobs cancelled while
processing) they advised not to use SIGNAL. This is true for zLinux but
also for guest VM, VSE and SFS (all of them can trap the signal.)
We had this issue for linuxguests that did not shutdown within the
timeoutperiod due to running processes on the database. Also, A guest VM
will signal users within VM (usually only the VMSYS* filepools) and then
shutdown regardless of the successfull logoff of other services in VM. A
VSE issues only a message in the hardcopy and some eventprocessing
(FAQS-ASO comes to mind) has to ensure the correct shutdown of services
and jobs within VSE. In all of these cases the guest user could still be
shutting down when the timeoutperiod passes and that would be much the
same as using FORCE in the first place.
Regards, Berry.
Rob van der Heij schreef:
You could tweak the inittab to make the 3-finger-salute do a restart
rather than shutdown. You can then SIGNAL the user... (not FORCE
since that would make CP take the guest out after some time despite
the reboot)
