Received: from kestrel by betelgeuse.Ukc.AC.UK   Over Ring with SMTP  id aa23405;
          4 Oct 88 15:59 BST
Received: from emas-a.ed.ac.uk by kestrel.Ukc.AC.UK   via Janet (UKC CAMEL FTP)
           id aa23572; 4 Oct 88 15:59 BST
Date: 04 Oct 88  15:58:46 bst
From: J.Darby@ed.ac.uk
Subject: FTP
To: mg@ukc.ac.uk, Bishop@ed.ac.uk, J.Henshall@ed.ac.uk
Message-ID: <04 Oct 88  15:58:46 bst  030476@EMAS-A>

I've tracked down the problem with NIFTP between EMAS-A and UKC. Basically
EMAS-A sends a SFT thus:

Tue Oct  4 14:30:15 1988

Got SFT - input parameters:
        Information message           :     == "EMAS EMAS 370  NIFTP-B(80); VSN NAS XA 09/88"
        Protocol id                   :     == [0100] (256)
        Mode of access                :     == [8002] (32770)
        Data type                     : Mon <= [0003] (3)
        Text transfer code            : Mon <= [0009] (9)
        Text formatting               :     <= [0083] (131)
        Binary word size              :     == [0008] (8)
        Max transfer record size      : Mon <= [ffff] (65535)
        Private code name             :     == "INTER EMAS"
        Username                      :     == "jd"
        User name password            :     == <not telling>
        Filename                      :     == "bin/gnucpp"
        File size                     : Mon <= [1388] (5000)
        Minimum timeout               :     == [0258] (600)

To which UKC replies:

Sent RPOS

        File size                     :     == [002c] (44)
        Data type                     :     == [0002] (2)
        Text transfer code            :     ?= No value available
        Text formatting               :     ?= No value available
        Max transfer record size      :     == [ffff] (65535)
        Information message           :     == "UKC CAMEL FTP, Ok to transfer!"

Note that UKC's Camel decided that as the transfer is binary there is no need,
and indeed it shouldn't, reply with any values for the Text transfer and text
formatting parameters and gives No value available / Any acceptable as its
response. However this isn't good enough for EMAS-A which croaks on it.

The transaction is then cleared down thus:

Got STOP
        State of transfer             :     == [1001] (4097)
        Information message           :     == "No text tran code response on RPOS"

Sent STOPACK
        Information message           :     == "UKC CAMEL FTP, Sorry we couldn't help :-<"
        State of transfer             :     == [1001] (4097)

I think that this is a problem with the EMAS FTP as it shoudn't expect a reply
when it has been told that the transfer is binary.

Comments anyone?

Jim.






Received: from kite by betelgeuse.Ukc.AC.UK   Over Ring with SMTP  id aa11870;
          30 Oct 88 10:21 GMT
To: mg@ukc.ac.uk
Subject: p_go/find_work()
From: Peter Collinson <pc@ukc.ac.uk>
Organization: Computing Lab, Univ. of Kent, Canterbury, UK
Phone: +44 227 764000 x7619
Date: Sun, 30 Oct 88 10:21:25 +0000
Message-ID: <29187.594210085@kite>
Sender: pc@ukc.ac.uk

Reads the new directory on every child death.

It should

	stat the directory
	notice that the mtime has altered
	THEN read it

on a 4.2 system it is spending hours reading a big
directory






Received: from kite by betelgeuse.Ukc.AC.UK   Over Ring with SMTP  id aa11974;
          30 Oct 88 10:41 GMT
To: mg@ukc.ac.uk
Subject: More on p-go
From: Peter Collinson <pc@ukc.ac.uk>
Organization: Computing Lab, Univ. of Kent, Canterbury, UK
Phone: +44 227 764000 x7619
Date: Sun, 30 Oct 88 10:41:10 +0000
Message-ID: <29257.594211270@kite>
Sender: pc@ukc.ac.uk

	while (!shutdown)
	{
#ifndef _52
		check_morgue ();		/* who's dead?	*/
#endif
		find_work (new_work_dir);	/* what's new?	*/
		dispatch_work ();		/* what next?	*/
		write_information ();		/* tell everybody */
		VOID alarm (60);		/* start clock ticking	*/
		pause ();			/* mouch about	*/
		VOID alarm (0);			/* stop clock	*/
		initopr ("p-go");		/* Restart logs	*/
	}


