Kermit-11 known problems

07-Apr-1986 09:37 (Pending)

 On  RT11 FB systems with a large number of devices, Kermit can displace
the USR (force it to swap) and crash when accessing  the  USR  from  the
higher  addressed  overlays  in  Kermit. The fix for something like this
may not be practical; it can be worked around by UNLOADING and  REMOVING
unneeded  device  drivers  from  lowest  address to higher addresses (to
prevent fragmentation of background memory). If you run K11RT4.SAV on  a
FB  system  and find either (1) The program crashes on file transfers or
(2) KMON says the save image is too  large,  then  remove  the  unneeded
drivers and set the USR to swap. 

24-MAR-1986 14:23 (Fixed in version 3.49)

 Attribute processing is incorrect for some attribute types. This  dates
back  to  April 1984 when support was first added, but no other versions
were available to test against.  The  correction,  made  to  K11ATR.MAC,
will  cause  V3.49  or later of Kermit-11 to have compatability problems
with previous versions  of  Kermit-11.  The  main  problem  will  be  in
informing  each  other of binary file arrival; the only workaround is to
explicitly force two communicating Kermit-11's  into  binary  mode  with
the SET FILE command. See K11INS.DOC for further information. 

 The  specific  problem is that the protocol requires the attribute TYPE
field to be  followed  by  a  LENGTH  byte  to  specify  the  number  of
characters  following.  Kermit-11  was  not  always inserting the LENGTH
field. The new  version,  3.49,  will  be  able  to  tell  if  an  older
Kermit-11  is sending in the incorrect format by virtue of the fact that
the first attribute packet that is  sent  is  the  system  id  code  and
operating  system. Since this attribute will always be a short one (2 or
3 characters at most) it is a simple matter to detect the presence of  a
'D'  (for  DEC)  in  the  position  of  the  LENGTH field and set a flag
accordingly. However, in the case of the corrected Kermit-11 sending  to
a  pre  3.49 version, this will not be the case and all attempts to rely
on the transfer of attribute packets will fail. 

brian@uoft02.bitnet