HDTenEightyP/NetNews huggingface dataset:
From: edc@openage.COM (Ed Cooley)
Newsgroups: biz.sco.general
Subject: TruFax - SCO Unix
Date: 12 Aug 92 13:48:24 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 recently installed TruFax at a customer site.  We found the 
package available from two sources, COS who originally wrote the 
program, and Devcom who remarkets the product with value-added 
menuing scripts, etc.  The COS product is infinitely cheaper 
(around $395 I think) but for those who aren't into enhancing 
their own Bourne shell scripts the Devcom product is worth a 
look.  

The product supports Everex external fax modems which we find 
especially desireable since we have no love for internal modems 
in UNIX systems, or anything that closely resembles one.  
Although we have been actively suggesting the Digifax as well 
inspite of it being a PC add-in board; maybe we just have a level 
of faith in Digiboard.  The Everex fax/modem can be used for 
dial-in and dial-out both as a fax and a modem - always a nice 
feature.

The software is nothing fancy, and in fact uses a cpio script for 
installation to maintain useability across other operating 
systems.  The documentation is in need of improvement, but 
comprehensive like most UNIX manuals.  I would prefer to see some 
release notes specific to each of the supported operating 
systems.  The software actually reminds me more of an API than 
anything.  Most things are written in Bourne shell for easy 
modification.  That's good, because you will want to modify them 
for ease of understanding by your customers and their system 
users.  A macro is included for faxing directly from within 
WordPerfect as well (ALT-F).  Also, converters are provided for 
using TIF images.

Ring me up if you need more info.

> Has anyone have TruFax installed under SCO Unix?  


> -- 
> Vlink                                    | Steven E. Frazier
>                                    |---------------------------------------
>                                    | Local : sfrazier
> (614) 785-7335                     | Remote: sfrazier@eng.norstan.com

--------------------------------------------------------------------------------
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: stevea@i88.isc.com (Steve Alexander)
Subject: Re: TCP/IP connection times when nameserver running
Organization: INTERACTIVE Systems Corporation, Naperville, IL
Distribution: biz
Date: Fri, 21 Aug 1992 14:45:11 GMT

In article <DEAN.92Aug21093639@world.std.com> dean@world.std.com (Dean S Banfield) writes:
>When we run the name server, 'named', our connection times using TELNET into
>the SCO machine slow to a crawl.  It takes over 1 min to receive the login:
>prompt.  We know that the name server itself is delivering name resolution
>quickly, because CUTE/TCP "TELBIN" lets us know when name resloution is
>complete and when it is beginning to try and make a connection.

Sounds like forward mapping is working, but reverse mapping is not.  Check
to make sure that your in-addr.arpa domain is set correctly.

-- Steve
-- 
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
From: lee@dlpco.dlpco.COM (Lee Penn)
Newsgroups: biz.sco.general
Subject: Re: SCO X11R4 EFS and MultiScreens
Date: 13 Aug 92 22:09:31 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

>In article <9208110506.AA05016@bazooka.Altos.COM> bazooka!thilo@altos.Altos.COM (Thilo Koenig) writes:
>>...annoying "feature" of the Xsco SVGA X server...
>>Namely, if I switch to a different MultiScreen, all processing on the
>>X server stops (i.e., all clients seem to hang, including any normal
>>non-X UNIX processes running in an xterm >window).  And when I switch
>>back to the X server screen, processing resumes.

>I'll preface my explanation by saying that when you screen switch away
>from an X server you (the server) basically give up all rights on the
>video card on a SCO system.  You cannot write to the card, read from
.
.
.
>-- 
>          Stacey Campbell - staceyc@sco.com - uunet!sco!staceyc

running actively while I am switching between MultiScreens.  
However, upon giving it some thought, I can see the following.

A key element is that we normally keep a root logged into the 
first multiscreen for sysadmin needs.  Also, if someone gets 
locked up, it is much easier to switch to screen 1 and do our 
"root thing".  I find that we need root capability many times 
each day.

Therefore a key advantage of the MultiScreen function turns out to 
be the ability to log into the console as a different user on the 
different screens.

I see a need for a panning server to replace the the whole 
MultiScreen functionality at the console.  Plus, I would want to 
see some version of SCOTERM which would log a user into a 
specific screen at the console.  I guess the plays havoc with 
security, but it would resolve my need to have a root logged into 
the system during business hours.

In general, I like the idea of a panning server operating on a 
much larger virtual screen surface far better than the 
multiscreen concept.  With this, multiscreen goes away totally.

