HDTenEightyP/NetNews huggingface dataset:
From: Network Mailer <mailer%dearn.bitnet@utcs.utoronto.ca>
Subject: Undelivered mail
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Sat, 28 Mar 1992 08:29:01 GMT
Message-Id: <92Mar28.033322est.8985@ugw.utcs.utoronto.ca>
Source-Info:  From (or Sender) name not authenticated.

Your mail was not delivered to some or all of its
intended recipients for the following reason(s):

No recipients for this node.

--------------------RETURNED MAIL FILE--------------------
Received: from WATDCS(DCSMAIL) by DEARN (Mailer R2.08) id 4274;
          Sat, 28 Mar 92 09:29:01 CET
Received: from WATDCS by WATDCS.UWaterloo.ca (Mailer R2.08uw) with BSMTP id
 4211; Fri, 27 Mar 92 23:45:44 EST
Received: from watmath.waterloo.edu by WATDCS.UWaterloo.ca (IBM VM SMTP V2R1)
   with TCP; Fri, 27 Mar 92 23:45:41 EST
Received: from xenitec.uucp by watmath.waterloo.edu with uucp
	id <AA06180>; Fri, 27 Mar 92 23:46:25 -0500
Resent-Date: 27 Mar 92 03:44:11 GMT
Resent-Message-Id: <9203280446.AA06180@watmath.waterloo.edu>
Path:
 xenitec!watmath!watserv1!utgpu!csd.unb.ca!morgan.ucs.mun.ca!nstn.ns.ca!news.cs.
 indiana.edu!sdd.hp.com!cs.utexas.edu!uunet!olivea!isc-br!tau-ceti!visual!ssanbe
 g
From: ssanbeg@visual.spk.wa.us (Scott Sanbeg)
Newsgroups: biz.sco.general
Subject: Re: Modems
Message-Id: <1992Mar27.034411.692@visual.spk.wa.us>
Date: 27 Mar 92 03:44:11 GMT
Organization: The Visual Market Public Access Site - Spokane, WA
Source-Info:  From (or Sender) name not authenticated.

In article <9203250456.AA19452@lad.med.utas.edu.au> staley@lad.med.utas.edu.au
 (Michael John Staley) writes:
>...
>All files seem to be correct, gettydefs running etc etc.

I'm running Version 4, so these ideas apply to *it*. :) I'm also running
a modem on COM2. If your modem is 300-2400 baud, try the 3 definition for
the device (defined in gettydefs). If, on the other hand, you are running
the port at 9600, try using m.

>the damn thing will not work...it answers an incoming call and then
>the line drops.

disable tty2a
enable tty2A

Look for a description in your modem manual for the speed of hangup after
a DTR transition. It may be necessary to increase the time there. Also,
look in your System Administrator's Guide for where you set the maximum
allowed time that a user can take to log in. I was unable to find
just where it's listed in my manuals.
Scott


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Scott Sanbeg         Spokane, Washington     Voice: 509/535-2561
ssanbeg@visual.spk.wa.us (or) visual!ssanbeg@tau-ceti.isc-br.com
Newsgroups: biz.sco.general
From: zoo.toronto.edu!telly!becker!united!steved@watmath.UUCP
Subject: Xenix 2.3.4 system won't boot properly
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Reply-To: united!steved@watmath.UUCP
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Tue, 7 Apr 1992 14:20:27 GMT

   We have a system running Xenix 2.3.4.  It's a no-name clone 386/33,
with an IDE drive and two Consensys Powerports 8-port intelligent
serial cards.

   It will always boot up to the point of asking for ^D or the root
password (or autoboot past this point) and ask for the time.  The
next script in /etc/rc.d/2 is the Powerports software loading script,
which will run and finish normally.  The system will then sit there,
sync()ing occasionally, but will not get any further in the boot
process.

   I can sometimes get it to boot completely by booting it at 12 MHz,
and I can sometimes get it to work if I go into single-user mode,
get a couple of directory listings or other time-wasters, and then
continue.  Neither method, however, is guaranteed to work.

   Anyone seen this one before?  It's got me stumped.

