HDTenEightyP/NetNews huggingface dataset:
From: rob@wzv.win.tue.nl (Rob J. Nauta)
Newsgroups: comp.unix.sysv386,comp.unix.bsd,comp.arch,comp.sys.ibm.pc.hardware
Subject: Cyrix CX486SL
Date: 6 Apr 92 13:30:44 GMT
Reply-To: rob@wzv.win.tue.nl
Followup-To: comp.unix.sysv386
Organization: Sex, UNIX & Rock 'n Roll

I read in a magazine lately that Cyrix has announced a new processor,
the CX486SL, a clone of the Intel i486. The article stated that
apart from the price ($119 vs. $400 for a real 486 (both 25 Mhz)),
its main strength is the fact that it has a casing compatible with
the Intel 386SX. This made me wonder:
- I assumed that the 386SX is a surface-mounted component which is
glued/soldered onto the motherboard. If true, this makes upgrading
your 386SX motherboard rather difficult.
- A typical 386SX motherboard has a 16-bit databus, does this mean
that this processor is also only 16 bits external ?
- Does it have a coprocessor, like a real i486 ?

The concept isn't as interesting as I first thought, almost all
SX boards and PC's are 16 or 20 Mhz, 25 Mhz SX'es are rare, so
why go for this strategy ? Has any manufacturer announced a
motherboard based on this processor yet ?

Anyway, I've lost track on all the (clone and official) 386SX,
386DX, 486, etc chips available, so if you have any information,
please send mail, and I'll prepare a summary. I'm especially
interested in the chips which are n ot plain vanilla clones, like
a chip I heard about recently, which is a 25 Mhz component with
an internal speed of 50 Mhz. This sounds interesting, but muddles
the PC market. Nowadays, if you buy a 486, you might risk not
getting a real 486, but discover at home that your 50 Mhz machine
is really a 25 Mhz machine with that chip, or that your 25 Mhz
machine has a 16-bit 386SX design...

Rob
Newsgroups: comp.unix.sysv386
From: ajrooks@vlsi.waterloo.edu (Alan Rooks)
Subject: C and C++ compilers on SVR4
Organization: University of Waterloo
Date: Tue, 14 Apr 1992 06:52:04 GMT


Much thanks to Eric Raymond for the very useful SVR4 buyers guide FAQ, but...

