HDTenEightyP/NetNews huggingface dataset:
From: reh@wam.umd.edu (Richard Huddleston)
Newsgroups: comp.unix.admin
Subject: Re: temparary superuser
Date: 11 Oct 92 01:06:45 GMT
Distribution: usa
Organization: University of Maryland, College Park

In article <1992Sep28.204606.9071@ecst.csuchico.edu> helho@ecst.csuchico.edu (Weird!!) writes:
>Hi system administrators!
>
>  I am not a sys sdmin in my school. I just wanna learn more about Unix
>  . My question is how to become a root in the shell? My step is :
>   cp /bin/sh  ~myaccount
>   chmod 4777 sh 
>   chown root sh
>   sh
>
>   But I know it doesn't work because when I execute chown , user id
>   will automatically reset. Is there any way I could do such that I
>   can become a root?
>   Thanx for your attention!!    and sorry for my english :(
>
>	                                       
>						 Unix novice
>						 Ken

Heh heh heh.

If you send me $19.49, plus $.51 USENET Sales Tax (bringing the total to
$20.00), I'll be happy to explain to you why you don't want to be caught
trying to do something like you're suggesting.  If you act now, I'll even
throw in an explanation of why your system adminstrator probably wouldn't
care too much to have Unix Novices running all over his/her system with
root permissions.

Since you're apparently a Common Sense Novice, as well, that is.

-- 
Richard Huddleston  reh@wam.umd.edu  Personal opinions.

"It's after the end of the world -- don't you know that yet?" (Sun Ra)
Newsgroups: comp.unix.sysv386
From: cpcahil@virtech.uucp (Conor P. Cahill)
Subject: Re: Wangtek or Archive?? (and 60 MB tapes)
Organization: Virtual Technologies Inc.
Date: Wed, 7 Oct 1992 12:01:21 GMT

olson@anchor.esd.sgi.com (Dave Olson) writes:

>In <1992Oct06.155922.6313@wes.on.ca> tomh@wes.on.ca (Tom Haapanen) writes:
>| So is it really OK to use 60 MB tapes in a 150/250 MB drive?  Are the 
>| warnings about premature headwear really bogus?  120 MB is enough for
>| a lot of things I want to put on the tape, and I have a lot of old
>| 60 MB tapes kicking around...

>There are no such problems (head wear) using 600A tapes on any
>QIC120 or QIC150 drive that I've ever heard of.  Nor have I heard
>(ever) of any such things from any of our QIC tape drive vendors.


As I understand it, the problem is not from the short DC600 or DC6150
tapes.  The problem is from using long tapes (DC625 or DC525) in a 
tape drive that was not designed to handle them.  A tape drive sold
as a 150MB drive (especially an early one) is probably not designed
to handle the longer tapes and therefore could have a problem.

The issue is that the heads are not hard enough to withstand the extra
wear of moving in the same direction for the extended length of the
tape and that using only the longer tapes could cause some special wear
patterns on the heads that may make the tape drive no longer useful.

-- 
*** SENTINEL(tm) The ultimate Debugging Environment - email for more info ***

Conor P. Cahill              (703)430-9247            cpcahil@virtech.vti.com
Virtual Technologies, Inc.  46030 Manekin Plaza          Dulles, VA 20166 
Newsgroups: comp.unix.sysv386
From: sterling@netcom.com (Bruce Sterling Woodcock)
Subject: Kernel Tuning Parameters
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 14 Oct 1992 17:54:17 GMT

I am looking into doing some tuning of the kernel parameters in Dell 4.0
release of SVR4.  While I am familiar with some of the parameters in stune,
mtune, etc. there are several that are unfamiliar to me.  Could someone
provide a brief overview of each parameter, and/or point to some literature
that could help?  I don't need intimate details at this point... just a
general idea of what each one is for and how it affects the system.

Bruce

-- 
| sterling@netcom.com     |  "It is now quite lawful for a catholic woman to |
| sterling@oldcolo.com    |    avoid pregnancy by a resort to mathematics,   |
| bwoodcoc@nyx.cs.du.edu  |    though she is still forbidden to resort to    |
| sterling@gnu.ai.mit.edu | physics or chemistry." -H.L. Mencken (1880-1956) |
Newsgroups: comp.unix.sysv386
From: maxc0184@ucselx.sdsu.edu (Guy Cole)
Subject: File Size
Organization: San Diego State University Computing Services
Date: Fri, 16 Oct 1992 07:54:31 GMT

Greetings, Netland:
     I recently brought up a system using ESIX.  When uncompressing 
large files, I get the following error:

Filesize limit exceeded (core dumped).

     I don't have quotas enabled, and the drive has plenty of space.
I've looked in the SysAdmin Ref and SysAdmin Guide and can't find
any reference to this.

     I would appreciate any pointers.  Please send responses here
to this group or email me at cguy@titan.sdsu.edu

     Thanks in advance!
        Guy
From: k2ph@dxis.att.com (Bob Schreibmaier)
Newsgroups: comp.unix.sysv386
Subject: DMALIMIT?
Date: 11 Oct 92 11:34:32 GMT
Organization: QRM Central, Kresgeville, PA

I've notice that my AT&T System V/386 Release 3.2.3 UNIX
boots with the message:

WARNING: DMALIMIT Not Specified In /etc/default/boot

It seems to run with no problem, but I wonder if I should
be setting this to something.  Anybody have an opinion?
If so, what should it be set to?

Thanks in advance for your help.

Cheers,
Bob

-- 
-------------------------------------------------------------------
| Bob Schreibmaier K2PH | UUCP:     att!dxis!k2ph     |   Free    |
| (a.k.a. "The QRPer")  | INTERNET: k2ph@dxis.att.com |    the    |
| Kresgeville, PA       | ICBM:     40o55'N 75o30'W   | Intel 386 |
-------------------------------------------------------------------
Newsgroups: comp.unix.sysv386
From: j4jbail@srv.PacBell.COM (Jack Bailey)
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Controllers
Organization: Pacific * Bell
Date: Mon, 12 Oct 1992 17:51:03 GMT

In article <1992Oct12.115949.1154@dlpinc00.rn.com> dlparker@dlpinc00.rn.com (David L. Parker) writes:
>In article <1992Oct11.015901.27877@PacBell.COM> j4jbail@srv.PacBell.COM (Jack Bailey) writes:
>>In article <Bvwy64.4tF@maxed.amg.com> ed@maxed.amg.com (Ed Whittemore) writes:
>>>
>>>Our results show, that if we take the system you have above, and add
>>>another 32 MB of RAM ( cheaper than the PSI with 20 MB cache ),
>>>and for ISC 3.0, set NBUF to 16000 and NHBUF to 16384, we will get 
>>>even better performance, keeping the 174(x).
>>
>>So why can't I do this *and* add a disk cacheing controller?
>
>Do it and let us know what happens, i.e., performance with 32MB & no
>cacheing controller and 16000/16384 NBUF/NHBUF; with 16MB and cacheing 
>controller, normal NBUF/NHBUF; etc...  
>
>I'd say that should answer any absolute performance questions as well as
>relative cost/performance questions.  

I'll use iozone to benchmark the system as it is configured now,
and the with the parameters given above, and post the results.

-- 
J.J.Bailey	j4jbail@srv.pacbell.com
Contractor	510.823.6453
Newsgroups: comp.unix.sysv386,comp.unix.sys5.r4
From: larry@gator.rn.com (Larry Snyder)
Subject: Re: New ESIX 4.0.3 User Questions
Organization: The Gator Conferencing System 219-289-3745 
Date: Mon, 12 Oct 1992 16:58:27 GMT

orville%weyrich@uunet.uu.net (Orville R. Weyrich) writes:

>1) FAS -- Is it useful for ESIX 4.0.3? I certainly liked it for Microport.
>	I have also heard something about  SAS. Is this useful for my ESIX?

