HDTenEightyP/NetNews huggingface dataset:
From: anewton@bbx.basis.com (Allen J. Newton)
Newsgroups: biz.sco.general
Subject: NFS Lock Requests on SCO UNIX
Date: 16 Dec 92 22:16:44 GMT
Organization: BASIS International, Ltd., Albuquerque NM USA


    Hello, fellow SCO users!

    I have a SCO UNIX question, and hope someone here may have the answer.
    A co-worker informed me that older NFS implementations had a problem
    that all lock requests would go through the lockd daemon, which made
    lock requests extremely slow.

    We are considering purchasing the latest and greatest version of NFS,
    but we're wondering if that problem has been corrected.  Anyone out
    here have any ideas?
--
--------------------------------------------------------------------------------
Allen J. Newton     BASIS International Ltd,  (505)-345-5232
5901 Jefferson NE,  Albuquerque, New Mexico   87109
unmvax!anewton@bbx.basis.com
From: dkazem@nas.edu (Don Kazem)
Newsgroups: biz.sco.general
Subject: Hiding machines in mmdf
Date: 16 Dec 92 22:24:01 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Encoding: 485 Text
Precedence: bulk

I am running mmdf on a Unix host and am using it as a mail exchanger.  It
accepts our outgoing mail from a DOS box that is the smtp gateway to our email
system on the LAN.

I have hidden the mail gateway such that all outgoing messages go out from
user@nas.edu, however, the return path shows user@mailagent.nas.edu.  Mialagent
is the DOS box.

My question is how can I change the return path as well, or even do away with
it?

Thanks.

F.Don Kazem-zadeh
dkazem@nas.edu
Newsgroups: biz.sco.general
From: art@chaos.cs.umn.edu ()
Subject: RPC timeout
Summary: Increase callrpc timeout?
Keywords: timeour RPC
Organization: University of Minnesota
Date: Fri, 11 Dec 1992 18:58:38 GMT

I remember a discussion a while back about increasing timeouts on RPC
(callrpc) but I don't remember the solution. Is their an easy one ?
Like a parameter somewhere? Could someone give me the verdict.
Thanks
Art Reisman
art@chaos.cs.umn.edu
612-375-1066
Newsgroups: biz.sco.general
From: wang@hp4at.eunet.co.at (Wang)
Subject: X11-Servercard recommendation for ODT (2.0) ??
Organization: EUnet EDV-Dienstleistungsgesellschaft m.b.H
X-Newsreader: Tin 1.1 PL4
Date: Tue, 15 Dec 1992 10:47:33 GMT

In order to increase the graphicsperformance I'm considering to run the
X11 Server on a addon-board.
Anyone can recommend a brand/type? Since my budget is limited it should
have a good price/performance value!
Thanks a lot,

Michael

-- 
Michael Zacherl, Management Data Wang Ltd., Vienna |
E-MAIL: mza@zwerg.wang.co.at                       | "Proof your chances,
PHONE:  +43 (1) 89-111 ext. 433                    |  and leave them or not."
FAX:    +43 (1) 894-17-14                          |     
Newsgroups: biz.sco.general
From: steph@sco.COM (The Steph)
Subject: Re: slip/cu
Organization: The Santa Cruz Operation, Inc.
Distribution: biz
Date: Wed, 16 Dec 1992 19:49:58 GMT
Keywords: SLIP cu


Fred Harris <fredh@teal.csn.org> writes:

>I am attempting to establish a remote SLIP connection between
>two machines using SCO Opendesktop 1.1.  Does anyone know if
>it is possible to use the standard SCO cu program, while running
>the slip interface, to remotely login into other systems? My goal
>is to connect my SCO ODT 1.1 UNIX system to another system running
>SLIP that will serve as a gateway to the 'Net'. 
>Any and all assistance is greatly appreciated.
>fredh

Once you have the SL/IP link up, using cu over that link is
not appropriate.  Since the link establishes an IP connection,
it is appropriate to use one of the TCP/IP remote login facilities
like telnet or rlogin, not cu.  Given that the proper routing
information is getting passed across the SL/IP link, rlogin
and telnet should be able to get you an interactive login on
any system the remote system can contact.  All you would need
is a default route, and the names/addresses of the remote systems.

Another way I can see to interpret your message is that you have
TWO serial lines, and the first is getting used by the SL/IP
connection.  In that case, establishing a lock file will cause cu
to ignore that line.  Create /usr/spool/uucp/LCK..tty?? (where ??
is the lower case name of the tty).  cu will then bypass that line.