I need more info on the C and C++ compilers available with the systems he
reviews.  When I pay for the development option (or if I don't have to
pay for it because it's free with the base system), what C compiler do I
get in Dell, Esix, Microport, and UHC SVR4?  I assume that all supply the
AT&T 386 compiler, but since my experience with this beast is that it is not
exactly highly optimizing, I wonder if some vendors support other compilers.
In fact, I've heard rumours of people using a Microsoft C compiler - although
I thought that Microsoft had never sold anything but 16 bit compilers
for 8086s.

Do any of the vendors supply C++ compilers?  (Probably cfront ports).  SCO is
asking a ridiculous price for theirs - are there reasonable ones?  Are there
third-party cfront vendors that specifically target SVR4/386?  How much do
they cost, and what cfront version are they?

Thanks in advance for any info.

Alan Rooks	University of Waterloo		ajrooks@vlsi.waterloo.edu
						ajrooks@vlsi.uwaterloo.ca
From: shwake@raysnec.UUCP (Raymond N. Shwake)
Newsgroups: comp.unix.sysv386
Subject: Re: ISA machines are cheap, not excellent, Unix machines
Date: 6 Apr 92 20:13:40 GMT
Organization: A/C International

rfarris@rfengr.com (Rick Farris) writes:

>> The untouchable floating point performance of HP-PA/IBM POWER chip sets
>> is one.  I have strong doubt that even i586, at least in its early batches,
>> can beat HP-PA/POWER in that area.

>So what?  Why does that make the PA-RISC chips more
>expensive to produce?  We're just talking about baking
>cookies, here, aren't we?  

I suspect one prime factor in the price differential involves volume: The
rather high cost of R&D associated with such chips and the high cost of
plant associated with their manufacturer must be amortized across a smaller
product volume than is the case with Intel's iAPX line. 
-- 

uunet!media!ka3ovk!raysnec!shwake			shwake@rsxtech
Xref: sparky comp.unix.sysv386:8733 comp.periphs.scsi:2290
From: pim@cti-software.nl (Pim Zandbergen)
Newsgroups: comp.unix.sysv386,comp.periphs.scsi
Subject: Ejecting DAT or Exabyte tapes through software ?
Date: 16 Apr 92 17:34:39 GMT
Organization: CTI Software BV, The Hague, The Netherlands

Is there a way to eject a DAT or Exabyte tape through 
software in ISC Unix 3.0 ? Perhaps some undocumented ioctl() ?

After backing up the system and verifying the tape,
I would want the backup script to have the tape ejected,
to prevent the whole world from reading the tape
and to prevent accicental overwrites.

-- 
Pim Zandbergen                      domain : pim@cti-software.nl
CTI Software BV                     uucp   : uunet!mcsun!sun4nl!ctisbv!pim
Laan Copes van Cattenburch 70       phone  : +31 70 3542302
2585 GD The Hague, The Netherlands  fax    : +31 70 3512837
From: donn@dellunix.dell.com (Donn Baumgartner)
Newsgroups: comp.unix.sysv386
Subject: Re: SCO UNIX: UUCP via TCP/IP
Date: 3 Apr 92 06:30:35 GMT
Organization: DELL Computer --UNIX Software Development Group-- Austin, Texas


In article <1992Apr2.120351.6816@news.rn.com>, larry@news.rn.com (Larry Snyder) writes:
> pete@wvus.org (Pete Gregory - UNIX SA) writes:
> 
> >Hi - SCO ODT 1.1 here...
> 
> >I recall a thread about eight (?) months ago regarding SCO's lack of
> >UUCP support over TCP/IP.  Today I have a more intense interest in getting
> >this running, and wonder if anyone has done this successfully with or
> >without support from SCO.
> 
> we aren't running SCO :) - but Dell SVR4 -- and we do UUCP over TCP
> connections with several sites -- including Sparcstations and 386 machines
> running ISC.
> 
> -- 
>  =*= Larry Snyder, Public Access Unix Site - 219-289-0777 - 10 lines =*=
>       internet: larry@gator.rn.com        uucp: uunet!trauma!larry

Well, again though not what you ask for... I might add that the freely
available C-Kermit program supports connections over tcp/ip (and this program
runs on more computers that you can believe :-).
							- Donn
Newsgroups: comp.unix.sysv386
From: rick@digibd.com (Rick Richardson)
Subject: Dell kernel memory corruption
Organization: DigiBoard Incorporated, Eden Prairie, MN
Date: Sat, 11 Apr 1992 23:46:39 GMT


I've noticed a corruption a of kernel data structure on Dell SVR4.
This is on a stock system with no additional device drivers.

Specifically, the value stored in linesw[0].l_open is getting corrupted.
I've checked this by looking at the value just after all of the device
driver XXXinit() routines are called, and then again after the system is
booted multiuser.

Just after the init routines are called, the value (for my system)
is 0xd007034c (ttopen+0), which is correct.  However, after coming up
multiuser, the value is 0xd0070050 (ttywait+64).  This corrupted
value is very lucky, in that if you add device drivers that use
the linesw[], they will just hang, rather than cause a kernel panic.

-Rick
-- 
Rick Richardson		Email: rick@digibd.com	Burned: ice still in lake, boat
Senior MTS		Fax:   (612) 943-0803	not.  Maybe next week.  Water
DigiBoard, Inc.		Tel:   (612) 943-5383	already up to the boathouse;
Eden Prairie, MN	Radio: N0NMY		hope we don't have a wet spring!
Newsgroups: comp.unix.sysv386
From: comeau@ditka.Chicago.COM (Greg Comeau)
Subject: Re: Interactive and the 486
Keywords: Interactive 486 DX SX EISA ISA
Reply-To: comeau@csanta.attmail.com (Greg Comeau)
Organization: Comeau Computing
Date: Thu, 9 Apr 1992 03:50:14 GMT

In article <1992Apr3.162727.5073@cs.wayne.edu> pbh@jake.cc.wayne.edu (Patrick Haggood) writes:
>Any C++ or COOL users out there?  If you
>ported these yourself, any outstanding headaches?

I know there are people using our stuff with COOL and they have
not registered any problems with us.

- Greg
-- 
	 Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
                   Producers of Comeau C++ 3.0 With Templates
          Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
            Voice:718-945-0009 / Fax:718-441-2310 / Prodigy: tshp50a
Xref: sparky comp.unix.sysv386:8212 comp.unix.questions:5882
From: dmunday@miavx1.acs.muohio.edu
Newsgroups: comp.unix.sysv386,comp.unix.questions
Subject: can't rewrite terminal control entry ???
Date: 6 Apr 92 05:28:23 GMT
Organization: Miami University Academic Computer Service"

I tried logging into our box running SCO Unix SV 3.2 via both dial up
lines tonight, and got the message:
 
Can't rewrite terminal control entry for ttyi1O
Authentification error; see Account administrator
 
I'm the account administrator!
I got this error on both ttyi1O and tty2a.
I got it when logging in as root or as munday.
 
Yikes!  What's wrong here and how do I fix it?
 
-------------------------------------------------------------------------
Dave Munday           | Bitnet    : dmunday@miavx1      Phone: 321-5145
Munday Computing, Inc.| INTERNET  : dmunday@miavx1.acs.muohio.edu
Miami University, Ohio| or        : munday@cinnet.com
                      | USmail    : P.O. Box 695, Oxford, OH 45056-0695
"Renting airplanes is like renting sex:  It's difficult to arrange on short 
notice on Saturday, the fun things always cost more, and someone's always 
looking at their watch."  - Ron Wanttaja
From: john@jwt.UUCP (John Temples)
Newsgroups: comp.unix.sysv386
Subject: Re: Terrible timing constraints in Device Drivers! Arrgh.
Date: 11 Apr 92 20:01:03 GMT
Organization: Private system -- Orlando, FL

In article <1992Apr8.013728.11864@gantz.bowlgreen.oh.us> gantzm@gantz.bowlgreen.oh.us (Michael L. Gantz) writes:
>The driver just sits there watching
>CLOCK change for 0 to 1 and back until it has collected the correct
>number of samples.  Now if I want to collect say 70000 samples at 7Khz
>that is ten seconds.  The problem is that the system effectively stops
>because of these darn dead spins since the only thing running for 10
>seconds is the device driver, remember I'm stuck in a while loop!

It sounds like you're also stuck with poorly designed hardware.  It was
probably built with DOS in mind, where sitting in a busy loop for 10
seconds (or 10 minutes) is just fine.

Probably the only way that you can do A/D conversion "right" with UNIX
is if the board uses DMA.  I.e., you tell the board "do 70000 samples
and DMA the results to this buffer," and it gives you an interrupt when
it's done.  The other approach that comes to mind would be having the
board generate an interrupt for each sample, but that's probably going
to incur a lot more overhead than the DMA approach.  Neither of these
approaches does you any good, though, unless the hardware supports
them.
-- 
John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
From: mark@jpl-devvax.jpl.nasa.gov (Mark R. Rubin)
Newsgroups: comp.unix.sysv386
Subject: Re: Problem with 600foot tapes
Date: 17 Apr 92 19:29:36 GMT
Organization: Jet Propulsion Laboratory (NASA)

o In article <1992Apr17.041701.7429@i88.isc.com> mikebe@i88.isc.com
  (Michael G. Beirne) writes:

  > It doesn't matter now as the Archive formats on writes. Either dump
  > the tapes or give them to someone with an HP workstation and a HP
  > Cartridge tape drive.


o My (two years ago) experience with HP tapes/drives is that once the
  tapes are written to on a non-HP drive, they are ruined for HP use.

o As has been discussed, HP tapes have some sort of factory-installed
  formatting on them.  Once it is wiped out, HP drives can't handle
  them.  The tapes cost twice what similar capacity, non-HP, tapes go
  for, and HP drives are unable to re-format the tapes (or HP is
  unwilling to provide firmware/software to allow them to do so).



MARK
mark@jpl-devvax.jpl.nasa.gov
Newsgroups: comp.unix.sysv386
Subject: Re: Drivers for DAK CD rom under ISC Unix ?
From: andyb@wndrsvr.la.ca.us (Andy Brager)
Date: Tue, 7 Apr 1992 22:14:14 GMT
Organization: Wonder Server - Public Access for SoCal
Keywords: DAk CD ROM ISC 2.0 Unix

larry@news.rn.com (Larry Snyder) writes:

>ahh - what we need now is for one of us to bite the bullet
>and buy a CD-ROM and let the rest of us know how it works :)

