HDTenEightyP/NetNews huggingface dataset:
From: bill@Celestial.COM (Bill Campbell)
Subject: Re: hardware head-scratcher
Organization: Celestial Software, Mercer Island, WA
Date: Thu, 28 Jan 1993 18:24:34 GMT

In <9301271106.aa03897@alvarez.alvarez.COM> /dev/null <alexl@alvarez.COM> writes:

:.>      Here's a wierd one for everyone to puzzle over:
:.>      My system has two parallel ports.
:.>      Under SCO Xenix 2.3.3 they were lp0 and lp2.
:.>      Under SCO Unix 3.2.4 they are lp0 and lp1.
:.>      No switches were changed.
:.>      Why? Why? Why?

Just another example of the idiotic PC architecture.  The first
parallel port on Xenix depends on whether it's on a separate
board or on a video board.

:On SCO 3.2.4 The parallel ports are numbered in the order they 
:are found. 

This makes it a bit easier to connect.  Many times I've had to
cat a file to /dev/lp0 or /dev/lp1 to figure out which was the
working device on Xenix systems.

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?
Newsgroups: biz.sco.general
From: davidf@golem.waterloo.on.ca (David J. Fiander)
Subject: Re: MMDF list-processor
Date: Thu, 28 Jan 1993 01:10:19 GMT

According to jonr@bigsky.dillon.mt.us (Jon Robinson):
>I've set up some lists using MMDF under SCO UNIX 3.2.2.  All works
>fine except that when the list redistributes the message to the other
>people in the list, and the people then respond, the message goes to
>the individual who originally sent the message rather that being sent
>to the list.  Basically, I'm looking for a way to have the message
>headers automatically include the line
>Reply-To: listname@bigsky.dillon.mt.us

This is actually more of a mail-reader problem than a
list-processor problem.  When a user sends a message to the
mailing list, the headers look like

	From: Joe Bob <joe@widget.com>
	To: The Frizbee User Community <frizbee@gateway.org>

and this is exactly what they look like when a reader of the
list gets his copy.  Mailx (and most other readers) have two
ways to reply to a message: the "individual" reply, and the
"group" reply.  If somebody replies to a message using the
individual reply, then the response will only go to the
originator of the message (ie. Joe Bob).  If she uses the group
reply, then the message will be "to" the originator, and "cc"ed
to the mailing list address.

In mailx the "r" command defaults to the individual reply, and
the "R" command defaults to the group reply; MH defaults to
group reply, use "-nocc all" for an individual reply; Elm uses
the "r" command for individual replies and the "g" command for
group replies (I think).

Changing the headers in the way you have proposed is generally
considered anti-social.  One reason is that mailx doesn't
understand reply-to headers, so it wouldn't work for those
users, and another is that it becomes impossible to reply to
just the originator of the message on systems that do honour
the reply-to header.

- David
Newsgroups: biz.sco.general
From: Ed Cooley <edc@openage.com>
Subject: UUNET sales phone number
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Tue, 26 Jan 1993 17:43:34 GMT
Precedence: bulk

Does anyone have UUNET's sales phone number?

--------------------------------------------------------------------------------
Ed Cooley           12209 Bayswater Road    "An independent service and
Technical Manager   Gaithersburg, MD 20878   support provider for SCO
Open Age, Inc.      Main: 301/948-6422       products."
edc@openage.com     Fax:  301/948-9644

Newsgroups: biz.sco.general
From: Wes Chalfant <wes@kofax.com>
Subject: what to do with lost+found entries
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Thu, 21 Jan 1993 18:11:56 GMT
Precedence: bulk

Anthony P Lawrence <world.std.com!apl@uunet.UUCP> wrote:
> lee@dlpco.dlpco.COM (Lee Penn) writes:
> : On my wish list is also the ability to easily figure out what 
> : file might be corrupt when I get a bad block message from the OS. 

> I, too, have wanted such a utility.  Thinking about it, it doesn't
> (conceptually) look like it would be all that hard to do.

	It's a little tricky -- you have to walk through the inodes
