At 10:12 AM 1997/09/25 +0200, [log in to unmask] wrote:

<snip>

>The RDTC needs to be configured in NMMGR (to be recognised by the 3k) but
>the download must come from an OV-DTC-manager equipped machine 'close' to
>the RDTC (I'm not sure what I mean with 'close', but I think that if they're
>not on the same segment, the download must be bridged, (I'm really far out
>on a limb here)). On 5.0 you also need an OV-DTC-manager on the host-side to
>tell the FEDTC to turn on RAFCP (not sure about 5.5).

The Navy (where emergency procurements take months, standard priority
procurements can take years) has found itself in situations were the
OpenView DTC Manager PC (and software) were "somewhere in the procurement
pipeline" when new systems which had remote DTCs went live.  The solution
(a very poor one, but it worked) was to turn on bridging of the appropriate
protocols  across a wide area network (the LANs with the DTCs were on the
east coast, and the OpenView DTC Manager PC (used for another LAN) was on
the east coast, a number of routers away.

Downloads to the DTC (required whenever the DTC takes a power hit or is
powered up) can take a while when downloading across the WAN, but you can
make it work.  I'd STRONGLY recommend AGAINST downloading across a WAN.  We
had to put all kinds of filters on the routers, and switch routers around
because not all the routers were capable of the controls necessary.
Obviously, as soon as the OpenView DTC Manager PC arrived at the west coast
site, it was put into operation immediately and the bridging terminated.

John


--------------------------------------------------------------
John Korb                            email: [log in to unmask]
Innovative Software Solutions, Inc.

The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.