HDTenEightyP/NetNews huggingface dataset:
From: ve3pak@micor.ocunix.on.ca (Alayne McGregor and Brett Delmage)
Subject: WANTED: Information on CONSENSYS V4
Organization: M.B. Cormier INC., Orleans (Ont)
Distribution: na
Date: Thu, 16 Apr 1992 09:46:42 GMT
Keywords: CONSENSYS V4

Sorry if this is a FAQ. I didn't see any responses to a similar question that
was posted earlier.
As a long-time SCO Xenix operator, I don't usually read this newsgroup.

Does anybody have any actual experience with CONSENSYS V4 UNIX, or any reasons
to buy or stay away from it? I saw their ad on the inside back cover of the
April 1992 UnixWorld, and had them fax their product literature. It looks
like a good deal, and I am looking to move up from SCO XENIX, to a real
networking system.

Post responses here, Thanks.

Brett Delmage
brett@ve3pak.ocunix.on.ca


Newsgroups: comp.unix.sysv386
From: fanj@remb6489.wpd.sgi.com (Fan Jiao)
Subject: Experience on Concensys V4
Reply-To: fanj@remb6489.wpd
Organization: SGI
Date: Thu, 16 Apr 92 16:30:15 GMT

I have been playing with it for about three weeks. I installed in the following
system:

* 486@33MHZ, 1990 AMI BIOS
* 8M mem
* 180 MB for UNIX partition
* ProDesigner IIs SVGA 1M RAM
* IDEK MF-5217 monitor.

1. Installation:

   A lot of pain! It took 7-8 hours to install from 3.5 FD. Installation pgm
is Okay, but not very good; does not check to see if your HD has enough space
to install. It is highly recommended that you should install the Base System
and Run Time package first, and get the new kernel built before installing
anything else. Note that if you run into the situation that no disk space
is left, you will have to start over again!

2. General Impression:

   Very good binaries! It seems that the source code is very solid. The 
directory layout looks like a SunOS(in fact a lot stuff are copyrighted under
Sun)! Both networking dev and X/Motif dev is very good.

3. Documentation:

   If you do not have any BSD/SunOS's networking docs, or OSF/O'Reilly X docs,
and you want to do some hacking on either networking or X, what you've got
is the man pages. You need to spend about $100 or more to buy the hardcopy docs.

   The package includes two small docs for installations, not bad, and very
minimum.

4. Hardware Compatibility:

   I used to have a 3COM 3C507 board which is not claimed to be supported by
Consensys.  The machine cannot be booted up by the miniroot when the board was
there. However, after have installed all, the new kernel can be booted up with
that board.

5. X:

   The only required networking stuff for running X are 'nsu' and 'inet'.
   Initially, I had some problems to build OSF's demos. Should use the
following LDLIBS:
   -L/usr/motif/lib -lXm -lXt -lX11 -lsocket -lnsl -L/usr/lib -lgen -L/usr/
   ucblib -lucb.

   And you need to setup X and Motif dev man pages by yourself.

6. X Performance:

   Surprisingly, window's performance under mwm is as least as good as any
10 Mips machine with primitive 8 bit graphics board.

   However, the performance of text scrolling in a xterm is VERY bad largely
due to the fact I am using a very primitive SVGA board.

   Some PEX operations are not supported by X386 1.2 because of that board.

   PEX clients run very slow.

   I wonder if I have 16MB memory...


-- 

Fan Jiao
From: larry@news.rn.com (Larry Snyder)
Newsgroups: comp.unix.sysv386
Subject: Re: C and C++ compilers on SVR4
Date: 15 Apr 92 22:48:13 GMT
Organization: The Gator Public Access Unix Site (219)289-0777

ajrooks@vlsi.waterloo.edu (Alan Rooks) writes:

>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

Dell comes both with the stock AT&T compiler but with the gcc 
compiler as well -- all set to "rock and roll" out of the box!

>In fact, I've heard rumours of people using a Microsoft C compiler - although