I *have* a CD-ROM (Sony).  Of course I've also got ISC 3.0.  However, I
haven't attempted to install the CD-ROM (I don't have any CD's and
I've had so many damn hardware problems I didn't want to introduce
extra uncertainty - new mamaboard on the way...yeehah! )

So, sometime after I redo my filesystems, install the new mamaboard,
get the AST Fourport board up and running -which requires building a 
cable, among other things- and have a CD drop into my lap :) I'll 
install it.  Well, maybe sooner.

Andy
-- 
		DO NOT BUY TOUCHE COMPUTERS -email for details
Large Packages (2K+ Total): cerritos.edu!swc!wndrsvr!andyb
Did you know that VAX mailers strip trailing blanks?  Don't use uuencode.
-I don't know but I been told; two sides to every story - Joe Walsh
Newsgroups: comp.unix.sysv386
From: john@jwt.UUCP (John Temples)
Subject: Re: Writing/reading 386 I/O ports
Organization: Private system -- Orlando, FL
Date: Sun, 12 Apr 1992 19:41:27 GMT

In article <3243@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes:
>I have an pc board project that I need to access via the I/O port.

This should probably be a FAQ since it comes up so often.  Dick?

There are three solutions that I know of:

1.  Write a device driver for the board.

2.  Use the sysi86(SI86V86, V86SC_IOPL, PS_IOPL) call to get I/O
privilege so you can do ins and outs.  This call requires root
permissions, though.

