Google
 

Trailing-Edge - PDP-10 Archives - bb-bt99e-bb - mcb702.d11
There is 1 other file named mcb702.d11 in the archive. Click here to see a list.
                 EDIT DESCRIPTIONS FOR DECNET-10-MCB-V702                       
  
  
                             EDIT 1      FOR MCB
  
  
[SYMPTOM]
The circuit connecting a DN20 to a DECnet Phase 4 VAX will stay
in ON-SYNCHRONIZING for a KDP or ON-STARTING for a DMR/DMC.
[DIAGNOSIS]
The check for the received Data Link blocksize in the TI (Transport Init)
message was wrong.  The check compared it to the DLLSIZE and if they
didn't match, Transport would reject the TI.
[CURE]
Have the check follow the formula in the Transport spec that
requires the received Data Link blocksize to be greater than or equal
to the maximum (routing message size, hello message size, 246).
This is edit 1.65 in TLILIN.BLI.
********************************************************************************
  
  
                             EDIT 10     FOR MCB
  
  
[SYMPTOM]
  
     Upline dumping works unreliably, dump files always write  28K  even
if there is more memory to be dumped.
  
[DIAGNOSIS]
  
1)  NMLMCB  doesn't  allow optional fields in MOP messages.  If the node
    requesting the dump fills in optional  fields,  the  dump  will  not
    proceed, since NMLMCB has ignored the request.
  
2)  NMLMCB  doesn't  read  the  memory  size  from MOP messages.  NMLMCB
    assumes that  it's  just  going  to  be  dumping  28K  PDP-11s,  and
    therefore  assumes  that  to  be the dump limits.  No code exists to
    read the memory size out of the MOP dump request  message  that  the
    requesting system sends.
  
3)  NMLMCB doesn't allow DUMP COUNT to be set via NCP.  The DUMP ADDRESS
    and DUMP COUNT parameters in NMLMCB were made read  only,  and  thus
    cannot be set via NCP.
  
4)  NMLMCB  forgets  to  close links after DAP connect failures.  If the
    username/password  information  given  as  part  of  the  dump  file
    specification  are in error, the file access listener on the TOPS-20
    system will abort the connection, and NMLMCB's file access  routines
    will  fail  to  close  the link.  After several attempts to open the
    dump file (due to retransmission of the MOP  dump  request),  NMLMCB
    will  be  unable to open any subsequent links.  Further, NCP will be
    unable to connect to that MCB  and  NODES  cannot  get  the  network
    topology.
  
5)  NMLMCB doesn't always deallocate its buffers when dumping.  NMLMCB's
    file access code doesn't always release its  data  buffers  when  it
    should.
  
[CURE]
  
1) Allow optional fields on received MOP messages.
  
2)  Add  code  to  read the requesting system's memory size from the MOP
    dump request, and use that as the DUMP COUNT for that request.
  
3) Make DUMP COUNT and DUMP ADDRESS writable NCP parameters again.
  
4) Always release a link during errors in file access.
  
5) Make sure buffers always get deallocated.
********************************************************************************
  
  
                             EDIT 2      FOR MCB
  
[SYMPTOM]
The source node address in the packet header for an event was wrong.
[DIAGNOSIS]
It was caused by a typo in PKTA_HDR.
[CURE]
Fix it by using F instead of S.
This is edit 1.09 in XPTNMI.BLI
********************************************************************************
  
  
                             EDIT 3      FOR MCB
  
[SYMPTOM]
None observed.  Potential race condition.
[DIAGNOSIS]
In MAINLINE in the VISITS check we call TERMINATE to get rid of a CCB
and then several lines later, try to use that CCB.
[CURE]
Move the call to TERMINATE to after the last reference to that CCB.
This is Edit 1.72 to XPTSEL.BLI
********************************************************************************
  
  
                             EDIT 4      FOR MCB
  
[SYMPTOM]
DN20 crashing with a SS$DTE "Magic finger".
[DIAGNOSIS]
The DECnet phase 4 retransmitted CI message looks enough like
a DECnet phase 2 routing message that it is being passed by
the DN20 to TOPS-20.  TOPS-20 then detects that it is an invalid
message and believes the DN20 is sick and forces a reload of
the DN20 (a Magic finger).
[CURE]
Add a check in PH2HDR for a zero length destination name.
This will cause a "packet format error" event to be generated
each time that message is received instead of passing it on to TOPS-20.
This is Edit 1.73 to XPTSEL.BLI
********************************************************************************
  
  
                             EDIT 5      FOR MCB
  
[SYMPTOM]
MCB crashes with "Processor may have halted" crash reason.
[DIAGNOSIS]
Crash was caused by calling INI_LIN with 2 arguments instead
of 3 from the TIMLTM routine.
[CURE]
Add the third argument of .LINEb to the call to INI_LIN.
also fix the calls to TERM_LIN and TLITIM that have the same
problem.
This is Edit 1.15 in XPTTIM.BLI
********************************************************************************
  
  
                             EDIT 6      FOR MCB
  
[SYMPTOM]
The Network Management command to the MCB to
"SET CIRCUIT mumble COUNTER TIMER x" didn't handle
exact hour correctly.
[DIAGNOSIS]
Modulo arithmetic was used in the COUNTER_TIMER macro.
[CURE]
Fix the COUNTER_TIMER macro to not use the modulo function.
This is Edit 10 to NMUMCB.B16.
********************************************************************************
  
  
                             EDIT 7      FOR MCB
  
[SYMPTOM]
The MCB initializes over the DL11 line with the message
"DECnet-20 V3.0"
[DIAGNOSIS]
Since the MCB is same for DECnet-10, the message shouldn't
be product specific.
[CURE]
Change the message to "DECnet   V3.0".
This is patched in RSX11S.TSK and was generated because
of DECnet-10 QAR 125469.
********************************************************************************
  
  
                             EDIT 8      FOR MCB
  
[SYMPTOM]
MCB turns circuits to state off when line errors are encountered.
[DIAGNOSIS]
There are many causes for the MCB to turn the circuit to state
off.  The most common is because the CONTROL_OUT routine got
a DDCMP START RECEIVED error when it thought everthing was running.
It then turns the circuit off.  It should then reinitialize the
DMR/DMC; it doesn't.  Note KDP's handle this problem correctly.
[CURE]
In CONTROL_OUT after the DEVICE_SHUT_DOWN, add code to cause
the DMR/DMC to be reinitialized.
This is Edit 4.69 to DMC.B16 and was generated because of
DECnet-10 QAR 125463.
********************************************************************************
  
  
                             EDIT 9      FOR MCB
  
  
[SYMPTOM]
  
	Many DN-20 crashes.
  
[DIAGNOSIS]
  
	Race condition in  session control attempts  to close an  already
	closed logical link.
  
[CURE]
  
	Don't try to close a link that isn't open.
********************************************************************************
  
  
                             EDIT 006    FOR UTL
  
[SYMPTOM]
  
     VNP36  version 3.1(4) fails with an illegal instruction trap when
running version 347 or later of the KL microcode.
  
[DIAGNOSIS]
  
     Bits 0-8 in the source string length operand of an EXTEND MOVSLJ
instruction are non-zero.
  
[CURE]
  
     Zero the high order bits of the string length before executing the
move.
********************************************************************************
  
  
  
END OF  DECNET-10-MCB-V702