IF you are trying to use SL/IP over a dialup link, I would refer
you to the release notes which accompanied your TCP/IP distribution.
 A section in there illustrates exactly how to set up a SL/IP
connection over a dialup circuit.

As a last note, if you _are_ trying to use SL/IP over a dialup
circuit, I suggest you upgrade to Open Desktop Release 2.0 and use
PPP instead.  PPP already interlocks with the UUCP subsystem, and
uses the same dialers and control files (Systems, Devices) as UUCP
to establish its linkages.  more better faster smarter wowsier.

If I'm completely off-base with regard to what you're trying to do,
let me know, and I'll try to help with whatever it is that you _are_
trying to do.

Best of luck to you.
-- 
Steph Marr                  |    Steph at work:   |    Steph not at work:
SCO Network Engineering     |                     |
#include <std/disclaimer.h> | ...!uunet!sco!steph |   ...!sco!demesne!steph
#include <random/quote.h>   |    steph@sco.COM    | steph%demesne.uucp@sco.COM
From: gerg@netcom.com (Greg Andrews)
Newsgroups: biz.sco.general
Subject: Re: More stray _pointers_ from SCO Magazine
Summary: Clarificaton of a detail...
Date: 15 Dec 92 01:53:46 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

sl@wimsey.bc.ca (Stuart Lynne) writes:
>In article <1992Dec06.210707.21584@anomaly.sbs.com> kd1hz@anomaly.sbs.com (Michael P. Deignan) writes:
>
>>I would, in fact, classify this tip as extremely useful, as it has the
>>overhead by 33% or more is an important, vital piece of information I
>>would like to know about.
>
>I'd like to know how e can get 33% improvement period. With g you loose
>seven bytes for each 64 byte packet. That's 10%. 
>

Slight clarafication here.  UUCP "g" has a 6 byte header, not 7, and
each packet carries a total of 70 bytes (6 header + 64 data).  The
overhead ends up being approximately 8.6% (6 / 70 = .0857).

>
>To get full throughput you will need to adjust window size up to seven.
>

This answers the question you asked above.  With the stock window size of
only 3 packets, UUCP "g" will slow down over high speed modem links.  The
result is throughput only 60-70% of maximum.  Boosting the window size to
7 will bring throughput up to 100%, but only on V.32 (9600 bps) modem links.
V.32bis connections will run at approx 88% efficiency, and faster modulations
will be worse.

It's likely that the 33% figure Mr. (Dr.?) Deignan calls "overhead" is
the throughput of a 3-packet-window uucp session over V.32 or V.32bis
modem links.

