HDTenEightyP/NetNews huggingface dataset:
From: muegel@rtsg.mot.com (Michael S. Muegel)
Subject: SR10.4 sendmail problem
Organization: Motorola Inc., Cellular Infrastructure Group
Date: Sun, 26 Jul 1992 22:47:48 GMT

I have been using a version of IDA sendmail I compiled for some time
Recently I decidied to give the SR10,4 IDA+apollo sendmail a try. Since I
had alias auto-rebuild off I had to turn it on in the sendmail.cf file.

When sendmail tries to re-build the alias file on the fly I get the
following errors:

% testmail mmuegel
rebuilding alias database
/usr/lib/aliases: line 23: DBM store of mailmgr (size 15) failed: Not owner
/usr/lib/aliases: line 24: DBM store of postmaster (size 18) failed: Not owner
/usr/lib/aliases: line 25: DBM store of postmaster (size 18) failed: Not owner
...

This goes on through each alias. The mode/ownership on the dbm(3) files look 
like this before I run sendmail (via the testmail script):

% ls -lasg aliases*
   1 lrwxrwxrwx   1 root     staff          38 Jul 26 17:41 aliases@ -> /etc/mai
l_admin/bsd4.3/usr/lib/aliases
   4 -rw-r--r--   1 root     staff        4096 Jul 26 17:43 aliases.dir
  52 -rw-r--r--   1 root     staff      200704 Jul 26 17:43 aliases.pag

After the sendmail call the dbm files are zero length. Oh ya, yes, sendmail
is mode 4555 with an owner of root. So it is running suid root.

Any hints?
-Mike

-- 
-Michael S. Muegel <mmuegel@mot.com>
Software Tools Group
Fort Worth Research and Development Center
Motorola, Inc.
Newsgroups: comp.sys.apollo
From: bcr@cernapo (Bill Riemers)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: CERN, European Research Center for High Energy Physics
	<1992Jul20.142205.27209@edsi.plexus.COM>
Date: Tue, 21 Jul 1992 11:39:03 GMT

In article <1992Jul20.142205.27209@edsi.plexus.COM> chuck@edsi.plexus.COM (Chuck Tomasi) writes:

   In comp.sys.apollo you write:

   - The fact that root is root is root!  I log in to an HP-UX system and
   can't modify files across a system without punching a security hole in
   the kernel.  With the Apollo file system I've got the whole network (//)
   at my disposal.  When you're looking to do something simple like touch
   /sys/node_data/etc/daemons/tcpd for all nodes, that comes in handy.

Ah, but this is also one of its bigest problems.  If you have two or three
hundred private nodes linked together you have a problem.  You can't possably
have enough hired system managers take care of them all.  On the other hand,
you don't dare allow 200+ people with root privledge either.  What I wouldn't
give to be able to have someone from my university to have root access to our
nodes...  Instead, I have to wait weeks for a system manager to get time to
make relatively minor changes.

                                   Bill
Newsgroups: comp.sys.apollo
From: braham@physics.ubc.ca (Stephen Braham)
Subject: More on wanted Xapollo (R4)
Keywords: X11R4 server
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Wed, 29 Jul 1992 16:12:20 GMT

Uggg, I forgot to mention that my machines are 2500's. What I need
is an R4 Xapollo binary, rather than the vanilla R2 one, for
a 10.2 system. I have access to X11R4 fonts. I'm hoping to use
xdm on our suns to drive the Apollos as dumb X terminals. I don't
THINK that I need anything else in the way of, say, libraries (but
I may be wrong- if anybody knows differently, please yell at me).

			Steve

--
| Name: Stephen P. Braham | Perversion: Quantum Cosmologist|
| Hangout: UBC physics    | Signature:  Euclidean          |
|          Vancouver, BC  |--------------------------------+
|          Canada         | E-mail: braham@physics.ubc.ca  |
From: wjw@ebh.eb.ele.tue.nl (Willem Jan Withagen)
Newsgroups: comp.sys.apollo
Subject: Re: BSD printing help?  (lpr/lpq/lpd)
Date: 21 Jul 92 09:39:21 GMT
Reply-To: wjw@eb.ele.tue.nl
Organization: Digital Systems, Eindhoven University of Technology, the Netherlands

Mike Killoran:
=>  shows ways of submiting stuff into {i}prf with a C-program
=> which I deleted.