SAS is for streams such as SVR4, where as FAS is for 3.2 

>2) File systems -- I have a choice of S5, S52K, and UFS. What are the

ufs is by far the fastest and supports long file names, symbolic links,
and large amounts of inodes (>65K like for news partitions)

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry
From: apl@world.std.com (Anthony P Lawrence)
Newsgroups: comp.unix.sysv386
Subject: Re: USL's SVR4.2, when?
Date: 16 Oct 92 10:11:40 GMT
Distribution: comp.unix.sysv386
Organization: The World Public Access UNIX, Brookline, MA

In article <id.D43U.O91@ferranti.com> peter@ferranti.com (peter da silva) writes:
>
>I don't know if NT will be a contender, but OS/2 (much as I hate to admit it)
>already is. If UNIX Lite doesn't target OS/2 on price, it's dead. And I
>really hate OS/2's DOS derived API.
>-- 

But does anybody really run OS/2?  I'm not trying to be a wise guy at
all, but I see an awful lot of clients in the course of a year, and
I've run into OS/2 exactly once.  I also see a fair number of programmers
and consultants, and again, only one currently is focusing on OS/2.

Windows is everywhere. OS/2 is invisible. Gosh, I've seen VM/386 more often 
than OS/2!



		Tony

Lawrence & Clark, Inc		(617) 762-0707	(206) 323-2864
Xenix/Unix support,etc 	 	 Boston		 Seattle
Xref: sparky comp.unix.sysv386:15598 gnu.gdb.bug:1124
From: voder!wlbr!WLV.IIPO.GTEGSC.COM!amc@ucbvax.berkeley.edu (Allen M. Cohen)
Newsgroups: comp.unix.sysv386,gnu.gdb.bug
Subject: gdb 4.6 does not recognize ISC 3.0 core dump files
Date: 14 Oct 92 21:22:40 GMT
Followup-To: comp.unix.sysv386,gnu.gdb.bug
Organization: GTE Government Systems
Apparently-To: voder!ucbvax!gnu-gdb-bug

