HDTenEightyP/NetNews huggingface dataset:
From: Barry_Wolman@transarc.com
Newsgroups: comp.unix.aix
Subject: AIX LVM Metadata Area
Date: 27 Aug 92 13:32:43 GMT
Article-I.D.: transarc.webIbvv0Bwx3M1871b
Organization: Carnegie Mellon, Pittsburgh, PA

An AIX Logical Volume has N-bytes of metadata at the start of the
volume.  User code that writes to a logical volume is supposed to
avoid writing in this area.  I need to determine the value of N.
I've heard "don't write in the first page" ... does this mean N=4096?

Thanks,
Barry Wolman
From: alhy@unixhub.slac.stanford.edu (J. Scott Berg)
Newsgroups: comp.unix.aix
Subject: Re: Resume a suspended process
Date: 25 Aug 92 17:39:46 GMT
Reply-To: alhy@unixhub.slac.stanford.edu
Organization: Stanford University, dept of Physics / SLAC

In article <1992Aug25.125931.20033@nrcnet0.nrc.ca>, ng@nrccsb19.di.nrc.ca (Kai Ng) writes:
|> ng@nrccsb19.di.nrc.ca (Kai Ng) writes:
|> : Hi. The question seems trivial, but I can't find the answer. If a process
|> : is suspended, say by entering ^Z, in a window and the window is dismissed
|> : subsequently, is there a way to resume the process from a new window?
|> :
|> 
|> Here is the answer (thanks to hartmans@npc.ece.utexas.edu):
|> 
|>    kill -s cont pid
|> 
|> "cont" is the signal name of SIG_CONT (signal number 19) with the prefix
|> SIG_ dropped and is case insensitive.

I think there is a problem with this:  the output from the command
will have nowhere to go, since the tty that it was writing to is now
gone.  As far as I know, it will not take your current tty as it's new
tty.  So, it will probably stop as soon as you continue it, or just
sit there and eat cpu but not do anything  

					-Scott Berg

-- 
-------------------------------------------------------------------------------
The opinions expressed here are, of course, my own and nobody else's.
-------------------------------------------------------------------------------
J. Scott Berg
email: alhy@unixhub.slac.stanford.edu
real mail: Varian Physics
           Stanford  CA  94305-4060
phone:	(415) 926-4732 (w)
 	(415) 328-8246 (h)
-------------------------------------------------------------------------------
From: haedener@iacrs1.unibe.ch (Konrad Haedener)
Newsgroups: comp.unix.aix
Subject: Re: Running batchjobs without disturbing interactive usage, ok now?
Date: 28 Aug 92 14:39:28 GMT
Reply-To: haedener@iacrs1.unibe.ch
Followup-To: <BIS.92Aug28152036@maud.ifi.uio.no>
Organization: University of Berne

In article <BIS.92Aug28152036@maud.ifi.uio.no>, bis@ifi.uio.no (Bjorn Ivar Stark) writes:
|> We tried to run heavy batchjobs with max nicefactor (eq. 20) and
|> limited the RSS by setting the default RSS variable in
|> /etc/security/limits file, so that the interactive grafical user 
|> could do his work more or less unotified of the batch runs (we
|> hoped).
|> 
|> However in 3.1.5 this didn't work satisfactory, and we had to
|> dedicate this machine for grafical use (RS/6000 mod 550) and I
|> heard that neither the low priority nor the RSS limit was
|> implemented properly.
|> 
|> However is there any reasen that it work o.k. now in 3.2?
|> 
|> Anybody.
|>  
|> --
|> ------Vennlig hilsen-----
|> Oystein Fosli, B240
|> Norsk Hydro a.s           Ph.: (472) 739660       
|> Postboks 200		  Fax: (472) 739555
|> 1321 STABEKK	     internet: bis@ifi.uio.no
|> Norway

Two suggestions:

o  quick-and-dirty:

       #include <stdio.h>
       #include <sys/sched.h>

       main()  
       {
       pid_t procid;
       int   prio;

       printf("Enter PID:      ");
       scanf("%d", &procid);
       printf("\nEnter Priority: ");
       scanf("%d", &prio);
 
       setpri(procid,prio);
       }

   Enter the process id of your batch job and 126 as the priority
   (you need root privs). But beware: this is only an illustration of
   setpri(); terrible things will happen to your running system when
   you enter low values for the new priority.