3.  Write a device driver that grants I/O privilege.  I've done this;
it only requires one line of code: u.u_ar0[EFL] |= PS_IOPL.  This lets
you control access to I/O privilege through file system permissions
rather than unconditionally requiring root permissions.
-- 
John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
From: dylan@ibmpcug.co.uk (Matthew Farwell)
Newsgroups: comp.unix.sysv386
Subject: Re: PANIC: Can't switch to supervisor mode
Date: 9 Apr 92 13:24:47 GMT
Organization: The IBM PC User Group, UK.

In article <1992Apr3.175908.3425@engage.pko.dec.com> balson@3d.enet.dec.com jim Balson writes:
>In article <2454@ucl-cs.uucp>, D.Golds@cs.ucl.ac.uk (David Golds) writes...
>>A friend of mine is suddenly having a problem with a clone 'MESH' ISA 486/33
>>(of dubious quality) running standard (?) AT&T SVR4 from USL. I think the
>>motherboard might be by ETEQ but that's a guess.
>> 
>>The machine had been working fine for a couple of months, but recently it
>>failed to boot UNIX and has failed to do so ever since. The kernel starts to
>>load, they get a message abot the Tape driver being OK, then they get a
>>message like:
>> 
>>	PANIC: Can't switch to supervisor mode
>> 
>>(This is from memory and I don't think the wording is exact, but it's
>> certainly close and certainly something to do with supervisor mode...)
>> 
>>The machine then tries to dump pages (whatever that may mean - pardon my
>>ignorance) and sometimes succeeds and then halts. Other times it really gets
>>it's knickers in a twist and gives a DOUBLE PANIC that it couldn't dump the
>>pages.
>> 
>>We put the hard disk with UNIX into another PC (a 386/40 of even more
>>dubious quality) and it works fine there.
>> 
>>I've been reading this BB for a while now, but haven't seen this problem
>>mentioned. Can anyone help? If you can, I'll vote for you :->
>
>	This sounds like the 486 can't put itself into protected mode to me.
>I beleive, without having a specs in front of me, that initially the 386/486 
>will boot up in 'real' mode. Going into protected mode only after doing some
>initial setup (GDT/IDT etc.) Sounds like it could be a problem going from
>the initial real mode into protected mode.
>
>	If you have another mother board available, try swapping 486 chips
>and see if the 486 chip from the 'bad' mother board can boot unix in another
>working motherboard. if it can't, then you have it. If it can...then it's
>something else, but at least you narrowed it down a bit. Make sure both mother
>boards are of the same MHZ. I think it could cause problems sticking a 25 MHZ
>chip in a 33 MHZ board. I think.

