HDTenEightyP/NetNews huggingface dataset:
From: sts6f@vortex.mech.virginia.edu (Sonya T. Smith)
Subject:  xdtm help on Dell unix v2.2
Organization: University of Virginia
Date: Wed, 7 Oct 1992 13:21:05 GMT


Hello,

Again I am trying, without success, to install another one of my favorite utilities
under Dell unix v2.2; this time xdtm.  If anyone has this working with Dell 2.2 and
Motif I would appreciate it if you would tell me via e-mail what the secret is to make
it compile.  

BTW, is there a FAQ for novices like myself, that has tips on compiling some of these
PD utilities and frequently, encountered compiling problems, and suggestions on how to
go about fixing them?

What follows is a sample of the errors I am receiving;  Thanks in advance,
Sonya
-- 
"appman.c", line 299: undefined symbol: XpmAttributes
"appman.c", line 299: syntax error before or at: pixmapAttrs
"appman.c", line 302: undefined symbol: pixmapAttrs
"appman.c", line 302: non-unique member requires struct/union object: visual
"appman.c", line 302: warning: left operand of "." must be struct/union object
"appman.c", line 303: non-unique member requires struct/union object: colormap
"appman.c", line 303: warning: left operand of "." must be struct/union object
"appman.c", line 304: non-unique member requires struct/union object: depth
"appman.c", line 304: warning: left operand of "." must be struct/union object
"appman.c", line 304: cannot access member of non-struct/union object
"appman.c", line 305: undefined struct/union member: colorsymbols
"appman.c", line 305: warning: left operand of "." must be struct/union object
"appman.c", line 305: undefined symbol: XpmColorSymbol
"appman.c", line 305: syntax error before or at: )
"appman.c", line 306: undefined struct/union member: numsymbols
"appman.c", line 306: warning: left operand of "." must be struct/union object
"appman.c", line 307: undefined struct/union member: valuemask
"appman.c", line 307: warning: left operand of "." must be struct/union object
"appman.c", line 307: undefined symbol: XpmReturnPixels
"appman.c", line 421: undefined symbol: pixmapReadStatus
"appman.c", line 430: undefined symbol: XpmSuccess
"appman.c", line 916: warning: argument is incompatible with prototype: arg #2
"appman.c", line 1028: warning: identifier redeclared: trashQueryResult
"appman.c", line 1031: warning: type does not match prototype: delete
"appman.c", line 1114: warning: identifier redeclared: copyQueryResult
"appman.c", line 1117: warning: type does not match prototype: copy
"appman.c", line 1206: warning: identifier redeclared: moveQueryResult
"appman.c", line 1209: warning: type does not match prototype: move
"appman.c", line 1456: warning: identifier redeclared: execute
"appman.c", line 1461: warning: type does not match prototype: cwait
"appman.c", line 1582: undefined symbol: O_RDONLY
"appman.c", line 1590: undefined symbol: O_WRONLY
"appman.c", line 1590: undefined symbol: O_CREAT
"appman.c", line 1635: warning: argument is incompatible with prototype: arg #2
"appman.c", line 1977: warning: argument is incompatible with prototype: arg #2
From: j4jbail@srv.PacBell.COM (Jack Bailey)
Newsgroups: comp.unix.sysv386
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Controllers
Date: 16 Oct 92 23:31:55 GMT
Organization: Pacific * Bell

In article <Bw7y5I.Cs@maxed.amg.com> ed@maxed.amg.com (Ed Whittemore) writes:
>In article <1992Oct15.231111.28896@PacBell.COM> j4jbail@srv.PacBell.COM (Jack Bailey) writes:
>
>...
>
>>
>>Getting back to cost, one could argue that the labor involved in
>>fine-tuning a large system may be more expensive than dropping in
>>hardware.  Figure the costs incurred if you were to hire yourself
>>to bring the system to peak performance.  Now as you add more
>>serial ports, more network connections, and more applications,
>>consider the expense of retuning the system.  That cacheing
>>controller may not be so expensive after all.
>
>In many cases the cost of a cacheing controller is more than  or about
>the same as the cost of a new motherboard that accommodates more
>memory, especially now that boards using 16 MB simms are out, and the 
>prices of these simms are level with 4 MB simms.