I agree that calling "e" the solution to the throughput problem is dangerous,
for the reasons of link reliability that have already been pointed out, and
because (as far as I've been able to tell) the article never mentions the
option of boosting window size (documented in the uucico man page).  Before
I'd tell someone to switch to a non-reliable transfer protocol, I'd have them
tweak their present protocol as much as practical.  Even then, I'd explore
other options (e.g. spoofing modems, alternate uucp packages) before switching
from a reliable protocol to an unreliable one.

OTOH, I'm aware of some sites that are feeding large amounts of news with
UUCP "e".  They are running the risk of dropping files, but they're aware of
those risks and have acted to reduce them as much as possible (e.g. error
correcting modems, working RTS/CTS flow control on both ends, serial ports
that won't drop characters, etc.).  However, this solution isn't one I'd
offer to Joe Sysadmin.  Integrating the right serial hardware/software and
modems is NOT a job for someone who can't spend lots of time making it all
jump through the right hoops.

-- 
:::::::::::::::::::  Greg Andrews  gerg@netcom.com  :::::::::::::::::::
ObGuindon:  The Carp Diet.  You place a carp in your refrigerator
            and it takes away your appetite.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
From: ak751@cleveland.Freenet.Edu (Mark Saltzman)
Newsgroups: biz.sco.general
Subject: Re: Tape drive on floppy controller, no fun for crowbar+restore
Date: 19 Dec 1992 17:13:31 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: ak751@cleveland.Freenet.Edu (Mark Saltzman)
NNTP-Posting-Host: slc4.ins.cwru.edu


In a previous article, bob@consult.UUCP (Bob Willey CDP) says:

>In article <Z2J1VB2w165w@zswamp.UUCP> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
>>> Next time you'll likely buy a different tape drive.
>>
>>   I think that it's worth emphasizing this: the Jumbo tape drives from 
>>Colorado Memory Systems work well, provided that you buy the separate 
>>controller card (to get away from the floppy controller conflict, as you 
>>mentioned in your article), the UNIX software, etc... and, by the time you've 
>>bought all of the pieces, you've spent a significant fraction of the money it 
>>would have cost to put in a QIC-02 tape drive of higher capacity... and Jumbo 
>>tapes need to be preformatted (a slow process not shared by QIC-02 tapes)! 
>
>Yes, they can work successfully.  It does require a little bit of
>tinkering and making sure you have the JTAPE driver software from
>Colorado.
>
>However, One BIG NOTE of WARNING!!!
>
>For those uninformed, the Colorado 120mb is actually a 60mb unit uncompressed,
>and the Colorado 250mb is actually a 120mb uncompressed.  If you use tar
>you are limited to 60mb/120mb respectively.
>
>If you are like us, and use CTAR, the compression will recoup some of the
>area for you, depending on your file types.
>
>-- 
>>.. Bob Willey, CDP          ..  |  ..  uunet!consult!bob  bob@ccs.com   ..<
>>.. CCS Enterprises, Inc.    ..  |  ..   Office: (410) 820-4670          ..<
>>.. P.O. Drawer 1690         ..  |  ..      FAX: (410) 476-5261          ..<
>>.. Easton, Maryland 21601 ......|......... BBS: (410) 476-5098 ...........<
Is CTAR really necessary?  We do this:
tar cvf - <files> | compress -c > /dev/rjt0
Or with gnu tar:
gtar -cvf /dev/rjt0 +compress <files>

-Mark Saltzman

>
From: Eduard.Vopicka@vse.cs (Eduard Vopicka)
Newsgroups: biz.sco.general
Subject: Re: Hiding machines in mmdf
Date: 18 Dec 92 12:18:51 GMT
Reply-To: Eduard Vopicka <Eduard.Vopicka@vse.cs>
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
             Re: Hiding machines in mmdf
Precedence: bulk

} Try 
}         MLDOMAIN .edu
}         MLNAME nas
}         MLOCMACHINE mserve
} 
} 
} 
} .>   I tried this and rebuilt the database, but then when I manually ran the deliver
} .>   command
} .>   mmdf did not deliver any of the messages. When I undid their suggestion, it
} .>   worked again.
} .>   Any thoughts, comments, and/or suggestions will be greatly appreciated.
} 

We have encountered this problem about two years ago. I cannot remember
exactly and I cannot check it because we are using sendmail/IDA instead
of mmdf now. But changing MLNAME/MLOCMACHINE had something to do with
changing all occurences of the fully qualified machine name in the
mmdftailor file, especially in the MCHN lines. Soory if I am wrong,
this happened to us long time ago.

Ed

-- 

============================================================================
= 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") =
============================================================================
Newsgroups: biz.sco.general
From: briank@Kimbro.SeaSlug.ORG (D. Brian Kimmel)
Subject: Token Ring
Organization: D. Briank Kimmel - home system
Date: Fri, 11 Dec 1992 09:08:36 GMT
Keywords: Token Ring Microchannel

Hello,

I ran into a configuration problem and wonder if anyone else has a
situation like mine.

I have an IBM microchannel computer running ODT 1.1.  I added in
a token ring adapter card 2 days ago.  The machine runs fine if
the token ring drivers are not in the kernel.

If I do a mkdev token and then link unix (no I don't want tcp/ip on
this card, it will be running netbios) and then reboot, I get about
10 minutes or so of operation before the *E* panic sets in.

Has anyone else ever successfully configured a token ring card on
a microchannel machine?  If so, would you be willing to share how
you did it?

Thanks in advance.

Brian
-- 
D. Brian Kimmel - home system	Email: briank@kimbro.SeaSlug.ORG
Seattle,  WA        (206) 937-5742      Modem: (206) 937-6779
Newsgroups: biz.sco.general
From: fred@genesis.demon.co.uk (Lawrence Kirby)
Subject: hard drive accessing. 
Distribution: world
Organization: BT
Date: Tue, 15 Dec 1992 14:00:38 +0000


In article <m0n1IFk-000Fk0C@ilinx.wimsey.bc.ca> brian@ilinx.wimsey.bc.ca writes:

>
>As enscripted by Paul A. Fischer, Sr UNIX Sys Consultant:
>> >Also does UNIX come with disk defragmenting?
>> 
>> You need to buy it separately, or backup your filesystem, remake the fs and 
>> then restore.
>
>but is fragmentation a reality in UNIX (or any multi-{user,tasking} O/S)?
>
>If I have a file in the disk which is very large and completely contiguous,
>will the fact that the disk is scrambling all over the place satisfying (sp?)
>multiple read/write requests defeat the "de-fragmentation" of the disk?
>
>comments??
>

