HDTenEightyP/NetNews huggingface dataset:
From: dog.ee.lbl.gov!porpoise!network.ucsd.edu!munnari.oz.au!metro!maths.su.oz.au!szabo_p@ucbvax.Berkeley.EDU  (Paul Szabo)
Subject: Re: automatic screen turn-off
Organization: Mathematics, University of Sydney
Distribution: fj
Date: Tue, 1 Sep 1992 21:23:05 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <1992Sep1.124958.29119@lmpsbbs.comm.mot.com> shuky@mot.com
(Joshua Beinhorn) writes:
> In article  <BtuqtL.Jor@apollo.hp.com>  ganek@apollo.hp.com (Dan Ganek) writes,
> in answer to my question :
> >  >However, in some cases the screen is not turned off even if there is
> >  >no user input for hours. In particular, This happens when there is one 
> >  >window which covers all the screen.
> >  So, perhaps the app your running in the full screen window is calling
> >  gpr_$video_ctl.  Does it happen if your grow an ordianry  DM pad to full 
> >  screen?
> The screen is not being turned off when I leave it with no particular application
> running - just one or more shell and edit windows open.

I have the following explanation, which may of course be completely wrong...

Maybe the screen is not blanked out because there is mouse input. Sometimes
mice are left in a position where they generate a continuous stream of
input; in this case the cursor on the screen is an arrow, not reverting to
the steady-state block. In these cases I find that moving the mouse a tiny
bit will allow the cursor to become a block.

Inside the mouse there are two slotted wheels which rotate (in response to x
and y mouse movements) between a LED and a photodiode; these give pulses
corresponding to the succession of dark/light. If you happen to stop the
mouse such that the LED is half-obscured, the photodiode may not be able to
make up its mind whether it is light or dark, emitting a continuous stream
of pulses. (Whatever happened Schmitt triggers?)

Hope this makes sense.

Paul Szabo - System Manager   //        School of Mathematics and Statistics
szabo_p@maths.su.oz.au        //   University of Sydney, NSW 2006, Australia
Newsgroups: fj.mail-lists.apollo
From: davidy@hwcae.az.honeywell.com (David Young -davidy K26E2 x2968)
Subject: Problems after I have installed Domain OS
Posted-Date: Thu, 27 Aug 92 12: 18:04 -0600
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Thu, 27 Aug 1992 18:18:04 GMT
Return-Path: <davidy@hwcae.az.honeywell.com>


** cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!mips!mips!rtech!ingres!root@ucbvax.Berkeley.EDU  (Operator) on 26 Aug 92 18:30:23 GMT
** in [Problems after I have installed Domain OS] writes:

Operator> I have the following problem. I have just installed DomainOS on a
Operator> second Apollo 400 m/c and , using the other 400 as a master, am trying
Operator> to update the registry that there is a new node on the network. The
Operator> install guide says to type the following:

Operator> /etc/ctnode coley 4e593 -l -r -root

Operator> where coley is the new node name.

Operator> The above gives me the  following error:

Operator> Unable to update replicated root;local cache not updated - transmit failed (OS/network)

Sounds like your a little "green" :-)

Don't confuse the registry with Apollo's naming service.  The registry
is used ONLY for user login account information.

