From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 11-MAR-1994 15:43:07.64
To:	EVERHART
CC:	
Subj:	Thoughts On SMISERVER Usage Over Wide Network/Node Topology...

Date: Thu, 10 Mar 1994 22:42:07 -0500 (EST)
From: "Clayton, Paul D." <CLAYTON@radium.xrt.upenn.edu>
To:   fowlerk@southpower.co.nz
CC:   INFO-VAX@SRI.COM, CLAYTON@radium.xrt.upenn.edu
Message-Id: <940310224207.42200b56@radium.xrt.upenn.edu>
Subject: Thoughts On SMISERVER Usage Over Wide Network/Node Topology...


Ken Fowler @ "fowlerk@southpower.co.nz" asks the following question.

>Does anyone know if the SMISERVER has a documented interface??  I wan't to
>write a program similar to sysman that can perform commands on remote
>machines but I am not happy with sysman's interface.  Thus if it were
>possible I would like to write my own interface that makes use of the
>smiserver.  I wan't to write a program that can do things like this...
>
>$ mysysman :== $ site_utilities:mysysman
>$ mysysman/node=(nodea,nodeb)/user=????/pass=????  command-string
>
>I would use sysman but it is difficult from command procedures because you
>can't supply some of the stuff on the command line which makes symbol
>substitution difficult.  So, anyone know if SMISERVER is documented??  Or
>does anyone know of a better/different way to this??

We have long used the SMISERVER process to perform all sorts of tasks on both 
clusters and standalone nodes for years now. Using SMISERVER made life easier 
for doing all sorts of things. 

The basic problem that I ran headlong into was the DCL limitation on length of 
the command line data entered at such points as what nodes we wanted to 'talk 
with'. I did not want to constantly type 80+ nodenames in, and DCL would 
complain long before I got anywhere near 80.

After poking around the SYSMAN book and asking several questions to CSC, I 
ended up with the DCL procedure attached below, that we have called 
DO_SYSMAN.COM.

The cornerstone of the procedure is its use of a special logical name table on 
the local node which contains logical names, the equivelance names of which 
contain the node names we want to deal with. Using the logical names, 
eliminates any limitation on how many nodes can be accessed in sequence.

What we have done is 'build' logical names one on top of the other until we 
get all nodes listed by one name. For example:

	- logical name of 'endnodes' is all the standalone nodes
	- logical name of 'cluster' is ONE boot node PER cluster, all clusters
	- logical name of 'cluster_boot' is ALL boot nodes for ALL clusters
	- The case of 'ALL' is handled, not by one logical, but by combining
		logicals. See DCL below for specifics.

These logical names can then be selected based on the action being performed 
and on what nodes it needs to be performed on. 

The command line for its use would be something like:

	@do_sysman all "submit/que=sys$batch/nolog xx.com" "show que/bat/all"

This command would result in the following sequence occuring.
	- The username to be used is DEFAULTED to your current username. If
		someone wants to use a different username, the procedure is 
		easily changed to accomplish this.
	- once SYSMAN detects that the node list you specified contains node 
		'outside' your node/cluster, you will be prompted for the 
		password to the account you are currently logged into.
	- The 'envirnoment' for SYSMAN is established based on the equivelance 
		strings for the logical name(s) specified, in this case 'ALL'.
	- The first command "submit/que=sys$batch/nolog xx.com" is executed on 
		all the nodes that were selected.
	- The second command "show que/bat/all" is then executed on all the 
		nodes selected.

Depending on how you coded the command line, there could even be symbol 
substitution on the node originating the DO_SYSMAN usage. 

There are several caveats with this type of usage.

1. The SMISERVER process is NOT startd by default on standalone nodes under 
VMS. In order to get the SMISERVER process running on standalone nodes, 
include the following in your boot sequence somewhere.
	@sys$system:startup smiserver		!start SMISERVER process

2. It is VITAL to remember and understand the 'context' of how the command you 
specified is executed on the REMOTE NODE! Any and all symbols/logicals you 
need on the remote node MUST ALREADY BE on the remote node UNLESS you supply 
them somewhere in your commands. In other words, you local process symbols and 
logicals are NOT available to you on the remote node unless you execute 
'something' to establish them yourself.