That would certainly reduce the benefit of defragmentation but it wouldn't
eliminate it.

If your record size is greater than 1 disk block then a record read can be
satisfied in one contiguous disk transfer whereas it could require several
in a fragmented file.

Even if you are only doing single block reads and writes the filesystem has
to indirect through a series of index blocks to determine where it is on the
disk (especially in a large file). In a contiguous file these index blocks
will on average be closer to their data blocks.

Related data in the file may well be localised. In a contiguous file it would
be physically localised too which may reduce average seek time.

-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------
From: bill@Celestial.COM (Bill Campbell)
Subject: Re: Shell script poser
Organization: Celestial Software, Mercer Island, WA
Date: Mon, 14 Dec 1992 17:02:36 GMT

In <1992Dec14.122016.20084@golem.waterloo.on.ca> davidf@golem.waterloo.on.ca (David J. Fiander) writes:

:But there is a very good reason that you don't want to use the
:shell script instead of the sed or perl scripts.  I don't have
:perl, but it might be faster because of the way the operations
:ar performed.  The shell script takes four processes to convert
:a single line, while the sed script does the whole file with
:just one.  The shell script works, but I compared it to the sed
:script on a Sun4 running /usr/dict/words through it (I did this
:on the sun4 because that's where I had a big file of text).

:Here are the times for the sed script:

:	real	3m01.05s
:	user	2m59.80s
:	sys	0m02.71s

:And here are the times for the shell script:

:	real	143m49.08s
:	user	22m44.95s
:	sys	197m09.30s

:- David

I ran a perl version of this and got the following times on a 386-33
under Xenix 2.3.4:
+ time perl -pe 's/(.*)/\u\L$1/;' /usr/dict/words > /dev/null

	real        26.3
	user        23.0
	sys          0.2

wc -l /usr/dict/words
  23739 /usr/dict/words

Running the perl version on ODT 2 on a 486-33 EISA machine gives:
	real       14.5
	user       13.7
	sys         0.1

Is the Sun4 that much of a dog or is their /usr/dict/words a lot
longer?

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?
Xref: sparky biz.sco.general:4759 comp.unix.sysv386:17549 comp.unix.pc-clone.32bit:856
From: ktf@bc3.GUN.de (Klaus ter Fehn)
Newsgroups: biz.sco.general,comp.unix.sysv386,comp.unix.pc-clone.32bit
Subject: Re: Serial terminals-reset when line dropped (SCO 3.2.2)
Keywords: serial terminal sco 3.2.2 line drop
Date: 19 Dec 92 13:20:46 GMT
Organization: private

In article <1992Dec17.174331.3604%jim.uucp@wupost.wustl.edu> mike%jim.uucp@wupost.wustl.edu (Mike S.) writes:


>Using SCO 3.2.2, we have several serial terminals active, each in
>a user application.  When one of these serial terminals is re-booted,
>it blasts the correct Unix login down the line, which executes our
>.profile, and starts our application.

>The problem arises when a terminal is rebooted while in the application.
>What we would like to do is force all tasks associated with the terminal
>to terminate, thus restarting getty, when the line is dropped.

>So far, we have been unsuccessful in doing this.  Sometimes, the top
>level task will terminate, but the others (sh, etc) don't.

Look after the following things:

1. If the Unix-System got to know, if the Terminal is switched off or on, 
   you should use the 'modem-device' (tty2A instead of tty2a). Most
   Terminals I know have a setup-choice 'modem-control on/off'. 
   What is happening there ? The Terminal will then lower the DTR-Line
   to indicate it is off. Using the modem-device for the getty means in 
   this case, that the device-driver recognizes the missing DTR-Signal
   and a Signal SUGHUP (1) is sent to your applications.
   Note that you got to have a cable which carries also DTR/DSR(CD). 
   See the manual page serial(HW) for a closer cable-description.

2. If a Application should exit when the Terminal is switched off, it got 
   to react on the signal SIGHUP (1). If this signal is ignored, the 
   process remains, even when the login-shell terminates. init (PID 1) 
   will then become the new process-group-leader.
   The default reaction on signal SIGHUP (1) is to terminate. You may catch 
   the signal, if you want to perform any other reaction (flushing buffers 
   and removing temporary files is always a good idea).

3. Make sure, that in /etc/gettydefs the parameter HUPCL (Hang Up On Close)
   is set. (I'm not quite sure if this is really needed)

SEE ALSO:
   getty(M), gettydefs(F), ioctl(S), signal(S), serial(HW)
   
Greetings...
-- 
Klaus ter Fehn		<ktf@bc3.GUN.de>
Neanderstr. 4		{mcshh,smurf,unido}!easix!bc3!ktf
4000 Duesseldorf 1
FRG / Germany		Tel.: +49-211-676331
From: jeff@wisdom.bubble.org (Jeff Ross)
Newsgroups: biz.sco.general
Subject: Re: NFS problems! root not root?
Date: 17 Dec 92 21:00:43 GMT
Organization: Wisdom's Pony Express

In article <9212170911.aa09775@kagcpd01.ag01.kodak.COM> fietze@kagcpd01.ag01.kodak.COM writes:
>Hello Chuck,
>
>I have ODT 1.1 (still), but had similar problems.
>
>> We have two systems here loaded with SCO ODT 2.0.  One system has
>> the ODT Development System loaded, the other does not.
>>
>> :
>> 
>> Obviously, the rc startup scripts are not executed by the 'root' user during
>> startup.  What uid and gid does the system use?  Or does it use 'unknown'?
>
>They are started by init. When you do a 'nfs start' as root, you get
>similar problems on ODT 1.1: user cannot rlogin to your host due to
>authorization errors.
>
>> The 'df' command works great for ANY other user.  Thus, they are allowed to
>> 'fsstat' remote NFS filesystems, but user 'root' cannot.
>> 
>> The final piece to the puzzle appears when I do 'chmod +s /etc/mount'.  This
>> should allow all users access to the /etc/mount command (not a great idea).
>> With this done, I can log in as any other user (NOT root, he still can't do it)
>> and mount any remote NFS filesystems just fine!
>
>Root will get a UID of -1 when crossing NFS boundaries (security
>reasons) and *not* 0 (zero).

you just hit the nail on the head, unfortunatly I don't have nfs for sco,
but I have used it for some time on sun's and vax's.  basically when the
file is exported, you have an option of saying that "root" on machine1 _is_
"root".  

assuming sco has an /etc/exports do the following:
/usr/users	-access=machine1,root=machine1

>
   				Jeff
-- 

.Sig??? you want a stinkin' .Sig???
Jeff Ross
201-299-1819 (home)				jeff@wisdom.bubble.org
Newsgroups: biz.sco.general
From: fr@compu.com (Fred Rump from home)
Subject: Re: Anyone Hear of this Stuff????
Organization: CompuData Inc.
Date: Thu, 17 Dec 1992 17:38:38 GMT

apl@world.std.com (Anthony P Lawrence) writes:

>paul@openage.com (Paul A. Fischer, Sr UNIX Sys Consultant) writes:
>: Hi All,
>:
>: A customer of mine just asked me to teach a class on Pyramid Security.
>: I don't think it refers to a Pyramid UNIX system.  Does anyone have any ideas
>: on this?

>You mean like collapsing tunnels and long knifes that snap out of the
>wall and...

Hey, I would wing it. Start out with umpteen million Z levels of security and 
then work you way up the alphabet to C level and on to A-1 were nobody except
God gets to see anything.  :-)

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: apl@world.std.com (Anthony P Lawrence)
Subject: Re: Shell script poser
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Tin 1.1 PL3
Date: Tue, 15 Dec 1992 02:42:18 GMT

davidf@golem.waterloo.on.ca (David J. Fiander) writes:
: But there is a very good reason that you don't want to use the
: shell script instead of the sed or perl scripts. 

I was thinking:  this is biz.sco.general, and everybody has the
most recent versions of Xenix or Unix :-), so therefore everyone
has ksh.

I started using ksh because of command recall, but recently I've 
started to learn about it, and here is a first attempt at this
first letter capitalization with ksh:  (disclaimer:  I don't claim
to be a ksh expert, and I don't claim this is bullet-proof.  Nor
have I timed it against anything else.  It's just presented for
general interest and perhaps to help convince other SCO users to
take a closer look at ksh: there is a lot to look at!)
 
# ksh script to capitalize first letter of a line 
typeset -L1 -u first_of_string
	# defines a 1 character Upper case variable
typeset -l rest_of_string
	# defines a lower case variable
while read line
do
first_of_string="$line"
	# assigns first letter to variable, capitalizing as it goes
rest_of_string="${line#?}"
	# strips first letter and assigns the rest to lower case variable
echo $first_of_string$rest_of_string
	# print 'em
done

		Tony   apl@world.std.com

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

Newsgroups: biz.sco.general,biz.sco.opendesktop,comp.unix.sysv386,alt.bbs.unixbbs