HDTenEightyP/NetNews huggingface dataset:
From: wdc@ATHENA.MIT.EDU (Bill Cattey)
Newsgroups: comp.soft-sys.andrew
Subject: Hasn't the message line bogosity gone on long enough?
Date: 26 Aug 92 03:17:01 GMT
Distribution: world
Organization: The Internet

Who else here is tired of having the contents of the message line
dissappear when their pathname happens to be one character too long?

Isn't there some sensible way this can be fixed?

How about:

making the message line fixed with fonts, un justified?
making the message line two lines tall so that people will get the idea
they really can scroll around in it?

Other ideas?

I know I'm really tired of this.
My users sure are.

-wdc
From: wdr+@rchland.ibm.com (Wayne D Richardson)
Newsgroups: comp.soft-sys.andrew
Subject: Re: Questions about console
Date: 27 Aug 92 12:39:27 GMT
Reply-To: "Wayne D Richardson" <wdr@vnet.ibm.com>
Organization: The Internet

Excerpts from ext.misc.info-andrew: 25-Aug-92 Questionsabout console "Z.
Horvat"@RCHGATE.rchl (793*)

> I'm running the Andrew Toolkit on an IBM RS 6000 AIX 3.1.6.
> Console seems to have some problems:

> - Switching from the initial console display to another type ofconsole
> yields in the cursor beeing changed to the "clock" symbol, never
> returning back to the normal pointer. The stat graphs behavenormal.

This problem seems to have appeared in the last release or so.  To
showanother aspect of it, grab and drag a console (interior) border with
the rightbutton;  when released, the resizeicon[An Andrew ToolKit view
(a footnote) was included here, but could not be displayed.] remains as
the console pointer icon.

-wr
From: janssen@parc.xerox.com (Bill Janssen)
Newsgroups: comp.soft-sys.andrew
Subject: Re: More checks on size of ATK applications
Date: 25 Aug 92 18:18:47 GMT
Distribution: world
Organization: The Internet

Excerpts from ext.andrew: 21-Aug-92 More checks on size of ATK .. Nick
Williams@cs.city.ac (1088+0)

> Hence the 900 odd K of runapp could be cut down fairly massively.

> Am I wrong?

Not at all.  Here's my 24K (SunOS 4.1.1, SPARC) version of EZ:

    #include <stdio.h>

    #include <class.h>
    #include <im.ih>
    #include <buffer.ih>
    #include <frame.ih>

    #ifndef _XLIB_H_
    #define Window unsigned long
    #define Display char
    #endif
    #include <xim.ih>

    main (ac, av)
         int ac;
         char **av;
    {
      struct xim *xim;
      Window window;
      struct buffer *buffer;

      initclass();

      im_SetProgramName("edit");        /* if this isn't done,
    im_Create() will core-dump.  Dumb.  */

      window = atoi(av[1]);
      buffer = buffer_GetBufferOnFile (av[2], 0);
      xim = xim_New();
      if (!xim_CreateWindow (xim, "localhost"))
        exit(1);
      xim_SetView (xim, frame_Create(buffer));
      im_KeyboardProcessor();
      exit (0);
    }

    static initclass ()
    {
    #if ((sun)&&(sparc))

    #include <sys/fcntl.h>      /* for O_RDWR */

      {
        int fd;

        /*
         * XXX - force "/dev/zero" to be open as a file descriptor one
         * greater than the first available one, as a workaround for a
         * 4.1 bug (also present in 4.1.1) in the run-time loader.
         * (Fixed in System V Release 4, allegedly.)
         */

        printf ("doing fix for SunOS 4.1...\n");

        fd = open("/dev/zero", O_RDWR);
        dup(fd);                        /* one greater */
        close(fd);
      }
    #endif

      class_Init(AndrewDir("/dlib/atk"));
    }


Link it with libclass.a and libutil.a...

Bill
From: wdc@ATHENA.MIT.EDU (Bill Cattey)
Newsgroups: comp.soft-sys.andrew
Subject: Re: "slow networks"
Date: 1 Sep 92 16:25:35 GMT
Distribution: world
Organization: The Internet