After installing the ISC patch to gdb 4.6, I still
can't get gdb to read a core file:
e.g.: gdb a.out core
      core is not a core dump: File format not recognized

I did ./configure i386-isc-sysv32  (I'm using ISC 3.0)

Notes:
1) I added -D_XOPEN_SOURCE and -posix to CFLAGS
1a) Also added -lcposix to CC loading command.
2) in gdb/Makefile, ./munch invokes "head", which we don't have!
   We have tail, but not head.
-- 
<> Allen M. Cohen -- Autologic, Inc. 1050 Rancho Conejo Blvd.,T.O. Ca.91320 <>
<> 1853 Stonesgate St.             Internet:  amc@IIPO.GTEGSC.COM           <>
<> Westlake Village, Ca. 91361     Telephone: (805) 498-9611 ext. 195       <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
From: kwok@athena.cs.uga.edu (Leon Kwok)
Newsgroups: comp.unix.sysv386
Subject: ISC 3.0: How do I use /etc/hosts AND the nameserver?
Date: 7 Oct 92 20:37:55 GMT
Organization: University of Georgia, Athens

I am running Interactive 3.0 on a 386.  I have successfully configured
/etc/resolv.conf so that programs like telnet, rlogin, etc. use the
nameserver for hostname resolution.  However, I would also like to have
these programs look in /etc/hosts if the nameserver is unable to resolve
the hostname.  I have noted that 'ping' seems to look at both the
nameserver and /etc/hosts, for some reason.

Does anyone know how to "turn on" /etc/hosts and nameserver resolution?

Any help would be appreciated ...

Please e-mail, and I will summarize if there is interest.

