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

                 EDIT DESCRIPTIONS FOR TOPS-10-DCN-V702                         
  
  
                             EDIT 12221  FOR DECNET
  
[SYMPTOM]
  
  
  
  
DECnet free core is exhausted after several days of uptime.
  
[DIAGNOSIS]
  
When a job who was using DECnet logs out, no one ever  frees
up the core taken by that job's SJB block.  DECnet free core
fills up with these blocks after a while.
  
[CURE]
  
In routine JOBKL in  COMCON,  call  new  routine  SCULGO  in
SCMUUO.   SCULGO  waits  until all of the job's DECnet links
are gone, then calls FRESJB to free the memory taken by  the
job's SJB.
********************************************************************************
  
  
                             EDIT 12277  FOR DECNET
  
[SYMPTOM]
  
  
  
  
IME stopcode in DECnet Session Control layer.
  
[DIAGNOSIS]
  
Routine GETSTR in SCMUUO always checks for a maximum  string
length  of  39 bytes, even though the "User Data" string can
only be 16 bytes long.  If a user supplies a  string  longer
than  16  bytes,  other  data in the monitor is overwritten,
resulting in the IME.
  
[CURE]
  
Add another entry point to GETSTR to enable  the  caller  to
specify  the  maximum  string length.  Use this entry with a
length of 16 when getting the "User Data" string.
********************************************************************************
  
  
                             EDIT 12278  FOR DECNET
  
[SYMPTOM]
  
  
  
  
DCN stopcode SCMAAE when a  user  supplies  a  bad  argument
block to the NSP.  UUO.
  
[DIAGNOSIS]
  
DECnet module SCMUUO is supposed to address-check all  parts
of  the  user's argument block before executing the internal
NSP function which the user  specified.   Unfortunately,  if
the  user specifies a "Source Process Block" with a format 0
object type, then routine GETPRO knows it does not  have  to
check  the  user-supplied  task name, since it will never be
used.  That is true for most NSP.  functions, but the .NSFRI
("read  connect  information")  function uses the pointer to
the  task  name  as  the  address  of  a  place  to   return
information about a connecting task.  If the user supplies a
bad argument here, it  is  not  pre-checked,  and  when  the
monitor   tries   to  write  back  information,  it  gets  a
memory-reference failure, resulting in the DCN stopcode.
  
[CURE]
  
Check all of the parts of the user's argument block, even if
we "know" we do not need them.  We might need them later.
********************************************************************************
  
  
                             EDIT 12296  FOR DECNET
  
[SYMPTOM]
  
Any user can cause DCN(SCMAAE) stopcodes by sending long messages
to tasks which don't expect them.
  
[DIAGNOSIS]
  
If an application program does a NSP. .NSFDR function with the
NS.EOM and NS.WAI bits on, and a sending program sends more data
than requested, the receiver's buffer should be filled and remaining
data discarded until the EOM flag is seen in the received message.
The receiver's buffer count should be set equal to the negative
number of bytes discarded.  Unfortunately, if the message spans
more than one DECnet message, SCLINK will see a negative byte
count when receiving the second part of the message, and will
flag it as a %NEADE error, which will cause a DCN(SCMAAE)
stopcode later on.
  
[CURE]
  
If SCLINK sees a negative byte count in its internal argument
block, it should treat it normally, and just discard any incoming
bytes until it sees an EOM bit in an incoming message.  There is
no problem with a user supplying an initial negative byte count
when he does the .NSFDR function, as it will be rejected by
SCMUUO before actually starting a read operation.
********************************************************************************
  
  
  
END OF  TOPS-10-DCN-V702