o  solid-and-mature:

   use NQS (the Network Queueing System).

-- 
Konrad Haedener                             Phone: +41 31 65 42 25
Institute for Physical Chemistry            FAX:   +41 31 65 44 99
University of Berne
Switzerland                                 haedener@iacrs1.unibe.ch
Newsgroups: comp.unix.aix
From: jhardin@data.tamu.edu (James Hardin)
Subject: portholeClassRec in aXe
Keywords: unresolved function
Reply-To: jhardin@data.tamu.edu (James Hardin)
Organization: Department of Statistics, TAMU 
Date: Mon, 31 Aug 1992 22:48:09 GMT

  I am trying to compile aXe 3.0.1 using bsdcc and keep getting an
error about unresolved function calls. It cites portholeClassRec
if you use the -bloadmap:<loadmapfile> option. I am on a Model 550
running 3.2.1. I think I have made all of these extra X libraries
in the /usr/lpp/X11/Xamples library and have set up links from 
/usr/lib. Has anyone gotten this thing to compile? Some of our users
would love to use something other than emacs/vi and since I am trying
to get them off of the Macs and onto the RS6000's, I thought this
program would be a good selling point even though I have never
use it myself.

  Regards,

  James


-- 
------------------------------------------------------------------------------
James Hardin           |  Department of Statistics  |  College Station, Texas
jhardin@stat.tamu.edu  |  Texas A&M University      |  USA              77843
Bell: (409) 845-9447   |  FAX: (409) 845-3144       |  Campus mail stop: 3143
------------------------------------------------------------------------------
Newsgroups: comp.unix.aix
From: bis@ifi.uio.no (Bjorn Ivar Stark)
Subject: Running batchjobs without disturbing interactive usage, ok now?
Organization: Dept. of Informatics, University of Oslo, Norway
Date: Fri, 28 Aug 1992 14:20:35 GMT
Originator: bis@maud.ifi.uio.no

We tried to run heavy batchjobs with max nicefactor (eq. 20) and
limited the RSS by setting the default RSS variable in
/etc/security/limits file, so that the interactive grafical user 
could do his work more or less unotified of the batch runs (we
hoped).

However in 3.1.5 this didn't work satisfactory, and we had to
dedicate this machine for grafical use (RS/6000 mod 550) and I
heard that neither the low priority nor the RSS limit was
implemented properly.

However is there any reasen that it work o.k. now in 3.2?

Anybody.
 
--
------Vennlig hilsen-----
Oystein Fosli, B240
Norsk Hydro a.s           Ph.: (472) 739660       
Postboks 200		  Fax: (472) 739555
1321 STABEKK	     internet: bis@ifi.uio.no
Norway
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.unix.aix
Date: Thu, 27 Aug 1992 13:49:12 -0400 
From: Barry_Wolman@transarc.com
Subject: Re: Benchmark results: xlc vs gcc optimization quality

Here's another view of xlc optimization.

The Transarc Encina (TM) code base consists of at least 250K lines of
C code, including some large RPC stub modules generated by IDL.  We
discovered that it took about 4 hours to compile with -O and load the
code base on a SPARC II, but it took 17-20 hours to do the same build
on a comparable RS/6000 with xlc.  When I investigated, I found that
xlc was taking inordinate amounts of time to compile the large IDL
stubs.

I selected representative code modules written by four different, very
experienced system programmers and one of the IDL stub modules.  These
totaled 34K non-blank lines of code after include file expansion.  The
IDL stub was 19K lines.

I found that the vanilla SunOS cc compiler was quite uniform.
Compiling with -O caused the compilation time to increase by a factor
of 2.5 - 3.3.  The AIX xlc compiler showed much greater variability in
compilation times.  Using -o caused the compilation time to increase
by a factor of from 4.6 to 13.7.  The unoptimized AIX xlc compilation
times ranged from .5 to 1.5 times the unoptimized SunOS cc compilation
times, while the optimized AIX xlc compilation times ranged from 1.6
to 12.6 times the optimized SunOS cc compilation times.