But one can also do it with Shell-scripts. If the only desire is to
mess a little with the file before putting it to the printer. Just hack
a script in your favorite shell-language.

We've got this script which removes the manual settings from PS files
and adds enough extra stuff to make it more robust in printing AND it
generates accounting info. And all this in a script.

Willem Jan

-- 
Digital Information Systems Group, Room EH 10.35 
Eindhoven University of Technology   
P.O. 513                     		Tel: +31-40-473401,Fax: +31-40-448375
5600 MB Eindhoven            		The Netherlands
Internet:  wjw@eb.ele.tue.nl    
X400:      C=nl;ADMD=400net;PRMD=surf;O=tue;OU=ele;OU=eb;S=WJW;
Newsgroups: comp.sys.apollo
From: rees@dabo.citi.umich.edu (Jim Rees)
Subject: Re: Printing to Tektronix
Reply-To: Jim.Rees@umich.edu
Organization: University of Michigan IFS Project
Date: Sat, 25 Jul 1992 15:08:10 GMT

In article <13196@pogo.wv.tek.com>, davidh8@pogo.wv.tek.com (David Haight) writes:

  There are many such filters around to convert various raster
  formats to postscript but I don't know of one for gpr.

I know there is one, because we've got it.  It's called gpr2ps, and it may
or may not be part of the pbm package.  Ask archie.  If you can't find it,
send mail to oliveria@caen.engin.umich.edu.
Newsgroups: comp.sys.apollo
From: dododge@wam.umd.edu (David O. Dodge)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: University of Maryland, College Park
Date: Wed, 22 Jul 1992 06:33:33 GMT

In article <Brozvu.5uu@apollo.hp.com> ganek@apollo.hp.com (Dan Ganek) writes:
>>Misfeatures:
>>
>>   They changed the way the RM_$ calls work, so the program I wrote to put
>>   a picture in the DM background doesn't work right anymore (this also
>>   affected some of Apollo's own demo programs). RM_$ being unsupported and
>>   undocumented I probably shouldn't complain too much, though :-)
>
>I didn't change the way the rm worked! THEY (the dm and Xapollo) people
>changed the way it's used :-) At SR10 there is no longer a "background"
>rectangle - use RM_$INQ_INTERIOR_VIS_LIST on the root instead of
>RM_$INQ_VIS_LIST to get the exposed areas of the root.

