[comp.sys.xerox] TCP/IP: unbound var

koomen@CS.ROCHESTER.EDU (10/21/87)

System:		Lyric on 1108
File guess:	TCPLLICMP of 8-Jan-87 16:44:25

Folks,

every now and then I get an unbound var break in the \10MBWATCHER
process.  BT shows that \HANDLE.RAW.IP is calling the function
\ICMP.TIME.EXCEEDED (params: PACKET and CODE) with localvar IP and
freevar \ICMP.TRANSIT.TIME.EXCEEDED as arguments.  The latter turns out
to be unbound.  Does anyone know why it's unbound, and what the value
ought to be?

-- Hans

ps.  I did (APROPOS "EXCEEDED" T) in case \ICMP.TRANSIT.TIME.EXCEEDED
was a misspelling.  This turned up \ICMP.FRAGMENT.TIME.EXCEEDED, but
that one is unbound as well.

darrelj@sm.unisys.COM (10/21/87)

   by SUMEX-AIM.STANFORD.EDU with TCP; Tue, 20 Oct 87 18:51:28 PDT
   Received: by cayuga.cs.rochester.edu (5.52/e) id AA24932; Tue, 20
   Oct 87 21:50:30 EDT
   AA03087; Tue, 20 Oct 87 21:50:25 EDT
   Message-Id: <8710210150.AA03087@cursa.cs.rochester.edu>
   To: info-1100@sumex-aim.stanford.edu
   Cc: koomen@cs.rochester.edu
   Subject: TCP/IP: unbound var
   Date: Tue, 20 Oct 87 21:50:20 -0400
   From: koomen@cs.rochester.edu
   Status: RO

   System:		Lyric on 1108
   File guess:	TCPLLICMP of 8-Jan-87 16:44:25

   Folks,

   every now and then I get an unbound var break in the \10MBWATCHER
   process.  BT shows that \HANDLE.RAW.IP is calling the function
   \ICMP.TIME.EXCEEDED (params: PACKET and CODE) with localvar IP and
   freevar \ICMP.TRANSIT.TIME.EXCEEDED as arguments.  The latter turns out
   to be unbound.  Does anyone know why it's unbound, and what the value
   ought to be?

   -- Hans

I reported this one to Xerox last month.  In Koto, the corresponding
code had 0 compiled inline, so presumably a CONSTANT declaration was
missing at last compilation.
Workaround is (SETQ \ICMP.TIME.EXCEEDED 0).
	DARREL

AISupport.pasa@XEROX.COM (10/23/87)

AR #8897:  "TCPLLIP'S \HANDLE.RAW.IP freely references unbound
\ICMP.TRANSIT.TIME.EXCEEDED and \ICMP.FRAGMENT.TIME.EXCEEDED."  was
previously submitted on this problem. 

 The workaround is to  bind these variables to 0 and 1 respectively at
top level.

Judy Dering
AISupport