$CO is the only vendor that I am aware of which uses a Microsoft compiler

>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

that's not what you would expect from $CO?
-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                 uucp: uunet!trauma!larry
Xref: sparky comp.unix.sysv386:8432 comp.unix.bsd:739 comp.os.mach:618 comp.unix.wizards:2153 alt.folklore.computers:6244
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.unix.sysv386,comp.unix.bsd,comp.os.mach,comp.unix.wizards,alt.folklore.computers
Subject: Re: SVr4 and clone hardware buyer's FAQ
Date: 10 Apr 92 05:00:35 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Apr9.223543.15244@apollo.hp.com> goykhman_a@apollo.hp.com (Alex Goykhman) writes:

| In article <1fypqp#9NqV2h1QTT9N0yR5bj3PpxlN=eric@snark.thyrsus.com> eric@snark.thyrsus.com (Eric S. Raymond) writes:
| 
| >...........  Disk caching is good, but there can be too much of a good thing.
| >Excessively large caches will slow the system because the overhead for cache
| >fills swamps the real accesses (this is especially a trap for databases and
| >other applications that do non-sequential I/O).  More than 100K of cache is
| >probably a bad idea for a general-purpose UNIX box; watch out for manufacturers
| >who inflate cache size because memory is cheap and they think customers will be
| >impressed by big numbers.
| 
|     Large disk caches will improve disk performance, if configured properly.
|     By that I mean setting the cache segment size equal to the FS allocation
|     unit size (usually 1-8K).
| 
|     Stay away from disk caches that do not offer variable segment size.
|     Large "read-ahead" buffers may benefit MSDOS applications, but in a 
|     multi-tasking envoronment they can quickly become a drag on disk 
|     performance.

This is false, for decent controllers/disks.  Most modern SCSI disks,
for example, will immediately abort any readahead operations if a new
non-read command comes in (or a read for info not readahead).

Similarly very few *decent* disks will spend more than a few 10's of
usecs checking their caches.  Same goes for host based buffering, for
decent implementations.

That isn't to say that there aren't a lot of poor implementations
out there...
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.unix.sysv386
From: wang-mike@CS.YALE.EDU (Mike Wang)
Subject: SCO 3.2.4, QIC-02 Tape problem
Organization: Yale University
Date: Wed, 15 Apr 1992 01:24:06 GMT

Hi- I'm having this problem with SCO 3.2.4. I have an Archive SC499
controller with a Wangtek QIC-60 tape drive. I'm running a Gateway
2000 486/33 ISA machine with 8 megs of ram. The problem is, if I do,
for example,

tar cvf /dev/rct0 <ANYDIRECTORYHERE>

Then do a 

tar tvf /dev/rct0

It'll get most of the way through, and then near the end (I don't
know, about 8k, but a definate amount from the end) it will say

Tar: read error
read: I/O error

Or something like that (two lines), and die. I think it is not writing
everything out to the tape, because it'll restore everything up until
that point fine.

So, does anyone know wny this may be happening? For now I'm fixing the
problem by simply creating a 600k (a VERY safe margin) /tmp/dummy file
and doing "tar cv8 <whatIwantTObackup> /tmp/dummy" which will restore
what I wanted to backup.

I have changed that kernel parameter for tape buffer size from 128k to
256k but that had no noticable effect.

Any/all help is appreciated.