Isn't capitalism wonderful?

>I can see some place for a cacheing controller ( not too much! ), but
>far too often it is the lazy way of throwing dollars after better, but
>not great performance.

Yes, I agree it's lazier.  Sounds to me like the best thing to do
is guestimate the hardware requirements correctly up front.  We
wouldn't want any extra motherboards laying around.

>Tuning a system, with a little experience, is simply the very quick
>alteration of a few parameters, remaking the kernel, maybe adding a few
>simms, and rebooting. That's it. It's not like it's some arcane, time-
>consuming trial-and-error process.

For some of us it's that simple.  For others, I dunno...

Regarding the kernel parameters that were posted, the values
given for 32MB of RAM were NBUF=16000, and NHBUF=16384.  The
Operating System Guide says that NHBUF should be approximately 4
times the value of NBUF (or is it vise-versa?).  Also, the
default parameter for NHBUF is 500, which not an even power of 2.
The manual says it should be.  Comments?

-- 
J.J.Bailey	j4jbail@srv.pacbell.com
Contractor	510.823.6453
Newsgroups: comp.unix.sysv386
From: ed@maxed.amg.com (Ed Whittemore)
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Controllers
Organization: American Micro Group, Ft. Lee  NJ
Date: Thu, 8 Oct 1992 12:27:30 GMT

In article <jim.718492482@ferkel> jim@ferkel.ucsb.edu (Jim Lick) writes:
>I've heard the arguments that a disk cache on the controller is 'useless'
>under Unix, but I don't believe it as a general case.  As I understand it,
>the amount of disk cache Unix assigns is relative to how much memory is
>available.  If you run lots of big programs, the cache is going to get
>pretty small, right?  So the way I see it, having the cache on the disk
>controller makes certain that you will have at least however much cache is
>on the controller, plus however much Unix can assign in real memory.  Thus
>it is advantageous to have a disk cache on the controller.  The argument
>continues that adding more memory to the system is better than adding a disk
>cache.  But again, there is nothing saying that users won't gobble up this
>additional memory with larger programs and again leave you with a small
>cache.  Realistically, that's always what happens.  Users will always use
>more resources if more resources are available.  I think a guarantee of a
>certain size disk cache is better than hoping that unix will have room
>for a decent cache in memory.
>
>(PS- Anyone have experience with the DPT SmartCache for EISA boards?  I got
>their information packet in the mail 2 days ago and it looks pretty good.)
>
Actually, this question the question of DPT controllers and disk cache
has been addressed--right here--in the last week or so.

Anyway, benchmarks show ( Byte Unix Benchmarks, iozone, dd, home-brew )
beyond a shadow of a doubt that

         DPT CACHEING CONTROLLERS ARE A WASTE OF TIME AND MONEY

for Unix. If you want a big "SMART" cache with SVR3 set NBUF and NHBUF
to use about 1/4 of real memory, and add RAM; for SVR4 increase BUFHWM.

It's not that DPT or other cacheing controllers are bad, or slow, it's
just that Unix is too smart for them to be of any help, and its own
buffer structure outperforms the hardware disk cache. Use the cacheing
controllers where they can be of help with dumb OSs like DOS.

Get a BusTek BT 747S or 742A or Adaptec 174(x). Realistically, you can
almost always add RAM to the motherboard.

Ed Whittemore   uupsi!maxed!ed   ed@maxed.amg.com
American Micro Group, Inc.   201-944-3293
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.sysv386
Subject: Re: Any experience with Sony 4mm DAT drives?
Keywords: DAT tape 4mm SCO unix
Date: 16 Oct 92 12:34:02 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1beu5sINN3ie@usenet.INS.CWRU.Edu>, hossein@ces.cwru.edu (HOSSEIN) writes:

| - Are the 4mm tapes as reliable as QIC tapes?

  Yes.

| - Won't we have problems in connecting the external tape drive through the 
|   external SCSI port?

  No.

