HDTenEightyP/NetNews huggingface dataset:
From: rob@hobbes.cuc.ab.CA (Rob Parkhill)
Subject: Quotations
Organization: The Ohio State University Department of Computer and Information Science
Date: Sun, 27 Dec 1992 17:07:10 GMT

This looks like a good place to say this...
A couple of simple interface bugs...
1) Lip Service  

	Make the window big, and then resize it... ick! Buttons everywhere!
2) Quotations
	Search for a quote that doesn't exist and the 'Search' button stays as a 

	stop sign (doesn't change back to the 'Search' symbol until you search
	for a quote that does exist).

---
Rob Parkhill		|| Jack Frost roasting on an
rob@hobbes.cuc.ab.ca	|| open fire, Children nipping
(NeXTmail preferred!)	|| at his nose...
Can I can ya Al, how about Din? How about Laddie? Here
Laddie, here boy...
Newsgroups: comp.sys.next.bugs
From: dleon@seas.smu.edu (David Leon)
Subject: Installer and Digi Webster
Organization: SMU - School of Engineering & Applied Science - Dallas
Date: Wed, 23 Dec 1992 23:58:59 GMT

Two odd things I noticed after 3.0 upgrading:

1. Installer.app crashes when invoked by double-clicking a .pkg file, but
   works appropriately if invoked normally and then double-clicking a .pkg
   file.

2. Digital Webster no longer functions as a service (it crashes when used
   by the Services menu!)

Any fixes/workarounds?


Newsgroups: comp.sys.next.bugs
From: borris@boba.rhein-main.de (Borris Balzer)
Subject: My old Font-Problem with NS3.0
Reply-To: borris@boba.rhein-main.de (Borris Balzer)
Organization: Borris Balzer - DeskTopPublishing
Date: Tue, 22 Dec 1992 10:30:11 GMT


Hi there,

posting to other groups didn't bring any hints to solve my font-problem in an  
acteptable way (BTW: Thanks to all who answered).

The problem I've got:

NS2.1 installed, I used without problems fonts with the following names:
- Garamond (the ITC Garamond)
- AdobeGaramond
- StempelGaramond
- Garamond Three
After installing NS3.0 the AdobeGaramond and StempelGaramond disappeared from  
the font panel. A second run of 'font_update_2.0' (which works in 3.0 as fine  
as in 2.1!), 'buildafmdir' and at least 'cacheAFMData' didn't fix the problem.  
The fonts were shown as existing in the shell - but that doesn't fit to  
reality!
Using the old versions of 'font_update_2.0' and 'buildafmdir' (from NS 2.1 -  
the new 'buildafmdir' allows only to install about 256 fonts) didn't fix the  
problem, too.
Renaming the fonts AdobeGaramond to AdobeGaramont - using the T instead of D  
and StempelGaramond to Stempel - without 'Garamond (which was indeed a hard job  
- you have to do this into the outline and afm-files, too!) the fonts were  
represented with their new names in the font panel.
This might be only a interim fix - you get a lot of troubles in comunication  
with others (like Linotype-Services) because their fonts have the original  
names. Using the self-created new names results prints in Courier.

So my question to all reading this group: Is this a known bug in NS 3.0? Does  
anybody work on it? When NS 3.1 is available? Will it be free for 3.0-users?

Any suggestions to my font-problem?
Thanks for answering.
Merry (Ne)X(T)-mas

-Borris-
-- 

---
Borris Balzer - Kennedyallee 34 - D-6000 Frankfurt am Main - Germany
Tel +49-69-639266 - Fax +49-69-6312324 - e-mail borris@boba.rhein-main.de
Newsgroups: comp.sys.next.bugs
From: lfahnoe@kegworks.mn.org (Larry Fahnoe)
Subject: netinfo/security: lockout disables login_accounting
Organization: The Kegworks, Minneapolis, Minnesota
Date: Mon, 4 Jan 1993 02:37:31 GMT

Environment: standalone cube running 3.0

I would like to be able to log failed login attempts, and according to the
network and system admin guide (chapter 14, setting security options in
netinfo) I can do this.  After following the instructions and verifying
them with niutil:

	cubit> niutil -read . /
	master: localhost/local 
	security_options: login_accounting lockout 
	trusted_networks: 0 

To test this, I added a line to syslog.conf:

	*.debug		/usr/adm/debug

