Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

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.