looking at which blocks are allocated to which files, and then
translate the inode number to a file name (or start by walking through
the directories to get the inode numbers in the first place; in that
case you might seach some block lists twice, but that isn't a huge
effect).

> If nobody *has* done this, I'm going to take a whack at it next
> weekend (and probably will find that it's 80 times more work than I thought,
> as usual).

	A program to do this was written many, many, many years ago.
Before fsck, there were a handful of programs that could be used to
diagnose and fix file system problems such as these.  The memory grows
dim, the but I think the V7 program to translate block numbers to
inode numbers was "bcheck" (it *might* have been "dcheck").  Since the
SCO file system is still very close to the V7 file system (no flames,
please, the filesystem structure has changed little), perhaps someone
at SCO can dust off some old V7 tapes and find and update bcheck.
(For what it's worth, the original FileNet OS was based on V7 with
many extensions -- bcheck was used frequently in the early days as
some of the disk controllers they used were just a little unreliable).

	By the way, the program that translated inode numbers to
pathnames that originated at the same time is still distributed with
SCO UNIX -- it's called "ncheck".  In answer to some other questions
in this thread, the easiest way to generate a complete list of inode
numbers vs. pathnames for all mounted filesystems is to simply run
"/etc/ncheck". 

---------
Wes Chalfant    Kofax Image Products, Inc.    wes@kofax.com
From: fietze@kagcpd01.ag01.kodak.COM (Roman Fietze@kagcpd01.ag01.kodak.COM,KAG CP Development@kagcpd01.ag01.kodak.COM, 49 711 406 2839)
Newsgroups: biz.sco.general
Subject: Re: PC Unix/Xenix vendors
Date: 24 Jan 93 14:54:22 GMT
Reply-To: fietze@kagcpd01.ag01.kodak.COM
Organization: Kodak AG, Office Imaging, Product Engineering and Development
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Return-Receipt-To: fietze@kagcpd01.ag01.kodak.COM
Precedence: bulk

Hello Steve,

>  I'm not sure why I would want x11r5.  SCO gives us x11r4, and we've got
> x11r4 on our DEC's.  Both of them seem to work nicely.
> 
>  If someone could explain why x11r5 is better than x11r4 I'd appreciate it.

We too have X11R4 on more than one machine (HP, DEC, XVision) and most
of the clients we have only need Revision 4, but in bigger nets there
is at least one advantage (alltough we are stisfied with what we
have): with X11R5's font management you can save a lot of disk space.
I am sure that there are more interresting features, but I am not sure
if you really need them (login server, extensions to X).

There might be one advantage over X11R4, but maybe somebody else
should make a statement here: the speed. There was a big improvement
going from X11R3 to X11R4, maybe there is one going to X11R5 as well.

Roman

---------------------------------------------------------------------
Roman Fietze (Mail Code 2201)              Kodak AG Stuttgart/Germany
fietze@kagcpd01.ag01.kodak.COM                       fietze@kodak.COM
Newsgroups: biz.sco.general
From: kgermann@zeos.com (Ken Germann)
Subject: Re: USR DualStandard on 3.2.4
Organization: Zeos International, Ltd
Date: Tue, 26 Jan 1993 06:32:27 GMT

In article <1993Jan26.063027.8079@zeos.com> kgermann@zeos.com (Ken Germann) writes:
>In article <9301251329.aa05320@necis.necis.ma.nec.com> Dick Everhart <necis!dicke@transfer.stratus.com> writes:
>>
>>I concede!  I have to ask for help.
>>
>>I have been trying to get my USR HST Dual Standard modem to work for 2400 and
>>higher xbbs and uucp users.  Needless to say, I haven't succeeded.
>>
>>Using a standard 2400 baud Hayes configuration works fine.  I tried Mr.
>>Deignan's configuration for his 16.8k baud modem he recently posted, and the
>>users get garbage.  I'm not surprised.  I've also tried a couple of other
>>configurations, and again, the callers get garbage.
>>
>>I have to think that someone else out there is using one of these.  If you are,
>>I would appreciate knowing what your gettydef and Dialer entries look like.
>>
>>Thanks in advance,
>
>
>Need to port lock the DTE Interface speed to 38400 by doing an 
>&B1 when the modem is connectd to a DOS PC with the Baud Rate set
>at 38400. This is straight from USR.
>
>
You should also be using a getty that isn't chaining to another
lower speed. i.e.