However after much tinkering about, I find that when you add the lockout
flag, you loose login_accounting's ability to log failed attempts.  A
simple test shows this:

	- set security_options to login_accounting
	- try a few bad logins
	- set security_options to login_accounting + lockout
	- try a few more bad logins

Only the first set of login errors will be logged.  It seems that
sucessfull logins get logged in either case, but I was not testing for
that case.  I have done these tests on a system with a fresh netinfo
database so I do not believe that there are additional bogosities in my
netinfo database that were causing problems.

Additionally, it seems that simply sending a HUP to syslogd does not cause
syslogd to really read /etc/syslog.conf.  I found that to add a new log
file required syslogd to be killed and restarted.

--Larry
-- 
Larry Fahnoe                        Cellular One
612/832-7616                        7900 S. Xerxes Ave, Suite 301
lfahnoe@kegworks.mn.org             Minneapolis, MN  55431
Newsgroups: comp.sys.next.bugs
From: paul@seer.demon.co.uk (Paul Lynch)
Subject: Re: Installer and Digi Webster
Organization: P & L Systems
Date: Thu, 24 Dec 1992 08:26:23 GMT

In article <1992Dec23.235859.21824@seas.smu.edu> dleon@seas.smu.edu (David  
Leon) writes:
> Two odd things I noticed after 3.0 upgrading:
> 
> 1. Installer.app crashes when invoked by double-clicking a .pkg file,  
but
>    works appropriately if invoked normally and then double-clicking a  
.pkg
>    file.
> 
> 2. Digital Webster no longer functions as a service (it crashes when  
used
>    by the Services menu!)

Neither of these occur on my system.

Paul
-- 
Paul Lynch
P & L Systems                   (NeXTmail) paul@seer.demon.co.uk
Tel: (0494)671501                      paull@cix.compulink.co.uk
Fax: (0494)680228                       76711.451@compuserve.com
Newsgroups: comp.sys.next.bugs,comp.sys.next.programmer,comp.databases.oracle
From: mrb@earth.wustl.edu (Mike Bray)
Subject: Two DBKit bugs - help me find fixes please
Organization: Washington University, St. Louis MO
Date: Wed, 30 Dec 1992 04:58:35 GMT

I'm running NextStep 3.0 (gold) on a Turbo Color NeXTStation, and 
Oracle 6.0.33.2.1.

1.  I have discovered a problem with DBExpressions that I haven't seen 
described anywhere yet.  I'm using the Oracle adaptor.  I create a DBExpression 
with the following description:  "select sysdate from dual".  Executing a fetch 
and displaying the results gives me GMT time.  Executing the same SQL statement 
from SQL*DBA, the Oracle administration tool gives me local time, as I expect, 
and need.  I suspect there's a problem with an environment variable or dwrite 
that is used to tell the MACH kernel what time to return.  Oracle Tech 
Support hasn't been able to tell me just what Oracle does to get the time, and 
I'm totally confused about how the NeXT does time localization.

I need a workaround of some sort.  Merely subtracting 7 hours from the GMT time 
doesn't allow for semi-annual daylight time shifts.

2.  Using the same DBExpression scheme as described above, but this time using 
the string "select to_char(sysdate,'HH:MI:SS') from dual" causes the program to 
crash.  I isolated the problem to the presence of the colon in the format 
string.  Substituting a period for the colon resulted in the proper response.  
I'm guessing that DBKit or the Oracle adaptor use an OCI call such as "osql3" 
and doesn't properly parse colons inside quotes, treating them like bind 
variables by mistake.  For a workaround, I'm resigned to using periods and then 
doing a character substitution on the result string to get the time format I 
want.

Question:  What version of Oracle OCI was used in the Oracle Adaptor?

Thanks,
Mike Bray 
mrb@earth.wustl.edu
307-332-6973 x279
From: werner@freya.inesc.pt (Werner Vogels)
Newsgroups: comp.sys.isis
Subject: Re: Question I got about use of shared memory in Isis
Date: 3 Jan 93 17:32:18 GMT
Organization: INESC - Instituto de Engenharia de Sistemas e Computadores, Lisboa, Portugal


> PS: You should also read about Ameoba RPC (email to rvr@cs.cornell.edu
> for pointers to Ameoba papers on this) and Chorus RPC (email to
> rozier@chorus.fr).  DELTA-4 also uses shared memory, I think,
> but I am sure Werner can be counted on to fill us in on this once
> he sees your query!  