| - What about the compatibility of the CAM or ASPI driver methods?

  No idea. We use DAT as a big QIC, and it works fine. We have about 30
around the world, taking data which people send us. They seem to work
just fine.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
Newsgroups: comp.unix.sysv386
From: witr@rwwa.COM (Robert Withrow)
Subject: Re: comm problem
Reply-To: witr@rwwa.com
Organization: R.W. Withrow Associates
Distribution: usa
Date: Sun, 11 Oct 1992 16:13:57 GMT

In article <1992Oct8.135946.13315@info.ucl.ac.be>,
   aa@info.ucl.ac.be (Andre April) writes:

| I also have problems with the serial ports of my AT&T unix SVR4 4.0. When
| I use X386, the mouse has an erratic response. It seems that most of the
| characters generated by the mouse are lost.

They are not ``lost'' they are just being awkwardly buffered in the driver
so that the data isn't getting to the server frequently enought to support
smooth mouse movement.

The solution for Xfree86 (which you should be using in preference to
X386, unless you get your X386 from SGCS, due to the bug fixes), is to
use the system supplied mouse drivers and the Xqueue method in the
server.

Alternatively, and for other devices (such as a joystick, in my case), the
solution is to use SAS.  It can be configured to forward data to the
user program more frequently.

-- 
 Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM
 R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA
Newsgroups: comp.unix.sysv386
From: rlerdorf@zeus ()
Subject: Help with VGA mode 3 - SCO Unix
Organization: University of Waterloo, Canada.
Date: Thu, 8 Oct 1992 18:01:01 GMT

I received a request from a couple of programmers in Brazil about
VGA mode 3.  

> We need some help about programming VGA methods.  The write mode 3
> doesn't work.  We have two books and both explain the same thing,
> but the mode doesn't work.  We need examples and more explanations.

Could somebody give me a hand answering this one, or directing me to an ftp
site where I can pick up some decent VGA programming examples?

(Please e-mail replies)
---
Rasmus Lerdorf     internet: rlerdorf@zeus.uwaterloo.ca (NeXT-mail)
  _   _   _   _    FAX     : 519 746-4791                     Nutec Corp. 
 _ _   _ _ _ _     Phone   : 519 886-6009                     DIA member
_   _   _   _   ** AlphaWindows(tm) Coming soon to a terminal near you **
Newsgroups: comp.unix.sysv386
From: peter@ferranti.com (peter da silva)
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Controllers
Organization: Xenix Support, FICC
Date: Wed, 14 Oct 1992 23:02:30 GMT

In article <Bw1w1M.M3p@wimsey.bc.ca> sl@wimsey.bc.ca (Stuart Lynne) writes:
> It is an axiom that unless you are already using the fastest CPU available
> in your main system, the cheapest way to buy more CPU cycles is to buy a
> faster processor for it. You will able to use the CPU cycles for more than 
> just I/O as well. 

This "axiom" ignores things like interrupt latency, non-real-time kernels,
cache bashing, and specialised processors. In other words, it's not always
true. Otherwise, why buy a digiboard or install FIFO uarts? They're slower
than the main processor, and you can always just get a 586...

> This does not hold true if you already have the fastest CPU available and
> it's running at full speed *and* the I/O processor can do the job fast
> enough. 

Actually, I'd put that: "this does not hold true if you already have the
fastest CPU available *OR* the I/O processor can do the job fast enough".
Our 486 boxes find the 186 on the serial cards plenty helpful, and I doubt
that going to a 586 will help if we were to make it drive a bunch of 8250s
itself.
-- 
Peter da Silva                                         `-_-'
Ferranti Intl. Ctls. Corp.                              'U` 
Sugar Land, TX  77487-5012           "Heeft u vandaag al uw wolf geknuffeld?"
+1 713 274 5180                       "Tjener, denne ret er stadig levende."
From: shane@cs.sunysb.edu (Shane Bouslough)
Newsgroups: comp.unix.sysv386
Subject: Re: Colorado Jumbo250 tape drivers for SCO.
Date: 10 Oct 92 05:23:08 GMT
Organization: Dept of Computer Science, State U of NY at Stony Brook
X-Newsreader: Tin 1.1 PL5

