Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!UMIX.CC.UMICH.EDU!krowitz%richter
From: krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz)
Newsgroups: comp.sys.apollo
Subject: Re:  Apollo prmgr troubles
Message-ID: <9003081502.AA02337@richter.mit.edu>
Date: 8 Mar 90 15:02:52 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 54

In regards to the problem of the print manager (/sys/hardcopy/prmgr)
and the print server (/sys/hardcopy/prsvr) not talking to each other,
I have come up with yet another point which system managers will need
to check ...

I recently started running multiple global location brokers on my network.
Up to this time I had no problem running the print server on one node (the
node to which the printer was attached, of course), the print manager on
another node, the pre SR10 print queuing program (/sys/hardcopy/pre10q) on
yet a third node, and using the prf command from anywhere I liked.

After starting up two addition copies of /etc/ncs/glbd (for a total of 3
global location brokers) in order to make certain that the whole net would
be able to continue operating if my master node went down, I found that the
various components of the SR10 printing system could not talk to each other
unless they were running on the same node. The two additional replicas of
the global location broker had been started according to the example given
in the help file, ie:

      /etc/ncs/glbd -create -from dds://orginal_glbd_node

When I ran /etc/ncs/drm_admin to check the state of the glbd databases, I
found that not all of the replicas were known to each other, so I used the
"addrep" command to add the replicas to the list, and then the "merge_all"
command to merge the replicated databases. As soon as this was completed,
the print server and the print manager (which were running on two seperate
nodes) saw each other, registered the printer with the manager, and began
operating. Here's the sequence of commands I used (for those who are not
familiar with drm_admin):

$ drm_admin
drm_admin: set -o glb -h dds://original_glbd_node
drm_admin: addrep dds://second_glbd_node
drm_admin: addrep dds://third_glbd_node
drm_admin: merge_all


One interesting note ... the "merge_all" command only worked when I used
the "set" command to operating on the original glbd node. When I tried to
use one of the other nodes as the hub for the merge, drm_admin refused to
do the merge because the system clocks on the three nodes were out of sync
by a minute or two ("skewed" is the term drm_admin uses). When I set
drm_admin to use the orginal glbd node as the default host to use as the
hub of the merge operation, I still get the messages about the skewed clocks,
but the merge operation is completed despite the messages. Any NCS experts
out there who can shed some light on what is going on?


 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter.mit.edu@eddie.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)