The IDL stubs caused particular problems for xlc.  The unoptimized
(optimized) compilation times for the SunOS cc compiler were 80 (213)
seconds, while the times for the AIX xlc compiler were 66 (900)
seconds!  Clearly, a major component of the extra 13-16 hours of
compile time was time spent (wasted?) compiling IDL stubs with
optimization.  When performance tests showed no appreciable
performance benefit from optimized stubs, we changed our build rules
to eliminate -O for stubs.  We now compile everything except the
stub modules with -O on all supported platforms.

I filed a problem report with IBM on the slow compilation times.  They
gave me an updated xlc a few weeks ago, but there was no noticable
improvement in compile times with -O.  One of the analysts who called
me about this problem said it had something to do with the stub
modules having a large number of external variables that are declared,
but are never referenced in the generated code.  I think there's more
to the problem than this.

Has anyone else found examples of code that cause optimized xlc
compilations to take >10 times as long as unoptimized compilations.
Perhaps a better characterization of the performance profile of xlc
might help IBM improve -O compile times.


Barry Wolman

------------------

Encina is a trade mark of Transarc Corporation.
From: scott@austin.ibm.com
Newsgroups: comp.unix.aix
Subject: Re: Buggy malloc workaround
Date: 3 Sep 92 17:53:26 GMT
Organization: IBM Austin
Originator: scott@porter.austin.ibm.com


In article <Btx211.2DD@watdragon.uwaterloo.ca>, mskucher@watdragon.uwaterloo.ca (Murray S. Kucherawy [MFCF]) writes:
> My problems with putuserattr() calls are, according to IBM, caused by a bug
> in malloc implemented in AIX V3.2.  According to the man page for malloc,
> you can set the environment variable MALLOCTYPE to "3.1" and it will
> use the older version of malloc.
> 
> It's not clear whether this is to be done at runtime or compile time.
> Anyone know? My program is to be run by a shell script remotely, and it will
> be tough to ensure that the environment variable is set.

I'm sure what they meant to say was that putuserattr() has a bug in its use
of malloc which is now evident when using the AIXv3.2 malloc.  The AIXv3.2
malloc does a better job of reusing storage and so programs that don't
initialize storage correctly may break when they worked OK on AIXv3.1.

The MALLOCTYPE environment variable is used at runtime.

Scott L. Porter				IBM PSP Austin / AIX Kernel Development
                   	 		Internet: scott@glasnost.austin.ibm.com
Newsgroups: comp.unix.aix
From: ntingle@sax.stanford.edu (Nick Tingle)
Subject: Looking for Serial Term for RS6000
Organization: Los Alamos National Laboratory, NM
Date: Wed, 26 Aug 92 21:54:29 GMT

Hi !
 
I'm planning to buy a dumb serial terminal for my RS6K. Can anyone advice
me which are the best buys ? I want the cheapest (old, refurbished OK),
should work for atleast 3-6 months.
 
Can anyone tell me which serial terms should I go for ? 
 
Is there any place in San Jose/Sunnyvale/Santa Clara area where I can find
a used one ?
 
Thanks in anticipation
 
NT.
 
-------------------------------------------------------------------------
My mate stole my .sig file !!!!

Newsgroups: comp.unix.sysv286
From: rbt@tous.oau.org (Robert B. Tate)
Subject: 9track 1/2" tape drives
Summary: any ideas?
Organization: Tate Enterprises
Date: Sun, 30 Aug 1992 23:28:41 GMT