marrevola@iris-dcp.es wrote:
^^^^^^^^^^^^^^^^^^^^^
: In article <1992Oct07.113848.9675@vpnet.chi.il.us>,
:	lisbon@vpnet.chi.il.us (Gerry Swetsky) writes:
: > In article <1992Oct5.135131.71@iris-dcp.es> marrevola@iris-dcp.es writes:
                                                ^^^^^^^^^^^^^^^^^^^^^
: >>FTP site for Colorado Jumbo250 tape backup under SCO Unix System V?
                                               ^^^^^^^^^^^^^^^^^^^^^^^
: >     As I recall, they SELL those drivers - at least they used to!
: >     Be very careful before you post these to an ftp site!
: > 
: > | Help stamp out stupid .signature files!           Gerry Swetsky  WB9EBO  |
: > | Home (708)833-8122       vpnet (708)833-8126      lisbon@vpnet.chi.il.us |
: 
: Yes??????!!!!
: 
: Thanks a lot.
: Next time I'll be very carefull but, do many people use a 250 MegaByte backup
: system for DOS?
         ^^^^^^^
I don't get it.

--
Shane Bouslough       | #include <stddisc.h>
shane@sbcs.sunysb.edu | #include <happy.rhodes>
Xref: sparky comp.unix.sysv386:15411 comp.unix.sys5.r3:33 comp.unix.pc-clone.32bit:305
From: bassin@wsuaix.csc.wsu.edu (Ed Bassin - Sociology;S23679)
Newsgroups: comp.unix.sysv386,comp.unix.sys5.r3,comp.unix.pc-clone.32bit
Subject: editors for System 5
Date: 9 Oct 92 20:13:09 GMT
Article-I.D.: serval.1992Oct9.201309.20145
Organization: Washington State University

We recently purchased a 486 running AT&T Sys 5, Rel 3 (an old copy that no
one was using) for instructional purposes.  Our primary reason for getting the
system was to run softwae rsuedin tea ching statistics, but we would also
like to make the system available to students for some basic text editing.
My question is if anyone knows of a public domain/shareware/freeware text
editor (or reasonably priced commercial product) that students could use on
VT100 compatible terminals to do some basic text editing.  Our requirements
are that it be easy to use, easy to teach, and stable.  Though I use vi in
my own work, it doesn't meet the easy to use/easy to learn criteria.  Any
suggestions?

Thanks in advance,
Ed Bassin
Newsgroups: comp.unix.sysv386,comp.unix.sys5.r4
From: larry@gator.rn.com (Larry Snyder)
Subject: Re: xboard-2.0.tar has been uploaded to US4BINR
Organization: The Gator Conferencing System 219-289-3745 
Date: Wed, 14 Oct 1992 12:41:09 GMT

Aren't these postings getting rather old?

I mean, a multiple page item posted on each individual file
is a little crazy -- just think if I posted a multiple page
ad for each of the 13,000 files on-line.


-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry
Newsgroups: comp.unix.sysv386
From: dlparker@dlpinc00.rn.com (David L. Parker)
Subject: Re: ISC update: v3.1?
Organization: Automated Data Management Services
Date: Sat, 10 Oct 1992 12:23:45 GMT

In article <1992Oct9.154317.25261@xyzoom.info.com> rob@xyzoom.info.com (Rob Lingelbach) writes:
>I heard recently that SunSoft plans to release an update to ISC
>version 3.0 (SVR3.2) this fall that will include symbolic links, long
>filenames, and the Korn Shell.  I was surprised to hear this because I
>thought SunSoft's upgrade path for ISC users was going to be to
>Solaris 2.0.  
>
>Can anyone confirm or deny the information? 
>