You shouldn't start swapping chips on a motherboard (esp the CPU) unless
you know *exactly* what you're doing.  If you don't know the answer to
the above question (which I don't) then you shouldn't be mucking about
with your motherboard like you're suggesting.

Dylan.
-- 
'If there is a hung parliament, and John Major and Neil Kinnock have
both been hung, then I am willing to take over.  Vote Insanity - you
know it makes sense' - Screaming Lord Sutch
Newsgroups: comp.unix.sysv386
From: eric@ms.uky.edu (Eric H. Herrin II)
Subject: Disk size (number of cylinders) limitation on SVR4?
Keywords: big gig drives
Date: Sun, 12 Apr 1992 02:58:12 GMT
Organization: University Of Kentucky, Dept. of Math Sciences
X-Bytes: 

We just obtained a very large (1.25 gig) ESDI drive with the following 
characteristics: 83 sectors/track, 15 heads, 2100 cylinders.  When the
Ultrastor 12F-24 does it's sector mapping, the drive becomes:
	63 sector/track, 16 heads, 2591 cylinders
Our version of AT&T SVR4.0 (straight from source) doesn't like anything above 
2048 cylinders; the hard disk driver complains about "can't find block -X on 
drive 0" or "HD: interrupt with no request queued" and then the installation 
dies.

Does anyone know of any version of SVR4.0 that supports this drive (Micropolis
1518-15)?  It currently works, but I lose about 300 meg of space.  Any 
suggestions about where to look for the limitation in the sources?



-- 
--
|  	Eric H. Herrin II - {rutgers,uunet}!ukma!eric, eric@ms.uky.edu	     |
|			  University of Kentucky			     |
From: ogden@lamar.ColoState.EDU (Fred Ogden)
Newsgroups: comp.unix.sysv386
Subject: Re: Installing TCP/IP on ISC3.0.
Summary: GOT IT!
Keywords: ISC TCP/IP v.3.0
Date: 13 Apr 92 23:00:36 GMT
Article-I.D.: yuma.1992Apr13.230036.19980
Organization: Colorado State University, Fort Collins, CO  80523

Thanks everyone for your offerings regarding my IRQ problem with ISC 3.0 
TCP/IP.  I solved my problem by re-configuring wd0 for IRQ 5 and re-building
the kernel.

By the way, new users.  When you build a new kernel in ISC 3.0 you must
also install it.  DO NOT assume that because you built a new new one that it
automatically becomes the active one.  It doesn't.

***********************************************************************
Fred L. Ogden
Engineering Research Center
Colorado State University
Fort Collins, CO 80523
ogden@lamar.colostate.edu
***********************************************************************
Newsgroups: comp.unix.sysv386
From: cpcahil@virtech.uucp (Conor P. Cahill)
Subject: Re: BIG disk
Organization: Virtual Technologies Inc.
Distribution: na
Date: Sun, 12 Apr 92 13:14:42 GMT

gws@n8emr.uucp (Gary Sanders) writes:

>Has anyone used a big > 1gb disk on ISC 2.2. I know there is a 1gb
>limitation, but can I use a larger disk but not user the upper
>disk area.  I am working on getting the upgrade, but untill
>I do would like to make use of the disk.

ISC has a fixdisk available for the HPDD on 2.2 which will fix the problem
with the adaptec controller. 

NOTE that ISC only has the problem with >1GB on SCSI drives using the 
adaptec controller (or look-alikes).  I don't believe the problem exists
with the future domain controller, although you give up quite a bit 
of performance using the future domain over the adaptec.

-- 
I guess these are the views of VTI - since it is my consulting company.

Conor P. Cahill              (703)430-9247              uunet!virtech!cpcahil 
Virtual Technologies, Inc.  46030 Manekin Plaza            Sterling, VA 22170
From: merlin@neuro.usc.edu (merlin)
Newsgroups: comp.unix.sysv386
Subject: Re: SpeedUp Sources and Patches on export.lcs.mit.edu
Date: 7 Apr 1992 02:05:45 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: neuro.usc.edu

In article <ku109jINNpgm@syrian.cs.utexas.edu> glenn@cs.utexas.edu (Glenn G. Lai) writes:
>Maybe it is, maybe it isn't.  If a person chooses to go against my wish, I'll
>NOT do anything about it, but I hope that he/she will at least show the courtesy
>of respecting it.

o  I think all of us who use X386 owe Glenn an enormous debt of gratitude.

o  Glenn really asks for what an author truly deserves -- respect for his work.

o  Someday perhaps more academic software writers and consumers will follow
   Glenn's course of action rather -- a request for respect for authorship.
Xref: sparky comp.unix.sysv386:8690 comp.unix.questions:6229 comp.terminals:658
From: chris@alderan.sdata.de (Christoph Splittgerber)
Newsgroups: comp.unix.sysv386,comp.unix.questions,comp.terminals
Subject: Looking for TATUNG VT-4100 term(info/cap)
Keywords: terminal, TATUNG, VT-4100, terminfo, termcap
Date: 15 Apr 92 18:14:58 GMT
Followup-To: poster
Organization: C. Splittgerber Datentechnik, Denkendorf, Germany

The subject sais it all, I'm looking for a terminfo description for
the TATUNG VT-4100 terminal.

A termcap entry would also help, (I can convert it to terminfo).

Thanks very much in advance,
                             Chris

PS: Redirected followup to email, because I can't read these newsgroups.
-- 
*** Perfection is archived only at the point of collapse. - C.N.Parkinson **
----------------------------------------------------------------------------
Replies-To:  chris@alderan.sdata.de    UUCP: uunet!mcsun!unido!alderan!chris 
Phone:       +49 711 344375            Fax:  +49 711 3460684
From: ebert@esfra.sub.org (Christian Ebert)
Newsgroups: comp.unix.sysv386
Subject: Re: SCO/NFS reliability?
Date: 8 Apr 92 19:47:40 GMT
Organization: Ebert & Stegemann GmbH; Frankfurt/Main

In <1992Apr3.200719.2260@tse.uucp> markt@tse.uucp (Mark Turner) writes:


>Hi folks ... can anyone comment on the reliablity of using an SCO NFS 
>filesystem between two networked SCO/ODT 1.0 systems? My workstation has a 
>large hard disk but no tape backup ... the other system has a tape backup but
>not much available disk space. The ideal (make that cheapest) solution 
>seems to be for me to allow the other workstation to mount an NFS partition
>from my workstation. This means that the backup software on the machine
>equipped with a tape drive can operate as it always does, but the files will
>be physically stored on my hard disk. The only hitch is that I quite often 
>reboot my machine, and the other workstation seems to slow down considerably 
>when this happens. I'm assuming that this is a result of the "hard" vs "soft" 
>mount choices that I've made. (I've choosen a hard mount.) Any comments would 
>be appreciated.