Thanks.
================================================================================
Lee Penn,  DLP Technologies, Inc.                     Voice: 513 232-7791
SCO Advanced Product Center                           FAX: (513) 232-7801
7444 Jager Ct.
Cincinnati, OH  45230-4344                           email: lee@dlpco.COM
Newsgroups: biz.sco.general
From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Subject: Re: SCO UNIX System Performance
Date: Sat, 15 Aug 1992 06:49:07 GMT
Organization: The Programmer's Pit Stop, Ann Arbor MI

In article <1992Aug14.143622.16232@bullns.on01.bull.ca> alee@bullns.on01.bull.ca (Anthony Lee) writes:
>I have a 486 based PC running SCO UNIX.  Recently, I have upgrade the system memory from 32MB to 16MB.  The performance has degraded substantially.  When talking to SCO.  I am told that SCO runs terribly for system with > 16MB of RAM.  Somehow, I do not believe this is quite right.  

[Please hit <return> every 75 characters or so.]

The problem is related to the design of the ISA bus and bus-mastering
DMA controllers, such as the Adaptec 1542B.  Specifically, the ISA bus
only has 24 address lines, which means the maximum memory address a
device on the ISA bus can access is 16MB.  Controllers that do
bus-mastering DMA have to be able to access the memory they are
DMAing to or from, and this means that all disk transfers to or from a
bus-mastering controller must happen below the 16MB limit.

This means that if you have a bus-mastering controller and more than
16MB of memory, the OS must sense when a transfer to an address above
16MB is about to happen, provide buffer space for the transfer at an
address below 16MB, and then copy the contents of that buffer to the
high address once the transfer is complete.  Naturally, this
additional buffering stage will slow down DMA transfers.

SCO Unix loads its kernel from the highest memory address down, so it
would stand to reason that on a >16MB system, the kernel I/O buffers
could well end up above 16MB, thus incurring an extra copy on all disk
I/O.  I would hope that SCO has discovered this by now and made sure
that the kernel block cache gets allocated below the 16MB line, even
if the rest of the kernel is loaded above it.

However, you will only notice this performance hit under very specific
conditions -- >16MB of memory, a controller that uses bus-mastering
DMA, and a DMA address above 16MB.  What kind of performance problems
are you having?  CPU?  Disk?  Communications?  Do they go away if you
take the extra memory out?

-- 
Marc Unangst                | Real men don't make backups.  Real men never
mju@mudos.ann-arbor.mi.us   | accidentally delete files that they're going
                            | to need later.
From: fr@compu.com (Fred Rump from home)
Newsgroups: biz.sco.general
Subject: Re: FOXPRO FOR SCO WHEN????
Date: 16 Aug 92 20:12:10 GMT
Article-I.D.: compu.1992Aug16.201210.17665
Organization: CompuData Inc.

lee@dlpco.dlpco.COM (Lee Penn) writes:

>Has anyone heard when FoxPro for SCO Unix might ship.  I have had
>many customers interested, but there is no news of availability.

>Microsoft purchased FOX and I wonder if it will ever be a real
>product for SCO users.

Last I spoke to the FOX people at PC Expo (they had a UNIX FoxPro display
there) they claimed that it would be a winter/spring thing. When I suggested 
that the original planned release was to be fall '92 (as I had heard 
previously and saw mentioned in the press), they claimed that such an 
announcement had never been made and even the current 'later' plan was not 
really a scheduled release yet. They will get to it when they get to it but 
they will build the product.

In other words, they don't want to promise anything specifically that pins 
them down.

fred
-- 
W. Fred Rump 	office:	   fred@COMPU.COM     'mans feet have grown/so big 
26 Warren St.   home: fred@icdi10.compu.com  that he/forgets his littleness'
Beverly, NJ. 08010                          		Don Marquis 
609-386-6846    bang:uunet!cdin-1!icdi10!fr   
Newsgroups: biz.sco.general
From: johne@sco.COM (John A. Ehler)
Subject: Re: FAX Solution Needed
Organization: The Santa Cruz Operation, Inc.
Date: Tue, 11 Aug 1992 22:42:52 GMT



SCO has added a performance supplement to the Microsoft LAN Manager for 
UNIX Systems product.  The user can expect roughly a 100% - 150% improvement 
in performance depending on the transport used (NetBEUI or TCP/IP).  The
supplement is available in the current shipping product or from the SCO Support
departments uucp server, sosco, by anonymous ftp in the Supplements directory.  If you do not know how to login to sosco, contact SCO Technical Support.