Internally the Delta-4 XPA relied heavily on the use of shared memory, 
although of a different kind than the subject of the orginal posting. 

In the Delta-4 model the group communication suite run on a dedicated 
network attachment controller. This hardware component provided the 
host machine with access to the network, and was designed (by 
self-checking methods) to be fail-silent. The group communication
suite offered a very versatile set of communication primitives
with the emphasis on variations in agreement and order. The
protocols where designed to exploit low-level network technology
and offered strong responsive garantuees. The communication at this
level was between heavy-weight group entities called "gates".

Also on the NAC ran a multi-threaded process called the Group Manager 
responsable for the mapping of groups at the host level into xAMp gates. 
The groups at host level implemented the different algorithms from
the Deltase object oriented application environment. The communication
between NAC (Group Manager / xAMp) and host (Deltase objects and 
capsules) was done by means of shared memory and hardware interrupts.
The receive and send queues were implemented in the NAC's memory
segments, accessable by both NAC and Host. 

Shared memory was never used in the XPA as a programming model for
the applications, they were all implemented using the Deltase object
oriented methods.

> (Werner was previously in the Ameoba group)

Although it often looks like it, not all Dutch researchers involved
in distributed systems come from this nest, I had/have to "grow up"
without Andy's supervision.

--
Werner
Newsgroups: comp.sys.isis
From: ken@cs.cornell.edu (Ken Birman)
Subject: FDDI multicast?
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Fri, 25 Dec 1992 03:25:48 GMT

Werner's message leaves me curious: how does one get at FDDI
multicast from UNIX?  Is the "model" similar to ipmcast?
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis
From: jsw@eembox.ncku.edu.tw (Master Jyh-Shi Wu (82.9))
Subject: More about Causality
Organization: National Cheng-Kung University
X-Newsreader: Tin 1.1 PL3
Date: Sun, 27 Dec 1992 12:38:32 GMT

Newsgroups: comp.sys.isis
From: jhb@bnr.ca (John Bell)
Subject: isis source
Organization: Bell Northern Research
Date: Mon, 21 Dec 1992 15:42:28 GMT

Would some kind soul please point me towards the isis
ftp node and FAQ node.
Thanks,
John
Newsgroups: comp.sys.isis
From: ken@cs.cornell.edu (Ken Birman)
Subject: Re: isis source
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Mon, 21 Dec 1992 17:06:24 GMT

In article <1992Dec21.154228.28765@bcars6a8.bnr.ca> jhb@bnr.ca (John Bell) writes:
>Would some kind soul please point me towards the isis
>ftp node and FAQ node.

ftp node: ftp.cs.cornell.edu; login anonymous, password "me@my-host"

FAQ node: instead, we refer people to pub/comp.sys.isis, which has the
          full archive of postings up through number 1001.  
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis
From: ken@cs.cornell.edu (Ken Birman)
Subject: Question I got about use of shared memory in Isis
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Sun, 3 Jan 1993 15:23:04 GMT

Thought people might be interested by this:
> From: ajay@sjc.mentorg.com (Ajay Kumar)
> Subject: RPC on shared memory transport


>         I've been sampling the discussions on comp.sys.isis
> for some time. You seem to have done studies of RPCs and
> various transport mechanisms. Do you know of any implementation
> of RPCs that uses shared memory as the transport mechanism ?
> How does the performance of shared memory compare with UDP ,
> which on a single machine is reliable ? It seems to me that as
> we get more boxes with multiple CPUs and shared memory on desktops,
> communicating between different processes on the same machine will
> become as important as between processes on remote machines . Does
> isis address these types of architectures in particular ?

Mach uses this approach to RPC.  Performance is good for big
messages, but so-so for small ones, since the cost of playing with
page tables is substantial.  I would email to bershad@cs.cmu.edu for
his papers on "lightweight" RPC and also ask for pointers on this
question about basic Mach uses of shared memory...  Rick Rashid published
most of the Mach papers in places like USENIX, so you need the 
publications list from CMU to track the full set down.

As for Isis, we don't do anything special about this, but in our
manual, section on "examples", you will find an example of how to
use shared memory within a group of processes all of whose members
reside on the same machine.  So, it isn't hard to exploit shared
memory within an Isis application, but we don't use shared memory as
a communication layer ourselves.

The reason I don't do anything specific about this in Isis is that
management of the memory pool in which messages live is necessarily
an OS problem -- and Isis is a communication subsystem, not an OS.