What is happening on kestrel is:

	dispatch_work()

sets things off.

	write_information()

takes a long time.

If any process dies during this write, it's line is not used until
either the alarm fires or the next process dies.

Things then get worse - if the program starts several children its
again possible that one of them may terminate before the pause is called.

The code needs to `hold off' alarms/SIGCHLD until the pause is entered
- this is a 4.2/4.3 only solution.

There should perhaps be an interlock between toll() and the code here
- which is cleared at the top of the loop and set in toll(). If this
is set then do not do the pause(). This is probably portable.






From: mg
Subject: HERE

Put the local site names in a config file, rather than being burnt in to the
code.







Received: from kite by gos.Ukc.AC.UK   Over Ring with SMTP  id aa04931;
          6 Feb 89 8:45 GMT
To: "M.W.Guy" <mg@ukc.ac.uk>
Subject: Re: P-Max on kestrel 
In-reply-to: Your message of Sun, 5 Feb 89 23:18:29 GMT .
From: Peter Collinson <pc@ukc.ac.uk>
Organization: Computing Lab, Univ. of Kent, Canterbury, UK
Phone: +44 227 764000 x7619
Date: Mon, 06 Feb 89 08:45:39 +0000
Message-ID: <14402.602757939@kite>
Sender: pc@ukc.ac.uk

It wu
It would be better also to not latch onto one site and keep sending.
Better scheuling there would help






Received: from kite by gos.Ukc.AC.UK   Over Ring with SMTP  id aa05825;
          16 Feb 89 20:03 GMT
To: mg@ukc.ac.uk
Subject: More than 4
From: Peter Collinson <pc@ukc.ac.uk>
Organization: Computing Lab, Univ. of Kent, Canterbury, UK
Phone: +44 227 764000 x7619
Date: Thu, 16 Feb 89 20:03:20 +0000
Message-ID: <10532.603662600@kite>
Sender: pc@ukc.ac.uk

I think for scheduling reasons it seems a good idea to have connections fail with
FULL. It seems to stop it settling down to simply sending news transfers o
slow receievers - thus blocking everything else.

Would be good to make it re-read P-max tho.






From: mg
To: mg
Subject: binary files
Date: 12 Mar 89

Make the definition of a binary file "any file with top bits set.
This is pragmatic, because users so frequently send their mailboxes,
or word-perfect documetns sent as binary files, on which the other end
often barfs (eg VMS).






Received: from harrier by gos.Ukc.AC.UK   Over Ring with SMTP  id aa14798;
          20 Mar 89 18:58 GMT
Date: Mon, 20 Mar 89 18:48:53 +0000
From: jch@ukc.ac.uk
To: mg@ukc.ac.uk
Subject: FTP


Saturn crashed and reloaded. In the meantime FTPs tried to talk to
Saturn and found it wasnt there. When Saturn came back the FTPs
eventually realised and started working, except that the ones that
tried when Saturn went down were stuck 'active' in fq. Any new
FTPs worked ok, but these old ones stayed 'active' and never went.

This is an effect which I have seen before. Given long enough (more than 5 or
6 hours) they go eventually.

Anyway Sean came in and said to try killing p-go (kill -9) and restarting it.
This did the trick, but is it safe to use?

Jim






Received: from kite by gos.Ukc.AC.UK   Over Ring with SMTP  id aa05559;
          3 Mar 89 16:02 GMT
To: mg@ukc.ac.uk
Subject: Re: From Harrier 
From: Pete Collinson <pc@ukc.ac.uk>
Organization: Computing Lab, Univ. of Kent, Canterbury, UK
Phone: +44 227 764000 x7619
Date: Fri, 03 Mar 89 16:02:08 +0000
Message-ID: <4213.604944128@kite>
Sender: pc@ukc.ac.uk

Found on harrier - again!





------- Forwarded Message

Date: Fri, 03 Mar 89 15:58:40 +0000
From: root@ukc.ac.uk
Subject: From Harrier
To: pc@ukc.ac.uk

Date: Fri, 03 Mar 89 00:00:07 +0000
From: root@Ukc.AC.UK
To: ftp
Subject: FTP accounting failed

Failed to read header!

------- End of Forwarded Message