3. IF there is a node that you have NOT started the SMISEVER process on, yet 
you reference it in your logical names, then the SMISERVER process will be 
created for you on the remote node. This thanks to VMS shipping a 
SYS$SYSTEM:SMISERVER.COM procedure. The issue here is that the process will 
NOT have the name of SMISERVER and in some cases you can end up in a locked 
out SMISERVER state due to logical name usage by SMISERVER. Best you start it 
in the boot files and let it run from then on.

4. There is currently a 30 second time limit on waits for remote nodes to 'come 
back'. This time may not be large enough depending on network topology, node 
resources and their consumption. Try 30 seconds. It you get timeouts all over 
the place, then you might want to increase it. It it is random timeouts, then 
look to 'hung' SMISERVER processes. Kill them off and start a new one in its 
place.

5. There is a common problem in SMISERVER usage that will end up with the 
process gone and a SYS$SYSTEM:SMISERVER.DMP file on disk. ANALYZE/PROCESS of 
the dump file will show a 'BAD_LOAD address' (or some such wording) error. In 
our case, we get them all the time. I have yet to hear/see about ANY fix for 
this type of problem. CSC knows about it. Just restart the SMISERVER, delete 
the dump and get on with it.

Other then that, it works great. Stops having to log in all over the place. I 
got in the habit of creating a DCL command file that did what I wanted (if it 
needed more then one line) and then referencing it in the DO_SYSMAN.COM 
command line. Having DFS setup and configured all around made this type of 
usage a snap. I could reference a file on my local node from the REMOTE node 
as if it was ON the REMOTE node using the DFS disk specification.

Have fun.

pdc


Paul D. Clayton 
Address - CLAYTON@RADIUM.XRT.UPENN.EDU		(USA)

Disclaimer:  All thoughts and statements here are my own and NOT those of my 
employer, and are also not based on, or contain, restricted information.


---------------

DO_SYSMAN.COM....

$goto start
$!
$! The following procedure will take as paramaters the statements that are
$!      needed to execute on various nodes. The selection of which nodes to
$!      run the commands on is based on the P1 parameter. Legal settings for
$!      the target of the commands are:
$!
$!              ALL     Will run on ALL clusters AND end nodes.
$!                              Needed Symbols Are = CLUSTER_BOOT and ENDNODES
$!              CLUSTER Will run only on one member of each clusters.
$!                              Needed Symbol Is = CLUSTER
$!              END     Will run only on the END nodes
$!                              Needed Symbol Is = ENDNODES
$!              BOOT    Will run on ALL the Boot nodes for the various clusters.
$!                        Even if more then one boot node exists for a cluster,
$!                        all boot nodes will be targeted.
$!                              Needed Symbol Is = CLUSTER_BOOT
$!
$!      If you want the commands to be executed on ALL nodes WITHIN each 
$!	cluster you MUST right your own command file which will execute 
$!	SYSMAN within each cluster. If ALL is chosen, then both the ENDNODE
$!	and cluster members will have the commands executed on them.
$!
$!      The P2, P3 and P4 parameters contain the commands that you want to
$!      have executed on the nodes. They should be enclosed in '"' characters
$!      and  DO ***NOT*** including the 'DO' prefix.
$!
$!      An example command line would be as follows.
$!        @do_sysman all "submit/que=sys$batch/nolog xx.com" "show que/bat/all"
$!
$!	Note that if MORE then ONE command is specified for execution, they 
$!	will be executed SERIALLY among the nodes selected. Meaning that the 
$!	FIRST command will execute all around, then the SECOND and so forth.
$!
$!      Note that the password to be used on the systems will still be
$!      prompted for entry during the course of executing the procedure.
$!
$!      pdc - 10/31/90
$!
$! Add in line to set the TIMEOUT value to 30 seconds when going around using
$!      SYSMAN. This will stop the HANG forever problem with the utility and
$!      a node that does not want to respond.
$!      pdc - 6/17/91
$!
$! Make major changes to this procedure to allow for large node name lists and
$!      make use of the logical name table to stop the problem with these
$!      large node lists. 
$!      pdc - 7/22/91
$!
$start:
$set noon               !continue at all costs...
$on control_y then $goto exit_point             !delete the file if terminated
$!
$! First we want to define the node names that are to be used
$!
$! First we have to handle the case of creating the logical name table in
$!      SYSTEM space and then populating it with the names of the nodes.
$!
$create/name_table/nolog/parent=lnm$system_directory sysman$node_table
$!
$! The next logicals are for all the end nodes that we will be dealing with.
$!
$define/nolog/table=sysman$node_table endnodes endnodes1,endnodes2,endnodes3
$define/nolog/table=sysman$node_table endnodes1 node1, node2, node3 
$define/nolog/table=sysman$node_table endnodes2 node4, node5, node6
$define/nolog/table=sysman$node_table endnodes3 node7, node8, node9
$!
$! The next names are for ONE node per cluster, and since we don't care WHICH
$!	boot node, we will use the cluster ALIAS names here.
$!
$define/nolog/table=sysman$node_table cluster alias1, alias2, alias3, alias4
$!
$! The next names are for ALL boot nodes for ALL clusters.
$!
$define/nolog/table=sysman$node_table cluster_boot boot1, boot2, boot3, -
	boot4, boot5, boot6
