SYSMAN protocols

[Wim Van den Wyngaert]

I did the following :

$ set ho alp23
%SYSTEM-F-UNREACHABLE, remote node is not currently reachable
$ sysman
SYSMAN> set env/node=alp23
Remote Password:
%SYSMAN-I-ENV, current command environment:
Individual nodes: ALP23
At least one node is not in local cluster
Username SYSMGR_WVW will be used on nonlocal nodes

SYSMAN> do show time
%SYSMAN-I-OUTPUT, command execution on node ALP23
%SYSMAN-I-NODERR, error returned from node ALP23
-SYSTEM-F-UNREACHABLE, remote node is not currently reachable
SYSMAN> Exit
$ rl salpv1
[TNDRIVER: Proxy login for user "SYSMGR_WVW" in progress ...]

>set ho alp23
%SYSTEM-F-UNREACHABLE, remote node is not currently reachable
>mc sysman
SYSMAN> set env/node=alp23
%SYSMAN-I-ENV, current command environment:
Individual nodes: ALP23
Username SYSMGR_WVW will be used on nonlocal nodes

SYSMAN> do show time
%SYSMAN-I-OUTPUT, command execution on node ALP23
24-DEC-2004 09:14:02
SYSMAN> Exit

Is sysman using the cluster protocol to reach other cluster nodes ?

Wim

[Uwe Zessin · Accepted solution]

Yes. By the way: have you noticed that you don't get asked for a password as long as you environment is limited to the cluster?

[Volker Halle]

Wim,

SYSMAN uses SCS in a local cluster (communicates with CSP = CLUSTER_SERVER process). For a remote node, it uses DECnet.

Described in VAXcluster Principles book by Roy G. Davis, Chapter 8.5

Volker.

[Wim Van den Wyngaert]

Uwe,

Yes I did. But I'm an infrequent sysman user. I have another tool that creates "normal" processes that have gone thru a login. But it needs decnet or IP which I don't have towards alp23 (thank you network team).

Wim

[Uwe Zessin]

Ah, you said you have one big homogenous cluster, right?

I used to manage a number of small clusters scattered around Germany. Fortunately, all were reachable via DECnet and we made quite some efford to have the clusters look identical. SYSMAN (which appeared in VAX/VMS V5.0) certainly helped managing all the systems - a big thank you to VMS engineering!

[Wim Van den Wyngaert]

Uwe,

Only a pitty that login.com is not executed in the process.

Wim

[Robert Gezelter]

Wim,

Actually, on more than a few occasions I have been very happy that LOGIN.COM was not executed.

When dealing with problems at client sites, the SYSMAN connection has often been the only way into a remote machine when DECnet and IP did not (or had not) yet started. SYSMAN allowed me to get into the system and fix the problem.

If the LOGIN.COM had been executed, it might have been very difficult to actually login.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

Rob,

That's why I use my own tool. I can type commands in the way I am used too. And the process stays alive and can receive multiple commands.

I use sysman in case of big problems only.

set env/login/cluster would be an improvement.

Wim

[Jan van den Ende]

Wim,


Only a pitty that login.com is not executed in the process.


As per Bob's answer it should be clear that that would NOT ALWAYS be desirable.

And something else: it probably would not do you much good.
Each separate SYSMAN command stands on its own, and any symbol setting or logical name definitions executed in, eg, LOGIN.COM are GONE the moment you get back to the SYSMAN> prompt!

The way around that is to have your sequence of commands (say, DEFINE SYS$LOGIN ; @LOGIN.COM ; @work-to-do ) in one file, and define SYSMANINI to point to that file.

Not so easy to set up an environment and do some 'inter-active' work, though.

hope this helps some,

Proost.

Have one on me.

Seasonal greetings to all!

jpe