HDTenEightyP/NetNews huggingface dataset:
From: gezelter@rlgsc.com
Newsgroups: comp.sys.dec
Subject: Re: DEC Pro 350
Date: 17 Nov 92 00:36:10 EST
Organization: Robert Gezelter Software Consultant, Flushing, NY

In article <woodbe.721933501@craft.camp.clarkson.edu>, woodbe@craft.camp.clarkson.edu (Brian E. Wood) writes:
> Hi, 
> 
> I'm new to this group because I'm trying to find out about about a DEC Pro 350
> computer.  I am in a group that owns one and we are hoping to upgrade it for 
> our use, which only means about 20 people would have access to it.  Our 
> DEC has a 10 Meg hard drive, 256k of RAM, and a dual floppy drive of 
> undetermined size.  We would like to get a larger hard drive between 100-200
> Megs in size, an ethernet card, and increased RAM.
> 
> What I would like to know is if it is possible to upgrade this system into something usable, or tradeable.  Or who to get into contact with about these questions.  
> 
> 
> Thank you.
> Please e-mail me
> 
> Brian E. Wood		woodbe@craft.camp.clarkson.edu
-- 
Brian,
 
Sorry to be the bearer of bad news, but the largest drive that 
can be hooked up to a PRO 350 is the DEC RD53 (the DEC relabel of 
the Micropolis 1325, which works quite well). However, to use 
this drive on your 350, you will need to have the later version 
of the disk controller, which postdates many Pro 350's. 
 
P/OS is can support more than one user on the machine at a time, 
but, since I presume that you do not have the multiple serial 
line add-in option, that limits you to two users (one on the 
console, and one on the "printer" port).
 
Memory capacity is maxed out at 1MB (If memory serves correctly, 
the CTI bus only includes 20 address lines on the etch).
 
I hope that the above has been helpful.
 
- BOb
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
| Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                                                 |
+--------------------------------------------------------------------------+
Newsgroups: comp.sys.dec
From: rince@dcs.warwick.ac.uk (James Bonfield)
Subject: seggy fault with ps
Summary: main(){vfork();pause();}
Keywords: vfork pause ps
Organization: Department of Computer Science, Warwick University, England
Date: Tue, 17 Nov 1992 12:19:41 GMT

Hello,
	The following program compiles and runs fine on my Decstation 5000/240
running Ultrix 4.2.

main() {
    vfork();
    pause();
}

However, from then on /bin/ps prints up the following:

$ ps
  PID TT STAT   TIME COMMAND
Segmentation fault
$

