Trailing-Edge
-
PDP-10 Archives
-
bb-bt99g-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