I think, the "hard" mount is really the problem. Try the soft mount.
But based on our experience, the soft mount doesn't work well on
SCO ODT 1.0. You should update to 1.1. Then it will run without any 
problem.


Best regards

Christian
-- 
----------- beware of programmers who carry screwdrivers -------------
| Christian Ebert                |  ebert@esfra.sub.org              |
| Staedelstrasse 8               |  100016.633@compuserve.com        |
| D-6000 Frankfurt 70 / Germany  |  +49 (69) 61 90 47                |
From: kdorota@kruuna.hut.fi (Krzysztof Dorota)
Newsgroups: comp.unix.sysv386
Subject: Need Berkeley lpr for SVR3.1.
Date: 6 Apr 92 20:24:31 GMT
Distribution: comp
Organization: Helsinki University of Technology, Finland


Hello all,
 
My apologies if the following is trivial for most of You 
(I visit this group very rarely):

We are looking for Berkeley lpr/lpd port to AT&T SVR3.1.
The target machine is Unisys 6000/50  (386).
In fact we need only a client part of that stuff (lpr, lpq, lprm).
Both, commercial and free software we are interested in.

Any help would be greatly appreciated.

Krzysztof

*------------------------------------------------------------------------*
! Krzysztof DOROTA, Helsinki University of Technology,  Administration   !
! Office, Information Systems,       Otakaari 1, SF-02150 Espoo Finland  !
! Voice: + 358 0 4512012,  Fax: + 358 0 465077,  E-mail: kdorota@hut.fi  !
*------------------------------------------------------------------------*

--

*------------------------------------------------------------------------*
! Krzysztof DOROTA, Helsinki University of Technology,  Administration   !
! Office, Information Systems,       Otakaari 1, SF-02150 Espoo Finland  !
! Voice: + 358 0 4512012,  Fax: + 358 0 464788,  E-mail: kdorota@hut.fi  !
*------------------------------------------------------------------------*