dennis@Peanuts (Dennis Cottel) (12/07/89)
Warning: Apollo complaint follows.
lori@hacgate.UUCP (Lori Barfield) sends us a nifty shell script including
some constructions like:
> /com/lcnode -b -id | /com/fpat -i -c -rm 2 ^node | read num_matches
The trouble with this is that if you have an Apollo internet--for
instance, several rings connected via Ethernet--commands like lcnode
and lusr display only information for the local subnet. There is no
option on them to display all the connected nodes in the Apollo
internetwork.
This means that when you go to an internetwork, suddenly all the shell
scripts in which you used tricks like the above to find all the nodes,
or update all the disks in the network, don't work anymore and have to
be modified. And changed again when you add another subnet. Some of
the nice network transparency that is Apollo's strength has been
taken away.
I complained about this to the Apollo hotline, as well as submitted an
APR. Apollo's response was essentially, "That's the way it works."
Nuts.
Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152
(619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennisjshoj@EARTH.LERC.NASA.GOV ("Jeffery Hojnicki") (12/07/89)
Dennis Cottel writes: >lori@hacgate.UUCP (Lori Barfield) sends us a nifty shell script including >some constructions like: > >> /com/lcnode -b -id | /com/fpat -i -c -rm 2 ^node | read num_matches > >The trouble with this is that if you have an Apollo internet--for >instance, several rings connected via Ethernet--commands like lcnode >and lusr display only information for the local subnet. There is no >option on them to display all the connected nodes in the Apollo >internetwork. > >This means that when you go to an internetwork, suddenly all the shell >scripts in which you used tricks like the above to find all the nodes, >or update all the disks in the network, don't work anymore and have to >be modified. And changed again when you add another subnet. Some of >the nice network transparency that is Apollo's strength has been >taken away. Although this is true for some applications, the instance sited is easily fixed with the lcnet command. Use lcnet to get a listing of the connected networks and then do an lcnode on each network. A script to do just that follows. Jeff Hojnicki -- My opinions are not those of NASA NASA LeRC JSHOJ@earth.lerc.nasa.gov Some of the lines in my scripts are not always the most elegant, but they usually get the job done. --------------------CUT HERE------------------------------------------------ #!/com/sh eon # Get connected net id's NETS := ^"lcnet -c | chpat '{????????}?*' '@1'" # substitute appropriate options on lcnode command # .aaaa is needed on the from node spec, but any hex code will do for NET in ^NETS by word args "^NET" | read -type string THISNET lcnode -b -id -from ^THISNET.aaaa endfor
dennis@Peanuts (Dennis Cottel) (12/08/89)
After I said: > ... commands like lcnode > and lusr display only information for the local subnet. ... jshoj@EARTH.LERC.NASA.GOV ("Jeffery Hojnicki") writes: > ... the instance sited is > easily fixed with the lcnet command. Use lcnet to get a listing of the > connected networks and then do an lcnode on each network. A script to do > just that follows. Granted. My point, though, is that you shouldn't *have* to write shell scripts to do these kinds of things; basic system support tools should be supplied as part of the system. Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis