• Remote system reboot

    From Mike Luther@1:117/3001 to Gord and Herbert on Tuesday, November 20, 2007 13:07:08
    Well, thanks to you both, I did get a successful reboot on the remote OS/2 BBS box with HyperHost for the first time ever! But the story is even more interesting.

    I remotely sent out the SHTDWN16.ZIP file SHUTDOWN.EXE and my custom REXX .CMD file to the remote box. It was jammed so that even though I could connect to it either via HyperAccess for OS/2 or modem to the Bink/Max BBS operation, if I
    got to it with HyperAccess I couldn't do anything with the OS/2 remote desktop operation once connected. So in this case, I connected with Bink/Max and exited to the SysOp command line OS/2 window in MAX there. OK, set up the desired operation, ran the REXX file with a correct password. As expected, the
    remote operation dissapeared off the modem connect line into the BBS connection.

    It wouldn't connect again either, so indeed, the system had dropped the BBS operation as a result of SHUTDOWN.EXE. But wait! There's more!

    Curiously, the HyperHost phone line answered then. And curiously, when the remote desktop came up, sure enough the Bink/MAX BBS object wasn't working there either at that point. As well, the OS/2 shutdown process was apparently 'stuck' on a question as to whether to shut down HyperHost in a 'typical' OS/2 sys-admin grey box request to close this application as well!

    Hmmmmm .. Apparently, what SHUTDOWN.EXE did was to kill off the BBS, but couldn't automatically kill the HyperHost object on the way to the automatic reboot that was part of the <SHUTDOWN /a5 /b> command line I fed to it by the REXX script.

    Hmmmmm .. I could have told the remote desktop to just go ahead and shut it down. I think that would have resulted in the SHUTDOWN.EXE application getting
    to 'correctly' complete the OS/2 shutdown operation,cleanly. And then per the expected instructions, I'd get an automatic reboot of the system. Which in this case always starts per the OS/2 setup with all the right stuff running for
    the whole remote system from scratch.

    But in this case, for experimental purposes, knowing that the Bink/MAX BBS operation was, indeed, already not running, I chose to instruct the HyperHost to do a reboot from the pull/down pointer menu pane in the HyperAccess control panel from the local operation here.

    I waited a few minutes, wondering if I had a 50 mile trip or not.

    WONDERFUL! On call back, both the BBS was working, as well as the HyperHost remote desktop! And without making the long drive, I was, for the first time, remotely able to clear the crippled desktop. I was able to do a complete remote OS/2 remote desktop maintenance run on it. Without making the long drive
    out there to clean things up.

    When I get to where I've got to go by the place anyway next time, I'll try this
    whole remote seance deal and go ahead and tell the remote desktop to shut down the HyperHost application on the run to the SHUTDOWN.EXE way of rebooting things. I suspect I'll get the full reboot operation remotely done correctly that way also. But I didn't want to risk the drive out trip right now to test that.

    Thank you both for motivating me to work this out, as well as point me toward the utility that works so far at this.

    Sleep well; OS/2's still awake! ;)

    Mike @ 1:117/3001

    --- Maximus/2 3.01
    * Origin: Ziplog Public Port (1:117/3001)
  • From Gord Hannah@1:17/23 to Mike Luther on Tuesday, November 20, 2007 16:26:51
    Replying to a message from Mike Luther 1:117/3001 to Gord and Herbert,

    About Remote system reboot, On Tue Nov 20 2007

    Thank you both for motivating me to work this out, as well as point
    me toward the utility that works so far at this.

    Coming from an OS/2 guru, you are welcome.

    Hope this helps. Keep us posted.

    We are a fine board trying to make it better.
    Cheers! Gord
    -=Team OS/2=-
    --- timEd/2 1.10.y2k+
    * Origin: Marsh BBS (c), Dawson Creek, BC Canada (1:17/23)