Conference netcad::hub_mgnt

I had exactly the same problem, I followed the instructions and even had the 
Agent share the segment of the load host alone.

My load host is also a VMS system, I have the impression that load failure are
due to a resource problem on your load host, request packets or nonpaged pool.

My load host is the bootmember of a small LAVC and the cluster got completely
stuck when I wanted to load the DECagent with the new firmware.(I had no problem
whatsoever with the V1.0 load) Things start getting suspect when I typed the
"start 200000", the cluster activity was slowing down quite a lot and I lost
windows on my station(bootmember).

Finally after many attempts I got the firmware loaded having no clustermembers
and the agent being the only one with which I shared the segment.

I followed the loading instructions as follows:

I first typed NCP> load node xxxxx
immediately thereafter I typed the start 200000 at the agent's console
after a while the load timed out as you described it
then I typed NCP> trigger node xxxxx
and then it worked, I did not dare to retry the load so my statement about the
resources is only a guess...

I've finally succeeded in loading the new Agent SW. 

I took a 3 meter Thinwire cable, connected it to the thinwire port at the right
side of the Hub, connected a VAXstation on it and terminated the thinwire.

I then pulled out all the modules, except the Agent90, and did a LOAD NODE from 
NCP, which terminated with a no comm error. I then did the TRIGGER NODE command
and the Agent90 started flashing faster on the LED next to the term port. After 
a while all the three top LEDs wnt out, and a self-test a short while after that.

Is this the way it was meant to work? I had a lot of problems getting it loaded,
and I can't believe that you have to pull out all modules, and put the Agent on
a spearate LAN to get it loaded. Any improvements are nescessary and welcomed.