John Ehler
SCO Networking Engineer




From: lee@dlpco.dlpco.COM (Lee Penn)

Lee getting in his 2 cents worth:

I've been trying to solve the dos connectivity puzzle for some
time and thought I would share some results along with Fred's
comments:

I've tried:

        Atlantix Axcess (now out of business but worked well)

****>   SCO Lan Manager (slow when trying to load programs)

        FTP/PC-TCP  (works well but expensive)

        ESKER's TUN PLUS TCP  (nice feature but slow loading
                dos programs from the virtual disk)

        LOCUS PC Interface

        JSB Desktop as the Windows based tool for allowing users
                to run UNIX programs under windows

Some performance notes:

        I have a program from Studebaker Worthington which they
give away to compute lease deals.  As a simple minded test, I
simply load the main menu for this program and time it for how
long it takes to bring up the main menu on my screen.

        LOCAL C: Drive:         1 second or less

        TUN Virtual Drive:      12 seconds

****>   SCO Lan Mgr             15 seconds

        PC Interface            3 seconds
From: paul@openage.COM (Paul A. Fischer, Sr UNIX Sys Consultant)
Newsgroups: biz.sco.general
Subject: Multiple UUCP Hops (Was: Anomaly)
Date: 12 Aug 92 13:29:13 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

>>It doesn't even make any sense unless you're a local call to uunet.
>>This would require two connections to uunet, and the only thing I
>>pay for when I call anomaly directly is Ma Bell.  I generally get
>>better transfer speeds talking to almost any site other than uunet too.
>>

>The question was meant as an inquiry. I would agree that the transfer rates
>on UUNET have a lot to be desired. There were a few manuals I was reading
>that stated that the multiple hops via UUCP was possible. I wanted to 
>verify something that didn't make sense to me.

Yes you can do multiple UUCP hops such as:

        uucp machinea!file machineb!file

If you set it up you can even do:

        uucp macha!machb!file machc!machd!file

What you can't do, and I wish you could is:

        uuto filename macha!machb!machc!username


--------------------------------------------------------------------------------
Independent SCO support and service provider in the D.C. metro area.
No Incumbents in '92. Get the crooks out of office. Vote & Send a Message
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: steveo@world.std.com (Steven W Orr)
Subject: More on SysV.4 /dev/fd*. PLEASE HELP ME??
Organization: SysLang, Inc.
Date: Sat, 15 Aug 1992 18:57:05 GMT

I got one response from an SCO guy who assures me that the drivers
for Release 4 style /dev/fd* pseudo-devices exists internally at SCO
but its just not available for general consumption.

I want to learn more about device drivers and this looks like a
perfect opportunity to do it. These sound like very simple device
drivers to implement. Unfortunatly, I have no idea where to begin (I
still have a level of anticipation when I relink my kernel :-)).
So....

If anyone at SCO could PLEASE see his/her way to providing me with
something either official or unofficial I would be equally grateful.
If someone outside of SCO has done something like this, it would be
just as welcome.

Many thanks in advance.
-- 
----------Time flies like the wind. Fruit flies like bananas.------------------
Steven W. Orr      steveo@world.std.com     uunet!world!steveo
----------Everybody repeat after me: "We are all individuals."-----------------
From: fr@compu.com (Fred Rump from home)
Newsgroups: biz.sco.general
Subject: Re: Banyan Systems Announces VINES for SCO UNIX
Date: 12 Aug 92 17:29:42 GMT
Article-I.D.: compu.1992Aug12.172942.3872
Organization: CompuData Inc.

andrew@airs.com (Andrew Evans) writes:
[lots of high numbers deleted]
>>* Applications toolkit    $995

>How about my first-born child, when I get one?  Would you prefer male
>or female?

I think what they want is a UNIXoid or was that eunuchoid? At those rates sex 
doesn't really matter anymore.
fred 
-- 
W. Fred Rump 	office:	   fred@COMPU.COM     'mans feet have grown/so big 
26 Warren St.   home: fred@icdi10.compu.com  that he/forgets his littleness'
Beverly, NJ. 08010                          		Don Marquis 
609-386-6846    bang:uunet!cdin-1!icdi10!fr
From: mike@pacsoft.com (Mike Stefanik)
Newsgroups: biz.sco.general
Subject: Re: /dev/u problems
Date: 20 Aug 92 19:28:51 GMT
Organization: Pacific Software Group, Riverside, Ca.