Excerpts from mail: 28-Aug-92 Re: "slow networks" Bob Dew@alw.nih.gov (1038*)

> As things are, if ATK is compiled without the options for AFS and AMDS,
> are the resulting programs much larger and more complicated than if the
> message server code didn't exist at all?

I forgot to answer this issue.

I can't compile messages without the AFS option enabled.  Well, I can,
but if any of the file servers in my READ ONLY mspath goes down,
messages will not let me SEND outgoing mail -- even though I am sending
it with sendmail!

The amsn.do file is 1 Meg.  What of that do I REALLY need to read
hierarchies of messages format archives and to send mail using sendmail?

-wdc
From: ZRSN@DS0RUS1I.BITNET (Jiri Mracek)
Newsgroups: comp.soft-sys.andrew
Subject: Snapified AMS
Date: 31 Aug 92 12:10:26 GMT
Distribution: world
Organization: The Internet
X-Unparsable-Date: Mon, 31 Aug 92 13:48:00 MSZ

Hello,
I need  your help in the following matter:
    Our universal computer will be replaced by a RS 6000 cluster.
    During a login process a user will be (automatically) assingned
    to a mashine which is not heavily loaded. Hence, such a user
    doesn't know what machine (s)he will be actually using. That is
    why (amog other things) we have to solve a mail problem. Namely,
    users should be able to read their mail on whatever machine of
    the cluster  they are.
    Being in a AFS cell we decided to use AMS which allows
    distributed mail processing. So,  I copied the binary
    distribution of ATK 5.1 (/afs/andrew.cmu.edu/itc/ ...
    /X.V11R5/ftp/cdrom/rs_aix31/andrew.tar.Z) and installed it.
    I read the appropriate help file, /usr/andrew/help/ams.help,
    which claims:
          -- explicitly run the message server as a separate
    process, by typint the name of the program plus an "s":

        messagess.

    Unfortunately, there is no messagess program in the binary
    distribution of ATK 5.1, is there? .
    Then, I looked for other ms-help files. In the file NonUnix.ins,
    Building and Installing Snapified Clients and Servers, I found
    something usefull. It looks like I have to get the source
    distribution of ATK  to build, to install and to run
    Snapified Clients and Servers, haven't I?.

I appreciate any help and/or hint.


Jiri Mracek                     Phone : +49 711 685 4806
                                Fax   : +49 711 682 357
Systems Section                 Email : Mracek@rus.uni-stuttgart.de
Computer Center                 Mail  : Allmandring 30
University of Stuttgart                 7000 Stuttgart-80
                                        Germany
From: paw@coos.dartmouth.edu (Pat Wilson)
Newsgroups: comp.soft-sys.andrew
Subject: ATK4 or 5 for AIX 3.2?
Date: 31 Aug 92 18:39:26 GMT
Distribution: usa
Organization: Project NORTHSTAR
Originator: paw@coos.dartmouth.edu


I'm attempting to build ATK4 for rs/6000s running AIX 3.2 (and AFS).
Does anyone have configuration files they'd share?  Even better, of
course (I guess), would be ATK5 configuration files for AIX 3.2 - all 
that's shipped on the CDROM are AIX 3.1. 

I've never had to make ATK before, so my apologies if the solution
is extremely obvious...

Thanks.
-- 
Pat Wilson
Systems Manager, Project NORTHSTAR
paw@northstar.dartmouth.edu
From: wdc@ATHENA.MIT.EDU (Bill Cattey)
Newsgroups: comp.soft-sys.andrew
Subject: Re: "slow networks"
Date: 27 Aug 92 23:04:29 GMT
Distribution: world
Organization: The Internet

It turns out that there is a great deal of hair in the message server,
and a great deal of AFS version 3 specific code there.  The abstraction
barriers are regularly crossed in complicated but necessary ways to deal
not so much with security as reliability.  