-Steve
--
steved@united.UUCP                  ...!{uunet,xrtll,becker}!united!steved
--------------------------------------------------------------------------
Stephen M. Dunn, CNE, Senior Systems Analyst, United System Solutions Inc.
104 Carnforth Road, Toronto, ON, Canada M4A 2K7             (416) 750-7946
From: lsven@uceng.UC.EDU (Loncaric  Sven)
Newsgroups: biz.sco.general
Subject: ARE ADAPTEC 1542B AND MICROPOLIS 1588 SCO COMPATIBLE ?
Date: 7 Apr 92 01:23:09 GMT
Distribution: na
Organization: College of Engineering, University of Cincinnati

I am thinking about buying Micropolis 1588 (660MB SCSI HD) for my 486/25 ISA
machine and have the following question: Are Adaptec 1542B and Micropolis 1588
compatible with SCO UNIX ? Has anyone this combination running ?
I would appreciate to hear your good/bad experiences.

Please reply to my E-mail address.

Many thanks in advance
-- 
Sven Loncaric
Department of Electrical and Computer Engineering, University of Cincinnati
Internet: lsven@uceng.uc.edu
Newsgroups: biz.sco.announce
From: eah@xenitec.on.ca (Ed Hew)
Subject: Re: Length of filenames 
Organization: XeniTec Consulting, Kitchener, Ontario, CANADA
Date: Tue, 07 Apr 1992 03:23:40 GMT
Summary: 255 char filename support in 3.2v4

In article <9204061457.AA07251@saathi.ncst.ernet.in> saathi.ernet.in!durgesh@watmath.UUCP writes:
>> I think that there is a restriction on the number of characters in
>> the filename.
>
>Yes, 14 characters. Irritating, but there it is!
>	[....]
>But one hears that the newest version of SCO Unix will not
>have this limit.

Indeed, this is true.  SCO UNIX 3.2v4 supports POSIX compatible
long filenames.  In the EAFS (Extended Acer File System), your
filename can be up to 255 chars.  There are some in-place
upgrade concerns outlined in the release notes.  Note that
3.2v4 has been shipping for over a month now.

Just to make life sweeter, EAFS also supports BSD-style
symbolink links.

} I hope that's incorporated into ODT too.

Not in ODT 1.1, which sits on top of 3.2v2, but one could
certainly speculate that the next release of ODT will likely
incorporate these and other very useful SCO UNIX 3.2v4 features.
--
  Ed. A. Hew,    <edhew@xenitec.on.ca>    ....!uunet.ca!xenitec!eah
  XeniTec Consulting Services, Kitchener ON, Canada +1 519 570 9848
 [biz.sco.{opendesktop,general,announce} newsgroup/mlists godfather]
From: acsedm!hk@watmath.UUCP
Newsgroups: biz.sco.opendesktop
Subject: EISA and add-on boards -- HELP
Date: 13 Apr 92 01:11:11 GMT
Organization: [resent by] The SCOODT gateway and Propagation Society
Submit-To: scoodt@xenitec.on.ca
Resent-By: mmdf@xenitec.on.ca
Precedence: bulk

Hi netters:

Questions about EISA machines and SCO Unix.

(The 2 machines we are working with are ALR 486/33's but they seem
to behave the same as an HP Vectra 486 EISA.  The tape drive
which is giving us problems is a Mountain 150MB drive with it's
own controller.  The other machine has a Legacy SCSI 150MB drive
which is also giving us errors.)

EISA 486 machines normally arrive with EISA configuration
programs and EISA and ISA config data files for the various types
of boards being built today. 

Often these machines are preloaded by vendors with DOS along with
the DOS drivers and software associated with the above mentioned
EISA or ISA boards. 

1. It seems that these boards - for example a tape controller - will
   work with DOS, even if the EISA config program indicates that it
   is not there.  However, Unix seems to require it.  Is this
   assumption correct, or if incorrect, could someone point me in a
   differenct direction as to why we can't get a tape to work properly? 
   (We have eliminated the obvious such as conflicting IRQ, DMA, and
   starting address).  SCO's technical help department was very
   accomodating but after going over all the tape board settings and
   trying various combination, and the inevitable "Well, it should
   work", we are coming to the conclusion that perhaps, the
   configuration might have something to do with this. 
   Unfortunately, there is little useful documentation. 

