Trailing-Edge
-
PDP-10 Archives
-
BB-D868C-BM
-
4-documentation/netcon.tco
There are 6 other files named netcon.tco in the archive. Click here to see a list.
TOPS20 Change Order Number 4.2320
Written by: SROBINSON 10-Jul-79 10:36:10
Edit checked: NO Document: YES
TCO Tested: NO Maintenance Release: NO
Hardware-related: NO
Program: NETCON
Related TCO's:
Related SPR's:
Problem: NETCON returns "Invalid Line Id" when asked to show counts for
a DTE connected to a DECnet DN20.
Diagnosis: In routine RQRLCT in module NCU.MAC, an error return
from the .BTRLC function to the BOOT JSYS is treated as
an indication of an invalid line id. This should be treated
as some other error so as not to confuse the user.
Solution: Return "Insufficient Status" because it is closest available
indication of the true error.
TOPS20 Change Order Number 4.2329
Written by: SROBINSON 15-Jul-79 14:36:37
Edit checked: YES Document: YES
TCO Tested: YES Maintenance Release: NO
Hardware-related: YES
Program: NETCON
Related TCO's:
Related SPR's:
Problem: NETCON destroys portions of its data base, free core list, and
code occasionally.
Diagnosis: All indications point to the free core memory management headers
stored in freed blocks are being destroyed. Tracing it down revealed that
the routines used to load a DN20 front end using a .BIN file tertiary loader
read in records from the file larger than the allocated buffer. The buffer
size was calculated as the largest string that could be sent across a NCU
link.. not the max size of .BIN file record.
Solution: The problem is more complex than time allowed to fix. The real
fix would be to rewrite the .BIN file reading routine into suitable
co-routines that really knew how to read .BIN files. But instead the
buffer size was expanded to 500 words (from 111) noting that no current
.BIN file has a record of that size (500*4 bytes) and if it occurs again
before the INPLDA routine can be rewritten, we know the symptoms and
have a quick fix.
TOPS20 Change Order Number 4.2445
Written by: JENNESS 6-Sep-79 14:58:10
Edit checked: YES Document: NO
TCO Tested: YES Maintenance Release: NO
Hardware-related: NO
Program: NETCON
Related TCO's:
Related SPR's:
Problem: The memory manager gets it's headers or free block pointers
messed up and can't recover gracefully.
Diagnosis: No checking for the free chain being sorted in the proper
order and insuffcient bounds checking.
Solution: Put in free chain sort order checking when releasing a block
to the free chain (RELFRE). Also do substantial code clean up to remove
NO-OP code that was obviously a remnant of the code absconded from
the monitor module FREE.
TOPS20 Change Order Number 4.2446
Written by: JENNESS 6-Sep-79 15:04:07
Edit checked: YES Document: NO
TCO Tested: YES Maintenance Release: NO
Hardware-related: NO
Program: NETCON
Related TCO's:
Related SPR's:
Problem: NETCON every once in a while will suck up all the JFN's on
the system.
Diagnosis: When NETCON has it's EXECUTOR set to some node that either
does not exist or is currently inaccessible it gets link aborts on
the NCU link while waiting for data. When the abort comes in, which
it does interpret correctly, it tries to close the link. The link
did not close and NCP decided that it didn't matter and threw away
any record of the link ever being referenced.
Since the connect had not been made the NICE request was requeued
only to have the same sequence to happen again, usually until all
the JFN's on the system were taken, at which time NETCON threw up.
Solution: Change the routine RELRQI to set the CZ%ABT bit before
doing the CLOSF on a link if a normal CLOSF attempt failed.
TOPS20 Change Order Number 4.2447
Written by: JENNESS 6-Sep-79 15:07:43
Edit checked: YES Document: NO
TCO Tested: YES Maintenance Release: NO
Hardware-related: NO
Program: NETCON
Related TCO's:
Related SPR's:
Problem: More memory management problems. Problems in the memory
manager are being masked in NETCON because no one is reporting failures
to return memory to the chunk free pool.
Diagnosis: No error message or stopcode routine is being called when
RELFRE fails.
Solution: Change, in both NCU and NCP all places where RELFRE fails
to a FATAL.ERROR and stop the run. There is no occurence of this
condition that cannot be considered fatal.
TOPS20 Change Order Number 4.2478
Written by: JENNESS 20-Sep-79 14:06:57
Edit checked: YES Document: NO
TCO Tested: YES Maintenance Release: NO
Hardware-related: NO
Program: NETCON
Related TCO's:
Related SPR's:
Problem: NETCON hangs on 2020's during initialization. It never processes
NCP commands and has a link of DCN:-TASK-TOPOL.TOPOL opened. This link
obviously goes to no node.
Diagnosis: The routine TOPINI doesn't correctly check for lines that are
ON but no node is at the other end. Since this routine is called inline
with the NCP startup code and the DCN: link never will get a response
from the TOPOL task, NCP will never service OPR commands.
Solution: Add code in TOPINL loop to check if first byte of node name
is a null. If it is then the line is ignored, instead of requesting
topology information from an open line.
TOPS20 Change Order Number 4.2488
Written by: JENNESS 26-Sep-79 15:37:57
Edit checked: YES Document: NO
TCO Tested: YES Maintenance Release: NO
Hardware-related: NO
Program: NETCON
Related TCO's:
Related SPR's:
Problem: The command "SET LOCAL LOOPBACK ENABLE/DISABLE line-id"
always gives the error "%NETCON: invalid line-id".
Diagnosis: Looking at the port parsing routine a AOBJP instruction was found
trying to increment along the ORION command message blocks. This is a
technique used in some programs that need to validate the length of a command.
NETCON does no such validation. The instruction should never have been there
are it is very doubtfull that this command ever worked.
Solution: Remove it.
TOPS20 Change Order Number 4.2489
Written by: JENNESS 26-Sep-79 15:45:27
Edit checked: YES Document: NO
TCO Tested: YES Maintenance Release: NO
Hardware-related: NO
Program: NETCON
Related TCO's:
Related SPR's:
Problem: After fixing the parsing for loopback commands (see TCO 4.2488)
it was noticed that the "SHOW STATUS KNOW LINES" command returned
a state of "Unknown" when loopback was set.
Diagnosis: The NICE task (NCU) in NETCON doesn't know how to properly
interpret the line status functions that were returned from the NODE
JSYS.
Solution: Fix the routine PRTINF in NCU to do the following translation
from NODE JSYS line status' to NICE type line status:
.NDLON => .LSTON Line on
.NDLOF => .LSTOF Line off
.NDLCN => .LSTCN Controller loopback
.NDLCB => .LSTCB Cable loopback
Currently any other status type (which there aren't any in NSPSRV for
local lines) will return a 377.