TCP FTP multiple logins to TOPS-20 hosts

[Mabry Tyson <TYSON@sri-stripe.arpa>]

VOGELSANG:>sys7>local>rel7>sri-ip-tcp-52-16-patches-1>sri-ip-tcp-52-16-patches-1-5.lisp
Function (DEFUN-IN-FLAVOR FS:TCP-FTP-VALIDATE-CONN FS:TCP-FTP-CONN):  Be less restrictive (and thereby follow the spec better) 
								      with responses to NOOP.  Allow 201 as well as 200 as responses.

For a long time we have been bugged by the lispm requiring logins for
each file during the transfer of multiple files from some TOPS-20 hosts.
(eg, :COPY FILE XXX20:<FOO>*.BAR LOCAL:>FOO>*.*)
I have complained about it several times.   (Simply having the
Symbolics remember your password is antisocial (besides being stupid)
since it generates one job on the foreign host for each file
transferred.)

Since it *STILL* hadn't been fixed in 7.1 and I was being bitten by it
again, I finally tracked it down and have a patch.

The problem is that the Symbolics TCP code doesn't follow the specs
(RFC 959) properly.  I've hit this elsewhere where it was easier to
find but this one was better hidden.  It turns out that in
(DEFUN-IN-FLAVOR FS:TCP-FTP-VALIDATE-CONN FS:TCP-FTP-CONN),
the Symbolics sends a NOOP to the FTP connection and expects a
200 reply.  At least some TOPS-20s respond with a 201.  The
specs seem to allow any 2xx reply and certainly doesn't care
what the one's digit is.   The patch, for this particular
problem, is to change the first occurence of 200 in that
function to be '(200. 201.).

It would seem that the right fix is to change
tcp-ftp-check-command-response so that it ignores the
one's digit (and maybe the ten's).


(By the way, for those of you on SLUG who might be bitten by
the STRU and MODE bugs in TCP-FTP, note that the function to patch
is not in SYS:IP-TCP;FTP-SERVER but is actually in the new
version of that file in patch 8 of version 52.   The bug is that
CL:MEMBER doesn't work on strings.  Add an appropriate :TEST keyword.)

(Symbolics:  by the way, it appears that there might just be a small
timing but wherein RETR will get refused with a 425 Data connection
failed.  Connection refused.  This seems to occur fairly often if I do
not have TCP:*TCP-FTP-DEBUG-P* set to T.  Almost always when I am
tracing, the connections work.  If you have any TOPS-20 experts around,
you might check to see if the 20s have a timing problem here.   If so,
it might be advisable to put a 1 to 5 second delay on sending out the
RETR.)