2. When configuring an EISA machine, are the values stored in CMOS just
   as they are in an ISA machine?  If not, where are the values stored
   and is there an equivalent of the "cmos" routine for EISA machines?

3. It's only a gut feel, but memory caching seems to be a factor.  Does
   caching have any impact on tape controllers?

4. The lack of documentation is stressful.  Are there any definitive
   articles or books around, elaborating on these points? 

Any help would be greatly appreciated.
--
Harold Knopke                        E-mail: uucp ....!alberta!acsedm!hk
Aspen Computing Solutions            Internet: hk%acsedm@cs.UAlberta.CA
10215 - 178 St.                      voice: 403 486 2466
Edmonton, Alberta, Canada, T5S 1M3   fax:   403 963 5161
Newsgroups: biz.sco.opendesktop,biz.sco.general
From: johnfa@i88.isc.com (John Fanelli)
Subject: Re: NFS problems in odt1.1
Organization: INTERACTIVE Systems Corporation, Naperville, IL
Date: Wed, 15 Apr 1992 18:43:55 GMT

In article <1992Apr15.121018.24328@bernina.ethz.ch>, rudi@igc.ethz.ch (Rudi van Drunen) writes:
|> 
|> Hello !
|> 
|> We are using SCO ODT 1.1 on a AST 486/33 EISA machine. On the same network
|> there are some suns. We have a disk partition of the AST machine mounted on 
|> the suns by nfs. 
|> 
|> Quite often we encounter the following problem :
|> when using nfs quite heave (eg. running RANLIB on the suns on a file on the
|> AST disk) the SCO ODT machine hangs in the network. All connections to
|> and from the machine are dead. The only way to solve this is by rebooting the`
|> machine.
|> 
|> Has anyone encountered the same problem, or does have a hint how to solve it ?

	What type of ethernet card are you using, and what are the read and
write sizes for the mounted file systems??  Some of the slower ethernet
cards cannot handle large back-to-back packets.  I would recommend mounting
the filesystem with read and write size of 1K and then testing.  It this
works, bump to 2K, etc.


|> 
|> Thanks !!

	Your welcome (if this is the problem).
|> 
|> Rudi van Drunen
|> rudi@igc.ethz.ch.
							john fanelli
							johnfa@i88.isc.com
From: eah@xenitec.on.ca (Ed Hew)
Newsgroups: biz.sco.opendesktop
Subject: test, please ignore
Date: Thu, 09 Apr 92 21:00:09 GMT
Followup-To: poster
Distribution: biz
Organization: XeniTec Consulting, Kitchener, Ontario, CANADA

The big question:  does the injector hack make all those annoying
"Resent-To:" headers go away without breaking anything else?
Will it prevent upstream sites from tossing them back in like
they've been doing?  Hope...hope...

		--ed
--
  Ed. A. Hew,  <edhew@xenitec.on.ca>  ...!uunet!watmath!xenitec!eah
  XeniTec Consulting Services, Kitchener ON, Canada 01+519+570-9848
 [biz.sco.{opendesktop,general,announce} newsgroup/mlists godfather]
Xref: sparky biz.sco.opendesktop:385 biz.sco.general:1775 comp.unix.xenix.sco:1884
From: ronald@robobar.co.uk (Ronald S H Khoo)
Newsgroups: biz.sco.opendesktop,biz.sco.general,comp.unix.xenix.sco
Subject: Re: SCO Technical Library Supplements available
Date: 7 Apr 92 12:31:53 GMT
Organization: Robobar Ltd., Perivale, Middx., ENGLAND.

In article <23567@scorn.sco.COM> dionj@sco.COM (Dion) writes:

> SCO Online Support - Technical Library Supplements
> In addition, these directories are replicated at
> ftp.uu.net under ftp/pub/sco-archive.

More correctly, ftp.uu.net[137.39.1.9]:/vendor/sco
Europeans may find the mirror site in England more acccessible:
src.doc.ic.ac.uk[146.169.3.7]:/unix/sco-archive
(Did you know this one existed, Dion ? It's got a rather outdated
 README from 22 Feb 1991 by rosso :-)

src.doc also runs an e-mail based server for UK sites only.
Sending "help" to info-server@doc.ic.ac.uk may help, but I'm not sure.
-- 
Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
-- 
/home/ronald/.signature: Not a name file
Newsgroups: biz.sco.opendesktop
From: KJELL HOLMGREN  <abacus.hgs.se!kjell@watmath.UUCP>
Subject: Time touble
Submit-To: scoodt@xenitec.on.ca
Organization: [resent by] The SCOODT gateway and Propagation Society
Date: Mon, 13 Apr 1992 15:35:39 GMT
Resent-By: mmdf@xenitec.on.ca
Precedence: bulk
From: acds.physik.rwth-aachen.de!kuku@watmath.UUCP (Christoph Kukulies)
Newsgroups: biz.sco.opendesktop
Subject: lng321a
Date: 13 Apr 92 12:13:05 GMT
Organization: [resent by] The SCOODT gateway and Propagation Society
Submit-To: scoodt@xenitec.on.ca
Resent-By: mmdf@xenitec.on.ca
Precedence: bulk


I looked for lng321a on ftp.uu.net and though it's listed in the info
file it's not physically there.

Can anyone tell me how to install these .Z files? I tried (for instance
lng227.Z) to dd if=lng227.Z of=/dev/rfd096ds15 , tried also tar'ing the 
files to disk. No success. I always get: tar file not extracted from the
custom script.

--Chris
From: tjc@uniplex.co.uk (Tim Clarke)
Newsgroups: biz.sco.opendesktop
Subject: Re: TRIDENT 8900
Date: 7 Apr 92 17:28:59 GMT
Reply-To: tjc@uniplex.UUCP (Tim Clarke)
Organization: Uniplex Limited, Redwood House, Hemel Hempstead

I had the old ODT 1.1 with Update F and then Update G. and I could never get the 1024x768 resolution to work, but it would under windows 3.
When I went to the X11R4 EFS the 1024x768 x16 works fine but none of the 256 colversions does.


Tim Clarke
From: bill@Celestial.COM (Bill Campbell)
Subject: Re: Length of filenames
Organization: Celestial Software, Mercer Island, WA
Date: Wed, 08 Apr 1992 16:25:32 GMT

In <9204061457.AA07251@saathi.ncst.ernet.in> saathi.ernet.in!durgesh@watmath.UUCP writes:

:> What is the maximum length of the file name that is accepted. I
:> recently did cp action.c action.c-backup. Later I did a ls -l
:> action*. The response was action.c-backup not found.
:> I think that there is a restriction on the number of characters in
:> the filename.

:Yes, 14 characters. Irritating, but there it is!
:....

Yes, irritating, but not fatal.  The 14 character name limit has
been around as long as AT&T UNIX, and wouldn't be too much
problem if the BSD types didn't insist on using longer names
because theirs is better, and they have to prove it!

Personally I try to limit file names to 12 characters to leave
room for the ',v' suffix RCS appends, and since I've even had to
move code to MS-DOS (ugh) I try to keep withing the ridiculous
DOS 8.3 naming conventions.  It makes my life easier in the long
run.  Just because a feature exists doesn't mean I have to use
it.  I've never had major problems porting my software amongst
various flavors of *IX because I stay away from system specific
``features''.

Bill
-- 
INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
             uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591
SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
From: staceyc@sco.COM (Stacey Campbell)
Newsgroups: biz.sco.opendesktop
Subject: Re: TRIDENT 8900
Date: Mon, 06 Apr 92 16:23:33 GMT
Organization: The Santa Cruz Operation, Inc.


In article <2APR199220570044@venus.tamu.edu> jle9162@venus.tamu.edu (ECKHARDT, JASON LEE) writes:
>I have a trident 8900 svga card with 1 meg ram...
>
>I am trying to get this card to work with ODT but only 640x480x16 seems
>to work correctly...when I configure the card for 1024x768x16 I get a mess like
>it's not using the right scan rate or something.. 

I can give you a generic answer iff you are running with one of the Impact
boards and have the X11R4 EFS installed.

A good way to try and get a mode working is to basically try all the
Impact II and Impact III grafinfo entries, and don't be put off by the
board name on the box.  It seems that Trident produced the Impact II,
then an Impact III that was not compatable with the II, then another III
that is compatable with the II.  There is no straightforward way to
determine which of the last two you have.  If you have one of the newer
Impact III boards then it should work with the Impact II grafinfo entries.

We are currently trying to figure out a way to reliably identify which
Impact a customer actually has, and direct them to the correct grafinfo
file.
-- 
     Stacey Campbell - staceyc@sco.com - {uunet,ucscc,att}!sco!staceyc
Newsgroups: biz.sco.opendesktop
From: acds.physik.rwth-aachen.de!kuku@watmath.UUCP (Christoph Kukulies)
Subject: 1.2 GB disk
Submit-To: scoodt@xenitec.on.ca
Organization: [resent by] The SCOODT gateway and Propagation Society
Date: Tue, 14 Apr 1992 11:46:39 GMT
Resent-By: mmdf@xenitec.on.ca
Precedence: bulk

I have a Adaptec 1542A controller with a Wren VI (766MB) attached to my 
SCO 3.2.2 system. Can I easily add an external 1.2 MB SCSI drive without
problems or would I have to change to a 1542B controller?

--Chris
From: ssanbeg@visual.spk.wa.us (Scott Sanbeg)
Newsgroups: biz.sco.opendesktop
Subject: Re: Length of filenames
Date: 10 Apr 92 00:48:08 GMT
Organization: The Visual Market Public Access Site - Spokane, WA

In article <9204061457.AA07251@saathi.ncst.ernet.in> saathi.ernet.in!durgesh@watmath.UUCP writes:
>
>Either way, you are stuck with the 14 char. limit.
>But one hears that the newest version of SCO Unix will not
>have this limit. I hope that's incorporated into ODT too.
>Comments, anyone?

It is true. The new release supports EAFS and 255 char filenames.
Scott
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Scott Sanbeg         Spokane, Washington     Voice: 509/535-2561
ssanbeg@visual.spk.wa.us (or) visual!ssanbeg@tau-ceti.isc-br.com
Newsgroups: biz.sco.opendesktop
From: saathi.ernet.in!durgesh@watmath.UUCP
Subject: Re: Length of filenames 
Submit-To: scoodt@xenitec.on.ca
Cc: scoodt@xenitec.on.ca
Organization: [resent by] The SCOODT gateway and Propagation Society
Date: Mon, 6 Apr 1992 14:57:22 GMT
             <1992Apr3.212403.5552@iti.org> 
Resent-By: mmdf@xenitec.on.ca


> What is the maximum length of the file name that is accepted. I
> recently did cp action.c action.c-backup. Later I did a ls -l
> action*. The response was action.c-backup not found.
> I think that there is a restriction on the number of characters in
> the filename.

Yes, 14 characters. Irritating, but there it is!
When file names greater than 14 characters are used, 
you can set a kernel parameter to either:
1. treat it as error and take no action (default) OR
2. silently shorten the name to 14 chars and use the shorter name.

Either way, you are stuck with the 14 char. limit.
But one hears that the newest version of SCO Unix will not
have this limit. I hope that's incorporated into ODT too.
Comments, anyone?

-- durgesh
--------------------------------------------------------------
 Durgesh D Rao                  Email : durgesh@ncst.ernet.in
 KBCS,NCST,Juhu,Bombay-49       Voice : 6201606/6201574 Ext 41
--------------------------------------------------------------
From: whittington@fixsr1.enet.dec.com (Phantom)
Newsgroups: biz.sco.opendesktop
Subject: removing TCP
Date: 6 Apr 92 21:54:29 GMT
Organization: Digital Equipment Corporation

I am getting a very bothersome error message and then my system locks up. It
turns out the Lan Manager and TCP get started when I boot my system, and I have
not properly configured my network. I don't want to configure my network using
TCP but instead DECnet. My question where do I remove the references to
starting TCP and or Lan Manager in my startup?

Thanks for any response.... 
Newsgroups: biz.sco.opendesktop
From: mm@hela.iti.org (Michael McFarland)
Subject: SNMP binary/source
Summary: SNMP available?
Organization: Industrial Technology Institute
Distribution: biz
Date: Mon, 13 Apr 1992 17:41:47 GMT

I've heard that there is a SNMP package available 
for SCO. Any idea where I can get it? And how much?
From: eah@xenitec.on.ca (Ed Hew)
Newsgroups: biz.sco.opendesktop
Subject: Re: test, please ignore
Summary: It helps to hack the correct injector script!
Date: Thu, 09 Apr 92 21:07:16 GMT
Followup-To: poster
Distribution: biz
Organization: XeniTec Consulting, Kitchener, Ontario, CANADA

In article <1992Apr09.210009.15164@xenitec.on.ca> eah@xenitec.on.ca (Ed Hew) writes:
>The big question:  does the injector hack make all those annoying
>"Resent-To:" headers go away without breaking anything else?
>Will it prevent upstream sites from tossing them back in like
>they've been doing?  Hope...hope...

Yeah, and it would help if I hacked on the _correct_ injector
script, now wouldn't it?!?

		--ed
--
[mail, mail, go away....fill up my filesystem some other day.]
[pick a hat, pick a site.   Notoriously:  edhew@xenitec.on.ca]
From: eah@xenitec.on.ca (Ed Hew)
Newsgroups: biz.sco.opendesktop
Subject: Current SCO rev #s (was Re: installing lng* files)
Date: 15 Apr 92 02:20:32 GMT
Organization: XeniTec Consulting, Kitchener, Ontario, CANADA

In article <9204140930.AA13137@acds.physik.rwth-aachen.de> acds.physik.rwth-aachen.de!kuku@watmath.UUCP (Christoph Kukulies) writes:

>Is there a list of the most recent release numbers of the various products?

I posted the most current
"SCO Product Availability Summary, March 26, 1992"
to biz.sco.announce and it's companion "scoann" mailing list
just yesterday.  It should have propogated to Europe by now.
--
  Ed. A. Hew,    <edhew@xenitec.on.ca>    ....!uunet.ca!xenitec!eah
  XeniTec Consulting Services, Kitchener ON, Canada +1 519 570 9848
 [biz.sco.{opendesktop,general,announce} newsgroup/mlists godfather]
Newsgroups: biz.sco.opendesktop
From: acds.physik.rwth-aachen.de!kuku@watmath.UUCP (Christoph Kukulies)
Subject: installing lng* files
Submit-To: scoodt@xenitec.on.ca
Organization: [resent by] The SCOODT gateway and Propagation Society
Date: Tue, 14 Apr 1992 09:30:52 GMT
Resent-By: mmdf@xenitec.on.ca
Precedence: bulk

I figured out meanwhile that I have to use /etc/xinstall. (BTW, I know
how to uncompress a .Z file - that was not the question). The actual 
problem was that I was trying to install it with custom.

The init.lng227 for instance fails because it is expecting to be at 
/dev/console when installing. My tty was named /dev/syscon (?).
I modified the init script, wrote it back to disk and did the install
again only to find out that I have already TCP 1.1.3 (tcprt) while
lng227 is TCP 1.1.1

Is there a list of the most recent release numbers of the various products?

And, in my original question, I also asked, why lng321a is not in
the archive though it is in the info file.


--Chris
From: hal@zurich.ai.mit.edu (Hal Abelson)
Newsgroups: biz.jobs.offered
Subject: Scheme programming position at MIT
Date: 11 Apr 92 13:28:38 GMT
Reply-To: hal@altdorf.ai.mit.edu
Distribution: biz.jobs.offered
Organization: M.I.T. Artificial Intelligence Lab.


The MIT Artificial Intelligence Laboratory has an opening for a
Research Scientist to provide system support for research in symbolic
and numerical computing.  We are seeking an outstanding system
designer who will assume primary responsibility for the continued
development of MIT's implementation of the Scheme dialect of Lisp, and
the associated Unix environment.  Other duties include continuing
research on high-performance implementations of Lisp-like languages,
and supervising students and staff members.  A formal degree
(bachelor's level or higher) in Computer Science is preferred.
Applicants must have experience with Scheme and with Scheme
compilation techniques, and must have developed substantial
applications in Scheme or Lisp.  Applicants must also have extensive
knowledge of Unix, although they should have sufficiently good
programming taste to not consider this an achievement.

MIT is an Affirmative Action/Equal Opportunity Employer.  MIT is a
non-smoking environment.

Please send inquiries to Prof. Hal Abelson, MIT Artificial
Intelligence Laboratory, 545 Technology Square, Cambridge, MA 02139,
hal@ai.mit.edu.




--

-- Hal

Newsgroups: biz.comp.software