The new work on Horus (follow-on to Isis) will use shared memory more
effectively.  Robbert van Renesse is the expert on this -- but he doesn't
waste his time with newsgroups :-(  Email to him directly with
questions (rvr@cs.cornell.edu)

When Isis V3.1 runs over Mach, we are planning to start making better
use of Mach IPC for local IPC. Hence, ISIS V3.1 will benefit from whatever
Mach does in this respect...  Same for Isis over Chorus...
The current V3.0 release uses UDP even when it runs on Mach or Chorus.

Ken

PS: You should also read about Ameoba RPC (email to rvr@cs.cornell.edu
for pointers to Ameoba papers on this) and Chorus RPC (email to
rozier@chorus.fr).  DELTA-4 also uses shared memory, I think,
but I am sure Werner can be counted on to fill us in on this once
he sees your query!  (Werner was previously in the Ameoba group)
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
From: ken@cs.cornell.edu (Ken Birman)
Subject: Re: 2.2.5: spooler problems
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Sun, 3 Jan 1993 14:28:06 GMT

In article <QfEQ_ve00h5K13C2cS@cs.cmu.edu> Sean.Levy@cs.cmu.edu writes:
>Hey all,
>
>I cannot get the spooler to function properly under 2.2.5. If this is
>all better in 2.2.7, I appologize for the waste in bandwidth, but I
>haven't had a chance to install the new version, so...
>

Well, I think that it works in 2.2.5 and 2.2.7, but we have run into
a number of problems with one of our commercial users.  Tim Clark is the
spooler expert now and will be back from a vacation/business trip around
January 15.  Meanwhile, here's my understanding of the situation.

 - The spooler works on V2.2.5 except when the destination WAN is
   specified as "all".  "all" causes many problems and can hang the
   failure-recovery code -- bad news.

   For V2.2.7, the spooler should work ("all", too) but is annoyingly
   slow.  Moreover, it lacks flow control mechanisms and hence if you
   try even moderately hard, you can get the spooler itself to consume a lot
   of memory and eventually shut down.

   For WAN message rates of up to about 5 per second, average, the V2.2.7/
   V3.0.7 spooler should be fine.  (1k messages).

 - Tim recoded the problematic part of the wide-area code and got a big
   speedup plus better handling of large messages and better flow control.
   His version is available now for beta-test users (now means "when he 
   gets back from his trip").  It gets about 30 messages per second to a
   remote node and by the time of the real release we may be able to push
   this up by an additional 20-30%.

The main issues are that "all" was implemented incorrectly in V2.2.5/V3.0.7
and just didn't work, and that the disk logging mechanism used was unfortunate
in those versions of the spooler.  V3.0.7/V2.2.7 fixes the bug in all, but
we needed to recode the way that the wan spool files themselves are managed
to get acceptable performance -- thats where the 30/second numbers come from;
the limit is related to the bandwidth of a flushed write to a local file
system... we may introduce a less safe mode in which the disk IO is not]
flushed on every WAN write; this would let us push to about 100/second...

I hope this is helpful.  Tim will send more info when he gets back.  For
CMU, I guess I would get Tim to prove the new version and work with that
directly -- no point in reinstalling it after just 2 weeks!

-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis
From: ken@cs.cornell.edu (Ken Birman)
Subject: Re: Notes on IP Multicast option for ISIS
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Wed, 23 Dec 1992 15:06:56 GMT

In article <1992Dec22.212230.28572@cs.cornell.edu> ken@cs.cornell.edu (Ken Birman) writes:
> >I am working on IP multicast for Isis...

> Brad Glade asks: "how will we handle the case where an old application
> tries to join a process group that is using ipmcast, and hence doesn't
> follow the new rules."  (from email to me)

As things stand, this is quite a bit easier for an application that
used ISIS_IPMCAST in starting up than for one that didn't.  So:

  - If the caller used ISIS_IPMCAST, I can turn the feature on for 
    a group even if PG_IPMCAST is omitted, if it turns out that the
    group was created by someone who specified PG_IPMCAST.

  - If the group was created to not use IPMCAST and the caller tries
    to specify PG_IPMCAST, the system will return an error, number
    IE_IPMCAST (``ipmcast not used uniformly within this group'')

  - If the caller doesn't use ISIS_IPMCAST and tries to join/become a client
    of a group that is using IPMCAST, I will return the same error.

... I don't really see how the system can do better than this,
unfortunately.  There is a lot of mechanism that needs to be running
when you try and join a group which is using IPMCAST and if it isn't
in place, the whole thing just won't work.

> A different question: ``[I] said that if a platform doesn't allow multicast
> and the option is used, performance may suffer... why?''

The problem here is that the older Isis UDP scheme is more appropriate
for point-to-point message passing; it does lots of things to cleverly
piggyback multiple messages on each packet, etc.  The ipmcast code does
retransmit messages using a point-to-point scheme, which is why someone
who doesn't have a platform supporting multicast can still join in, but
every message to him will be lost and retransmitted -- which is why performance
would suffer badly in that case.

---

PS: Please post questions directly, so readers can see the questions
and not just the answers!
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428
Newsgroups: comp.sys.isis
From: werner@freya.inesc.pt (Werner Vogels)
Subject: Re: FDDI multicast?
Organization: INESC - Instituto de Engenharia de Sistemas e Computadores, Lisboa, Portugal
Date: Fri, 25 Dec 1992 16:01:02 GMT

In article <1992Dec25.032548.13096@cs.cornell.edu>, ken@cs.cornell.edu (Ken Birman) writes:
|> Werner's message leaves me curious: how does one get at FDDI
|> multicast from UNIX?  Is the "model" similar to ipmcast?

The model is independent of ipmcast, You just need an ioctl to your 
controller to add and delete mcast addresses. Like it happends now 
in if_ether.c you will need a CLASSD to MAC address conversion and problably 
you want some bookkeeping. The real hardware stuff is left to the device 
driver. If the driver is correctly written you do not really need to keep
much state about duplicate joins of ipmcast groups; the driver should
maintain this itself. In the pre ipmcast SunOS 4.1.1 days you could 
find the multicast addresses at controller in the arpcom structure which 
is part of every if es_if (ethernet), but the new ipmcast ethernet module 
does different bookkeeping.

--
Werner
From: ken@cs.cornell.edu (Ken Birman)
Newsgroups: comp.sys.isis
Subject: Forwarded comments Re: Notes on IP Multicast option for Isis
Date: 24 Dec 92 16:29:26 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

From: gthaker@hannibal.atl.ge.com (Gautam H Thaker)

Here are my two cents worth of comments...

   When will IP mcast be used?
      - I plan to require that all (or most) machines using Isis support
	the IP Multicast standard, which was developed by Steve Deering at
	Stanford and has become part of Solaris 2.1; Steve's code is also
	available for many other platforms, but perhaps not as a standard
	offering from the vendor.

Requiring that most machines using isis support IP Multicast seems
a bit strong. I don't know if HP, DEC, IBM, Lynx etc. support this
as well as SOlaris 2.1, be cause we worry about using ISIS from all
these other platforms.

	The code defines some setsockopt() options: SO_REUSEADDR, IP_MULTICAST_TTL,
	IP_ADD_MEMBERSHIP, IP_DROP_MEMBERSHIP.  It also includes a multicast
	router, called "mrouted".  If these are not up, IP multicast use triggers
	a point-to-point mechanism slightly but not drastically slower than
	the usual Isis UDP scheme.

      - You will need to have an authorization for "ipmcast" in your isis.rc
	file.
Eventually, multicast should be folded in with price of standard ISIS
to keep ordering process simple, but no big deal here.

      - You will need to specify ISIS_IPMCAST as a flag to isis_remote_init()

      - Only messages sent in diffusion mode (to the full set of members and
	clients) will be multicast.  However, you can overlap groups and in this
	way can build up other patterns pretty easily.
Not sure about this. Does this mean that if I have peer group of 10 members
and I do a normal cbcast multicast won't get used? 

   From experiments (done, however, with a different version of the code) we
   expect to see a benefit for groups with more than about 4 members.  However,
   we have yet to experiment seriously with the new code on Solaris, for
   technical reasons, so I won't have solid numbers for a little longer.

Please consider publishing a "performace brief" for ISIS, including
numbers for multicast perf. I realize that you and your staff does not
have infinite time, but perhaps slowly something can be built up.

Also, how do people find Solaris 2.x overall?   Do things work seamlessly,
or is some amount of effort needed to move to Solaris?
-- 
Kenneth P. Birman                              E-mail:  ken@cs.cornell.edu
4105 Upson Hall, Dept. of Computer Science     TEL:     607 255-9199 (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     607 255-4428