Thanks for the tip. I'll have to dig up my old backdrop program and see
how it worked (it's been a few years). The weird thing is that the way
it is now it isn't consistent -- it seems to pick a window at random to
throw the image/pattern into (same as the old moire demo program -- not
surprising since I think that's what I used as a model for my backdrop code).

>>   Recent versions of GPR have the mouse handling screwed up. Try playing
>>   "star wars" on a DN3500 to see what I mean.
>                                 
>HUh??? Explain, please.

The easist way to see what's going in is to play Revenaugh's Star Wars on
a DN580 and then try it on a DN3500. The difference should be immediately
noticable. The 3500 (and other newer models) buffer the mouse input
"incorrectly".

The problem is that gpr_$cond_event_wait will return a gpr_$no_event
even when there is still mouse information in the buffer. Graphics-intensive
programs such as Star Wars therefore have the response to mouse input
lagging behind the actual mouse movements. The program believes that it
is keeping up because GPR tells it that it has read all the events off
the queue.

The more graphics work the program is doing, the longer the delay. I
have some animation-style programs that delay several *SECONDS*.

This has been a problem for quite some time now. It's not usually
something you worry about, but with game programs it makes them kind of
difficult to play :-).

                                           -Dave Dodge/dododge@wam.umd.edu
Newsgroups: comp.sys.apollo
From: cameron@spectrum.cs.unsw.oz.au (Cameron Simpson)
Subject: an annoying bug in the C compiler ...
Reply-To: cameron@spectrum.cs.unsw.oz.au (Cameron Simpson)
Organization: CS&E Computing Facility, Uni Of NSW, Oz
Date: Wed, 29 Jul 1992 10:28:00 GMT

Observe the (short) C program listed below.
That -2147483648 is the value of MIN_INT and MIN_LONG.
When compiled and run, eg

	cc it.c
	./a.out 147

the puts() gets executed. Ugh. Bumping the constant by one makes things
work. A bit suss, no? This is going to bogosify the code I'm fixing...
	- Cameron Simpson
	  cameron@cs.unsw.oz.au

#include	<stdio.h>
#include	<stdlib.h>
#include	<limits.h>

int
main( int argc, char	*argv[])
{
	int		l;
	unsigned long	ul;
	char		*cp;

	l=strtol(argv[1],&cp,0);
	fprintf(stderr,"\"%s\"=%ld, left at \"%s\"\n",argv[1],l,cp);
	if (l <= -2147483648)
		puts("argh!!\n");

	ul=strtoul(argv[1],&cp,0);
	fprintf(stderr,"\"%s\"=%lu, left at \"%s\"\n",argv[1],ul,cp);
}
From: olav@eddy (Olav Schettler)
Newsgroups: comp.sys.apollo
Subject: Debugging with GCC on a 3500 ?
Date: 21 Jul 92 07:54:33 GMT
Article-I.D.: gmd.1992Jul21.075433.25850
Organization: GMD, Sankt Augustin, Germany
X-Newsreader: Tin 1.1 PL4

Has someone done debugging for the Gnu-C compiler on a Dn3500 ?

Any hints, pointers ? 

Cheers,
--
Olav Schettler

FIT
Institut fuer Systementwurfstechnik (SET)
P.O. Box 1316                            phone: +49 (2241) 14-2291
Schloss Birlinghoven                     fax:   +49 (2241) 14-2342/2823
W-5205 Sankt Augustin 1                  email: olav@borneo.gmd.de
From: basti@orthogo.uucp (Sebastian Wangnick)
Newsgroups: comp.sys.apollo
Subject: NFS mount: Access Denied, SR10.3
Date: 21 Jul 92 11:13:51 GMT
Organization: Orthogon System GmbH, Bremen, Germany

A few days ago my colleagues installed a new version of NFS (Release notes
say 2.2, protocol spec say 3.2.5) on our Unix-PC's (Interactive Unix).
Now we get ``Access denied'' on our SR10.3 Apollos when trying to mount
the PC's via NFS. This is the same message that we got all the time
when trying to mount our other NFS servers (IBM RS6000, AIX3.2;
SONY NWS-3410, NEWS-OS 4.1R).

It seems to me that our problems are due to incompatibilities between
the SR10.3 version of NFS (whichever it may be) and the newer versions.
Since we don't want to upgrade to SR10.4, here's my question:

Is there a patch available for SR10.3 that fixes the abovementioned problems?
Does anybody know it's number so that sales folks at HP here in Germany
can be told what to sell to me?

Thanks in advance.

-- 
Sebastian Wangnick   Orthogon System GmbH
(basti@orthogo.uucp) Linzer Strasse 4
Tel +49 421 219136   D-2800 Bremen 33
Fax +49 421 213093   Germany
Xref: sparky comp.sys.apollo:3055 comp.windows.x.motif:5090
From: pfander@kommu.UUCP (Dr Gotthard Pfander)
Newsgroups: comp.sys.apollo,comp.windows.x.motif
Subject: C++ V2.1.0 versus OSF/Motif ANSI/NON-ANSI. Help needed
Keywords: C++, OSF/Motif, ANSI
Date: 21 Jul 92 10:01:15 GMT
Followup-To: comp.sys.apollo

C++ V2.1.0 as supplied by HP/Apollo uses ANSI-calling convention as default.

The supplied libraries: libC.a, libOstream.a, ... all expect ANSI-calling.

Using OSF/Motif, being NON-ANSI as supplied by HP/Apollo,
thus creates a serious compatibility-problem.

Using C++ requires at least the library libC.a for the _main an similar things.

Anyone got a good idea, how to solve this decently.

Please, don't tell me things like RTFM ....

pfander@kommu.erls01.siemens.de

Gotthard Pfander
SIEMENS AG, ANL A 593
Werner von Siemens Str. 50
D W8520 Erlangen
Tel +49/9131/7-28711
From: malowany@cenparmi.concordia.ca (Stephen Malowany)
Newsgroups: comp.sys.apollo
Subject: Re: WANTED: X11R4 Server binaries for 10.2
Keywords: X11R4 server
Date: 30 Jul 92 01:29:40 GMT
Organization: CENPARMI, Concordia University, Montreal, Canada

In article <braham.712344695@physics.ubc.ca> braham@physics.ubc.ca (Stephen Braham) writes:
>Greetings Folks,
>	We have a few Apollos running DomainOS Release 10.2
>(BSD 4.3, of course) and we're in reasonably desperate need
>of the BINARIES for an X11R4 server. We're low on disk space,
>and thus want to avoid bringing in the entire MIT X11R4
>distribution (as well as having other technical problems).
>Do any of you have a copy of an R4 Xapollo that we can
>grab from you? We'd be EXTREMELY appreciative.

I have made available an Xapollo binary which I built from the MIT X11R4
patch-level 18 sources, on a DN3500(mc68020), SR10.2, cc v6.7

ftp.cs.concordia.ca:/pub/Xapollo-R4-10.2.tar.Z

We use our Apollos as X terminals by disabling the DM, and running only
the kernel, tcpd, and "Xapollo -query xdmhost".

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steve Malowany                                                  Systems Analyst
Centre for Pattern Recogn. & Machine Intell.     malowany@cenparmi.concordia.ca
Department of Computer Science                         malowany@cs.concordia.ca
Concordia University                                   Montreal, Quebec, Canada
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: comp.sys.apollo,comp.windows.interviews
From: dododge@wam.umd.edu (David O. Dodge)
Subject: Interviews vs. Apollo C++
Summary: major problems
Originator: dododge@rac2.wam.umd.edu
Organization: University of Maryland at College Park
Date: Thu, 23 Jul 1992 10:02:20 GMT

Note that this is crossposted to both comp.sys.apollo and
comp.windows.interviews.

At my workplace we're trying to get InterViews running on our Apollo
Domain/OS machines. I believe we're using IV 3.0.1 beta and the latest
version of Apollo CC, but the binaries are segmentation faulting all over
the place.

Here's an example of one spot where things are going wrong:

  For one of our own programs we have a class we wrote called OurViewer,
  which inherits most of its stuff from Viewer. We don't define a Draw()
  member function for OurViewer, and when we call Draw() within one of
  OurViewer's member functions, the program dies. If I replace the Draw()
  invocation with an explicit call to Viewer::Draw() it suddenly starts
  working.

  A process traceback shows the problem to be with the invocation itself,
  i.e. the program never actually enters Draw(), but gives a "reference
  to illegal address" or some such when it attempts to make the call.

This behavior is only consistent in that the program always crashes at
the same places. However other calls of this type (a member calling a
virtual function that was inherited from another class) work just fine --
it's only a few specific spots that have the problem.

Anyway this is a MAJOR annoyance, and from the looks of it it's most likely
the compiler's fault. This code runs just fine on a Sun Sparc.

Note that I'm coming into this a bit late -- someone else already did
most of the work in getting InterViews to compile at all (I believe cpp
was crashing originally or something like that). The person who originally
did the work changed only a few things in the code, and in any case those
changes shouldn't be causing this type of problem.

So has anyone actually managed to get InterViews built on an Apollo? Any
suggestions?

                                         -Dave Dodge/dododge@wam.umd.edu
Newsgroups: comp.sys.apollo
From: ced@APOLLO.HP.COM (Carl Davidson)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Date: Tue, 21 Jul 1992 19:19:45 GMT
Organization: Hewlett-Packard Company, Chelmsford, MA

In article <1992Jul20.142205.27209@edsi.plexus.COM>, chuck@edsi.plexus.COM (Chuck Tomasi) writes:
|> 
|> My biggest gripe about Domain was in dealing with nodes on an internet
|> (not THE internet, just a site that had net IDs.)  If you wanted to move
|> a machine from one net to another you had to remove the hint_file on all
|> the OTHER machines and reboot them so they knew the new machine was gone
|> (or just arrived.)  What a stupid way to do it!  Someone please tell me
|> there is a better way or it has changed in 10.4.  There is nothing worse
|> than wasting a Saturday moving one node to another floor of the building
|> for a demo and then having to move it back a few days later.
|> 
|> -- 
|> Chuck Tomasi             |     "Mom, it's Data.  I heard you know
|> chuck@edsi.plexus.COM    |      how to turn him on." 
|> spool!cserver!edsi!chuck |                    -Wesley  "Datalore"
|> ------<Enterprise Data Systems Incorporated, Appleton Wisconsin>------

Fixed in SR10.4. 

-- 
Carl Davidson  (508) 436-4361  |
Chelmsford System Software Lab | Microkernels: Where less is more.
The Hewlett-Packard Company    | 
DOMAIN: ced@apollo.hp.com      |
Newsgroups: comp.sys.apollo
From: ianh@resmel.bhp.com.au (Ian Hoyle)
Subject: Re: Favourite DOMAIN/OS features (or mis-features) (slow i/o)
Organization: BHP Research - Melbourne Laboratories, AUSTRALIA
Date: Sun, 26 Jul 1992 22:25:22 GMT

rees@dabo.citi.umich.edu (Jim Rees) writes:

>Actually, ios isn't what makes disk io slow.

Then what does??

We have a DN5500 with a (supposedly) fast 700Mb disk acting as a news server
and it just gets appallingly slow whenever it has to do anything that
resembles a lot of i/o eg news unpacking, omniback backups, compress for
news batching etc. In fact it comes close to stopping if these operations
happen to overlap :-(

I'd **luv** to be able to tune _something_ to make it go just a teensy bit
faster,

	ian
--
   /\/\     :  Ian Hoyle,  Senior Research Scientist
  / / /\    :  Image Analysis Group
 / / /  \   :  BHP Research - Melbourne Laboratories
/ / / /\ \  :  245 Wellington Rd, Mulgrave, 3170, AUSTRALIA
\ \/ / / /  :  Phone    +61-3-560-7066
 \  / / /   :  E-mail   ianh@resmel.bhp.com.au
  \/\/\/    :
            : "The kernel IS a continuously running random number
            :  generator" -- Larry Wall

Newsgroups: comp.sys.apollo
From: bush@cae.prds.cdx.mot.com (Michael Bush)
Subject: Re: Upgrade DN3550?
Organization: none
Date: Thu, 23 Jul 1992 12:30:52 GMT

chris@ceco.ceco.com (Chris Icide) writes:

(Regarding 5500 upgrades)

>If anyone has been through this process, could you please let me know
>how it went, and any bugs/problems I should be prepared to deal with.

The 5500 upgrade is basically as difficult as replacing a bad motherboard,
except in this case you're replacing a good board with an even better one.
The one real catch that makes your life miserable is that you are required
to invol the node's disk after the upgrade, because it gets switched to a
4K block factor once the 040 is installed.  So before you do it, make sure
you have all the data backed up!  Other than that, it's a relatively easy
(and inexpensive) way to get better performance.  Of course, that won't stop
you from still wanting a 700 box in 6 months...
-- 
Mike Bush
Motorola Codex - Mansfield, MA
bush@cae.prds.cdx.mot.com or bush_m@msm.cdx.mot.com
Newsgroups: comp.sys.apollo
From: uch024@zx1 (Lothar Koniczek)
Subject: Re: Mtools on Apollo
Reply-To: uch024@zx1.hrz.uni-dortmund.de
Organization: University of Dortmund (Germany), Department of Chemistry
X-Newsreader: Tin 1.1 PL4
Date: Tue, 21 Jul 1992 11:49:44 GMT

uhl@oracle (Walter Uhl) writes:
: I started playing around with Mtools last week.  Got everything
: to compile fine but found that when I executed "mdir a:" the 
: floppy spins up and mdir reports back "Cannot initialize 'A:".
: 
: Has anyone out there got the full suite of mtools working?
: How do I talk to the HD controller?  The mtools programs 
: work fine under Linux on my PC.
: 
: Thanks for the help.
: 
: Walter Uhl
: 
: email to uhl@solaria.hac.com   Not to the header address.
Newsgroups: comp.sys.apollo
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Subject: Re: Problems with 10.4
Organization: University of Toronto Chemistry Department
Date: Thu, 23 Jul 1992 14:45:08 GMT

In article <14kv48INNh5r@agate.berkeley.edu> alanc@ocf.berkeley.edu writes:
>We recently finished upgrading our cluster of 16 machines (2 DN 4500's + 14
>3500's) to 10.4 - and since then we've been having several problems:
>
>- csh/tcsh will go into a "can't find any commands" mood, from which the only
>	way to do anything is exec /bin/ksh.  (It seems to be linked to the
>	tty's as some tty's have the problem & others don't...rebuilding the
>	tty's "cures" the problem for a few days, but then it comes back)

You don't happen to be running NFS on these systems, do you?
Since I moved our home directories to a HP-UX system, our DN2500 systems
have become so flaky when doing basic things like 'rn' that they are
useless; they can not reliably spawn subshells seems to be the problem
(since my .cshrc file has to be accessed by NFS).

>- processes aren't dying properly.  For example a user telnet's in, and
>	starts reading news.  The telnet will die, but it's child csh and the
>	trn will keep going.  In fact, the last process in the chain will
>	start using huge amounts of processor time.  The only solution we've
>	found for this so far is to check the process table every 10 minutes
>	and kill -HUP every process who's unix_PPID is 1 (and is not owned
>	by root/daemon/user/etc.)  kill(-9, -1) is also failing at times.

This one is caused by improper handling of signals in telnetd and
rlogind (and ftpd and ...) - this was changed at SR10.4 so that
the members of a process group (which basically will correspond
to a login session) are not signalled when the parent of the group
dies. The child processes then start eating cpu (reason unknown).

I suggest you call HP if you are on support; we called this in back
in April (Call # A1975057, A1975055, Escalation issue EPIC 1801).
We are testing a fixed rlogind for the DN10000, but no fixes for
telnetd, or the M680x0 nodes, after more than 2 months.
-- 
What are the chances that any computer system will ever "work" properly?
... and Slim just left town. -*- Mike Peterson, SysAdmin, U/Toronto Chemistry
From: krowitz@QUAKE.MIT.EDU (David Krowitz)
Newsgroups: comp.sys.apollo
Subject: free? Apollo equipment
Date: 22 Jul 92 20:58:33 GMT
Distribution: world
Organization: The Internet

Just in case you called the MIT property office and got told
"huh?" (yeah, the big "my dog ate it" excuse), here's a copied
of the revised, double checked, and recently resubmitted
list of Apollo equipment that we have been trying to throw away
since April. Call the MIT property office. Maybe you *don't*
want to talk to Mr. Earl Fuller, maybe you want someone else,
I dunno. Call 617-253-1000 to get the main MIT switchboard and
ask for the property office.


== David Krowitz


==========================================================
From LKURTEN@EAGLE.MIT.EDU Wed Jul 22 16:51:41 1992
Received: from EAGLE.MIT.EDU by quake.mit.edu id AA07696g; Wed, 22 Jul 92 16:51:41 EDT
Received: from TMS-PORT-5.MIT.EDU by EAGLE.MIT.EDU with SMTP
	id AA01525; Wed, 22 Jul 92 16:50:18 EDT
Message-Id: <9207222050.AA01525@EAGLE.MIT.EDU>
Date: Wed, 22 Jul 92 16:55:10 
From: LKURTEN@EAGLE.MIT.EDU (Libby Kurten)
To: krowitz
Status: R


July 22, 1992.

To:	Earl Fuller
From:	Libby Kurten, 54-520
Re:	Disposal of surplus equipment.

The following is a list of surplus computer equipment from the Apollo 
workstation network. This equipment is no longer in use, nor is it 
needed for spare parts anymore. Please initiate the necessary MIT 
property office paperwork so that we can dispose of these items.

Equipment purchased by Peter Molnar
1) Apollo DN320 workstation (//MILNE)
     MIT property # 0193596
      S/N A0080432
2) Apollo 70 Mb hard disk plus floppy drive
     MIT property # 0193596 (attached to //MILNE)
     No S/N tag
Equipment purchased by Marcia McNutt
1) Apollo DN330 workstation (//BENO)
     No MIT property #
     S/N A00133571
2) Apollo 70 Mb hard disk plus floppy drive
     No MIT property #  (attached to //BENO)
      S/N A00134472
Equipment purchased by Tom Jordan
1) Apollo DN560 workstation (//LOVE)
     MIT property # 0196812
      S/N 55002114
2) Apollo DN330 workstation (//HOOKE)
     MIT property # 0195618
      S/N A00223389
3) Toshib P1351 dot matrix printer
     MIT property # 0191107
4) Kennedy 9400 9-Track tape drive
     MIT property # 0184943
5) Apollo DN330 workstation (//HUTTON)
     MIT #0184937
     S/N A00140565
Equipment purchased by Sean Solomon
1) Apollo DN330 workstation (//EWING)
     No MIT property #
      S/N A00253419


Please call me with any questions, x3-6180.  Thank you