--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Leon K. Kwok                       + bitnet  : ST28@UGA               +
+ Management Science                 + internet: kwok@athena.cs.uga.edu +
+ University of Georgia              + phone # : (706) 542-8067         +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Newsgroups: comp.unix.sysv386
From: sean@utoday.com (Sean Fulton)
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Controllers
Organization: UNIX Today!
Date: Tue, 13 Oct 92 12:43:40 GMT

In article <BvyMF5.uH@maxed.amg.com> ed@maxed.amg.com (Ed Whittemore) writes:
>
>I guess you came in a little late in this discussion.
>
>The point is you CAN of course add both system buffers and a cacheing 
>controller.
>
>It just won't help.
>
>In fact, performance will be worse than with just the system cache.
>
>The problem is writing thru, first the system cache, then the disk 
>cache, and finally to disk. 
>
>Your caches are redundant, not doubled. And the system caches is the 
>better one.
>-- 
>Ed Whittemore   uunet!maxed!ed   ed@maxed.amg.com
>American Micro Group, Inc.   201-944-3293

Well, here's a question: I have 32 M RAM on my EISA machine, and a
Mylex DCE376 with 4 M cache. I ran tunesh and let it configure my
kernel.

Now, how do I get the best performance out of what I've got? From what
I'm reading here, it seems as though it makes more sense to pull the 4
M SIMMS off the mylex and add them to my memory card. Is this correct?
Or is there a way to make use of the 4 M on the Mylex.

These abstract arguments about which is better are good, but getting
hard to follow. I, like perhaps others reading this list, am wondering
how to apply this discussion to my own equipment.

sean
From: rsj@wa4mei (Randy Jarrett)
Newsgroups: comp.unix.sysv386
Subject: Re: ISC update: v3.1?
Date: 11 Oct 92 04:15:21 GMT
Organization: Amateur Radio Gateway WA4MEI, Chamblee, GA

In <Bvwyqq.4yF@maxed.amg.com> ed@maxed.amg.com (Ed Whittemore) writes:

  >In article <1992Oct10.122345.1518@dlpinc00.rn.com> dlparker@dlpinc00.rn.com (David L. Parker) writes:
  >>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

  >What came out in August was 3.01. It does not have symbolic links, long
  >filenames.

  >The included Korn Shell does not have job control.

The ksh that they included was a very old version '86a' and has
all kinds of problems.

  >The stated policy of SunSoft is to support the two different product 
  >lines indefinitely. 

  >Solaris 2.0 is not replacing Interactive.

  >SunSoft say they are considering releasing a series of technical and
  >functional updates (not new releases) which may include such things
  >as job control for the ksh, full DOS 5.0 support for VP/ix, symlinks
  >and other things.

They also broke some other things such as the getty.  Several people
that have upgraded are having problems and end up going back to the old
version.

I did get the same information when I called about the symlinks and file-
names.

Hopefully they will fix the filesystems to handle more inodes.


Randy

-- 
Randy Jarrett  WA4MEI 
UUCP  ...!{emory,gatech}!wa4mei!rsj   | MAIL: 54 Patterson Rd.
PHONE +1 404 822 4073		      | Lawrenceville, GA 30244
Newsgroups: comp.unix.sysv386
From: tep@engr.uark.edu (Tim Peoples)
Subject: WANTED: Z-Modem binaries for SCO 3.2.2 or 3.2.4
Summary: Ain't got no Dev-Sys
Keywords: SCO binary zmodem
Reply-To: tep@engr.uark.edu
Organization: University of Arkansas
Organiztion: University of Arkansas, Dept. of Computer Systems Engineering
Date: Thu, 15 Oct 1992 17:50:36 GMT


   Does anyone have the rz/sz package available in binary form for
SCO Unix.  I sure could use a copy.  (Convincing the boss man to
shell out for a dev/sys is not very easy).  

   Thanx, for your help.  (email responses please, if it's not
   too much trouble)

Thanx again,
Tim

-- 