Bj�rn Olav Haugom

    Since I wrote the code to load the DECagent 90 (you may fire when ready
    :-}), I am very interested in knowing why this is not working for you.
    
    NCP on a VMS load host will issue an error similar to the following if
    service is DISABLED on the circuit through which you are trying to
    load:
    
    %NCP-W-LINCOM, Line communication error
    
    %SYSTEM-F-IVMODE, invalid mode for requested function
    
    Note that enabling circuit service may cause your load host to spend
    significantly more time processing certain network traffic (e.g.
    broadcast packets).  So if circuit service is ENABLED you might be
    running into a resource problem (although I'm doubtful that's the
    case).  My load host is a MicroVAX 3900 loading through a DELQA.  Here
    are the NCP parameters I have on my VMS system which work for me:
    
    NCP>sho ciruit qna-0 char
    
    Known Circuit Volatile Characteristics as of  6-JUL-1993 12:47:18
    
    Circuit = QNA-0
    
    State                    = on
    Service                  = enabled
    Designated router        = 55.1021
    Cost                     = 4
    Maximum routers allowed  = 33
    Router priority          = 64
    Hello timer              = 15
    Type                     = Ethernet
    Adjacent node            = 55.1021
    Listen timer             = 45
    
    NCP>sho line qna-0 char
    
    Line Volatile Characteristics as of  6-JUL-1993 12:53:12
    
    Line = QNA-0
    
    Receive buffers          = 10
    Controller               = normal
    Protocol                 = Ethernet
    Service timer            = 4000
    Hardware address         = 08-00-2B-0F-8A-36
    Device buffer size       = 1498
    
    Note that the NCP LOAD command is a "load and wait" process, which
    means that once the command is issued you will not be returned to the
    NCP prompt until the load is complete.  If there is an error, it will
    be displayed on the terminal.  With NCP TRIGGER, only the initial
    boot/load request is issued, then the loading occurs in the background
    (sort of a "spawned" LOAD command) and you will be returned to the NCP
    prompt.  If an error occurs in the load, you will not be notified
    unless you have OPCOM logging enabled on your terminal ($ REPLY/ENABLE)
    or you check the SYS$MANAGER:OPERATOR.LOG file.
    
    Also, remember that when loading an agent which is in a hub that
    contains a bridge, you must be certain that the bridge is not filtering
    MOP DL packets (protocol types 60-01 and 60-02) from the backbone.  Use
    the DECbridge> SHOW PROTOCOL command to see what protocol filters (if
    any) are set in the bridge.  Obviously, connecting a cable from the
    workstation into the right side of the hub (workgroup side) or even
    into a thinwire repeater (90C) port that is in the hub will bypass
    bridge filtering.
    
    When loading the DECagent using the two-step load procedure, here's
    what you should observe regarding the LEDs on the front of the
    DECagent:
    
    o After you issue the CCI> START 200000 command, the first three LEDs
      should be on and the fourth LED should flash at about a 1/4-second
      interval.  This indicates that the DECagent is awaiting the boot
      request (LOAD or TRIGGER provides this request).  Note that there
      is no console output generated by the image which is running at this
      point.
    
    o Once you issue the LOAD or TRIGGER command at the NCP prompt on the
      load host, all the LEDs except the first one should go off.  This
      should happen very quickly after the NCP command is issued.  If it
      does not, then either the LOAD/TRIGGER command never made it to the
      wire or the DECagent didn't recognize the request.  In the latter
      case, I am very interested in knowing your configuration and network
      load.  If things happen as they should, then the first three LEDS
      will again be on and the fourth LED will flicker rapidly (now loading
      packets into a landing pad area in RAM).  After about ten seconds or
      so, the flicker should stop (load complete, now calculating the CRC
      and writing image to flash RAM).  Seven to ten seconds later all the
      LEDS will go on (reset in progress) then all but the first LED will
      go off.  After self-test completes (about 10 seconds), the DECagent
      should come up running the new image (first three LEDs on, fourth LED
      flickers with network traffic unless there's no IP address set, in
      which case the third and fourth LEDs alternately flash at a
      one-second interval).
    
    Having other modules in the hub should have no effect on the load
    process (with the exception of the bridge filtering issue noted above).
    I have had DECserver 90TLs and DECwanrouter 90s attempting to load
    their images when a DECagent in the same hub was being loaded and I
    have not seen any problems.
    
    Please let me know (with specific details of your configuration) if you
    continue to have problems loading DECagents.
    
    Roger Gaudet
    DECagent 90 devo.

    Hi,
    
    Could someone please supply me with the NCP node characteristics needed
    to load the DENMA v1.1 upgrade ?
    
    I have 
    
    	service circuit = sva-0
    	hardware address = 08-00-2b-25-07-fc
    	load file = DENMA011.SYS
    	software type = system
    	software identification = denma011.sys
    
    after the denma_load loads and trigger or load results in a device
    timeout. 
    
    Any ideas ?
    
    
    
    Thanks,
    
    Alan.

Assuming you have done CCI>start 200000 (that's two hundred thousand) after
loading DENMA_LOAD.SYS and the LED near the db25 connector is flashing, you
should be able to trigger/load the agent from NCP.  If the agent doesn't reset
almost immediately after you issue the trigger/load command (all but the
left-most LED will go off for a second or two), check your connections.  All the
DENMA_LOAD.SYS image lives for is to recognize a MOP boot request, which is
issued by NCP trigger/load, then start the load process.

There have been some problems reported by others that are similar to this one
which were discovered to be a bad load image (DENMA011.SYS, not DENMA_LOAD.SYS).
If this is a VMS load host, you might want to verify the integrity of the load
image by doing an $ ANALYZE/IMAGE DENMA011.SYS.  If no errors are uncovered, the
image should be OK.  You can do this with the DENMA_LOAD.SYS image also.  I
don't know how to verify an image (or even if it's possible) on an ULTRIX load
host.

Another thing that comes to mind is that if you have a bridge between the load
host and the DENMA, be sure it is not filtering MOP DL and RC packets (protocol
types 60-01 and 60-02 respectively).

...Roger...

    I set this up here with our DENMA and it loaded o.k.
    
    I started looking at physical line counters and found that they were
    clocking a few send/receive failures. The ESA0: device had 2 errors
    against it (SDA> show lan/full) and they were "9" - hardware errors.
    We replaced the cpu modeul and that fixed the problem.
    
    
    How about including an example set up in the release notes (show node
    fred char) ?
    
    Thanks,
    
    Alan.