HDTenEightyP/NetNews huggingface dataset:
From: PIRARD@VM1.ULG.AC.BE (Andre' PIRARD)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Windows Socket API
Date: 21 Aug 92 11:52:46 GMT
Article-I.D.: louie.9208210943.aa03735
Organization: University of Liege (Belgium), SEGI (Computing Center)

On Thu, 11 Jun 1992 00:34:41 EDT Roger Fajman said:
>The Windows Socket API sounds like a big step forward.  I wish that
>it dealt with DOS applications too, however.

Indeed!!! [When will be the time we can sit the best app on the best stack].
And my wish is that the DOS spec would consider DESQview multitasking.
Specifically, add the necessary tasking primitives that plain DOS misses.
And avoid up-calls and up-memory-references (or do them DV compatible).
Many excellent programmers do not necessarily want to tackle Windows
programming and there are many good programs (DOS or Unix) to adapt easily.
Think of CUTCP now reassembling packets and getting more than 25%
throughput on 9600 baud SLIP (this is just an example, sorry, Brad).
And remember those non-GUI guys, and that DV's multitasking is
well worth Windows'.

I wish that people [universities?] dreaming to implement yet another stack
would write the specs instead.
Isn't this the way to stop the price gouging discussed on another thread?

BTW1, I am unsure how the Win specs cover this: by all means, please also
make the job of the network administrator [mine] easier by normalizing
the access to usual PC setup parameters usually stored in a device driver
file (local host name, user name, print server's address etc...).

BTW2, incite ISO 8859 [aka ANSI in Windows' terms] programming; that's
normally easy in Windows, as the line code is the same as Windows'
internal code. A little more difficult for DOS apps that have to translate
ISO 8859-1 to internal PC 850, as DOS doesn't seem to want to support ISO.
Then, on the title page of the specs, you may add a European model of
a socket *and* connect them...

Andr'e PIRARD         SEGI, Univ. de Li`ege          139.165 IP Adm.
B26 - Sart Tilman     B-4000 Li`ege 1 (Belgium)      +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET
From: sbjie@engr.psu.edu (Sanjay Joshi)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Routines/Libraries to allow communications between PC's using C programs
Date: 21 Aug 92 15:22:29 GMT
Distribution: all

hi,

We are in the process of connecting several PC (runnning Dos) and 2 Dec 
Station 5000running Ultrix via ethernet, to allow controlling a
manufacturing sytem.  The PC's will have FTP software Inc.'s PC-TCIP
software.

We would like the PC's to be able to communicate with the Dec Stations,
and other PC's through (C or C++) programs where messages could be send back
and forth.  The Dec stations can communicate with each other using unix's
socket interface (I think).

Is there any software libraries or routines available (commercial or
public domain) that will allow communicaitons between programs.

Thanks for any help.

sanjay joshi.
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs
From: andrick@rhrk.uni-kl.de (Ulf Andrick)
Subject: How to mount PC file systems via tcp/ip? 
Reply-To: andrick@rhrk.uni-kl.de (Ulf Andrick)
Organization: University of Kaiserslautern (Germany)
Date: Thu, 20 Aug 1992 21:00:04 GMT

I read somewhere that one could use idmnt by FTP to mount directories
of another PC running SOSS (Stan's Own Server) and wanted to try it.

But idmnt attempts to transmit user and password and seems to expect 
some appropriate response, which SOSS apparently does not deliver.

SOSS's portmapper seems to register the request, but probably doesn't 
do anything about it, while idmnt complains about the response from
`authentication' server missing.

Do I do something wrongly, is there any remedy or is it that it just
can't work?



Ulf R. Andrick                                  andrick@rhrk.uni-kl.de
Tierphysiologie
FB Biologie
Universitaet
D-W 6750 Kaiserslautern

Xref: sparky comp.protocols.tcp-ip.ibmpc:4741 comp.os.ms-windows.apps:1978
From: swlodin@kocrsv01.delcoelect.com (Steve Lodin)
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.apps
Subject: Novell and WinQVT/Net (Argggghhhh)
Date: 14 Aug 92 19:45:34 GMT
Organization: Delco Electronics Corp.
Originator: swlodin@kocrsw15


**** Posting for a friend who can't get his PC to work ****

I am trying to set up an AST 486/33 to run on an existing Novell network
(v3.11) WITH the ability to run WinQVT/Net.  I, like others in the past
and present, am having difficulty making IPX and TCP/IP coexist.  I
remember a posting several months ago on this subject which suggested
the following additions to autoexec.bat:

     lsl.com
     3c507.com -n -w 0x60
     odipkt.com
     winpkt 0x60 0x63
     pktint
     ipxodi.com
     netx.com

When I run this, it seems everything loads into RAM except winpkt, which
gives a message similar to "packet driver is at segment xxxx,
there is no packet driver at 0x63".  When I run windows 3.1 after this
sequence, my machine hangs.

If anyone out there has any experience with Novell NetWare and WinQVT/NET
simultaneous usage, please respond with a sample .bat file and/or
explanation of what's going on.  I can get each protocol to work separately,
but not together.

Thanks in advance for any assistance in lowering my blood pressure.

Mike Thoeny
Delco Electronics Corp
thoeny@kocrsv01.delcoelect.com
-- 
Steve Lodin	Internet: swlodin@kocrsv01.delcoelect.com  UUCP: deaes!swlodin


Thanks Tom for the nifty signature thingy.
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Can packet drivers for ethernet be converted to T-R NDIS?
From: <A6054OS2@HASARA11.BITNET>
Date: Friday, 21 Aug 1992 14:57:53 CET
Organization: SARA - Stichting Academisch Rekencentrum Amsterdam

I'm using OS/2 2.0 and have TCP/IP 1.2 installed with the IBMTOK MAC
driver.
Since programs like Archie can only be used with ethernet packet drivers
(those progs are based on CUTE or NCSA telnet), I can't use these Network
Information Retrieval progs.
However I lately read something about converting packet drivers to NDIS. Is
that possible and how? Or is there some info available on this topic? Or other
possibilities to use those programs?
 
All help is very much appreciated,
 
Rachid Tebbal
University of Amsterdam
Department of Information Systems
The Netherlands.
Xref: sparky comp.protocols.tcp-ip.ibmpc:4798 comp.os.ms-windows.apps:2104
From: mhart@blackjack.dt.navy.mil (Michael Hart)
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.apps
Subject: Re: Novell and WinQVT/Net (Argggghhhh)
Date: 20 Aug 92 10:08:53 GMT
Followup-To: comp.protocols.tcp-ip.ibmpc

In <Bt9EHC.BHr@usenet.ucs.indiana.edu> ntaib@silver.ucs.indiana.edu (Iskandar Taib) writes:

>In article <1992Aug14.194534.14216@kocrsv01.delcoelect.com> you write:
>>autoexec.bat:
>>
>>     lsl.com
>>     3c507.com -n -w 0x60
>>     odipkt.com
>>     winpkt 0x60 0x63

This line, ^, should be "winpkt 0x63 0x60".
The _new_ vector should be the first number, the old vector the second.

>Two things strike me as odd. The 3C507.com you are running is
>NOT a packet driver. It is an ODI driver. Therefore sticking 
>-w and 0x60 after it doesn't make sense. odipkt emulates a packet
>driver at 0x69, so your winpkt line should have something like
>0x69 0x79 after it. My guess is that you don't even need winpkt,
>since you aren't running NCSA Telnet. 

I disagree.  While I don't have/use a 3c507 card, I use a 3c503.
Having the -w and 0xnn on the lines indicates to me that he's using
a clarkson driver; the -w is a 'Windows' switch, and the 0xNN is the
vector you want the card to use.

--
|   Michael G. Hart                   mhart@blackjack.dt.navy.mil    |
|--------------------------------------------------------------------|
|     You think _I_ speak for the government or the navy?  HAH!      |
| Aviation, computers, quality improvement, Northern Exposure, money |
From: broughton@NICAD3.NIC.BC.CA (Simeon Broughton)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: ka9q
Date: 20 Aug 92 15:00:07 GMT
Distribution: world
Organization: The Internet

Sorry if this is a FAQ but I can't find an answer. I have 100+
PC's using CUTCP,  and I would like them to use a dynamic pool
of say 30-40 IP numbers.  I have ka9q installed on a PC and
at the end of the autoexec.net I have:-

bootpd start
bootpd dns nnn.nnn.nnn.4 nnn.nnn.nnn.5
bootpd dynip sl0 nnn.nnn.nnn.200 nnn.nnn.nnn.249

When I fire up my client I get the first available IP number and
the dns entries ok, but I can't seem to get the subnet mask or
default gateway to be passed. As I understand it the bootptab
file doesn't enter into this as that is only for static entries.
Any help or pointers appreciated.

      Simeon Broughton, Manager, Computer Services. (604)334-5254
   North Island College, 2300 Ryan Road, Courtenay, B.C. V9N 8N6. CANADA
                  broughton@nicad3.nic.bc.ca

Xref: sparky comp.protocols.tcp-ip.ibmpc:4832 news.software.readers:1690
From: timmi@asylum.sf.ca.us (Timothy G. Reynolds)
Newsgroups: comp.protocols.tcp-ip.ibmpc,news.software.readers
Subject: Re: Trumpet Shell for FTP Software TCP stack.
Date: 21 Aug 92 14:01:59 GMT
Reply-To: timmi@babyoil.ftp.com
Followup-To: comp.protocols.tcp-ip.ibmpc
NNTP-Software: PC/TCP NNTP

>I thought I would test newsx under Windows. You are right, it appears not to 
>work under Windows Enhanced Mode. Like a lot of my favorite software, it 
>works fine in Windows Standard Mode (just type win /s), which I usually run 
>anyway.
>================================================================
>Sean D. True
>Rational Systems, Inc.
>seant@ratsys.com -- uunet!rational!seant

Just to add another data point, if anyone cares, I run Windows 3.1 in
standard mode because I have a 286 with only 1 meg of RAM, and I
can't get Trumpet to work over either the generic or a board specific
FTP kernel.  The message I get has nothing to do with timeouts; it
simply say "cannot open NNTP session".  My feeling is that it's a
memory limitation problem.
--
Timothy G. Reynolds					FTP Software
FTP Technical Support					26 Princess St.
timmi@ftp.com						Wakefield, MA
(617) 246-2920							01880

	"We're well into the later half of the twentieth century,
	 paranoid misogyny is just plain out of style."
From: sammy@anagld.analytics.com (Sam Blackburn)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Windows Socket API
Date: 23 Aug 92 01:19:14 GMT
Organization: Computer Sciences Corporation - Systems Engineering Division

PIRARD@VM1.ULG.AC.BE (Andre' PIRARD) writes:

>On Thu, 11 Jun 1992 00:34:41 EDT Roger Fajman said:
>>The Windows Socket API sounds like a big step forward.  I wish that
>>it dealt with DOS applications too, however.

I just ordered the TCP/IP SDK from Microsoft and the salesman said that it
covers Windows, DOS and OS/2 (probably 1.3).  This is the SDK that implements
WinSock API.
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: robert@arbo.microbiol.uwa.oz.au (Robert Coelen)
Subject: SLIP via modem
Organization: University of Western Australia
Date: Mon, 17 Aug 1992 01:14:52 GMT

This is probably a FAQ, but I have not had to think about this 'problem'
until now. I need to configure SLIP from my home computer via a modem
link with the campus. What do I use ?

Thanks in advance for the replies


Robert Coelen
From: bruno@broue.rot.qc.ca (Bruno Majewski)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: S L O W idmnt with PC/TCP 2.05 (or: NFS slow?)
Date: 21 Aug 92 14:16:45 GMT
Distribution: world
Organization: Groupe de Recherche Operationnelle en Telecommunication (ROT)
X-Newsreader: Tin 1.1 PL4

Hello there,

We are having an irritating problem with a part of FTP Software's PC/TCP 2.05,
InterDrive: it's s*l*o*w mounting of "network drives" on the server thru idmnt.
Using drive Y: (for example) is ok (performance is what we expect it to be),
but mounting it will take between 35 and 40 seconds !!!

I don't think this is configuration of the networking software on the client
PC, because actual use of the drive would be as intolerable as mounting it.
At one point, I suspected an obscure option for idmnt could improve perfor-
mance, but there are not performance-related options for it (as far as I can
see).

I have also tried mounting drives on machines of various speeds with same
delays. This is leading me to believe that this is "normal" performance
for NFS: am I right?

Or is it that our NFS server is badly installed/configured?

We are running the NFS server on a 386-33 with Interactive UNIX SVR3.2 .

Please answer thru E-Mail; if this is of general interest, post answers
to the net, too.


Thanks in advance to all that will help us.


Bruno Majewski
From: CEARLEY_K@WIZARD.COLORADO.EDU (Vide Infra)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: CUTCP - TN3270 Reset (AGAIN!)
Date: 18 Aug 92 11:04:00 GMT
Distribution: world
Organization: The Internet


Some time back there was a discussion of the RESET function from 
Clarkson's TN3270 implementation (CUTCP). We have tried to map 
TN_RESET to CTL-R. We get FUNCTION NOT IMPLEMENTED when we press
CTL-R in a 3270 session. Any hints?

		-Thanks
		-Kent Cearley, University of Colorado, Boulder

Newsgroups: comp.protocols.tcp-ip.ibmpc
From: alh@einoed.in-berlin.de (Adrian Le Hanne)
Subject: opinions about Lan Workplace?
Organization: Einoed Unix & Netzwerke, Berlin (FRG)
Date: Tue, 18 Aug 1992 12:04:35 GMT

Hi,
we have to do some work with Lan Workplace in a unix environment. This product
is needed because the customer wants to work with Gupta's SQL-Windows and
an unix based informix server. I'm not familiar with the Lan Workplace 
product and would like to learn about your experience with this software.
E-mail responses are preferred.

thank you,
Adrian
-- 
Adrian S. Le Hanne        Einoed Unix & Netzwerke, Koepenicker Str.154, D-1000
alh@einoed.in-berlin.de   Berlin 36. Tel.: 030/611 31 26,  Fax.: 030/826 98 75
                                         "Christianity Is Stupid" -Negativland
Newsgroups: comp.protocols.tcp-ip.ibmpc,news.software.readers
From: trier@odin.ins.cwru.edu (Stephen C. Trier)
Subject: Re: Trumpet Shell for FTP Software TCP stack.
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Sun, 16 Aug 92 03:20:47 GMT

In article <1992Aug15.180822.26989@news.csuohio.edu> cowboy@trans.csuohio.edu (Syscrusher) writes:
>Try reducing your mss to mss=256 and reduce your rwin to rwin=256.  This
>might help, particularly with a SLIP connection.

This is not always the best advice.  The mss should definitely be in the
200 range, but the receive window can stay large.  Making the receive window
as short as the MSS makes TCP very inefficient.

MSS-sized windows cause TCP to degenerate into a protocol more like XMODEM
in which every packet must be acknowledged before the next can be sent.  It
can't stream the data out like it can when the receive window is a reasonable
size.  (In the latter case, the sender can start transmitting the next data
packet *while waiting for* an acknowledgement for the last.  When everything
goes right, there are no sit-and-wait-for-a-reply delays.)

-- 
Stephen Trier                      "I am not a lawyer, though I play one
Network Services Engineering        on the net."
CWRU IRIS/INS/Telecom                  Chris Torek, torek@horse.ee.lbl.gov
trier@ins.cwru.edu
From: kk881595@longs.LANCE.ColoState.EDU (kevin knappmiller)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Telnetting to a PC (with reply to FLAMES)
Date: 12 Aug 92 17:49:56 GMT
Reply-To: kk881595@longs.LANCE.ColoState.Edu
Organization: Engineering College, Colorado State University

I replied:

>>   If you are willing to pay some money and want a little more than
>>   this you should check out DesqView/X.  It might be more than
>>   you need or cost more than you want to pay, even though the
>>   price in September 'might' be acceptable to many of us.

> 
> Yes, I quite agree, and we already have a copy, but in addition to
> the Desqview/X you need Quarterdeck's TCP/IP Manager, AND the FTP
> kernel (or soon a TCP/IP kernel from Novell...). This just about
> triples the price; we're talking very serious bucks, and we ARE
> eventually going to have several systems running DVX, but for our
> typical low-budget NCSA Telnet user the economics make no sense.
> Also there are much more limited applications than would warrant
> shelling out the big bucks. I think Quarterdeck made a serious mistake in
> going for the Novell market instead of the TCP/IP world.
> 

I agree with you, and posted numerous flames myself.  As a response
a Quarterdeck representative called me and talked for quite a while.

I doubt that the TCP/IP version will ever sell for less than the other versions
primarily due to more licensing costs, but it appears that once the Novell
kernel is bundled in that previous Quarterdeck users can get the whole
thing for about $200 until the special offer runs out.   The street price
should be about $300.  That's still more than NCSA Telnet, but it's in the
range that I think far more people are willing to pay. (At least for use
on some machines.  We too will probably continue to use NCSA Telnet
on most of the PC's,  but for the newer machines with sufficient
graphics capability I think it's got a lot of potential.)

It's too bad that Quarterdeck missed the boat with their TCP/IP release,
but that's the nature of the game when lawyers get involved.  I think
they will try to make up for it.  (The problem may be you early birds
who paid over $500 and aren't real happy about it.)

Kevin
From: jackson@acf3.nyu.edu (Robert Max Jackson)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Crynwr WD8003E v. 10 packet driver problem
Keywords: packet drivers wd8003e
Date: 18 Aug 92 14:29:43 GMT
Organization: New York University



     In response to my query about a problem using version 10 of
the Crynwr packet drivers for Western Digital cards (WD8003E.COM)
Hugh Redelmeier (Thanks Hugh) reposted a June message from Russ
Nelson describing a bug in the 8390 driver used by the packet
driver for this (and other) cards.  As I have neither the skill nor
time (after 7 months of time tracking this down) to figure out how
to reassemble the whole packet driver, I decided to see if I could
simply patch the existing v.10 driver.  It seems to me that it will
work and I am seeking confirmation (I tried it and it seems ok, but
who knows what time bombs await).
     Below, as best I can figure it, is the incorrect and corrected
code (a macro used to insert pauses in communications with the
board).

Actual Code
in Hex        Assembler
-----------   -------------
50            PUSH    AX
E561          IN      AX,61   <---WRONG
58            POP     AX

50            PUSH    AX
E461          IN      AL,61   <---RIGHT
58            POP     AX

This piece of code seems to appear nowhere else in the remaining
code used for the packet driver.  Therefore, a simple search and
replace of the first 4 bytes by the second 4 bytes would seem to
patch the buggy code.  

     IS THIS CORRECT???
From: dan@ORTTA (Daniel C. Cummings)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: ncsa telnet and the del 333p machine - does anybody's work?
Date: 14 Aug 92 18:53:15 GMT
Article-I.D.: ORTTA.dan.24
Organization: U of Mn

In article <mikelle.6.0@vaxb.gbus.virginia.edu> mikelle@vaxb.gbus.virginia.edu (Eddie Mikell) writes:

>Greetings:

>I am experiencing a problem with getting NCSA telnet to work with a
>Dell 333p 386 33mhz machine.

>I am using an ibm token ring card, the ibmtoken software, and plain
>vanilla telnet.  This same set up has worked on most clones I have 
>used (treasure chest, dtk, alr, etc) without a hitch.

Well....it *does* work...I have 20 Dell 333P 386 33Mhz machines with IBM 
Token Cards running NCSA Telnet with success.  My networking software is 
Novell and I am using IPXPKT which talks to IPX which in turn talks to the 
hardware.  We have left the shadowing on and everything is configured as 
shipped.  

(Autoexec example)
LSL
TOKEN
IPXODI
IPXPKT 0x60
NETX
F:
login

I suspect that you may have a problem with IBM's LAN Support program and 
IBMTOKEN.COM or perhaps a problem with shared RAM conflicting with another 
driver or card.  Make sure to try it with nothing loaded high and no other 
cards in the system...that might help you troubleshoot it.  Does your 
config.tel specify the correct interrupt for the packet driver?  We gave up 
on IBMTOKEN because you had to use LAN Support with it....too much 
overhead.  IPXPKT has worked well for us.

Hope this helps!
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Help needed with QVTNET27
From: hippo@sonoma.edu (Michel Davidoff)
Date: 20 Aug 92 20:35:55 PDT
Organization: Sonoma state university

Can you tell me where you got this? I've version 2.6 and I'm looking for 2.7
From: croussel@hayes.com
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Windows (protected mode) to NDIS
Date: 17 Aug 92 13:45:38 EDT
Organization: Hayes Microcomputer Products, Norcross, GA


Hail pc.networking.wizards!

I'm looking for some code, or pointers or both.

I need to do RAW packet input and output via NDIS from a 
Windows/386 application.

I'm no PC expert, but I know some Protected-to-Real-to-Protected
shenanigans are gonna have to happen.

Anyone know anything out there in the Public Domain which can 
do this for me?

Note that I need RAW packet access, and, if necessary we can assume 
no other NDIS clients are running.

- chris




-- 
Chris Roussel 			   internet: hayes!croussel@uunet.uu.net
(404) 840-9200 (x.2147)                uucp: ...uunet!hayes!croussel
Hayes Microcomputer Products       U.S.Mail: p.o.box 105203, Atlanta, GA 30348
Newsgroups: comp.protocols.tcp-ip.ibmpc
From: stefan@helios.physics.utoronto.ca (Stefan Mochnacki)
Subject: Weird inefficiencies in a PCROUTE SLIP link.
Organization: University of Toronto Physics/Astronomy/CITA
Date: Thu, 20 Aug 1992 07:01:03 GMT

I have a BIZARRE problem with my PCROUTE SLIP link being
tested in the lab ...


CONFIGURATION:


ether(subnet 77)==[PCROUTE]----SLIP----[PCROUTE]==ether(subnet 99)
||
_===> SLIP to outside...

There are many machines on subnet 77, including a Sun SS1+ and 386i.
On subnet 99 there is a Compaq Portable II with WD8003E on
packet driver and various test programs (ping, NCSA Telnet,
WATTCP ftp, etc.)

The PC's running PCROUTE have WD8013EP cards and 16550AF serial
chips. 16MHz AT clones (286), 8MHz bus. Internal ether and SLIP drivers;
I have tried Crynwyr packet drivers with same results.


PROBLEM:

When I download files using ftp from Suns on net 77 to the
Compaq on net 99, I get 700 or so bytes per second (quite OK for
a 9600 baud serial link.) But uploading is very slow using NCSA 
(typically 60 to 100 bytes/sec).

I have tried WATTCP ftp, with weirder results: downloading crashes,
while uploading runs at about 300 bytes/sec. (This is on the Compaq).

Telnet and ping seem to work OK through the link. Routing information
about net 99 is not being propagated through the "permanent" SLIP
connecting 77 to the outside world; my testbed system is supposed to
replace the present SLIP. The failure of propagation may be a function 
of the old SLIP's limitations ...


REQUEST:

Has anybody got any advice about such weird inefficiencies? Is the
trouble a strange interaction between the routing PC's and the Suns, 
or between the routers and the test PC ? Is the problem in the test
PC ? Is the problem in those EP cards? (I'm aware of some of the
discussion on this group about SMC packet driver problems ...).

If I can be fairly confident that the problem is restricted to the
test Compaq setup, I'll install the system and test it with transfers
between Suns. Any comment ?

					Stefan Mochnacki


-- 
Stefan W. Mochnacki          INTERNET - stefan@centaur.astro.utoronto.ca
Astronomy, U. of Toronto     UUCP - {uunet,pyramid}!utai!helios.physics!stefan
Ph. (416) 884-9562           BITNET - mochnacki@utorphys.bitnet 
FAX (416) 884-2672	     LOCATION - David Dunlap Observatory