In an article, d166alab@utarlg.uta.edu (AJAY BARVE) writes:
>We had a server crash today.  After rebooting the server I tried
>to mount /dev/u however I got the error message that " cannot stat 
>/dev/u " [...]

This means that the block special device in /dev was eaten.  You
don't mention what other (if any) filesystems you have, so I'll assume
that you have the "standard" configuration of a root filesystem,
swap space and /u filesystem.  You can try this (logged in as root,
in single-user mode):

	# rm /dev/u /dev/ru
	# mknod /dev/u b 1 42
	# mknod /dev/ru c 1 42

The first line will remove any bogus files... don't worry... this will
not affect the data on your /u slice.

The second and third lines create the block and character special device
names for the /u slice.  You should now be able to run fsck on /dev/u,
and then mount it.  You might also want to make sure that the /u directory
is intact.

If you aren't sure what the minor device numbers are for your /u slice,
you can always look for it on your bootable root floppy (you *do* have a
bootable floppy in case of emergencies, right?)

-- 
Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike
Pacific Software Group, Riverside, CA
From: belal@sco.COM (Bela Lubkin)
Newsgroups: biz.sco.general
Subject: Re: c-news compiling on SCO
Date: 13 Aug 92 01:38:26 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

Bill Campbell quoted:

> From: Bill Campbell <bill@celestial.com>
> Date: Wed, 12 Aug 1992 06:32:59 GMT

> In <BsuC2p.451@gator.rn.com> larry@gator.rn.com (Larry Snyder) writes:
> 
> :jpr@jpradley.jpr.com (Jean-Pierre Radley) writes:
> 
> :>>It's a well-known fact that C News won't work on SCO Unix.  In fact,
> :>>once you get past the above bug, you will find that it generates
> :>>hu-YUUUGE database files.  This problem can't be programmed around as
> :>>there is a kernel hack in SCO that makes dbz files not work unless they
> :>>are larger than 102.4 meg big.  SCO refuses to fix this since they
> :>>consider it a "feature".

I can't quite tell from the attribution, who said this; and the quoted
message never showed up here.  In any case, I've never heard of this.
It is well known that the optimizer in the 3.2.2 DS breaks "dbz".  This
has been fixed in the 3.2.4 DS.  There is no "kernel hack" involved and
the reason dbz files are so large when dbz is compiled with the 3.2.2
DS, with optimization, is that dbz's hash function gets mis-optimized.

>Bela<
From: belal@sco.COM (Bela Lubkin)
Newsgroups: biz.sco.general
Subject: Re: fsck: can't read blk xxx, SCSI
Date: 12 Aug 92 20:23:04 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

Uwe S. Obst wrote:

> >Normally *NIX redirects such blocks to an area that was allocated when the
> >system was installed. 
> [..]
> 
> am i wrong or should/could this normally be done by the SCSI harddisk
> itself? i remember someone telling me that the controller on the SCSI
> drive checks for bad blocks and remaps them automatically?!

The SCSI spec *allows* this but does not require it.  There are two
optional features: Automatic Write Reallocation (AWRE) and Automatic
Read Reallocation (ARRE).  Unfortunately, very few SCSI drives on the
market actually implement these.  AWRE works like this: when you try to
to write a block, if the drive detects a problem during writing (i.e. a
hard error on the disk), it silently, automatically uses a different
block and updates the bad block table on the drive.  The operating
system never knows about it.  I don't know how ARRE works -- the problem
is much more difficult.  You read a block; the drive has a problem with
it, so it reports an error to the operating system, which is now
supposed to realize that it doesn't have the data it needs.  I don't
know if the drive is supposed to "try real hard" and deliver approximate
data, then reallocate a new block and write that approximate data to it;
or if it just allocates a new, blank block, and tells the OS "sorry, no
data", or what.

ODT 2.0, and MSv4.1 for 3.2v4, contain a new SCO utility,
scsibadblk(ADM).  This can turn on AWRE & ARRE, if the drive supports
them; and it can scan the disk and manually reallocate blocks from the
drive's replacement block pool.  SLSes which provide this facility to
XENIX 2.3.4 and UNIX 3.2v2/ODT 1.1 are forthcoming but are not yet
available (the utility requires changes to the SCSI disk device driver).

It is a fallacy to assume that the drive takes care of all this.  The
facility to do so is *optional* -- and not widely implemented.

