From foner at ai.mit.edu  Tue Oct 24 00:47:51 1989
From: foner at ai.mit.edu (Leonard N. Foner)
Date: Oct 23 89 19:47:51 EDT
Subject: inquir broken
In-Reply-To: "Pandora B. Berman"'s message of Mon, 23 Oct 89 19:08:26 EDT <659250.891023.CENT@AI.AI.MIT.EDU>
Message-ID: <8910232347.AA10349@wheat-chex>

   Date: Mon, 23 Oct 89 19:08:26 EDT
   From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU at mintaka.lcs.mit.edu>

       Date: Mon, 23 Oct 89 15:20 PDT
       From: Alan Bawden <bawden at parc.xerox.com>
       Subject: inquir broken
       To: foner at ai.mit.edu
       Cc: CENT at ai, BUG-INQUIR at ai, BUG-ITS at ai, ARCHY at ai
	   Date: Tue, 17 Oct 89 22:29:41 EDT
	   From: "Leonard N. Foner" <foner at ai.mit.edu>
	   I just fixed ARCHY's address to say
	   ... at ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM.  Just specifying
	   @SYMBOLICS.COM yields nondeterministic results
       The results are completely deterministic since we go out of our way to
       keep the name "Symbolics.COM" attached to -some- host in the host table
       we use.  (Remember host tables? -- we still use 'em.)  I don't happen
       to know which host that is at the moment, perhaps we need to move it to
       Elephant-Butte.
       Note that using "Symbolics.COM" or "Elephant-Butte.SCRC.Symbolics.COM"
       in the NAMES file or INQUIR database does -not- affect what address the
       mailer uses in delivering the mail.  In either case it will be
       canonicalized to the primary name of the host (Elephant-Butte in this
       case).
   no, SCRC (and the other standard names) all canonicalize to STONY-BROOK.

That's fine.  Since the "@SYMBOLICS.COM" is hidden from the mailer at
Stony by the mailing list expansion on AI, the Stony mailer can't spazz
and do something stupid.

       So perhaps someone should put Bill's address back the way it was
       before...
   i did that the next time i had an occasion to go into NAMES >..

Okay, thanks.  I was under the mistaken assumption that everything that
looked like a domain name was getting delivered to Mintaka for domain
lookup and delivery.  Guess not.  (Guess I was confused by all the
@MINTAKA's all over ITS headers since the ARPAnet evaporated.)

						<LNF>

From CENT%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU  Tue Oct 24 00:08:26 1989
From: CENT%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU (Pandora B. Berman)
Date: Oct 23 89 19:08:26 EDT
Subject: inquir broken
Message-ID: <659250.891023.CENT@AI.AI.MIT.EDU>

    Date: Mon, 23 Oct 89 15:20 PDT
    From: Alan Bawden <bawden at parc.xerox.com>
    Subject: inquir broken
    To: foner at ai.mit.edu
    Cc: CENT at ai, BUG-INQUIR at ai, BUG-ITS at ai, ARCHY at ai
	Date: Tue, 17 Oct 89 22:29:41 EDT
	From: "Leonard N. Foner" <foner at ai.mit.edu>
	I just fixed ARCHY's address to say
	... at ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM.  Just specifying
	@SYMBOLICS.COM yields nondeterministic results
    The results are completely deterministic since we go out of our way to
    keep the name "Symbolics.COM" attached to -some- host in the host table
    we use.  (Remember host tables? -- we still use 'em.)  I don't happen
    to know which host that is at the moment, perhaps we need to move it to
    Elephant-Butte.
    Note that using "Symbolics.COM" or "Elephant-Butte.SCRC.Symbolics.COM"
    in the NAMES file or INQUIR database does -not- affect what address the
    mailer uses in delivering the mail.  In either case it will be
    canonicalized to the primary name of the host (Elephant-Butte in this
    case).
no, SCRC (and the other standard names) all canonicalize to STONY-BROOK.

    So perhaps someone should put Bill's address back the way it was
    before...
i did that the next time i had an occasion to go into NAMES >.

From bawden at parc.xerox.com  Mon Oct 23 23:20:00 1989
From: bawden at parc.xerox.com (Alan Bawden)
Date: Oct 23 89 15:20 PDT
Subject: inquir broken
In-Reply-To: <8910180229.AA08171@wheat-chex>
Message-ID: <19891023222018.3.ALAN@MR-BUN.parc.xerox.com>

    Date: Tue, 17 Oct 89 22:29:41 EDT
    From: "Leonard N. Foner" <foner at ai.mit.edu>
    I just fixed ARCHY's address to say ... at ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM.
    Just specifying @SYMBOLICS.COM yields nondeterministic
    results

The results are completely deterministic since we go out of our way to keep
the name "Symbolics.COM" attached to -some- host in the host table we use.
(Remember host tables? -- we still use 'em.)  I don't happen to know which
host that is at the moment, perhaps we need to move it to Elephant-Butte.

Note that using "Symbolics.COM" or "Elephant-Butte.SCRC.Symbolics.COM" in
the NAMES file or INQUIR database does -not- affect what address the mailer
uses in delivering the mail.  In either case it will be canonicalized to
the primary name of the host (Elephant-Butte in this case).

So perhaps someone should put Bill's address back the way it was before...

From foner at ai.mit.edu  Wed Oct 18 03:29:41 1989
From: foner at ai.mit.edu (Leonard N. Foner)
Date: Oct 17 89 22:29:41 EDT
Subject: inquir broken
In-Reply-To: "Pandora B. Berman"'s message of Tue, 17 Oct 89 02:43:42 EDT <656327.891017.CENT@AI.AI.MIT.EDU>
Message-ID: <8910180229.AA08171@wheat-chex>

   Date: Tue, 17 Oct 89 02:43:42 EDT
   From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU at mintaka.lcs.mit.edu>

   i was trying to fix ARCHY's inquir entry to show his real net address,
   which is york%ila-west.dialnet.symbolics.com at symbolics.com. inquir has been
   fukt over (yes, i know, several years ago) so that it refuses to accept
   this address on the grounds that it is "too long for this item". when i ran
   inquir on AI, this msg flashed by before i could see it, and i was
   confronted merely with an altered inquir entry listing giving "T" as the
   address. fortunately i examined the modified entry and so did not send it
   off for installation. when i supduped over to MC, inquir showed me the
   error msg with a decent delay. on both machines, what seems to occur is
   that a T<CR> replaces the so-called too-long item, and the too-long item
   ends up appearing as if it had been typed to the What next? question.
       anyway, i had to go into NAMES > in order to fix archy's address..

I just fixed ARCHY's address to say ... at ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM.
Just specifying @SYMBOLICS.COM yields nondeterministic
results---sometimes, the mailer at whichever machine at Symbolics
happens to get the mail becomes confused and will do something random
with such an address, because the mailer doesn't yet "really"
understand domains and sometimes thinks, "Wait, there's no site named
Symbolics...  I guess I'll do something weird."  (There *is* a site
named SCRC, but...)

It'll be a while until the mailer does understand domains correctly.  Until
then, you should specify a real host, not a domain.

						<LNF>

From cstacy at bbn.com  Tue Oct 17 17:08:22 1989
From: cstacy at bbn.com (cstacy at bbn.com)
Date: Oct 17 89 12:08:22 -0400
Subject: inquir broken 
In-Reply-To: Your message of Tue, 17 Oct 89 02:43:42 -0400.
             <656327.891017.CENT@AI.AI.MIT.EDU> 
Message-ID: <8910171219.aa11140@mintaka.lcs.mit.edu>

    Date: Tue, 17 Oct 89 02:43:42 EDT
    From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU at mintaka.lcs.mit.edu>
    Message-ID: <656327.891017.CENT at AI.AI.MIT.EDU>
    
    i was trying to fix ARCHY's inquir entry to show his real net address,
    which is york%ila-west.dialnet.symbolics.com at symbolics.com. inquir has been
    fukt over (yes, i know, several years ago) so that it refuses to accept
    this address on the grounds that it is "too long for this item". 

I don't understand this part of the bug report.  The system has always had
fixed limits on the length of the items.  The limits are defined in the file
LSRTNS, and there is also a definition in INQUIR which must be kept in step.
If INQUIR were to accept an overly long item, the INQUPD program would simply
truncate the item, and mail back a message to the luser indicating that the
data was truncated.  That the user interface doesn't let things get that far,
is definitely a feature.  (This is especially true if the field under
discussion is the network address!)

If your complaint is that 40 characters is too small, in these days of kludged
up mailing addresses, I'd believe that.  It takes somewhat of an operation to
change the database format though.

    when i ran
    inquir on AI, this msg flashed by before i could see it, and i was
    confronted merely with an altered inquir entry listing giving "T" as the
    address. fortunately i examined the modified entry and so did not send it
    off for installation. when i supduped over to MC, inquir showed me the
    error msg with a decent delay. on both machines, what seems to occur is
    that a T<CR> replaces the so-called too-long item, and the too-long item
    ends up appearing as if it had been typed to the What next? question.
        anyway, i had to go into NAMES > in order to fix archy's address..

I have a version of INQUIR in which this bug is probably fixed, but I'm going
to wait until I happen by MIT to try it out; it's too painful to debug over
lots of telnet hops and so forth.


From CENT%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU  Tue Oct 17 07:43:42 1989
From: CENT%AI.AI.MIT.EDU at MINTAKA.LCS.MIT.EDU (Pandora B. Berman)
Date: Oct 17 89 02:43:42 EDT
Subject: inquir broken
Message-ID: <656327.891017.CENT@AI.AI.MIT.EDU>

i was trying to fix ARCHY's inquir entry to show his real net address,
which is york%ila-west.dialnet.symbolics.com at symbolics.com. inquir has been
fukt over (yes, i know, several years ago) so that it refuses to accept
this address on the grounds that it is "too long for this item". when i ran
inquir on AI, this msg flashed by before i could see it, and i was
confronted merely with an altered inquir entry listing giving "T" as the
address. fortunately i examined the modified entry and so did not send it
off for installation. when i supduped over to MC, inquir showed me the
error msg with a decent delay. on both machines, what seems to occur is
that a T<CR> replaces the so-called too-long item, and the too-long item
ends up appearing as if it had been typed to the What next? question.
    anyway, i had to go into NAMES > in order to fix archy's address.

From MMcM at stony-brook.scrc.symbolics.com  Sun Oct  1 01:29:00 1989
From: MMcM at stony-brook.scrc.symbolics.com (Mike McMahon)
Date: Sep 30 89 20:29 EDT
Subject: can't yank from bolix
In-Reply-To: <19890930212059.0.ALAN@MR-BUN.parc.xerox.com>
Message-ID: <19891001002913.4.MMCM@OWL.SCRC.Symbolics.COM>

    Date: Sat, 30 Sep 89 14:20 PDT
    From: Alan Bawden <bawden at parc.xerox.com>

    This has a glitch:  If nobody is reading anything out of the tty input
    buffer, like if your program is running and not looking for typein, and the
    buffer gets full, then you won't be able to ^Z it.  The ^Z will just sit in
    a network buffer and never make it into the tty code (which checks for ^Z
    and ^_ does some other processing, before it even considers putting
    anything in the input buffer).

    I'll bet that the Sun you tried probably has the Unix-analog of this
    glitch: if a program isn't reading from the terminal, then input can get
    backed up sufficiently (perhaps back across the network) so that you can't
    do anything to interrupt it.

Fixed in Tenex :-)