I believe it's already out, and that it's version 3.01.  I believe that
VP/ix and X11R5 were also updated.  The policy on upgrades as various 
SunSoft people have expressed it to me is that SVR3 will continue to be
a supported product, with periodic upgrades, for some time.  Meaning  
(at least to me) that as long as people are interested in buying it, 
they'll keep selling it.
-- 
Dave Parker
Automated Data Management Services, Pleasant Hill, MO 64080-1331
(816) 987-5167/5218 voice/fax
Newsgroups: comp.unix.sysv386
From: enertec@netcom.com (The Gang at Enertec)
Subject: COMPAQ's new pro-signea
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 15 Oct 1992 21:34:16 GMT

Has anyone seen ISC UNIX 3.0 running on the new COMPAQ Pro-Signea line?

No one at COMPAQ seems to be interested in ISC, they seem to be moving
toward SCO.

If anyone has seen this, please drop me a line.


Thanx in advance,


John Feras

enertec@netcom.com

-- 
enertec@netcom.COM
Netcom - Online Communication Services San Jose, CA
Newsgroups: comp.unix.sysv386
From: ed@maxed.amg.com (Ed Whittemore)
Subject: Re: netstat -i crashes Interactive SVR3(.2.2.3) / netd.cf weirdness
Organization: American Micro Group, Ft. Lee  NJ
Date: Sun, 11 Oct 1992 15:32:19 GMT

In article <1992Oct11.022704.27430@meteor.wisc.edu> Mike O'Connor <mjo@snclib.snc.edu> writes:
>
>Problem:  Running "netstat -i" on my Interactive SVR3 with TCP 1.2
>          causes bad things to happen.  I have my network up and I
>          believe it's working just fine, but...
>
>Problem:  The documentation on netd.cf is horrible.  I can't seem
>          to find anything apart from a cryptic manpage and sample
>          files that only work to a point.  I'd like to get SLIP
>          and Western Digital Ethernet (SMC) to work together, and
>          I really don't know what to massage/pamper to get things
>          to work.  
>
>Please email all replies as news service here is less than 100% reliable.
...
First of all, upgrade to v. 1.3 of TCP/IP since many crash-prone bugs
are fixed in the later release.
-- 
Ed Whittemore   uunet!maxed!ed   ed@maxed.amg.com
American Micro Group, Inc.   201-944-3293
Newsgroups: comp.unix.sysv386,biz.sco.general
From: tomh@wes.on.ca (Tom Haapanen)
Subject: How fast should a SCSI tape drive be? -- and CTAR
Organization: Waterloo Engineering Software
Date: Fri, 16 Oct 1992 12:44:56 GMT


I recently changed from a Mountain external QIC-02 tape drive to a Wangtek
5150ES internal SCSI drive.  I never measured the speed of the Mountain,
but it seems to me that the Wangtek is awfully slow, with a clear on-off-
on-off sound from the drive.  In fact, upon doing some timings, the drive
only manages only about 1 MB per minute, which seems quite low.  And the
results are about the same regardless of whether I use tar, cpio or dd.

Here is the system configuration:
	386/40, 64K cache, 16 MB RAM
	IDE controller 
	2x200 MB IDE drives
	Adaptec 1542B SCSI controller
	660 MB Micropolis SCSI drive (ID 0)
	Wangtek 5150ES tape drive (ID 6)
... and ...
	SCO Unix 3.2.2
	SCO TCP/IP and NFS

Also, on a different topic, I have seen many good words said about CTAR in
these newsgroups.  Why does it seem to be so difficult to find details,
prices and dealers?  Does someone have a phone number?  Or names/numbers
of people selling CTAR in Ontario?

Will CTAR be faster than tar/dd/cpio?  Does it know how to append to an
existing tape archive?

[ \tom haapanen    "i don't even know what street canada is on" -- al capone ]
[ tomh@wes.on.ca                   "trust the programmer" -- ansi c standard ]
[ waterloo engineering software      "to thine own self be true" -- polonius ]
Newsgroups: biz.sco.general,comp.unix.sysv386
Subject: Re: SCO Unix 3.2.2, C News and lack of inodes
Summary: 
Expires: 
Followup-To: 
Distribution: 
Organization: Waterloo Engineering Software
Keywords: 

