From: rasure@nell.eece.unm.edu (John Rasure)
Newsgroups: comp.soft-sys.khoros
Subject: (none)
Date: 6 Apr 92 17:03:47 GMT
Article-I.D.: pprg.37295


In "", Bob Clark (ISD) x7123 (csh) writes:
+ 
+ I can get the distributed processing to operate well between DG,
+ SGI, and SUN on our Reston LAN.  I can even get the distributed
+ processing functionality to work for a DG in Menlo, California 
+ using Reston, Virginia DG, SGI, and Sun processors.  But when 
+ trying to go the other way, i.e. running cantata in Reston and 
+ distribute processing to a Menlo processor(named xian), I get a 
+ message like the following:
+ 
+  editimage: Cannot access "/usr/tmp/vheqBAAa00415@xian.wr.usgs.gov"
+  for reading 
+ 
+ The local Reston editimage routine can not access a remote 
+ Menlo vheq output file.  The above "vheqBAAa00415@xian.wr.usgs.gov" 
+ file does not exist in the remote's /usr/tmp area, yet the vheq glyph's 
+ on/off switch indicates the remote vheq routine ran ???  Could this 
+ be a problem having to do with some gateway specification or 
+ (LAN configuration issue) ???


Can't explain the non-existant file.  Is this problem persisting with Patch 5?
The reason that the glyph thinks it ran ok even though it didn't is because
the kexecvp() call is not getting status back from the remote machine ...
so it thinks it ran ok.


+ 
+ Have another question on distributed processing.  Currently, all
+ my account login ids are bclark.  What happens when, let's say at
+ SDSC or LANL, I'm given a different account login id, e.g. bozo.
+ Do I put in my remote bozo account's .rhosts file an entry for bclark
+ such as "sun4bta.er.usgs.gov bclark" ???   I've tried using this 
+ approach for remote shell execution, rsh/remsh.  Not much success.
+ I get a message of "Login incorrect."  Will this approach work for 
+ Khoros ???   This is important issues for those using Khoros in a 
+ multi-managed distributed environment.  Everyone has their own way 
+ of managing.  Any help is appreciated.

If the machines that you are using support "r"commands, you can often
start the necessary daemon ... but if they are not supporte because of
security or becuase of incompatibility, then start the daemon by hand.

The cantata manual explains how to start a remote daemon by hand.  This
is provided so that you can have different login ids on different machines
and so that you don't have to set up .rhosts.

+ 
+ Been looking at a Patch 3 version of concert.  I used a command similar
+ to the following:  
+ 
+   convert -command cantata -d2"some other system name" &
+ 
+ I'm running between different architectures again,  DG, SGI, and SUN.
+ When I select from the main cantata workspace, different subforms popup 
+ on each of the two systems.  I can select the "routine" subform to 
+ popup on both systems, but when I select from this subform, different 
+ routines and the resulting glyphs are different between the machines.  
+ Is there some environment variable that I have to consider changing 
+ for one or both systems ??? Or is the problem with the Patch level I am 
+ using.  Except for the DG, binaries come from UNM.

Concert is in the prototype stage.  It shows the feasibility of remote
collaboration, but lacks the sophistication it needs to be really
productive.  The cantata application has the most limitations with respect
to concert .... 

+ 
+ Dennis and my Division are working on Survey's affiliate membership.
+ 

That is good to here.  The consortium is beginning to pick up momentum, having
USGS sign up will be very important for the project.

+ bclark@sun4bta.er.usgs.gov
End of message from Bob Clark (ISD) x7123 (csh)
Newsgroups: comp.soft-sys.khoros