bbs # B38400  HUPCL # B38400  CS8 SANE HUPCL -IXOFF -IXON -CLOCAL RTSFLOW CTSFLOW -IXANY #\r\nEnter 'cocotext' to enter the text side of ZEOS Online.\r\n\r\n@!login: # bbs
-- 
Ken Germann              ZZZZ EEEE  OO   SSSS   ZEOS International, Ltd.  
support@zeos.com   INET     Z E    O  O S       Technical Support Dept.
uunet!zeos!support UUCP    Z  EE   O  O  SSS    1301 Industrial Blvd. N.E.
Any opinions expressed    Z   E    O  O     S   Minneapolis, MN 55413
herein are my own!       ZZZZ EEEE  OO  SSSS    FAX         612-633-4607
From: jonr@bigsky.dillon.mt.us (Jon Robinson)
Newsgroups: biz.sco.general
Subject: MMDF list-processor
Date: 26 Jan 93 23:08:02 GMT
Organization: Big Sky Telegraph
X-Newsreader: TIN [version 1.1 PL6]

SCO'ers

I've set up some lists using MMDF under SCO UNIX 3.2.2.  All works
fine except that when the list redistributes the message to the other
people in the list, and the people then respond, the message goes to
the individual who originally sent the message rather that being sent
to the list.  Basically, I'm looking for a way to have the message
headers automatically include the line
Reply-To: listname@bigsky.dillon.mt.us

So, anyone have any ideas?

Thanks
-Jon
-- 
Jon Robinson @ Big Sky Telegraph, Western Montana College of the UM
INTERNET: jonr@bigsky.dillon.mt.us / VOICE:406-6837870 / FAX:406-6837493
"Sometimes yes, sometimes no.  The staff usually forgets." - Fletch
From: gillett@rice-chex.ai.mit.edu (Walter E. Gillett)
Newsgroups: biz.sco.general
Subject: Re: HELP: Adaptec 1542b-connected SCSI periodically hangs for 2 minutes!
Keywords: Adaptec 1542 disk locks
Date: 23 Jan 93 02:30:54 GMT
Organization: MIT Artificial Intelligence Lab
NNTP-Posting-Host: rice-chex.ai.mit.edu

In article <96@shady.UUCP> kevin@shady.UUCP (Kevin Smith) writes:
>In article <1419@proa.es> alberto@proa.es (Alberto Poblacion) writes:
>:>In article <1j6rqaINN65i@life.ai.mit.edu> gillett@rice-chex.ai.mit.edu (Walter E. Gillett) writes:
>:>>Hi, Folks
>:>>    I'm using SCO ODT 2.0 (i.e. SCO Unix SysV 3.2.4.0) with a 1542b and a
>:>>Toshiba 876MB (formatted) SCSI drive.  This usually works just fine.  But
>:>>every now and then when under heavy load (usually paging) the disk will
>:>>just lock up for about two minutes.  During this time I can here the disk
>:>>step one track every two seconds or so.  After the two minutes are up things
>:>>usually continue normally.
>:>
>:>     The same thing happens to me under SCO UNIX 3.2.2. I have upgraded
>
>My guess would be that the drive is doing some kind of reset/error
>recovery.  Everything else stops because all disk IO has stopped.

Well I've found out a LITTLE bit more since I posted my original query.  I
called up Toshiba and they told me that if the disk light is on then the drive
is just doing what it's told.  So I checked.  Not only is the disk light on
full-blast during this time but so is the Adaptec's activity light.  So I
think that whatever is going wrong is happening in the OS as opposed to the
drive or controller.  Also, sar -d generally hangs 'til the system
unsticks itself but when the system starts going again sar -d spits out all
the timestamped readings during the hung period.  This leads me to believe
that while xterm was stuck and thus unable to print sar's output, sar was
still running.  The numbers sar spit out said that the disk was:

16:55:51 Sdsk-0    96.69      1.00     53.97    863.58      0.00     17.91

(p.s. this seems kinda slow to me for a disk/controller combo that supposedly
      can do 1MB/s)
					      -Joe
---------------------------------------------------------------
Joe Shapiro (NOT Walter Gillett, though I'm using his account!)
Please send replies to:                        joe@ConSolve.com
From: fr@compu.com (Fred Rump from home)
Newsgroups: biz.sco.general
Subject: Re: SCO UNIX AND HD'S
Date: 23 Jan 93 15:23:42 GMT
Organization: CompuData Inc.

ron.brandt@satalink.com (Ron Brandt)  writes:

>Were about to install SCO UNIX on a new clone 486DX-33 with 4 megs of
>Ram and a 500 Meg Fujitsu SCSI hard drive and ALLWAYS IN-2000 controller
>card along with a 4 port Digiboard. Does anyone have any thoughts on
>this setup ie: Does SCO work ok with SCSI??

SCO works fine with scsi. I would get a little more memory though. It's cheap 
and makes life easier with swapping. On the other hand with a 4 port system 
you probably should have picked Xenix.

Fred
-- 
W. Fred Rump 	office:	   fred@COMPU.COM     "A man's library is a sort of 
26 Warren St.   home: fr@icdi10.compu.com 	harem" - Emerson (1860) 
Beverly, NJ. 08010                          		 
609-386-6846    bang:uunet!cdin-1!icdi10!fr
From: paul@openage.com (Paul A. Fischer, Sr UNIX Sys Consultant)
Newsgroups: biz.sco.general
Subject: Adaptec 1542 disk locks
Keywords: adaptec 1542
Date: 25 Jan 93 02:20:16 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

>After several recent posting regarding systems using Adaptec 1542B with
>various SCSI Hard Drives.  Several of us were reporting situations where
>during high activity it would pause for anywhere between seconds to in
>one case several minutes.  In our case, it is more like 15 seconds of the
>HD light on constant with no activity.

>A recent posting asked questions about the size of various paramteres so:
>NBUF: determined at startup   (w/16mb)   1024 i/o bufs
>NHBUF: 512  hash buffers
>SCO Xenix 386  v2.3.4

Well NHBUF is supposed to be 25% of NBUF, rounded up to the nearest power of 
two.  I know if NBUF is large, and NHBUF is set too low you can have the 
problems described, but I'm not sure what happens when it's too high.

BTW NBUF should be 10% of RAM.

Try lowering NHBUF to 256, and let me know what happens.

--------------------------------------------------------------------------------
Independent SCO support and service provider in the D.C. metro area.
Insert clever saying here...
Paul A. Fischer           | Open Age Inc.  | paul@openage.com
Sr. UNIX Sys. Consultant  | (301) 948-6422 | (301) 948-9644 Fax
From: paul@openage.com (Paul A. Fischer, Sr UNIX Sys Consultant)
Newsgroups: biz.sco.general
Subject: RE: SCO UNIX AND HD'S
Date: 23 Jan 93 22:22:48 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: scogen@xenitec.on.ca
Precedence: bulk

>Ram and a 500 Meg Fujitsu SCSI hard drive and ALLWAYS IN-2000 controller
>card along with a 4 port Digiboard. Does anyone have any thoughts on
>this setup ie: Does SCO work ok with SCSI??

>Any help/advice would be greatly appreciated..

Your RAM is a little anemic, and The only SCO drivers for the Always come from 
Always, so you better get them first.

I've been up and running 18 months on SCSI SCO.
--------------------------------------------------------------------------------
Independent SCO support and service provider in the D.C. metro area.
Insert clever saying here...
Paul A. Fischer           | Open Age Inc.  | paul@openage.com
Sr. UNIX Sys. Consultant  | (301) 948-6422 | (301) 948-9644 Fax
Newsgroups: biz.sco.general
From: fr@compu.com (Fred Rump from home)
Subject: Re: PC Unix/Xenix vendors
Organization: CompuData Inc.
Date: Thu, 21 Jan 1993 05:37:28 GMT

infmx!ten_forward!aland@uunet.UU.NET (Alan Denney) writes:

>So, in other words, SCO is *always* THE correct solution, and any other
>choice must necessarily reflect ignorance on the part of the customer or
>competition?
>Sheesh.


No, any other choice is best left to the competition.  We live in market where
free choice predominates.  I don't believe all potential DBMS users must buy
Informix or even must think it's *always* the best product in the market.
Correct?

There are reason why you and your company push what it knows best.  There are
similar reasons why my comapany pushes what it knows best.

Is that too difficult to understand?

Perhaps I ask a Progress person for an answer or are all DBMS systems
the same?  Many people choose not to buy your product.  Does that make them
stupid or ignorant?  In the same sense vendors choose to specialize in one or
the other DBMS package and sell and service nothing but.  Does "that" make
them ignorant?

Fred
-- 
W. Fred Rump 	office:	   fred@COMPU.COM     "A man's library is a sort of 
26 Warren St.   home: fr@icdi10.compu.com 	harem" - Emerson (1860) 
Beverly, NJ. 08010                          		 
609-386-6846    bang:uunet!cdin-1!icdi10!fr   
Newsgroups: biz.sco.general
From: sl@wimsey.bc.ca (Stuart Lynne)
Subject: Re: gcc 2.3.2 on SCO 3.2.4 (__STDC__)
Organization: Wimsey Information Services
Date: Sat, 23 Jan 1993 02:29:00 GMT

In article <DRG.93Jan22093904@candidus.ma30.bull.com> drg@candidus.ma30.bull.com (Daniel R. Guilderson) writes:
>In article <9301212346.AA04169@jpradley.jpr.com> jpr@jpradley.jpr.com (Jean-Pierre Radley) writes:
>
>   > The solution is to get gcc 2.3.3 which eliminates the problem.
>
>   Oh? Really? Not here it didn't. I posted my patches the other day.
>
>All the patches I have seen come by here (maybe I missed yours) have
>defined __STDC__ to be 0.  That is definitely wrong.  __STDC__ should
>be defined as 1 for gcc.  Defining it as 1 causes problems in the SCO
>header files but there is a script called fixincludes (or fixinc.sco)
>which should fix the header files.

Opinion varies. Some of use don't want our include files mucked up
(some would say they are already mucked up enough). So we just
set __STDC__=0. That does work well. I have very little problem
getting things to compile under SCO with this.

Saying it is wrong, is well... definitely wrong. 

It's not an issue that has a black and white answer. In my opinion
using a GCC compiler that emulates the SCO compiler is what I want.
I get to complain to SCO about their header files when they don't
work properly.

If you want a GCC compiler that doesn't then fine. Go for it. But 
don't complain to SCO and ask for support for the munged header files.

-- 
Stuart Lynne <sl@wimsey.com> ......................... UNIX Facsimile Software
Wimsey Information Technologies ................... moderator biz.sco.binaries
uucp login:nuucp passwd:nuucp .................... ftp.wimsey.com:~ftp/ls-lR.Z
PD Software for SCO UNIX .................... ftp.wimsey.com:~ftp/pub/wimseypd
Xref: sparky biz.sco.general:5652 comp.sys.dec:7133
From: tps@jptcs.COM (Tim Sailer)
Newsgroups: biz.sco.general,comp.sys.dec
Subject: Big Drives
Date: 27 Jan 93 16:32:11 GMT
Followup-To: biz.sco.general
Organization: JPT Computer Solutions
X-Newsreader: TIN [version 1.1 PL6]

I have a client that has ODT 1.1 running on a networked 386-33 with
an Adaptec 1542B SCSI controller. They are going to port our huge
application and data to a DECStation 5000 soon, but need to put another
large core drive online first. What is the largest SCSI drive that can
be hung on the SCO box, and will the same size drive work with the DEC?

Thanks,
Tim



-- 
Tim Sailer
JPT Computer Solutions - SCO Sales/Consulting/Administration and Mangling
PO Box 423 Mt Sinai, NY 11766
(516) 331-9001
From: ak751@cleveland.Freenet.Edu (Mark Saltzman)
Newsgroups: biz.sco.general
Subject: Strange problem with cd, sh, ksh, and bash
Date: 25 Jan 93 16:45:59 GMT
Reply-To: ak751@cleveland.Freenet.Edu (Mark Saltzman)
Organization: Case Western Reserve University, Cleveland, OH (USA)
NNTP-Posting-Host: slc10.ins.cwru.edu


I have been coming across directories on ODT 2.0 systems which can't be
accessed from sh or ksh, but can be accessed with bash.  For example:
$ cd Message
ksh: Message:  not found
but the same command issued from bash works.
Any ideas?
Thanks for any information,
-Mark Saltzman
From: paul@openage.com (Paul A. Fischer, Sr UNIX Sys Consultant)
Newsgroups: biz.sco.general
Subject: RE: passwd file corrupted
Keywords: passwd`
Date: 21 Jan 93 21:45:19 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk


>I am running sco v3.2.4 and I have some password file corruption. The system
>will boot normally,but will not accept any passwords. It will not accept the
>root passwd   at the single user prompt. I do have a working root and boot
>floppy. How do I restore my password file?

>Thanks,
>       Phil

You might try booting into single-user mode, and then do:

passwd root
passwd user1

etc

You might also try going into sysadmsh and resetting your security level.

--------------------------------------------------------------------------------
Independent SCO support and service provider in the D.C. metro area.
Insert clever saying here...
Paul A. Fischer           | Open Age Inc.  | paul@openage.com
Sr. UNIX Sys. Consultant  | (301) 948-6422 | (301) 948-9644 Fax
From: paul@openage.com (Paul A. Fischer, Sr UNIX Sys Consultant)
Newsgroups: biz.sco.general
Subject: Strange problem with cd, sh, ksh, and bash
Date: 26 Jan 93 02:49:32 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

>I have been coming across directories on ODT 2.0 systems which can't be
>accessed from sh or ksh, but can be accessed with bash.  For example:
>$ cd Message
>ksh: Message:  not found
>but the same command issued from bash works.
>Any ideas?
>Thanks for any information,
>-Mark Saltzman

Maybe the SUID bit is set on the BASH executable?
--------------------------------------------------------------------------------
Independent SCO support and service provider in the D.C. metro area.
Insert clever saying here...
Paul A. Fischer           | Open Age Inc.  | paul@openage.com
Sr. UNIX Sys. Consultant  | (301) 948-6422 | (301) 948-9644 Fax
Newsgroups: biz.sco.general
From: Eduard Vopicka <Eduard.Vopicka@vse.cs>
Subject: C-KERMIT binaries for SCO
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Reply-To: Eduard Vopicka <Eduard.Vopicka@vse.cs>
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Wed, 27 Jan 1993 16:16:43 GMT
Precedence: bulk

I am pleased to offer for testing C-KERMIT 5A(188) executable with dynamic
buffer allocation for SCO 3.2v4.x.
		Access:	anonymous ftp
		Server:	vsedev.vse.cs
		File:	/pub/sco/3.2v4.0/CK188/sco32v4netcdyn
With dynamic allocation, you can set fairly large send and receive
buffer size, eventually the window size. This can improve data throughput
in some applications. Example:
		SET RECEIVE BUFFER 4096
		SET SEND BUFFER 4096
		SET BLOCK 3
		SET WINDOW 4
I am interested in hearing not only about any possible problems, but also
about successful installations. Please send your reports to eda@vse.cs.

Eduard Vopicka

-- 

============================================================================
= Eduard Vopicka                             e-mail: Eduard.Vopicka@vse.cs =
= Computing Centre                              fax: +42 2 235 85 09       =
= Prague School of Economics                                               =
= W. Churchill square 4                                                    =
= CS 130 67 Prague 3                      ("There is always one more bug") =
============================================================================