$!
$! Now check to see what nodes we are to run on.
$!
$targets = ""           !define initial state, check later to see if changed
$if (p1 .eqs. "ALL" ) then $targets = "ENDNODES,cluster_boot"
$if (p1 .eqs. "END") then $targets = "endnodes"
$if (p1 .eqs. "CLUSTER") then $targets = "cluster"
$if (p1 .eqs. "BOOT") then $targets = "cluster_boot" 
$!
$if (targets .eqs. "")                  !now check to see if something legal
$then                                   !  was entered as P1...
$  type sys$input
 The P1 is UNKNOWN. This specifies the 'group' of nodes to do the requested
 operation on. Please supply on of the following.

              ALL     Will run on ALL clusters AND end nodes.
                              Needed Symbols Are = CLUSTER_BOOT and ENDNODES
              CLUSTER Will run only on one member of each clusters.
                              Needed Symbol Is = CLUSTER
              END     Will run only on the END nodes
                              Needed Symbol Is = ENDNODES
              BOOT    Will run on ALL the Boot nodes for the various clusters.
                        Even if more then one boot node exists for a cluster,
                        all boot nodes will be targeted.
                              Needed Symbol Is = CLUSTER_BOOT

$  exit
$endif
$!
$assign/process/nolog   sys$login:sman_spec_file_'f$getjpi("","PID").com -
		sman_work			!get working filename to use
$open/write cmd sman_work
$write cmd "assign/process/nolog  tt sys$command" !tell SYSMAN to get from term.
$write cmd "mcr sysman"                         !invoke SYSMAN utility
$write cmd "set env/node=(''targets')"          !tell the nodes we are working
$write cmd "set timeout 00:00:30"               !set timeout max at 30 seconds
$write cmd "do ''p2'"           		!enter the first DO command
$if p3 .nes. "" then $write cmd "do ''p3'"      !then the next one
$if p4 .nes. "" then $write cmd "do ''p4'"      !then the next one
$close cmd                      		!done writing, close it out...
$set noon                       		!continue if any errors...
$@sman_work                     		!now execute the procedure built
$!
$exit_point:
$!
$delete/noconf/erase -
     sys$login:sman_spec_file_'f$getjpi("","PID").com;* !destroy any evidence
$exit
$!
$! Now we will deal with the error of not being able to create the logical
$!      name table.
$!
$no_table_create:
$type sys$input

        You do not have sufficient privs to create the logical name table
        SYSMAN$NODE_TABLE in the SYSTEM directory. You must have SYSNAM
        priv to run this procedure.

        Aborting the procedure.

$exit
$!


