SYSMAN over TCP/IP

[Mark Hurcombe]

I know there have been discussions about this, pretty well all involving the of Decnet over IP. We currently do this and it is fine in most cases.
As part of the site specific shutdown procedure on a system we would like to use Sysman to execute commands on at least one remote node - that is a node that is not in the local cluster. My understanding is that this requires the use of Decnet. The problem is that one of the first things that shutdown does is stop Decnet (and the job controller) - this occurs before the site specific shutdown is invoked. It would be nice if Sysman could communicate to remote nodes using TCP/IP in a similar way to how the DCL monitor command uses TCP/IP (by running vpm$startup.com during system startup)
This probably wouldn't be an issue if Decnet was shutdown late in the shutdown process.

[Hoff]

Repost. ITRC glitched.

It would seem easier to change how you shut down your servers. The brute-force approach here would be to add a few site-specific lines at the top of the SHUTDOWN.COM procedure. That would need to be retrofit after upgrades and such, and would not be considered supported. The (more) supportable approach is to use your own shutdown commands, which prepare the servers and then issue the appropriate OpenVMS SHUTDOWN processing.

If you think IP is still running (and I'd not bet that would be an entirely reliable assumption during a typical OpenVMS shutdown), you can invoke commands remotely with rsh, rexec and such.

The reverse approach is to maintain a connection, and have the remote host detect the shutdown and act accordingly. Whether due to a connection dropping, or periodic probes or otherwise.

You might contact HP here, too, and ask for a slightly more flexible SHUTDOWN.COM sequence.

There are also open source tools around that manage numbers of hosts; tools that act akin to SYSMAN across hosts in an IP network environment. These tools are primarily targeting Linux and Unix platforms, but there may well be some applicability here depending on your local environment and your willingness to integrate with these.

http://labs.hoffmanlabs.com/node/1044

[John Gillings]

Mark,

If you're not too worried about snooping, you could use RSH to execute remote commands. SSH is more secure, but a bit more fiddly to setup.

If you're prepared to do a bit of self maintenance, I've had a few systems where SHUTDOWN.COM was renamed to REAL_SHUTDOWN.COM, then replaced with a procedure that first questioned "Do you really want to shutdown node NODENAME?" (in response to a legendary accident at one site I worked at where someone accidently shutdown the wrong node and killed a production system), then called SITE_SHUTDOWN.COM, then called REAL_SHUTDOWN.

Downside is you have to maintain the change through VMS updates.

re: Hoff

>You might contact HP here, too, and ask
>for a slightly more flexible SHUTDOWN.COM
>sequence.

Done that, a few times in fact, for exactly the type of reason that Mark is citing. No one seemed very interested.

From my recent experience, OpenVMS engineering seems to have completely lost interest in doing anything other than fixing obvious, overt and serious bugs. They even seem to be doing their best to avoid doing anything about them!

Chances of having any kind of new feature added is just about zero. :-(

[Mark Hurcombe]

Thank you both for your comments. We've discussed many of the ideas you both have suggested. Using Sysman would allow us to use the "standard" shutdown procedures either in the production cluster or the remote DR site, so it seemed to be an ideal and neat solution.
In our environment TCP/IP is the last thing to be shut down in syshutdwn.com so it should be available as a protocol earlier on.
We can work around these things OK.

[Wim Van den Wyngaert]

We disable the startup and shutdown of decnet by using
def/sys net$ignore_decnet true (net$logicals)
def/sys shutdown$decnet_minutes -1 (sylogicals)

And we control the shutdown ourself in our procedures. We like to close stuff before decnet is closed.

Wim

[The Brit]

Without knowing exactly what it is you want to accomplish on the remote system,

you might consider writing a dcl script on the remote node and the doing a "submit/remote" from the system which is shutting down.

Dave