Can anyone explain this problem? Is it unique to my system, or does everyone
have this prob? (Also another problem is that sendmail gets the following
error no matter what I do, *unless* I trace it!

pid 29155 (sendmail) was killed on an unaligned access, at pc 0x40ccd8

James Bonfield (jkb@mrc-lmba.cam.ac.uk)   Tel: 0223 402499   Fax: 0223 412282
Medical Research Council Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.

-- 
James 'Rince' Bonfield             O    .__   ._ ~ ~    /\/ ~        /\/
jkb@mrc-lmba.cam.ac.uk              o  /o  \_/ /        \/\  /o\/    \/\   ~
rince@dcs.warwick.ac.uk               (     | (  ~ ~         \(/\            ~
csuba@csv.warwick.ac.uk                \/__/ \_\                  ~
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.sys.dec
Subject: Re: Is the Alpha 3000(400/500) board upgradable?
Date: 20 Nov 92 14:30:19 GMT
Organization: Canisius College, Buffalo NY. 14208

In article <1992Nov18.154130.22416@PA.dec.com>, rjones@wsl.dec.com (Russ Jones) writes:
> 
> The DEC 3000 AXP Workstations are "classic" single-board computers.  There are no CPU daughtercards.  However, rest assured that these workstations will be upgradeable over time through many iterations of faster Alpha performance levels. 
> 
> Russ Jones
> UNIX Marketing
> Digital Equipment Corporation, Palo Alto, CA

  Substitute "3100" for "3000 AXP" and "MIPS RISC" for "Alpha" and we end up
  with something very close to a precise quote from DEC sales two+ years ago.
  ( 1/2 :-) ,  1/2 :-(  .  What's the symbol for "cynical" ?)



  greg pavlov
  pavlov@fstrf.org
Newsgroups: comp.sys.dec
From: mjr@hussar.dco.dec.com (Marcus J. Ranum AXP)
Subject: Re: DEC Support?
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Date: Thu, 19 Nov 1992 15:11:37 GMT

>   More "outrageous prices" --- care to justify these assertions?
>
>Okay, How many manufacturers are getting $10,000 for a 1.3 gig drive?
>How about $2000 for a single hard drive controller?  $8,000 for a 351
>meg drive?  (I would point out that an 8 meg RAM card costs $8,000,
>but I understand SGI has even higher prices than that.)  These are
>what I call outrageous prices.

[advance warning: possible tongue-in-cheek posting]

	Let's set up a hypothetical situation, and see how it fits. ;)
I have no idea if this is correct, but from where I sit this seems to
be what happens all the time...

Suppose you have a vendor and a 3rd party who both sell a 1.3Gb drive
for their computer. The vendor sells it for $10,000 and the 3rd party
for $3,000. Outrageous. Then we find out that the vendor has actually
designed and built that drive from the ground up, tested and qualified
it, documented it, laid in spare logic boards for it, had to set up a
whole field service organization that understands that drive, etc. The
3rd party, who are much smarter, buy the drives en masse and put them
in a customized box with a power supply purchased en masse. Let's just
suppose that the 3rd party pays $500 for the bare drive and logic board
and cabinet. Adding assembly, cost of sale, staffing and stocking, etc,
and they sell the drive for $3000 and pocket $500/drive. The vendor,
after building the drive, logic, paying the engineers, etc, etc, etc,
etc until they are blue in the face, finally slashes the price and
manages to sell the 1.3Gb drive for ONLY $10,000 and pockets $500/drive.

	Digital still has (but it's changing *FAST*) a tendency to
want to build everything from the ground up, rather than buying it
off the shelf, stuffing it into a box, and putting a label on it.
This is apparently not a very effective approach these days, since
it increases the time to market, increases costs, and decreases
revenues. I suspect a hard dose of reality is effecting a change.
The fact that Digital has been getting increasingly aggressive with
keeping prices down is a good sign to me - look at the DEC PCs -
they are almost in the ballpark of taiwan, inc. PCs. Nobody, even
IBM is getting away with selling overpriced stuff "hand built from
the ground up by craftsmen in our plant in the black forest, each
piece lovingly polished by a bevy of maidens before wrapped in
silk and shipped by cruise ship to your door" anymore.

	In short, you don't need to flame DEC for what you perceive
as high prices. Buying stuff from a 3rd party hurts a lot more than
anything you can post to USENET, and gets noticed more.

mjr.
From: jas6525@ultb.isc.rit.edu (J.A. Shue)
Newsgroups: comp.sys.dec
Subject: WANTED: Escape sequences for DEC VT340 terminal
Date: 15 Nov 92 16:52:04 GMT
Distribution: usa
Organization: Rochester Institute of Technology
Originator: jas6525@ultb

I would like to find a list of the escape sequences and what they do,
for a DEC VT340 terminal.  Especially the ones that control the
graphics.

Any and all pointers or partial lists would also be appreciated, e-mail
them to: jas6525@ultb.isc.rit.edu

Thanks.
+--------------------------------=+=---------------------------+
|        step into a heaven       |                            |
| where i keep it on the soulside | jas6525@ultb.isc.rit.edu   |
|          girl please me         | jas6525@ritvax.isc.rit.edu |
|         be my soul bride        |                            |
|           every woman           | +------------------------+ |
|     has a piece of aphrodite    | | RRRR      III    TTTTT | |
|        copulate to create       | | R   R      I       T   | |
|     a state of sexual light     | | RRRR   *   I   *   T   | |
|      kissing her virginity      | | R R    *   I   *   T   | |
|           my affinity           | | R  R       I       T   | |
|      i mingle with the gods     | | R   R     III      T   | |
|      i mingle with DIVINITY     | +------------------------+ |
|                       -R.H.C.P. |                            |
+--------------------------------=+=---------------------------+
From: andrewr@iagu.itd.adelaide.edu.au (Andrew Rutherford)
Newsgroups: comp.sys.dec
Subject: Re: can't "kill -9" processes on Ultrix/RISC
Date: 17 Nov 1992 22:39:33 GMT
Organization: The University of Adelaide
NNTP-Posting-Host: iagu.itd.adelaide.edu.au
X-Newsreader: TIN [version 1.1 PL6]

Philip Yzarn de Louraille (yzarn@lhdsy1.lahabra.chevron.com) wrote:

+ >On Ultrix/RISC 4.2A we often find processes that 
+ >can't be killed (by root, "kill -9") - short of a reboot.

+ >Is this expected behaviour under some circumstances?

+ Yes, if the process has been swapped out to disk and is not recalled.
+ The problem is why isn't the process recalled?

	This occurs because the process has gone into a device wait for
some reason. It doesn't receive the signals until it comes out of the
kernel, which (for instance) is why the pagedaemon and swapper can't
be killed - they always have these little "D"'s beside them if you do a
"ps aux".
	Philip has pointed out one possible cause - there are a number of
ways of doing this, usually to do with NFS and servers being down,
broken automounters, something waiting for the close on a pipe (under some
systems, not sure about Ultrix).
	There are a huge number of fun things you can do with the mmap()
call under SunOS, (un?)fortunatly none of these seem to work with OSF/1.
	There are ways of getting rid of processes like this, however it
involves grubbing around inside the kernel - it is NOT advised and you'll
probably get the kernel to panic if you miss one small thing. Only do this
if you were going to bring the machine down anyway.

	Andrew.

/*
 * Andrew Rutherford                 andrewr@itd.adelaide.edu.au
 * +61 8 228 5669            Real Programmers always confuse Christmas and
 * Room 1060, Adelaide Uni      Halloween because OCT 31 == DEC 25 !
 */
Newsgroups: comp.sys.dec,comp.os.vms
From: mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney)
Subject: Re: alpha memory requirements (vs vax) ?
Organization: Indiana University, Bloomington
Date: Mon, 16 Nov 1992 17:14:09 GMT

In article <1992Nov13.162542.5834@ais.com> bruce@ais.com (Bruce C. Wright) writes:
>In article <Bxnt6o.Jx0@mtholyoke.edu>, jbotz@mtholyoke.edu (Jurgen Botz) writes:
>> In article <1992Nov13.133438.8279@engage.pko.dec.com> jackson@pravda.enet.dec.com () writes:
>>>The memory for the new systems is priced at $125/MB, which is considerably 
>>>less than memory from Digital only a few weeks ago. In fact, Digital memory
>>>is less expensive than that of a third party who announced their memory
>>>for the DEC 3000 family before we announced the products.  We'll also trade
>>>in memory from a current workstation when you're upgrading to allow you
>>>to protect the investment that you've made in memory for our existing products.
>> 
>> Nonetheless it's too expensive... 70ns 1Mb chips are selling for less
>> than $2.50 per in volume... that works out to less than $25 for a
>> 9-chip SIMM.  If your manufacturing cost is as high as $10/SIMM,
>> that's still nearly a 300% markup.
>
>A minor nit, but ECC memory won't be 9 bits wide.  9 bits only gets
>you parity, you need more than that for ECC (depending on the method
>used).  I don't know offhand the memory architecture used by the
>Alpha so I don't know exactly how many chips it would need per SIMM.
>
>I suspect that the DEC memory is still on the expensive side though,
>just not as badly so as your computation would suggest.

There's another factor that our genious didn't take into account, that is,
the speed of the memory.  70ns memory won't hack it on a machine that is
running at 150-200MHz.  In case you didn't notice, 200MHz is a 5ns cycle,
a bit smaller than, oh, say *70*.

I know one 3rd party vendor, whose prices are significantly lower than DEC's
on most products, just quoted me $6495 for 64MB of memory for the Sandpiper.
DEC isn't too much higher than that, especially when you consider the price
disparity in the DECstation-line memory cards.

	Darrin
>Bruce C. Wright


-- 

mdchaney@iubacs mdchaney@bronze.ucs.indiana.edu mdchaney@rose.ucs.indiana.edu

"I want- I need- to live, to see it all..."
From: jeh@cmkrnl.com
Newsgroups: comp.sys.dec
Subject: Re: AlphaVMS - Production Ready???
Date: 22 Nov 92 08:41:11 GMT
Distribution: usa
Organization: Kernel Mode Consulting, San Diego, CA

In article <3826@creatures.cs.vt.edu>, acciai_g@csgrad.cs.vt.edu (Guy Acciai)
 writes:
> I work for a local company that's about to expand it's production facilities
> next year (12/93 time frame).  [...]
> our DEC sales rep seriously downplayed using Alphaboxes & AlphaVMS in such an 
> enviroment.  He reasons were, "while the hardware's ok, the software will
> not be ready/stable for such a production enviroment".  

At the end of CY 93???  I think this is being very overly conservative.  

> I was very surprised
> by such a response given DEC's claims that VAX/VMS -> ALPHA/VMS ports are
> supposed to be fairly trival and that our application is over a year after
> commerical release.  

> Our software base includes (please, no flames for this):
> Fortran, C, COBOL, FMS, DECNet (end nodes & routers), WPS, DTR, SNA, Ingres,
> DECWindows, TCP/IP, and Pathworks.  

The main issue you will have is whether or not all of these layered products
will be available in time.  If it isn't you can still run VESTed images on the
Alpha.  

> Our rep, instead is pushing for 4000-100's
> to later '(2-3) years' be replaced with alpha boxes.  

Hey, if he'll sign a deal wherein you get the full price of the 4000-100's,
plus any unusable components of those systems, as credit toward the Alpha, this
isn't a bad deal.  DEC has done that in some cases I've heard of. 

Otherwise, it isn't your company's job to help DEC rid itself of inventory of a
box that is about to become a VERY poor price-performance box.  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
Newsgroups: comp.sys.dec
From: zapantis@uvphys.phys.uvic.ca (Nik Zapantis)
Subject: Re: Is the Alpha 3000(400/500) board upgradable?
Reply-To: zapantis@uvphys.phys.UVic.CA
Organization: University of Victoria, Physics & Astronomy
Date: Wed, 18 Nov 92 23:20:48 GMT


In article <1992Nov18.154130.22416@PA.dec.com>, rjones@wsl.dec.com (Russ Jones) writes:
>
|>Nik,
|>
|>The DEC 3000 AXP Workstations are "classic" single-board computers. 
|> There are no CPU daughtercards.  However, rest assured that these 
|>workstations will be upgradeable over time through many iterations
|> of faster Alpha performance levels. 
|>
|>-- 
|>Russ Jones
|>UNIX Marketing
|>Digital Equipment Corporation, Palo Alto, CA
|>All opinions expressed are mine, and not necessarily those of my employer
|>

Should I read the above answer as a 'yes' to my question? Will DEC offer a
"classic" single-board upgrade for these systems?
One of the selling points of HP, IBM and now SUN, is that board upgrades will
be offered as new/faster CPUs become available.
I sure hope DEC does not choose to be different.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Nik Zapantis                  | zapantis@uvphys     (BITNET)  |
| Dept. of Physics & Astronomy  | 45393::zapantis(HEPnet/SPAN)  |
| University of Victoria        | zapantis@uvphys.phys.UVic.CA  |
| Victoria, BC                  | Phone: (604)721-7729          |
| V8W 3P6                       | FAX:   (604)721-7715          |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Newsgroups: comp.sys.dec
From: rjones@wsl.dec.com (Russ Jones)
Subject: Re: Is the Alpha 3000(400/500) board upgradable?
Organization: Digital Equipment Corporation
Date: Wed, 18 Nov 92 15:41:30 GMT

Nik,

The DEC 3000 AXP Workstations are "classic" single-board computers.  There are no CPU daughtercards.  However, rest assured that these workstations will be upgradeable over time through many iterations of faster Alpha performance levels. 

-- 
Russ Jones
UNIX Marketing
Digital Equipment Corporation, Palo Alto, CA
All opinions expressed are mine, and not necessarily those of my employer
Newsgroups: comp.sys.dec
From: zrepachol@cc.curtin.edu.au
Subject: Re: RM03 Massbus-SMD controller with a Fujitsu M2284?
Organization: Curtin University of Technology
Date: Mon, 16 Nov 1992 22:02:13 GMT

In article <1939@lysator.liu.se>, pen@lysator.liu.se (Peter Eriksson) writes:
> I have been thinking of perhaps trying to make use of the Massbus<->SMD
> controller/converter, that right now is sitting in a RM03, and try to
> connect a Fujitsu M2284 (130MB) SMD drive to a Vax 11/750 with it.
> 
> Is it possible to do it, and if so, how do I reconfigure the Massbus<->SMD
> controller?
> 

First you change the disk interface to "smd-ish" that is used for the disk-MBA
interface. Then you reblow the PLAs in the MBC to acount for the different
drive geometery.

Of course this assumes you have already patched the DRdriver to talk to your
disk...

~Paul

Xref: sparky comp.sys.dec:6096 comp.unix.shell:4815 comp.unix.ultrix:8440
From: john@sekrit.WPI.EDU (John Stoffel)
Newsgroups: comp.sys.dec,comp.unix.shell,comp.unix.ultrix
Subject: Re: tcsh on DEC OSF/1 Alpha
Date: 20 Nov 92 11:02:59
Organization: Worcester Polytechnic Institute
NNTP-Posting-Host: sekrit.wpi.edu
In-reply-to: iglesias@draco.acs.uci.edu's message of 20 Nov 92 06:21:13 GMT

>>>>> On 20 Nov 92 06:21:13 GMT, iglesias@draco.acs.uci.edu (Mike Iglesias) said:


Mike> Does anyone have config files/source changes/etc to get tcsh v6.02 to
Mike> compile on an DEC Alpha system running OSF/1?  I've made a stab at
Mike> it, but the compile dies right away in tc.os.h where it defines
Mike> sigpause().

Look on gatekeeper.dec.com for some already ported programs.  tcsh is
one of them.  Look in /.1/DEC/Alpha/apps

				John

--
Youth of today!  Join me in a mass rally for traditional mental attitudes!
-------------------------------------------------------------------------------
john@wpi.wpi.edu | Work Station Specialist | Worcester Polytechnic Institute
John Stoffel     | 508-831-5512 (work)     | Worcester, MA  01609
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.sys.dec
Subject: Re: DEC Support?
Date: 19 Nov 92 14:42:28 GMT
Organization: Canisius College, Buffalo NY. 14208

In article <DGRAY.92Nov16133448@menudo.uh.edu>, dgray@menudo.uh.edu (Dennis Gray Jr.) writes:
> 
> First, the technical sales line (800-DIGITAL) sometimes cannot even
> tell me what parts I can use with my machine.
> 
  I have used 800-DIGITAL a number of times over the past 3 years without
  encountering the above problem.  Then again, I never had cause to ask them
  "What parts do you sell for a DEC 5000 ?" 

> DEC "support" will not even talk to you unless you have one of their
> outrageously priced service contracts.

  Well, DEC did try using volunteers to man their support offices for a while.
  But after United Way removed the company from its participant list,  DEC
  found that it had to start paying its people.... :-)


  pavlov@fstrf.org
From: przemek@rrdstrad.nist.gov (Przemek Klosowski)
Newsgroups: comp.sys.dec
Subject: Re: FORTRAN, OSF/1, Alpha AXP
Date: 24 Nov 92 01:39:51 GMT
Organization: U. of Maryland/NIST
In-reply-to: oberman@ptavv.llnl.gov's message of 23 Nov 92 17:47:33 GMT

In article <1992Nov23.094734.1@ptavv.llnl.gov> oberman@ptavv.llnl.gov writes:

   There is no FORTRAN compiler for OSF/1 at this time. Last word I have is that
   the FORTRAN compiler for OSF/1 won't be available for at least a month.

We will have a demo Alpha with OSF/1 installed soon. I asked DEC if there will
be a Fortran compiler and they said "yes". I shall report what I find out
when our machine comes.
	
--
			przemek klosowski (przemek@rrdstrad.nist.gov)
			Reactor Division (bldg. 235), E111
			National Institute of Standards and Technology
			Gaithersburg, MD 20899,      USA

			(301) 975 6249
Newsgroups: comp.sys.dec
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: Alpha speed?
Organization: Digital Equipment Corporation
Date: 16 NOV 92 10:50:04    


In article <1699@niktow.canisius.edu>, pavlov@niktow.canisius.edu (Greg Pavlov) writes...
>In article <RICHARD.92Nov12152902@chemeng.stanford.edu>, richard@chemeng.stanford.edu (Richard Schiek) writes:
> 
>  The REAL question here may be why DEC is limiting "workstation"-class 
>  machines to the lower end of the range.  Too many of us who have been
>  using "workstation" platforms as multi-user and/or server systems ??
>  Though this may simply be a conflict between what us UNIX folks are
>  used to and what VMS folks are used to paying.
> 
It is a matter of cost. Most semiconductor processes have yield curves that
allow fewer parts at higher speeds than slower parts. This causes the higher
speed parts to be more expensive. Faster parts also need higher cost cache chips
to exploit the faster CPU. Therefore, faster chips appear first in the higher
price bands where the volumes are lower too.

In time as the yield curve shifts and tachnology advances, you will see >150MHz
parts in workstations which are cost contrained and high volume.

/d
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.sys.dec
Subject: Re: SCSI for DEC 5400??
Date: 19 Nov 92 14:50:41 GMT
Organization: Canisius College, Buffalo NY. 14208

In article <1992Nov18.020220.24797@scott.skidmore.edu>, ldg@scott.skidmore.edu (Leo D. Geoffrion) writes:
> 
> The local office claims that the 5400 does not support SCSI and
> that we'd need to upgrade to the model 5500 (board and memory swap) in
> order to achieve SCSI compatibility.
> 
  Emulex makes a SCSI board that will work in the DEC 5400.


  pavlov@fstrf.org
Newsgroups: comp.sys.dec
From: paul@sci.ccny.cuny.edu (Paul Chen)
Subject: PostScript in lps20, help!!
Organization: City College of New York - Science Computing Facility
Date: Mon, 16 Nov 1992 16:07:39 GMT


We have some problems to some of PostScript files (not all of them)
in our lps20, and these files can be printed in QMS or HP without
any problems. Lps20 can print most of PS files, only some 'special
or complicated' PS files can't be printed.
May be we need more fonts? How can I find out how many fonts we have?
Any suggestions?

Thanks in advance, please response via e-mail.

Paul


-- 
Paul Chen, System Manager                CC   CC  N   N  Y   Y   
Science Computer Facility,J302          C    C    N N N    Y      
City College of CUNY                     CC   CC  N   N    Y    -SCIENCE
New York, NY 10031                    	Internet: paul@sci.ccny.cuny.edu
Newsgroups: comp.sys.dec
From: olin@hermes.cheme.cornell.edu (Steve Thompson)
Subject: Re: DEC Support?
Reply-To: olin@hermes.cheme.cornell.edu
Organization: Chemical Engineering, Cornell University, NY
Date: Mon, 16 Nov 1992 19:57:40 GMT

In article <DGRAY.92Nov16133448@menudo.uh.edu>, dgray@menudo.uh.edu (Dennis Gray Jr.) writes:
>And now they cannot even supply tapes for their own machines.  A local
>office supply has a 3M equililent to the TK50 tapes, but all three of
>the DEC distributors I called have back orders (one guy said they had
>"several thousand on order").  This is really insane.

I just ordered a load of TK50 tapes from DEC Direct; they arrived in 4 days.

Steve

---------------------------------------------------------------------------
Steve Thompson, System Mangler   Internet: thompson@cheme.tn.cornell.edu
School of Chemical Engineering   Bitnet:   thompson@crnlchme
Olin Hall, Cornell University    Phone:    (607) 255 5573
Ithaca NY 14853
---------------------------------------------------------------------------