sef@kithrup.COM (Sean Eric Fagan) writes:
> In article <1992Oct15.214120.26465@wes.on.ca> tomh@wes.on.ca (Tom Haapanen) writes:
> >What I was BZZZZTing was your comment that EAFS is still limited to 64K
> >inodes.  I'm sure I've seen claims by SCO that you can have more inodes in
> >an EAFS filesystem.  Is that not true?
> 
> I see.  You were being obnoxious in stating as fact something you only
> thought, despite the flat-out statement by someone else that it was not
> true, not bothering to determine yourself whether or not you were right.
> 
> The answer to your question, since you did not seem capable of reading it in
> either of the messages you followed up to is "no, the EAFS still uses 16-bit
> inodes."  Which, as simple arithmetic will lead you to conclude, is 64k
> (although it is a bit less than that, as I think three inode numbers [0, 1,
> and 65535] are reserved or already in use by the filesystem-generation
> code).
> 
> -- 
> Sean Eric Fagan  | "You can't get lost in one room, no matter how
> sef@kithrup.COM  |  little effort you make to learn your way around."
> -----------------+    -- William E Davidsen (william@crd.GE.COM)
> Any opinions expressed are my own, and generally unpopular with others.

Newsgroups: comp.unix.sysv386
From: kdenning@portal.hq.videocart.com (Karl Denninger)
Subject: Re: Problems with Dell v2.2
Summary: Specialix board problem I bet
Organization: VideOcart Inc.
Date: Mon, 12 Oct 1992 15:51:01 GMT

In article <1992Oct11.213751.20506@mark-one.inet-uk.co.uk> mark@mark-one.inet-uk.co.uk (Mark Powell) writes:
>Got a problem. Installed Dell v2.2 and the drivers for my Specialix SI-8
>by hand (the pkgadd install disk didn't work.) Now ttymon complains that
>it cannot allocate a controlling tty on any port on the card. Changing
>this with uugetty allows a user to login, but ps -f shows that they have
>no controlling tty. 
>  I've gone back to the v2.1 kernel and drivers, but this makes no difference.
>Where apart from the kernel could such a problem be?
>Thanks in advance for any help.
>
>BTW the permissions are correct on these files.
>    When a user does login on v2.2 kernel the terminal is severely messed up.
>    Seems like the problem when something such as icrnl has been turned off
>    but it isn't. Changing back to the v2.1 kernel seemed to fix this???
>
>Also, xdvi dies just after start-up with the message "IO signal" ?? Anyone
>know why this is?

Sounds like there are a couple of possibilities..... (assuming you have a
stream driver there)

One, the "ldterm" line discipline module may not have been pushed.  If
pkgadd didn't work this is LIKELY.  You need to fix that; the exact
requirements are device specific.  Look for an "autopush" line which the
pkgadd installation script wanted to install somewhere, and track down what
it would have wanted to do.

Second, the driver itself may be seriously hosed.  Less likely if you can
talk to the ports at all, but possible.

--
Karl Denninger 		Inet:  kdenning@hq.videocart.com
VideOcart Inc.		Voice: (312) 987-5022
From: Steve_Lammert@transarc.com
Newsgroups: comp.unix.sysv386
Subject: Re: the laq of a FAQ
Date: 9 Oct 92 19:45:17 GMT
Organization: Carnegie Mellon, Pittsburgh, PA

rcd@raven.eklektix.com (Dick Dunn) writes:
> Those of you reading comp.unix.sysv386 may have noticed that there hasn't
> been a FAQ posting for a while. ...

Is there a site which maintains an archive of the messages in this
newsgroup and makes them available via anon ftp?  I'm looking for
any old FAQ...

Thanks,
Steve

 ----------------------------------------------------------------------------
  Steve Lammert          | Gulf Tower           | Internet: shl@transarc.com
  Facilities Coordinator | 707 Grant Street     | Voice:     +1 412 338-4443
  Transarc Corporation   | Pittsburgh PA  15219 | FAX:       +1 412 338-4404
 ----------------------------------------------------------------------------
         "No matter where you go, there you are." -- Buckaroo Banzai
 ----------------------------------------------------------------------------
Newsgroups: comp.unix.sysv386