M][ke
-- 
wang-mike@yale.edu // Yale University // Standard Disclaimers Apply
From: grog@adagio.UUCP (Greg Lehey)
Newsgroups: comp.unix.sysv386
Subject: Re: Will vp/ix ever support Windows in enhanced mode?
Date: 10 Apr 92 17:44:13 GMT
Organization: LEMIS, Schellnhausen 2, W-6324 Feldatal, Germany

In article <1992Apr8.181747.13041@kong.gsfc.nasa.gov> sheldon@kong.gsfc.nasa.gov (Roger Sheldon - AISS) writes:
>I was thrilled to get Windows 3.0 running under vp/ix under ISC 3.0.

Well, everybody to his own taste.

>Is it, as I suspect, impossible to run Windows in enhanced mode 
>under vp/ix?

At least for the time being, yes. vp/ix runs virtual 8086's, which
don't have `enhanced' mode. To handle Windows 3.1 in enhanced mode,
you would need a virtual 80386 mode. I suppose that could happen, but
I don't really see the need.
-------------------------------------------------------------------------------
Greg Lehey		         | Public access UNIX available - try BSDI 
 LEMIS         			 | out on our machine! Mail and news 
W-6324 Schellnhausen 2           | connections available
Germany				 | Fax: +49-6637-1489
Tel: +49-6637-1488               | Mail: grog%lemis@Germany.Eu.net
From: fnf@fishpond.uucp (Fred Fish)
Newsgroups: comp.unix.sysv386
Subject: Re: Did they take adb out of Unix for SVR4?
Date: 7 Apr 92 17:49:21 GMT
Organization: Amiga Library Distribution Services

In article <1992Apr7.043827.26812@telesoft.com> holder@telesoft.com (Robert L. Holder @ignite) writes:
>In <1992Apr6.071438.2731@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
>>Okay, who stole my adb?  It was there in SysVr3; in fact, I'd bet it's
>
>adb is definitely missing on NCR SVR4 Unix. I also did not
>see it on the now defunct Interactive SVR4. It is on my
>beta Solaris (Sparc).

Adb is also present in Commodore's SVR4 UNIX for the Amiga 3000.  It's not
a 386, but it is SVR4.  It does understand ELF object files, DWARF debugging
information, uses /proc, and can run processes in the background.

(Just another data point...)

-Fred
-- 
|\/ o\  Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284,  USA
|/\__/  1-602-491-0048 {asuvax,mcdphx,cygint,amix}!fishpond!fnf
Xref: sparky comp.unix.sysv386:8334 biz.sco.general:1764 comp.unix.xenix.sco:1871
From: wimb@bssi.nl (Wim Berkhof)
Newsgroups: comp.unix.sysv386,biz.sco.general,comp.unix.xenix.sco
Subject: pcnfsd dying away...
Keywords: pcnfsd exports sco unix
Date: 8 Apr 92 08:19:25 GMT
Organization: Baan Service bv, Barneveld NL


We are using the 'pcnfsd' version 1.4 on a system with SCO Software:


Set                              Release   Notes            
---                              -------   -----            
SCO Portfolio                    1.0.1h    installed        
SCO MultiView Runtime System     1.6.1d    installed        
SCO NFS Runtime System           1.1.1d    installed        
SCO UNIX 3.2v2/NFS Maintenance D 1.0.0b    installed        
SCO TCP/IP Runtime System        1.1.3f    installed        
Computone Intelliport Drivers    4.31      partially installed
SCO System V Operating System    3.2.2s    partially installed
 (prd = unixos)                  3.2.2s    installed        
 (prd = unixos)                  3.2.2s    partially installed


A customisation is made to check correctly for the password from the
'/tcb/files/auth' files. This works fine.

However the 'pcnfsd' is dying away every now and then without any
warning. 

Does anyone have experience using or configuring 'pcnfsd' on such
a configuration. Also I'd like to know how to use the '/etc/exports' 



================================================================================
    __o            wimb@hp.bssi.nl               Baan Service b.v.
  _ \<,            Wim Berkhof                   PO Box 105, 3770 AC Barneveld
 (_)/(_)           Customer Support Engineer     The Netherlands
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Newsgroups: comp.unix.sysv386
Subject: Re: SpeedUp Sources and Patches on export.lcs.mit.edu
Date: 6 Apr 92 05:40:12 GMT
Reply-To: goer@midway.uchicago.edu
Organization: University of Chicago Computing Organizations

In article <ktvo25INN7il@neuro.usc.edu> merlin@neuro.usc.edu (merlin) writes:
>
>>The file SpeedUp.tar.Z contains the sources and patches to build an enhanced
>>X11R5 server...
>
>>	Copyright 1992 by Glenn G. Lai				   	
>>	All Rights Reserved
>
>Once again, I think Glenn is doing us all a great service by distributing
>his code without charge to the academic community.  I am just curious about
>the effectiveness of the legal means being used to control its circulation.

Presumably he thought about a simple PD release, but rejected the idea.
Likewise, he probably thought about copyleft, but rejected that as well.

I've come around to the FSF way of thinking myself.  Academics always
seem to have to grovel to the commercial interests, and copyleft is kind
of a neat trick - using the law to reverse the process, and force aca-
demic standards of openness on the commercial interests.  The GNU project
writes good enough software that their ploy works (much to my benefit,
as an academic).  Glenn, if your software is good enough, why not use
the same approach?

This is not to say that the approach you took was not a good one.  I just
had the same question as the poster I quote above:  What exactly does your
copyright accomplish?

-- 

   -Richard L. Goerwitz              goer%ellis@uchicago.bitnet
   goer@ellis.uchicago.edu           rutgers!oddjob!ellis!goer
From: debra@wsinis07.info.win.tue.nl (Paul De Bra)
Newsgroups: comp.unix.sysv386
Subject: Re: NS16550A with DELL SVR4 2.1 asy?
Date: 2 Apr 92 12:09:49 GMT
Reply-To: debra@info.win.tue.nl
Organization: Eindhoven University of Technology, the Netherlands

In article <1992Apr2.053748.2546@dellunix.dell.com> donn@dellunix.dell.com (Donn Baumgartner) writes:
>
>The baud rate stuff is an explanation of history that I'll leave to someone
>else... suffice it to say that you can do 38400 with the Dell asy driver if
>your machine has the 'guts' (a 25MHz 386 cannot support 19200 & 38400, at
>least in some circumstances...).  The EXTA & EXTB stuff is truly historical.
>							- Donn
This remark has been made before, but my experience is different.
The standard asy drivers may indeed require a fast machine to keep up with
19200 or 38400 baud.

Fas on the other hand has no problem with 19200, even on a 16Mhz 386sx
(for interactive work and uucp) and most of the time the 16Mhz 386sx can
even keep up with 38400 baud. (it is impressive to see uucp pumping data
into a 386sx at over 3kbytes/sec) My cached 25Mhz 386dx machine never
loses data at either 19200 or 38400 baud.

This only shows that although some versions of Unix (Esix and Dell come to
mind) support the fifo-mode of the 16550 chips this does not mean that they
can handle the same serial i/o bandwidth as the fas driver.

Paul.
Newsgroups: comp.unix.sysv386
From: rivers@ponds.uucp (Thomas David Rivers)
Subject: Re: ISC 2.0.2 and *THE* inode bug
Keywords: C-news, ISC 2.0.2, inode bug
Date: Wed, 15 Apr 1992 11:29:45 GMT

Well, I gave it some thought, and decided that this was small enough
to post again without too much hassle....

Here is the original posting I archived, which looks like Conor P. Cahill
posted in 1990, which was a repost of an article posted by  "Buster".

The original patch is properly credited to T. William Wells, the last
address I have for him is: ...uunet!twwells.com!bill

There, apparently, is also a patch for ISC 2.2.1; they didn't quite
fix the problem there...

           - Dave Rivers -
           (rivers@ponds.uucp)

--------------- CUT HERE ------------------------------------------
>From rti!mcnc!ncsuvx!lll-winken!uwm.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!texbell!nuchat!buster!rli Thu Jul 12 16:41:31 EDT 1990
Article: 7366 of comp.unix.i386
Xref: mozart news.misc:3773 news.software.b:3737 comp.sources.bugs:1742 comp.bugs.sys5:975 comp.unix.i386:7366
From: goykhman_a@apollo.hp.com (Alex Goykhman)
Subject: Re: SVr4 and clone hardware buyer's FAQ
Organization: Hewlett-Packard Corporation, Chelmsford, MA
Date: Thu, 9 Apr 1992 22:35:43 GMT

In article <1fypqp#9NqV2h1QTT9N0yR5bj3PpxlN=eric@snark.thyrsus.com> eric@snark.thyrsus.com (Eric S. Raymond) writes:

>...........  Disk caching is good, but there can be too much of a good thing.
>Excessively large caches will slow the system because the overhead for cache
>fills swamps the real accesses (this is especially a trap for databases and
>other applications that do non-sequential I/O).  More than 100K of cache is
>probably a bad idea for a general-purpose UNIX box; watch out for manufacturers
>who inflate cache size because memory is cheap and they think customers will be
>impressed by big numbers.

    Large disk caches will improve disk performance, if configured properly.
    By that I mean setting the cache segment size equal to the FS allocation
    unit size (usually 1-8K).

    Stay away from disk caches that do not offer variable segment size.
    Large "read-ahead" buffers may benefit MSDOS applications, but in a 
    multi-tasking envoronment they can quickly become a drag on disk 
    performance.







-- 
-----------------------------------------------------------------------------------
All opinions are mine, if you find one please return it to goykhman_a@apollo.hp.com
-----------------------------------------------------------------------------------
Newsgroups: comp.unix.sysv386
From: karln%karln.UUCP@uunet.uu.net (Karl Nicholas)
Subject: Re: SUMMARY:gcc on isc sysvr3.2 version
Organization: Security Pacific
Date: Tue, 7 Apr 1992 18:27:52 GMT


Glad to hear of success with GCC-2.1. I had similar success with
gcc-2.0


But: I did not get libg++-2.0 to compile. I only tried half heartedly, 
but would like to hear from others.

  Has anyone gotten libg++-2.0 to compile under ISC 3.0?
  

Karl.




-- 
***************************************************************************
| Karl Nicholas                 | A million monkeys in a million years    |
| karln%karln.UUCP@uunet.uu.net | did write Shakespeare, we evolved ...   |
***************************************************************************
Newsgroups: comp.unix.sysv386
From: jantypas@soft21.s21.com (John Antypas)
Subject: Need PPP or CSlip for ISC TCP 1.3
Organization: 21st Century Software, Walnut Creek CA, USA
Date: Tue, 07 Apr 1992 20:58:42 GMT

Hello Netland,

Before I dive off the deep end and attempt to do this, has anyone,
either PD or comercial, ported PPP or (in a pinch) CSlip to ISC's
TCP/IP environment?

Many thanks.

-- 
John Antypas
jantypas@soft21.s21.com
...!uupsi!{uupsi2, mobdig}!soft21!jantypas
From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.sysv386
Subject: Re: Trouble Loading Dell's SVR4 onto a Gateway 2000 Machine
Date: 8 Apr 92 21:40:11 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <466@rri.UUCP>, tim@rri.UUCP (Tim Buck) writes:

|  Yes, yes, yes.  Interactive (which is identical to Dell's SVR4) ships on 
|  floppies, but the boot process hangs with the floppy access light staying on
|  forever.


  Sorry, they started from somewhat the same place, but they are vastly
diferent as anyone who has used both will attest. In particular they
have some diferent drivers (not changes to the same driver) as well as
diferent patches to the original code.

  If I were Sunsoft I would have piad Dell to do the Solaris port,
based on the observed reliability of the two vendor's products over
several years. Dell did ship ISC V.3, that's another issue, and is
related to why we chose SCO, but the V.4 is not remotely the same.
Neither company should be judged by the changes in the other's product.
-- 
	- bill davidsen (davidsen@crd.ge.com)
	GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
From: robert@alicia.sdata.de (Robert Ebe)
Newsgroups: comp.unix.sysv386
Subject: $TZ limited to 3 valid chars on ISC 2.0.2 ?
Date: 14 Apr 92 18:57:33 GMT
Organization: C. Splittgerber Datentechnik, Denkendorf, Germany

Hello,

I want to set the correct timezone variable $TZ on my ISC 2.0.2.
Therefore I set $TZ for Europe with

setenv TZ "MET-1MEST-2;089/2,271/2"

The problem is that ISC 2.0.2 seems to cut any timezone name to
3 characters. So on a `date' I get

Tue Apr 14 20:48:04 MES 1992

Does anybody know a way to work-around the 3 char limit on ISC 2.0.2?

Thanks, Robert

-- 
++++++++++++ Memorial line for Miles, the man with the horn +++++++++++++
robert@alicia.sdata.de      (...!uunet!mcsun!unido!alderan!alicia!robert)
Robert Ebe, 2:241/7401.17@fidonet.org  (Germany)    Voice: +49 7121 83335
From: debra@wsinis07.info.win.tue.nl (Paul De Bra)
Newsgroups: comp.unix.sysv386
Subject: Re: Memory Cache and Unix
Date: 1 Apr 92 11:56:30 GMT
Reply-To: debra@info.win.tue.nl
Organization: Eindhoven University of Technology, the Netherlands

In article <1992Mar30.154629.16259@candle.uucp> root@candle.uucp (Bruce Momjian) writes:
>I have heard of a few sites that have had problems using a motherboard
>with memory cache while running Unix.  The cache had to be disabled to
>run Unix ( particularly Everex 386/33 and SCO Unix 3.2.2).
>...
>I am considering buying a new motherboard with a cache and am running
>AT&T 386 Unix SVr3.1 and was wondering if I should stay away from a
>33MHz 386 with a cache, and settle for a 25MHz motherboard.

I have tried Unix sVr3.1, sVr3.2, sVr3.2u, sVr4.0 2.0, sVr4.0 2.1 and
sVr4.0 3.0 on an Everex Step 386/25 and none of these Unix versions
had any problem with the cache, which has been 64k and is now 128k.
All these versions of Unix can run and also be installed with the cache
being enabled.

The only potential problem with cached machines is that the cache and memory
may become inconsistent when using dma. floppy controllers use dma and so do
tape-controllers. i have both in my system and never experienced any
inconsistency.

Since all Everex Step systems have essentially the same cache system
i would be fairly confident that it is safe to run Unix on them with the
cache enabled.

The only problem which does indeed exist is that sVr3.1 (the oldest one
of the series) will not boot on 25Mhz cache systems or faster.
This is a bug (a busy-loop) in the boot-code which disappeared with sVr3.2.
sVr3.1 can be booted at low-speed and subsequently run at high speed.

Paul.
Newsgroups: comp.unix.sysv386
Subject: Re: C and C++ compilers on SVR4
From: chriss@pandanus.cs.ntu.edu.au (Chris C. Sleeman)
Date: 15 Apr 92 10:24:22 +0900
Reply-To: chriss@pandanus.cs.ntu.edu.au (Chris C. Sleeman)
Distribution: world
Organization: Computer Science, NTU

Where can I get gcc and g++?

Are they somewhere that I can ftp them?

Please e-mail me with an address to get them from!

Chriss
From: eric@snark.thyrsus.com (Eric S. Raymond)
Newsgroups: comp.unix.sysv386
Subject: Re: PROPOSAL --- The Great 1992 UNIX Dream Machines Bake-Off
Date: 8 Apr 92 15:14:50 GMT

In <1992Apr7.140644.27039@bilver.uucp> Bill Vermillion wrote:
> One BIG question.  Why is this limited to EISA machines.  Why not the
> MCA architecture.   I remember reading specs on an ALR machine (One of
> the few (if not only) that makes both and EISA and MCA, and the MCA
> outperformed EISA in some respects.    And what about the NCR machines,
> or any of the manfacturers of MCA bus based machines other than IBM.

Because MCA isn't commodity hardware.  So it's got a whole two manufacturers.
And yes, it's technically nifty.  But it's expensive, IBM effectively controls
it, and there's no reason to believe either of those things will ever change.
-- 
      Eric S. Raymond = eric@snark.thyrsus.com  (mad mastermind of TMN-Netnews)