The AMDS mail delivery method is fundamentally flawed.  It is bad design
to require the delivery agent to have to deal with the possibility that
there are as many delivery agents as there are users all attempting to
write into a unix file system home directory to copy mail in and update
status simultaneously.

Client/Server is a good model for a mail delivery agent.  It puts the
smarts for dealing with race conditions into small well-understood
blocks of code. It does not require a high speed network connection at
all times for mail delivery.

The AMDS method was an interesting experiment, and a lot of people
worked their butts off making it work and making it reliable.  I expect
they know more about race conditions than any other mail system delivery
gurus.  But the system would benefit greatly from a paradigm shift to
the common client-server models.

The toolkit architecture is another experiment.  But this experiment
turns out to be well suited to the problem domain and will continue to
influence GUI and toolkit designs for several years.  I believe that the
ATK richness should be kept, but that the AMDS richness should be
learned from and then radically simplified.

-wdc
From: ghoti+@ANDREW.CMU.EDU (Adam Stoller)
Newsgroups: comp.soft-sys.andrew
Subject: Re: message line bogosity
Date: 26 Aug 92 19:54:06 GMT
Distribution: world
Organization: The Internet

Excerpts from internet.other.info-andrew: 26-Aug-92 Re: message line
bogosity Robert Kemmetmueller@rch (781+0)

> Anyway, this is a little off-the-wall, but how about dynamically
> changing the font size?
> When something in the message line gets too long, the text can get
> shrunk so it still fits.
> If there's a whole mess of text, it can get scrunched down into a
> teeny-tiny font so it will all still fit.

I don't think that idea would fly too much - some people set up their
fonts specifically so that they can read them, and shrinking the fonts
for longer messages may greatly impair their ability to read the
information presented.

I'd be happy with the way it used to be a long time ago - if the message
was too long to fit in the existing space allocated for the
message-line, it wrapped - and all you would see was the wrapped
portion. 

BUT THEN you could enlarge the message line (horizontally and/or
vertically)  and find out what the whole message was.  If you increased
the size vertically - it became scrollable.  

AND it maintained a small (<10?) history of the last N messages - and
each was timestamped (much the way they are in Console) so you could get
some amount of context.  

The only thing I can see that would be an improvement - is if the
(vertical) size of the message-line were able to change on the fly -
dependant upon the length of the message being displayed - and then
automatically decrease in size again afterwards (heuristic needed)