I picked up a reel-to-reel 1/2", 9 track tape deck and the interface to a
IBM 8 bit bus slot at a auction this last weekend. Its a Wangco Mod 10,
NRZI drive (HEAVY!). Its in very clean/good shape and came with PC-DOS
software (which I haven't had time to try yet). It was packaged by
Electrovalue Industrial, Inc.  sometime around 1985-90. Does anyone know
anything about this Co. and/or this package? I would like to run it under
ISC V3.2 r3.0 (and the new one when it comes out?).

Along the same lines, I have a Cipher (F880?) 1/2", 9 track tape drive
that I could use also. Is there an interface converter to let it run on a
SCSI bus (Adaptec 1540B) or would it be better to try to find direct
interface to it like the above drive?

My stats:
	ISC V3.2 r 3.0, 486/33 NoName, w/16meg mem, DPT ESDI controller
	running 2 330Meg ESDI drives, Archive 499 (60meg QIC).

Any pointers and/or info will be of great interest.


-- 
 rbt@tous.OAU.ORG  (Robert B. Tate)       | A little knowledge is a dangerous
 {ucf-cs,peora,tarpit}!tous!rbt           | thing. Any less can kill you.
Newsgroups: comp.unix.bsd
From: asklingl@immd4.informatik.uni-erlangen.de (Andreas Klingler (Inf4 - hiwi))
Subject: Re: X386 and Diamond Stealth: not solution
Organization: CSD., University of Erlangen, Germany
Date: Thu, 3 Sep 1992 12:19:14 GMT

jtsilla@damon.ccs.northeastern.edu (James Tsillas) writes:

>X386E is currently trying to convince Diamond to change their policy. We
>hope to do that by showing them that it is in their best interests.

I had just made up my mind to buy a Diamond Stealth when I heared about all
this trouble. Well, I am looking for cards from other vendors now.
So maybe you should give them a list of people who are _not_ going to buy a
card from them, unless they change their policy.
If you are doing so feel free to put my name on it.
-- 
Andreas Klingler
asklingl@informatik.uni-erlangen.de
       I'd love to help you out... Which way did you come in?
From: cappucci@crs.cl.msu.edu (Chris Cappuccio)
Newsgroups: comp.unix.bsd
Subject: Re: [?] comp.os.386bsd
Date: 1 Sep 92 17:51:31 GMT
Organization: Michigan State University

u2105545@csdvax.csd.unsw.edu.au writes:


>Hi,
>Why there isn't a newsgroup "comp.os.386bsd"?
>386bsd and BSD distribution are differnet, aren't they?

Well it's hard to start a new group and it takes time, I think they are still
forming one (not sure) and I am sure that 386BSD and BSDi are two different
things..
Newsgroups: comp.unix.bsd
From: cproto@marsh.cs.curtin.edu.au (Computer Protocol)
Subject: Re: time for comp.unix.bsd.386
Organization: Curtin University of Technology
Date: Fri, 28 Aug 1992 13:14:04 GMT


Why are some idiots keep on arguing about naming things rather then
contributing something useful?
Newsgroups: comp.unix.bsd
From: hasty@netcom.com (Amancio Hasty Jr)
Subject: Re: Small X for 386 bsd??
Date: Mon, 31 Aug 92 19:57:58 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

In article <1992Aug31.153743.24065@msuinfo.cl.msu.edu> venkates@frith.msu.edu writes:
>Hi
>Even the binary only release of X for 386bsd requires lotsa disk!,
>I was wondering (forgive me if this sounds stupid) if one trim the existing
>X release to it's barest minimum, I am only interested in having some
>sort of a windowing system running on the PC and am not paricularly
>intersted in having a vast number of fonts etc being available to me.
>On the same note, if X cannnot be made any smaller, are there other windowing
>systems that can be used?
>Thank you all in advance
>
>Venkatesh Gopinath
>Michigan state University.



You can strip the binaries and pick and choose your configuration.
If this becomes a problem, please let me know

The stock X386 1.2E 1.0.1 server with no debug symbols is about 1 MB.

Amancio Hasty
From: gjh@netman.Berkeley.EDU (Gary J. Habermann)
Newsgroups: comp.unix.bsd
Subject: FORMs with bsd spooler
Date: 4 Sep 1992 16:24:30 GMT
Organization: A poorly-installed InterNetNews site
Distribution: world
Reply-To: gjh@netman.Berkeley.EDU (Gary J. Habermann)
NNTP-Posting-Host: netman.widener.edu

Does anyone know  how to handle special forms with a BSD spooler.  I have several forms
and want to be able to control which one prints?

Gary
Newsgroups: comp.unix.bsd
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: 386bsd: {src,etc}dist won't extract
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 1 Sep 1992 08:50:52 GMT

ccml@hippo.ru.ac.za (Mike Lawrie) writes:
+---------------
| The message "too many open files" occurs when I extract srcdist and
| bindist, but there is no problem with bindist.
| Can anyone advise how they managed to do the extractions?
+---------------

Do bindist first, then use the "cat" that you just extracted from bindist
(/mnt/bin/cat, if you booted off floppy), *not* the one on the "dist" floppy,
to extract from srcdist. It'll work.


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: sp_pm@space.alcbel.be (Paul Moore)
Newsgroups: comp.unix.bsd
Subject: Problems building olvwm on SunOS 4.1.2
Date: 1 Sep 92 15:31:49 GMT
X-Received: by usenet.pa.dec.com; id AA14897; Tue, 1 Sep 92 10:51:17 -0700
X-Received: by inet-gw-1.pa.dec.com; id AA02151; Tue, 1 Sep 92 10:50:38 -0700
X-Received: from ub4b.buug.be by mcsun.EU.net with SMTPid AA28052 (5.65b/CWI-2.174); Tue, 1 Sep 1992 19:50:26 +0200
X-Received: from alcbel.UUCP by ub4b.buug.be (5.65c/ub4b_02)id AA03586; Tue, 1 Sep 1992 19:50:24 +0200
X-Received: from se.alcbel.be by alcbel.be (4.1/SMI-4.1)id AA23955; Tue, 1 Sep 92 17:29:02 +0200
X-Received: by se.alcbel.be (5.57/SE_03)id AA23591; Tue, 1 Sep 92 17:32:27 +0200
X-Received: from btmpj9.space by space.alcbel.be (4.1/SMI-4.0)id AA06199; Tue, 1 Sep 92 17:31:49 +0200
X-To: comp.unix.bsd.usenet

Hello,

I believe that there is a separate newsgroup for SunOS, but I no longer have
direct access to News, and I can't recall what it's called.

Anyway, I've been trying to build olvwm 3.2 using olvwm3.tar.Z and the two 
patch files, located on export.lcs.mit.edu:/contrib. I've encounted two 
problems:

1. I can't compile ol_button.c, due to the unknown symbol OLGX_MORE_ARROW.
   Since this symbol appears not to be used anywhere else, I simply commented
   out the two lines making use of this symbol. 

2. During, the linker cannot find the library Xext in the directory
   /usr/openwin/lib. Is this a missing library on our system configuration?
   
Can anyone help me, please?

Thanks, Paul


Email: sp_pm@space.alcbel.be       Smail: Alcatel Bell Telephone
                                          Berkenrodelei 33,
Phone: (+32) 3/829.5024                   2650 Hoboken,
                                          Belgium
Newsgroups: comp.unix.bsd
From: adrian@cs.wm.edu (Adrian T. Filipi)
Subject: 3 1/2" bootable floppy?
Keywords: 3 1/2"
Organization: The College of William and Mary
Date: Thu, 3 Sep 1992 20:31:07 GMT

	There seems to be onlly one size dist.fs file, i.e. 1.2M. Is there
some way to turn this into a 3 1/2" or do I need to have a 1.2M floppy drive?
I've checked the unofficial FAQ and seen nothing regarding this.

	Thanks in advance,

	Adrian

Newsgroups: comp.unix.bsd
From: "Andrew A. Chernov, Black Mage" <ache@astral.msk.su>
Subject: HELP: Can't install 386bsd-0.1 into own partition!
Keywords: 386BSD
Organization: Kurchatov Institute of Atomic Energy, Moscow
Date: 26 Aug 92 14:51:57 GMT

Hi, 386bsd hackers!
I have some strange troubles with this system:

Problem description:
Can't install 386BSD into 0xa5 partition, but installation on whole
disk is sucessfull.
This bug is independent of partition size and order.

'install' diagnostics:
"High level... disk storage:"
Disk parameters and partition size are correct.
After "super-block backups ..." and its numbers 'install' says:
newfs: ioctl (WDINFO): No such process
newfs: /dev/rwd0a: can't rewrite disk label

Hardware:
ST-1239A (IDE) with _real_ CMOS configuration, i.e. 1272 x 9 x 36

Thanx in advance for any helps and hints.
-- 
In-This-Life:  Andrew A. Chernov    |  "Hay mas dicha, mas contento
Internet:      ache@astral.msk.su   |  "Que adorar una hermosura
Organization:  The RELCOM Corp.,    |  "Brujuleada entre los lejos
	       Moscow, Russia       |  "De lo imposible?!"  (Calderon)
Newsgroups: comp.unix.bsd
From: hasty@netcom.com (Amancio Hasty Jr)
Subject: Re: X for 386 bsd
Date: Fri, 04 Sep 92 02:07:04 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

In article <1992Sep1.181204.5986@noose.ecn.purdue.edu> tgt@neon.ecn.purdue.edu (Conan the Librarian) writes:
>Could someone please give me an update on using X386 with alternate
>video configuration (specifically, with an ATI Graphics Ultra "8514a" card).
>I am extremely eager to try X386 out!  How soon before this is possible?
>
>Thanks.
>
>-tom
>--
Currently, there is no support for the 8514 under X for 386BSD.

The good news is that there is a driver under Linux.
I am willing to help out but I don't have an 8514.
So if you the X sources and are willing to hack,
send me e-mail.


>Tom Tobin				UUCP:     pur-ee!tgt	
>Dept. of ChE				INTERNET: tgt@ecn.purdue.edu
>Purdue University			Ma Bell:  home (317) 463-0189
>W. Lafayette, IN 47907				  office "   494-4052 


Newsgroups: comp.unix.bsd
From: iand@labtam.labtam.oz.au (Ian Donaldson)
Subject: Re: lockd on 386BSD
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
Date: Mon, 24 Aug 1992 04:34:43 GMT

arnej@Lise.Unit.NO (Arne Henrik Juul) writes:
>Anyway, I will assert that it IS an NFS problem. The following
>program:

>  fd=open("afile", O_CREAT|O_WRONLY|O_APPEND);

>Will truncate the file "afile" when you mount FROM an NFS server on a
>386bsd system ON some operating systems (at least SunOS seems to have
>this problem, and probably lots more).

>This is a bug *somewhere* in NFS, and the big question is: SunOS or
>386bsd?  Personally I'd bet that SunOS was the problem here, but
>that's only my gut feeling that Sun are unable to implement their own
>protocols according to spec.

I fixed this exact bug in an ancient NFS port a few days ago (on a SVR3.2
machine actually).  The problem was that the NFS server wasn't interpreting 
the sattr information provided in the "NFS create" call properly.

One field of sattr is the file size.  When you do creat() of the above
form, SunOS sends the file size attribute as -1 over the wire which should 
mean to the server "don't change the file size".  The server is probably 
ignoring this field and truncating the file unconditionally (at least thats what
the server I worked on did).

The fix was trivial... just recognize the size attribute and if -1, leave
the file size alone, otherwise truncate to the specified value.

Ian D
Newsgroups: comp.unix.bsd
From: jtsilla@damon.ccs.northeastern.edu (James Tsillas)
Newsgroups: comp.unix.bsd
Subject: Re: X386 and Diamond Stealth: not solution
Date: 30 Aug 92 19:06:58 GMT
	<17gmpcINN8tc@wendy-fate.UU.NET>
Organization: Northeastern University, Boston, MA


Diamond isn't releasing technical info becasue they feel they do not
wish to reveal their proprietary architecture. While Orchid's S3 card is
just an OEM of an S3 product, Diamond developed their's independently. I
believe that Diamond may be willing to disclose their technical
reference if a non-disclosure is signed. The X386E project is not going
to sign a non-disclosure.

If you have bought a Diamond product and are mad about this situation,
you may try calling Diamond and politely notifying them of your
displeasure. Unlike the DOS world, the Un*x community lives and breathes
on openness so when something like this comes along it usually bothers
people.

X386E is currently trying to convince Diamond to change their policy. We
hope to do that by showing them that it is in their best interests.

-Jim.
--
	***                                                      ***
	***  James Tsillas  jtsilla@damon.ccs.northeastern.edu   ***
	*** "He is after me. Jim is after him."                  ***
	***          - Hop on Pop, Dr. Seuss                     ***
Newsgroups: comp.unix.bsd