+--------------------------------------+-------------------------------------+
| Tim Peoples                          | The time has come the hacker said   |
| tep@engr.uark.edu                    | to talk of many things,             |
| Dept. of Computer Systems Engineering| of simms and sockets and semaphores |
| University of Arkansas, Fayetteville | of processes and pings....          |
+--------------------------------------+-------------------------------------+
|    I need no disclaimer; nobody listens to what I have to say anyway!!     |
+----------------------------------------------------------------------------+

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: Sun, 11 Oct 1992 13:49:52 GMT

In article <1992Oct11.015901.27877@PacBell.COM> j4jbail@srv.PacBell.COM (Jack Bailey) writes:
>In article <Bvwy64.4tF@maxed.amg.com> ed@maxed.amg.com (Ed Whittemore) writes:
>>
>>To make the comparison fair you would have to allocate buffers of
>>a similar size ( as that in the hardware cache  )to the OS, via
>>NBUF/ NHBUF or BUFHWM, and then compare. 
>
>What does "fair" have to do with anything?  A disk cacheing
>controller was added, and the system response time was improved.
>If you can do other things to make the system faster, then go for
>it.  The point is that the cacheing controller made a positive
>difference.
>
>>Our results show, that if we take the system you have above, and add
>>another 32 MB of RAM ( cheaper than the PSI with 20 MB cache ),
>>and for ISC 3.0, set NBUF to 16000 and NHBUF to 16384, we will get 
>>even better performance, keeping the 174(x).
>
>So why can't I do this *and* add a disk cacheing controller?
>
>-- 
>J.J.Bailey	j4jbail@srv.pacbell.com
>Contractor	510.823.6453

I guess you came in a little late in this discussion.

The point is you CAN of course add both system buffers and a cacheing 
controller.

It just won't help.

In fact, performance will be worse than with just the system cache.

The problem is writing thru, first the system cache, then the disk 
cache, and finally to disk. 

Your caches are redundant, not doubled. And the system caches is the 
better one.
-- 
Ed Whittemore   uunet!maxed!ed   ed@maxed.amg.com
American Micro Group, Inc.   201-944-3293
Newsgroups: comp.unix.sysv386,comp.unix.sys5.r4,comp.unix.sys5.r3,comp.unix.pc-clone.32bit,comp.unix.bsd,comp.os.linux,comp.os.mach,comp.windows.x
From: kdenning@portal.hq.videocart.com (Karl Denninger)
Subject: Re: Announcing the availability of XFree86 1.1
Summary: More on this and unbundling
Organization: VideOcart Inc.
Date: Fri, 9 Oct 1992 16:25:45 GMT

In article <Bvux69.Az2@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes:
>In article <1992Oct7.194931.16296@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>>| This, by the way, is a perfect example of why SVR4 is better than SCO.
>>| We have a single binary kit, ~20MB compressed, that works on SVR4 from 7 
>>| different vendors.  
>>This may come as a shock, but V.3 worked that way, too, and Xenix/386
>>binaries will run on virtually anything. 
>
>	Bill, I have an idea that this refers to the fact that most
>	(if not all) r4s are pretty standard, specially in the networking
>	code.  Believe me, a networking program like X is NOT compatible
>	with all svr3's.  Back then, everyone did their network interface
>	different than everyone else.

Let me poke at that a bit.

The REASON that this is true in SVR4 is that there is a >bundled< IP stack
and assorted related items in the base OS.  Thus, the standardization which
makes possible the distribution of binary objects using these facilities is
a result of the bundled approach.

SVR3.x didn't work this way because TCP/IP was an add-on.  As a result every
maker did it differently, and the libraries from one would not work with the
other.  Thus, there was no standardization.

This, IMHO, is one of the best arguments for bundling a known set of
functionality in a release.  By doing this you nearly guarantee
compatibility across vendors.  This is a powerful argument for SVR4 and
related items...