>Bela Lubkin<  Support engineer, The Santa Cruz Operation
Newsgroups: biz.sco.general
From: wpeloqui@medar.com (Willie Peloquin)
Subject: SCSI driver for Xenix 2.3
Organization: Medar, Inc.     Farmington Hills, MI
Distribution: usa
Date: Wed, 12 Aug 1992 21:04:00 GMT

Hello,

    Does anyone have or know of a SCSI hard disk driver for Xenix 2.3?

    Thanks.

Willie


---------------------------------------------------------------------------
Willie Peloquin		      | I'm not a kid anymore, but this ain't no
wpeloqui@medar.com	      | midlife crisis, because whiskey and women
uunet!medar!n8mdy!wpeloqui    | have always been my vices!       Bocephus
---------------------------------------------------------------------------
-- 

---------------------------------------------------------------------------
Willie Peloquin		      | I'm not a kid anymore, but this ain't no
wpeloqui@medar.com	      | midlife crisis, because whiskey and women
From: pb@idca.tds.philips.nl (Peter Brouwer)
Newsgroups: biz.sco.general
Subject: Re: SCO UNIX System Performance
Date: 17 Aug 92 12:40:19 GMT
Reply-To: pb@idca.tds.philips.nl (Peter Brouwer)
Organization: Digital Equipment Enterprise B.V.,Apeldoorn,The Netherlands.

X-Disclaimer: This opinion is mine alone

In <Bt0Ixw.JDu@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:

>In article <1992Aug14.143622.16232@bullns.on01.bull.ca> alee@bullns.on01.bull.ca (Anthony Lee) writes:
>>I have a 486 based PC running SCO UNIX.  Recently, I have upgrade the
>>system memory from 32MB to 16MB.  The performance has degraded substantially. 
>>When talking to SCO.  I am told that SCO runs terribly for system with > 16MB
>>of RAM.  Somehow, I do not believe this is quite right.  
>The problem is related to the design of the ISA bus and bus-mastering
>DMA controllers, such as the Adaptec 1542B.  Specifically, the ISA bus
>only has 24 address lines, which means the maximum memory address a
>device on the ISA bus can access is 16MB.  Controllers that do
>bus-mastering DMA have to be able to access the memory they are

What version of SCO are you using?
We experienced the same kind of problems. One of the spots of problems was that
a bigger the unix disk cache ( NBUF ) was degreasing the performance.
SCO has improved the cache handling and cured the problem. All this was
experience in 3.2 version 4. 


--
#  Peter Brouwer,                | Digital Equipment Enterprise ,              #
#  NET  : pb@idca.tds.philips.nl | Integration Industry Standard Systems,      #
#  PHONE:ext [+31] [-0]55 432992,| Dept Systems Enginering, Bld V1/B4          #
#  FAX  :ext [+31] [-0]55 432070 | P.O.Box 245,7300AE Apeldoorn,The Netherlands#
Newsgroups: biz.sco.general,comp.unix.xenix.sco
From: apl@world.std.com (Anthony P Lawrence)
Subject: AST 486 SCSI Problems
Organization: The World Public Access UNIX, Brookline, MA
Distribution: usa
Date: Sun, 16 Aug 1992 13:59:02 GMT

New AST 486 eisa, Adaptac 1744, 510 Meg Connor, Archive 2525S.

Installation appeared to go well, but when I tried to access
tape, I got "Can't get Block Limits".  Further checking showed
that "tape status" was pretty confused about whether or not
a cartridge was in place, and tape reset didn't help unconfuse it.

Decided to reinstall with 1744 set to extended.  (why?  I dunno).

Installation went fine.  Same problem with tape, though.  Then,
suddenly, screenfulls of "Can't read block " off of dev 1,40.

Killed power.  Reboot, NO OS.  Wonderful.  Reset Adaptec to 
standard mode.  Re-install.  NO OS.

Tried to force a boot track.

NO OS.

Boot DOS floppy, run Adaptec utility.  It sees 8 (eight) drives!
(I've seen this only once before when somebody set the drive id to 7:
this drive is most assuredly not).

Decided to "Erase Boot Sector" on drive 0 (well, it's already 
in a pretty weird state, so what have I to lose?).  Command fails!


All this is happening on Saturday, so I've nobody to call.  I finally
gave up, and came home to read UnixWorld, September 1992.  On page
52 is a sidebar that details their never-solved woes with an AST 486.

So, I was going to look at replacing the Adaptec, but now I'm not sure.

Any thoughts?

			Tony


Lawrence & Clark, Inc		(617) 762-0707	(206) 323-2864
Xenix/Unix support,etc 	 	 Boston		 Seattle