--fish
From: krishna@shamu.csd.sgi.com (Krishna `Shamu' Sethuraman)
Newsgroups: comp.soft-sys.andrew
Subject: Re: "slow networks"
Date: 27 Aug 92 18:08:57 GMT
Reply-To: krishna@sgi.com
Distribution: world
Organization: The Internet


To solve this very problem, since I don't have anything but an 80x24 terminal
at home, I use CUI.  But, CUI is definitely *flexible* enough that I wrote a
cui.el for use with it, allowing me to read my mail at home through emacs.  Xmh
definitely is a lose, in my experience - I find myself abandoning goo-ui user
interfaces for an emacs-based client, even when I have to write the emacs
client myself.  Messages is the one GUI client that I retain, because of its
good design (at least in my estimation) and speed.

Providing a text client that's powerful enough to allow an emacs front end, is
again in my estimation, a sign of a user interface designed well enough to
accommodate future expansion and a high degree of personal customization.

Krishna Sethuraman
krishna@sgi.edu
Silicon Graphics Incorporated - the Leader in Visual Supercomputing
(If that's so, how come they use Motif?)

P.S.  Hi Bill!!!





Newsgroups: comp.soft-sys.andrew
From: zstern@adobe.com (Zalman Stern)
Subject: Re: Hasn't the message line bogosity gone on long enough?
Organization: Adobe Systems Incorporated
Date: Wed, 26 Aug 1992 06:49:03 GMT

[Text redraw improperly line wraps long message lines.]
If it overflows, build a dialog box with a large message line and pop that  
up instead. See how people like that. You could dynamically resize the  
message line instead. Both of these should be relatively easy to do if I  
recall frameview at all. (Which I probably don't).

In general, message lines are a difficult proposition to manage properly in  
a graphical UI. Its 1970's (or perhaps 1960s) technology. I would say that  
effort is better spent building a real dialog manager for ATK. Look at the  
Macintosh Toolbox, MacApp, or MS-Windows for examples.
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Virtual Reality has nothing on Calvin." Bill Watterson
From: Craig_Everhart@TRANSARC.COM
Newsgroups: comp.soft-sys.andrew
Subject: Re: "slow networks"
Date: 1 Sep 92 18:12:45 GMT
Organization: The Internet

Excerpts from internet.other.info-andrew: 1-Sep-92 Re: "slow networks"
Bill Cattey@Athena.MIT.E (669+0)

> Excerpts from mail: 28-Aug-92 Re: "slow networks" Bob Dew@alw.nih.gov (1038*)

>> As things are, if ATK is compiled without the options for AFS and AMDS,
>> are the resulting programs much larger and more complicated than if the
>> message server code didn't exist at all?

> I forgot to answer this issue.

> I can't compile messages without the AFS option enabled.  Well, I can,
> but if any of the file servers in my READ ONLY mspath goes down,
> messages will not let me SEND outgoing mail -- even though I am sending
> it with sendmail!

> The amsn.do file is 1 Meg.  What of that do I REALLY need to read
> hierarchies of messages format archives and to send mail using sendmail?

This has nothing to do with AMDS or sendmail.  This has to do with your
mspath, which of course is never read-only.  (Or, more to the point,
it's read-only to just about anybody.)

The message server's address validation code (yes, address validation,
done in the message server and NOT in AMDS) checks all destination
addresses you type to see if they might be names of bboards to which
you're trying to post.  (There is a read-only attribute usable on a
per-folder basis, that will refrain from validating any attempt to post
there, but this is an attribute of a folder, not an attribute of an
mspath element.)  The bboard names are ultimately stored as files and
directories under the mspath elements that you name, and the conversion
to postable addresses is done via files in those directories (under
those mspath elements).

And, gee, messages does exactly the same thing to me when I try to post
if any of the directory trees in my mspath is unavailable.  Only
messages will simply ask for confirmation of the address; it doesn't
``not let me SEND outgoing mail''.  Bill, does your Messages actually
refuse to send the mail, or does it simply ask whether the address is
correct as it stands, since you might have intended it to address mail
to be posted on one of the bboards?

		Craig
From: krishna@shamu.csd.sgi.com (Krishna `Shamu' Sethuraman)
Newsgroups: comp.soft-sys.andrew
Subject: Re: "slow networks"
Date: 27 Aug 92 18:09:02 GMT
Reply-To: krishna@sgi.com
Distribution: world
Organization: The Internet


To solve this very problem, since I don't have anything but an 80x24 terminal
at home, I use CUI.  But, CUI is definitely *flexible* enough that I wrote a
cui.el for use with it, allowing me to read my mail at home through emacs.  Xmh
definitely is a lose, in my experience - I find myself abandoning goo-ui user
interfaces for an emacs-based client, even when I have to write the emacs
client myself.  Messages is the one GUI client that I retain, because of its
good design (at least in my estimation) and speed.

Providing a text client that's powerful enough to allow an emacs front end, is
again in my estimation, a sign of a user interface designed well enough to
accommodate future expansion and a high degree of personal customization.

Krishna Sethuraman
krishna@sgi.edu
Silicon Graphics Incorporated - the Leader in Visual Supercomputing
(If that's so, how come they use Motif?)

P.S.  Hi Bill!!!
From: rdew@ALW.NIH.GOV (Bob Dew)
Newsgroups: comp.soft-sys.andrew
Subject: AMDS problem
Date: 1 Sep 92 15:59:11 GMT
Distribution: world
Organization: The Internet


Since building Andrew 5.1 on sun4c_41 running afs31b, we've been
experiencing frequent, but sporadic problems in reading new mail from a
user's home-area Mailbox.

When attempting to read new mail, a pop-up window reports, "Messages in
/afs/alw.nih.gov/dcrt/userid_here/Mailbox could not be properly read and
delivered (0 successes, 0 failures (0 locked, 0 in progress))".  The
message window at the bottom of the screen says, "Error: Bogus return
from system call (in system in ProcessNewMesssages)".

When this problem occurs, the user's setup appears fine--tokens are
present, quotas are well below limits, etc.  What's odd, though, is that
the  occurrence of this problem is linked to a host, rather than to a
specific user.  That is, when one user experiences difficulty reading
new mail from a particular workstation, everybody who logs into that
workstation sees the same problem.  Yet the workstation setup looks
normal.  Many different workstations (all with nearly identical setups)
have been experiencing this problem.

An automatic bug report generated from messages on a disfunctioning
workstation consistently shows only one peculiarity:  a warning always
indicates the presence of an open messages file in /tmp, as shown below:

    Here are the open files known to the file descriptor plumber:

    ----------------------------------------

    <warning:fdplumb>File '/tmp/oecs5xi0ts190kEU85' (opened by fopen) is
    still open.

    <warning:fdplumb>Total of 1 open files.     
 

Oddly, a directory listing of /tmp shows no such file, which leads one
to believe that messages is attempting to use /tmp for some sort of
temporary storage during new mail processing, and that the transaction
is unsuccessful.

This problem persists for hours or days at a time, then disappears.

If anyone has clue what might be causing this problem, we'd be very
grateful for some help.


Thanks,

Bob Dew
National Institutes of Health
Bethesda, MD  20892
(301) 496-5361
From: Craig_Everhart@TRANSARC.COM
Newsgroups: comp.soft-sys.andrew
Subject: Re: "slow networks"
Date: 28 Aug 92 17:02:46 GMT
Distribution: world
Organization: The Internet

Well, shucks.  When Bill Cattey proposed jettisoning the message server,
I assumed he was talking about jettisoning the funky message-server/MUA
(mail user agent, e.g. cuis, vuis, messagess) split in favor of some
newer protocol.  Not a bad idea to explore, what with interesting
mailbox-access protocols like IMAP and POP to check out.  Certainly the
MS/MUA split is cumbersome for linked-together MUA applications
(messagesn, cuin, vuin--the normal case); what seemed appropriate for
PC&Mac support in 1985 doesn't make that much sense today.  No surprise
here.

I didn't realize that what Bill seemed to be targeting was the whole
AMDS picture.  (Yes, lots of folks worked on making that reliable,
including guys like Mike Kazar making AFS work.)  I just don't see how
Bill's AMDS retrospective critique follows.  Essentially, AMDS follows a
client-server model, piggybacking on top of the AFS client-server model.
 AFS effectively provides a real good name service, allowing clients
anywhere to find the correct server for the desired service.

Given that Bill has never really lived with AMDS himself, I'm wondering
how he comes to his conclusions.  Perhaps the tenseness in the message
server (the UI-support component) is the stuff that Bill finds
objectionable.  Indeed, it was largely a matter of taste, whether to put
all that address validation support into the message server.  I happen
to like the support it offers.  In trying to package AMDS+messageserver
up for use at non-andrew.cmu.edu sites, the validation support becomes
something of a nightmare for installers, but we tried to deal with this
by making it reasonable for installers to turn all that stuff off.  And
it really can be helpful when it's in a working installation.  The
problem as I see it is that all the messageserver code to support
address validation is nightmarishly complicated.  Is that what Bill's
complaint is really about?

I guess I don't follow Bill's paragraph:
Excerpts from internet.other.info-andrew: 27-Aug-92 Re: "slow networks"
Bill Cattey@Athena.MIT.E (1456*)

> The AMDS mail delivery method is fundamentally flawed.  It is bad design
> to require the delivery agent to have to deal with the possibility that
> there are as many delivery agents as there are users all attempting to
> write into a unix file system home directory to copy mail in and update
> status simultaneously.

Wish I did follow this statement, so I could form some opinion about it.
 Clearly, in any mail delivery scene, somebody serializes mail
deliveries somewhere.  What's the difference how or when that happens?

I wouldn't claim that AMDS is flawless, or that there aren't parts that
should be re-worked or withdrawn.  (Or that the messageserver
name-validation stuff is simple.)  I just don't understand this
criticism--whether it's based on some new religion whose evangels
haven't reached this shore, or what.

		Craig
From: rapatel@THEOPHILUS.RUTGERS.EDU (Rocky - Rakesh Patel)
Newsgroups: comp.soft-sys.andrew
Subject: message, MIME and reformat/text patch.
Date: 31 Aug 92 18:42:33 GMT
Distribution: world
Organization: The Internet

<nl>
<nl>
One of the problems with the MIME support is that when one sends out<nl>
a message with the "Remove formatting & send" option, is that a MIME<nl>
header is included with content type set to US-ASCII for those uf us<nl>
in the US - even when not using encoding. This while perfectly legal,<nl>
can cause mailers that invoke metamail to invoke it on pure ascii text.<nl>
This annoys many users I send mail to. :-(   Given that mail gets sent<nl>
everywhere in the world in pure text format, I don't believe that the followin=
g<nl>
patch would hurt people given that (at least from my perspective) the remove<n=
l>
formatting and send option was designed to allow non-Andrew users<nl>
to read the message easily. I would translate that to be for non-MIME users<nl=
>
in the current situation. Well, here is the patch to atkams/messages/lib/sen=
daux.c for those that may be interested in it:<nl>
<nl>
*** sendaux.c.ORIG	Tue Mar 17 19:44:13 1992<nl>
--- sendaux.c	Mon Aug 31 14:14:53 1992<nl>
***************<nl>
*** 1117,1124 ****<nl>
  	      if (!charset) charset =3D "iso-8859-1"; /* Just a guess! */<nl>
  	      NeedsEncoding =3D 1;<nl>
  	  } else charset =3D "US-ASCII";<nl>
! 	  fprintf(fp, "MIME-Version: 1.0\nContent-type: text/plain; charset=3D%s\n"=
, charset);<nl>
! 	  if (NeedsEncoding) fprintf(fp, "Content-Transfer-Encoding: quoted-printab=
le\n");<nl>
  	}<nl>
  	/*    environ_Put("TextWriteVersion12", "X"); /* phased out 12/27/88, now d=
efault */<nl>
  	 d =3D sendmessage->HeadText;<nl>
--- 1117,1126 ----<nl>
  	      if (!charset) charset =3D "iso-8859-1"; /* Just a guess! */<nl>
  	      NeedsEncoding =3D 1;<nl>
  	  } else charset =3D "US-ASCII";<nl>
! 	  if ( ! (strcmp(charset,"US-ASCII") =3D=3D 0 && (! NeedsEncoding)) ) {<nl>=

! 	    fprintf(fp, "MIME-Version: 1.0\nContent-type: text/plain; charset=3D%s=
\n", charset);<nl>
! 	    if (NeedsEncoding) fprintf(fp, "Content-Transfer-Encoding: quoted-print=
able\n");<nl>
! 	  }<nl>
  	}<nl>
  	/*    environ_Put("TextWriteVersion12", "X"); /* phased out 12/27/88, now d=
efault */<nl>
  	 d =3D sendmessage->HeadText;<nl>
<nl>
<center><flushleft><center><nl>
</center></flushleft>Rakesh Patel</center><flushleft><center><nl>
<italic>Systems Programmer<nl>
</italic></center></flushleft><center><bold>Network Services/NJIN Project<nl>
Telcommunications Division<nl>
</bold></center><flushleft><center><bold><bigger>Rutgers University Computing =
Services<nl>
</bigger></bold></center></flushleft><center>rapatel@hardees.rutgers.edu<nl>
rapatel@pilot.njin.net<nl>
<nl>
</center><underline><nl>
</underline>