When you use the '-root' switch on ctnode, it is adding an entry to
the NS_HELPER database (apollo's name server).  Generally you use the
ns_helper in large networks or when you decide to create DDS internets
(not be confused with TCP/IP internets, which are different).

If you are only have two nodes, I'd use the command:

   /etc/ctnode -update -all

(this assumes that you are using the default NETID of zero too) and be
done with it. 

Otherwise, to successfully use the command you issued, you must start
the ns_helper on one or more of the nodes, and initialize it.  See the
help file on 'ns_helper', and the 'edns' command that is used to modify
the ns_helper database.

--
David J. Young                      Honeywell -- Air Transport Systems Division
Phone: 602.436.2968              P.O. Box 21111 M/S AZ75-K26E2 Phoenix AZ 85036
davidy@hwcae.honeywell.com                    uunet!asuvax!apciphx!hwcae!davidy
AMA   AMUG  APDA  BMWCCA  Golfer  Private Pilot  Scuba-Diver  and more....
Do you know Kimball?  EQ Kimball, the insurance man?
Newsgroups: fj.mail-lists.apollo
From: mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!ttknock@bloom-beacon.mit.edu  (Robert Armstrong)
Subject: Wanted: Fast/Color Apollo
Organization: None
Distribution: fj
Date: Sun, 23 Aug 1992 16:37:22 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>


 I am interested in buying a color Apollo system with either a fast
030/882 or an 040 in it. If you are selling one used or are a commercial
dealer please feel free to e-mail me any information.

ttknock@hal.gnu.ai.mit.edu
Newsgroups: fj.mail-lists.apollo
From: csus.edu!netcom.com!snow@decwrl.dec.com  (Tim Szeliga)
Subject: Re: Strange packaging technique
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: fj
Date: Thu, 3 Sep 1992 19:09:33 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>


A few years ago, we got a disk drive in a big packing case. To lodge
the drive securely in the box, there was a heavy 20 inch length of 1.5"x1.5"
hardwood.  Stenciled on the side (you're getting ahead of me here),
was the phrase (you guessed it) "HP P/N 19511-80014".  
  Many's been the time when an object (or person) required delicate
adjustment and received a wallop from "the HP Part Number".

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Tim Szeliga	 Org:National Weather Service / Hydrologic Remote Sensing
Voice: (612) 725-3259  			NOHRSC BBS:  (612) 725-3230  (8N1)
UUCP:	apple!netcomsv!frost!tim		Internet: snow@netcom.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Newsgroups: fj.mail-lists.apollo
From: ftpbox!mothost!lmpsbbs!mcil.comm.mot.com!gordonb@uunet.uu.net  (Gordon Berkley)
Subject: send_alarm for X?
Organization: Motorola Communications Israel Ltd., Tel Aviv
Distribution: fj
Date: Mon, 31 Aug 1992 13:10:53 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

One of the nice utilities available on Domain is "send_alarm", where you can
send a message to the screen of any user by name, or to a specific node
by node_id.

Now that I am using X, however, I don't *SEE* my DM window, so I don't
get my alarms.

Is there a similar function/utility available for X?

Does anyone know the format of the alarm server mail box, so that
such a utility can be written?
-- 
[  Gordon D. Berkley    INTERNET: gordonb@mcil.comm.mot.com   POST: cgb001   ]
[  PHONE: +972 (3) 565-8727      FAX: +972 (3) 565-8754      (UTC-2)         ]
Newsgroups: fj.mail-lists.apollo
From: haven.umd.edu!darwin.sura.net!europa.asd.contel.com!emory!cprince@ames.arc.nasa.gov  (Chea Prince)
Subject: rgb monitors
Organization: Emory University, Dept of Math and CS
Distribution: fj
Date: Wed, 26 Aug 1992 21:30:57 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

has anyone ever successfully connected an amiga 2500/30
to any one of the following monitors:

     hitachi 70J3 (was connected to an apollo DN460)
     MassComp (circa 1985--no model designation)
     apollo DN550

any specs on these woould be appreciated--thanks

chea  
Newsgroups: fj.mail-lists.apollo
From: philip@cel.cummins.com (Philip D. Pokorny)
Subject: Re: NeXT on HP700
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Thu, 3 Sep 1992 14:14:19 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In the August 31, 1992 issue of Open Systems Today there is an
interview with Lew Platt, HP's president-elect.  Quoting from the
article:

     Platt said HP, under certain circumstances, would
     willingly incorporate industry-standard software from
     Microsoft and even IBM into its products.  Regarding
     NT, Platt said HP would wait to see how the product is
     received in the market before deciding whether it would
     be beneficial to have NT running on PA-RISC.  If NT
     gains market share, "there is nothing whatsoever that
     would prevent us from porting that OS to our platform
     and we've already had discussions with Microsoft about
     this," said Platt.

     Platt also said that HP would consider incorporating
     into its own products, technologies that emanate from
     Taligent, the joint IBM-Apple object-oriented
     programming project.

     HP, for its part, is trying to make its PA-RISC
     architecture more prevalent in the industry by
     licensing it to vendors HP does not view as
     competitors.  One such company, Platt said, is Next,
     which is currently looking for a RISC technology on
     which to base its computers.  But Platt declined to say
     whether there had been any direct negotiations with
     Next.  Next also declined comment.

Guess that means that they are talking but they haven't come to
an aggreement on anything except not telling the press that they
are talking.


Sincerely,
Philip D. Pokorny
philip@cel.cummins.com
:)

Newsgroups: fj.mail-lists.apollo
From: eru.mt.luth.se!lunic!sunic!mcsun!dxcern!vxcrna.cern.ch!roeber@bloom-beacon.mit.edu
Subject: Re: HP cafe
Organization: CERN -- European Organization for Nuclear Research
Distribution: fj
Date: Thu, 3 Sep 1992 20:40:23 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <DYm-+S@engin.umich.edu>, afgun@engin.umich.edu (Andrew F. Gunnesch) writes:
> (I did not write this; IDK who the author is.  I found it hilarious.
>  YOUR mileage may vary)

My copy says "by Stephen Harrison and Noel Magee."
Newsgroups: fj.mail-lists.apollo
From: access.usask.ca!kakwa.ucs.ualberta.ca!acs.ucalgary.ca!cpsc.ucalgary.ca!ajfcal!novatel!hpeyerl@decwrl.dec.com  (Herb Peyerl)
Subject: SCSI Magtape support under 10.4?
Organization: none
Distribution: fj
Date: Sun, 30 Aug 1992 19:02:34 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Color me stupid... Our VAX cluster is just being upgraded and part of
the upgrade is a SCSI 6250bpi Magtape drive... We (apollo support) still
have some 1650bpi tapes that we may need to be able to read in the future
but not on a regular basis... I mentioned (probably in my sleep since I 
don't recall having done so) that SCSI magtape drives are supported 
under Domain/OS and if we were to get one of these drives as part of
our VAX upgrade; then our butts would be covered for reading these 
tapes (ie: by disconnecting said drive from VAX and connecting it to
an Apollo (35xx, 45xx, or 433s)... So, they went ahead and bought such a
drive... Now, I'm concerned that this is impossible and a pipedream..We've
already gotten rid of our old 1650 cypher drive so we're sort of stuck...

Please, someone tell me that I'll just be able to hook this SCSI tape drive
up to one of our nodes and do an "rbak -dev m ....."

anyone? Anyone?
-- 
"I was early to finish | hpeyerl@novatel.cuc.ab.ca <Reply-To>   | I brew |
I was late to start, I | peyerlh@cuug.ab.ca                     | there- | 
might be an adult, but | #define JANITOR "Network Administrator"| fore I | 
I'm a minor at heart." |    JANITOR, NovAtel Communications Ltd.|   AM.  |
Newsgroups: fj.mail-lists.apollo
From: destroyer!terminator!pisa.citi.umich.edu!rees@gumby.wisc.edu  (Jim Rees)
Subject: Re: Idle nodes? (was Re: automatic screen turn-off)
Organization: University of Michigan IFS Project
Distribution: fj
Date: Wed, 2 Sep 1992 18:54:18 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <1992Sep1.214827.22827@ucc.su.OZ.AU>, szabo_p@maths.su.oz.au (Paul Szabo) writes:

  > Is there a way to find out how long an Apollo node (i.e. the interactive
  > user logged on the display) has been idle? It might be sufficient to find
  > out whether the screen has been blanked out or not (with due regard to the
  > setting of scrto). Does anyone know the trick?

Seems to me that Nat Mishkin once hacked an inactivity timer into Aegis,
back around sr5 when he was still at Yale, but it never made its way into
the release.
Newsgroups: fj.mail-lists.apollo
From: dog.ee.lbl.gov!porpoise!network.ucsd.edu!munnari.oz.au!metro!maths.su.oz.au!szabo_p@ucbvax.Berkeley.EDU  (Paul Szabo)
Subject: Re: Idle nodes? (was Re: automatic screen turn-off)
Organization: Mathematics, University of Sydney
Distribution: fj
Date: Tue, 1 Sep 1992 21:48:27 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <BtwMGy.EG0@apollo.hp.com> ganek@apollo.hp.com (Dan Ganek)
writes:
> >I cannot find any documentation on the gpr_$video_ctl call. (Not that I
> >would need it at the moment.)
> 
> From /sys/ins/gpr.ins.pas:
> 
> {  GPR_$VIDEO_CTL --  turn video on/off  }
>     PROCEDURE gpr_$video_ctl(
>                 IN  on_off: boolean;
>                 OUT status: status_$t { returned status }
>                 ); EXTERN;
> 
> TRUE unblanks the screen,  FALSE blanks and resets the timeout 
>   
> This replaced smd_$video_ctl.

Thanks. Only problem is that my /sys/ins/gpr.ins.pas is older than yours (I
am only up to SR10.4 :-). Maybe you have access to the set of un-released,
complete include files? We simple mortals do not have smd include files
either.

Anyway, my real question was:

> Is there a way to find out how long an Apollo node (i.e. the interactive
> user logged on the display) has been idle? It might be sufficient to find
> out whether the screen has been blanked out or not (with due regard to the
> setting of scrto). Does anyone know the trick?

Paul Szabo - System Manager   //        School of Mathematics and Statistics
szabo_p@maths.su.oz.au        //   University of Sydney, NSW 2006, Australia
Newsgroups: fj.mail-lists.apollo
From: thompson@pan.ssec.honeywell.com ((jt) John Thompson)
Subject: re: Colour maps on DN4500 (again??)
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Fri, 4 Sep 1992 18:08:22 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>


> We have a DN4500 running SR10.3 (no patches) which has an 8 plane 19 inch colour monitor.
> 
> The command "lcm" was typed in at one of the pads and this changed the colour map.
> The question is, how do I get it back to "normal".
> 
> I have tried:
> 
> lcm                         this leaves it in this new different colour scheme.
> lcm -p /sys/dm/color_map    again, leaves it in this new scheme
> ...lots of other things w/ lcm...
> 
> I've also copied the /sys/node_data/etc/dm_display tree across from another node, but it makes no
> difference. Rebooting the machine makes no difference either.

Check to see whether the user(s) who have the colors go wrong have a file '$HOME/user_data/color_map'
hanging around.  This is used to configure the colors at login (see the OS 10.3 release notes).

If that doesn't work, try the DM command 'rs -f' and/or 'rs -o'.  Read the HELP pages for details.

If that doesn't work, put the contents of the master color_map file `node_data/etc/dm_display/color_map
into an edit pad, and prepend 'lcm -s ' to each line.  Make sure that this file is executable, and
then run it (or copy it into an input pad like a proper Domainiac would).  This will, 1 at a time, 
set the colors by force to the master set.  It takes a long time, and may wipe out the colors at first,
but it's always ended up by cleaning things up for me.

-- jt --
John Thompson
Design Services Engineer / Sys-Admin
Honeywell, SSEC
Plymouth, MN  55441
thompson@pan.ssec.honeywell.com

If you're not part of the solution, you're part of the precipitate.
*************************************************************************
* This e-mail correspondence is a work of fiction.  Any similarity      *
* between the views presented and actual views, personal or corporate,  *
* living, dead, or still to be conceived, is pure coincidence.          *
*************************************************************************

Newsgroups: fj.mail-lists.apollo
From: destroyer!terminator!dabo.citi.umich.edu!rees@gumby.wisc.edu  (Jim Rees)
Subject: Re: Strange packaging technique
Organization: University of Michigan IFS Project
Distribution: fj
Date: Fri, 4 Sep 1992 14:58:55 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <BtzApG.1o1@watserv1.uwaterloo.ca>, gordon@maxwell.uwaterloo.ca (Gordon R. Strachan) writes:

  The one I always like is the packing lists that list everything in the box
  including the packing list itself!  It even has its own HP part number.  HP
  paper work, you gotta love it! :-)

When I got my rs/6000 (great machine, wish they'd port Unix to it), it came
with a while stack of boxes containing things like a neat blue folder for
storing loopback connectors.  When you're done unpacking you have a sea of
empty boxes.  But the last box needs no unpacking; they ship an empty box in
which to store all the other packing material.

  Does anybody still have that old "story" about ordering lunch in the HP
  cafateria?  It was around about 2 years and I lost my copy.

You can get a copy of "Lunch, the HP Way," by Stephen Harrison and Noel
Magee, by ftp from archive.umich.edu in the 'apollo' subdirectory, file
'food-humor'.  The same file also contains "The Real World and Unix
Philosophy," by Bob Peirce.

Here's an excerpt from "Lunch."  The whole thing is pretty funny.

  My eyes glazed over. I asked for a burger and a root beer.
  The waitress looked at me like I was an alien.

  "How would you like to order that, sir?"
  "Quickly, if possible. Can't I just order a sandwich and a drink?"
  "No sir. All our service here is menu driven. Now what would you like?"
  I scanned the menu. "How big is the 00010 burger?"
  "The patty is rated at eight bites."
  "Well, how about the rest of it?"
  "I don't have the specs on that, sir, but I think it's a bit more."
  "Eight bites is too small. Give me the Double Burger Upgrade."

  My sales rep interrupted. "No, you want the Single Burger option 002
  'expands burger to two patties'. The Double Burger Upgrade would give
  you two burgers.

  "But you could get return credit on the extra bun," the waitress
  chimed in, trying to be helpful, "although it isn't documented."
Newsgroups: fj.mail-lists.apollo
From: dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bcrka451!norm@ucbvax.Berkeley.EDU  (Norm MacNeil)
Subject: IPC's in Apollo DOMAIN?
Organization: Bell-Northern Research Ltd.
Distribution: fj
Date: Tue, 25 Aug 1992 20:18:55 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>


I can't seem to find any IPC stuff on the Apollos; i.e., there is no support
for shared memory segments (shmat, shmctl, etc.), message queues (msgctl,
msgget, etc.), or semaphores (semctl, semget, etc.).

Is there any way to do this kind of stuff (without using sockets directly)?

Thanks,
  Norm.

-- 
+-----------------------------------------------------------------------+
 Norm MacNeil                     Phone: (613) 763-7497
 CAD Operation Tools Development    Fax: (613) 763-3317
 Bell-Northern Research Ltd.      EMail: norm@bnr.ca.BITNET (INTERNET)
 #include <disclaimer.std>       "Roller bladers do it in-line!"
Newsgroups: fj.mail-lists.apollo
From: Austin L. Conaty <austin@meto.UMD.EDU>
Subject: nmconfig  -h hostent_bind  Help!!??? 
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Thu, 3 Sep 1992 16:12:42 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>


Hello Folks,
I recently moved away from using a .5MB /etc/hosts file, and
started using nmconfig -h hostent_bind.  Now my /etc/hosts file 
is less than 120 lines, and I'm using 4 nameservers in /etc/resolv.conf.
The first one is 127.0.0.1, and the rest are local campus nameservers.

I can't seem to get processes like telnet, mail, ftp etc......
to look at the local /etc/hosts file first.  When I mail or telnet
to the address I get the error:  unknown host.  When I grep the /etc/hosts
file for that address, sure enough it is there.  

Should I have someone add this address to the campus nameserver?
Or is there a way to look at the /etc/hosts file before going out
over the net?

I should add that using nmconfig works great for common addresses,
but that a few uncommon addresses that I have in /etc/hosts just
don't connect.

Thanks,
Austin Conaty

PS  /sys/node_data/etc/daemons looks like this:
README		llbd		nmconfig	sendmail
damd		lpd		portmap		tcpd
glbd		mountd		rgyd

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

Austin L. Conaty                           austin@meto.umd.edu
Department of Meteorology                  austin@atmos.umd.edu
University of Maryland                     301-405-5357      
College Park, Md. 20742-2425               or: HEY YOU!!!!!  

-----------------------------------------------------------------------
Newsgroups: fj.mail-lists.apollo
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!rz.uni-karlsruhe.de!stepsun.uni-kl.de!sun.rhrk.uni-kl.de!zx1!uch024@ucbvax.Berkeley.EDU  (Lothar Koniczek)
Subject: Xfig-problems
Organization: University of Dortmund (Germany), Department of Chemistry
Distribution: fj
Date: Tue, 1 Sep 1992 11:52:33 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Hi X11/Apollo-gurus :_)
I've recently tried to compile xfig-2.1.3 on an Apollo 425t.
The compilation worked fine. The startup too.
The xfig-screen with the drawing-pad popped up on my screen.
I was very happy and tried to make a drawing. That went good too.
But when i wanted to save my work and clicked at the File... - menue,
xfig stopped and throw out an error-message:
SIGSEGV signal detected.
I threw the line defining the SIGSEGV signal (sure that wouldn't solve
the problem) out and got at next startup/File... selection the obvious
Segmentation fault.
So i debugged xfig to find out where the error would come from.
To my regret i found out that the function-call:
      XtAppMainLoop(tool_app);
is the place where the segmentation fault appears.
In fact it's the last line of the main() - routine in main.c
of the xfig-package.
So what can i do about that problem?
Has someone else got that segmentation fault on an Apollo 425t/DN3000
10.3.5 too?
                                          Lothar Koniczek

--
---------------------------------------------------------------------
Lothar Koniczek			|Internet: uch024@zx1.HRZ.Uni-Dortmund.de
University of Dortmund (Germany)|Bitnet:   uch024@ddohrz11.BITNET
Department of Chemistry		|Voice:  Sorry, currently not available
Newsgroups: fj.mail-lists.apollo
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!caen!destroyer!terminator!pisa.citi.umich.edu!rees@ucbvax.Berkeley.EDU  (Jim Rees)
Subject: Re: GNU Emacs for 18.58 and SR10.3/4 (at long last)
Organization: University of Michigan IFS Project
Distribution: fj
Date: Thu, 27 Aug 1992 19:25:48 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <1992Aug24.152417.24345@ttsi.lonestar.org>, mse@ttsi.lonestar.org (Mark Evans) writes:

  In article <1992Aug21.230108.7154@lucid.com> lnz@lucid.com (Leonard N. Zubkoff) writes:
  >A new version of my modifications to GNU Emacs for the Apollo is now available.
  
  Has anyone duplicated this feat for epoch 4.x?

It's not necessary.  I collected together the necessary parts and sent them
to the Epoch people.  Full support for Domain/OS is in Epoch 4.1.  This is
much easier than emacs, since epoch doesn't do gpr.  Most of the mods were
removing old, obsolete sr9.7 support.

There may still be a problem with unexapollo.c and sr10.4.  If someone will
send me the correct version, I'll pass it on to the Epoch people.  I don't
use sr10.4 myself.
Newsgroups: fj.mail-lists.apollo