-- 
Karl Denninger 		Inet:  kdenning@hq.videocart.com
VideOcart Inc.		Voice: (312) 987-5022
From: bob@obiwan.uucp (Bob Willcox)
Newsgroups: comp.unix.sysv386
Subject: Smail smtp support with ESIX 5.3.2D??
Date: 8 Oct 92 08:02:17 GMT
Organization: Bob's Place, Austin TX

Hello

I have been working on getting an Ethernet lan running between my three
systems here at home and have discovered that smail 3.1.28 doesn't seem
to work too well (yet) with ESIX's (5.3.2D) flavor of TCP/IP.  When I
rebuild smail with BSD_NETWORKING set and attempt to run
"/usr/lib/sendmail -bd" I get a core dump.  Before I spend much time on
this, I was wondering if others may have passed down this path before me
and can lead the way.

BTW: I have been told that ESIX has different sockets than everyone else,
but unfortunately, I have no documentation for the ESIX flavor.

Thanks in advance for any help or pointers,
-- 
Bob Willcox                ...!{rutgers|ames}!cs.utexas.edu!uudell!obiwan!bob
Phone: 512 258-4224 (home)
       512 838-3914 (work)
Newsgroups: comp.unix.sysv386
From: j4jbail@srv.PacBell.COM (Jack Bailey)
Subject: Re: Unix: Cacheing EISA SCSI vs. Non-cacheing EISA SCSI Controllers
Organization: Pacific * Bell
Date: Fri, 9 Oct 1992 19:27:43 GMT

The consensus among the participants of this discussion seems to
be that disk cacheing controllers are a waste of money.  My
opinion is that it depends upon the situation.

A friend of mine in the consulting business has a client running
a database application on Interactive 3.0.  The system is a
486/33 EISA with 32M memory.  Originally the system was
configured with the Adaptec 17xx (I don't remember the number).

Normally there are about 7 users banging on the 10-12M database
throughout the day.  The client considered the overall
performance of the application acceptable, with the exception of
one report which took just over 15 minutes to run.  Further, the
performance of the system was poor while the report was being
run.  The report was being run often enough to warrant some
action.

Money not being a problem, the consultant installed a PSI
controller with 4M memory, using the driver provided by
Interactive.  Not much difference, perhaps worse.  With 8M
memory, there was a noticeable improvement.  The current
configuration is 20M cache.  The system "feels" tremendously
fast.  The report now take 9 minutes to run, and while it is
running, no one seems to notice.

To counter "the disk blocks are already cached by UNIX" argument,
I just logged in and made a new kernel.  22 seconds.

Here are a couple of other important details: no kernel tuning
whatsoever was done after the installation.  The database itself
is some proprietary hodge-podge junk pile.  No attempt was made
to install or test the database on a 2K filesystem or the VFFS.
Normally the system does no swapping.

I'm not arguing whether or not other alternatives should have
been explored.  My point is that making blanket statements
are simply generalizations as should be treated as such.

-- 
J.J.Bailey	j4jbail@srv.pacbell.com
Contractor	510.823.6453
From: wadswort@babss.UUCP (John H. Wadsworth)
Newsgroups: comp.unix.sysv386
Subject: Re: DTK BIOS/Chipset systems...
Date: 15 Oct 92 13:11:47 GMT
Followup-To: comp.unix.sysv386
Distribution: usa
Organization: Bell Atlantic Business Systems Service Branford, Ct.

In article <1992Oct09.174320.11511@attics.rn.com> rdr@attics.rn.com (Dean Riddlebarger) writes:
>For 386 UNIX and/or Windows 3.1 installations, has anyone noticed any
>major compatibility problems with systems based on the DTK BIOS and
>chipset?  Especially 486 machines?

There have been some problems with dtk machines. Usually they are fine
for dos but may be flaky when pushed to run windows or unix-like os's.
I prefer to use Technology Power motherboards.
Newsgroups: comp.unix.sysv386