HDTenEightyP/NetNews huggingface dataset:
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: SGI Patches available ? (GRRRRRRRRR!!!!)
Date: 10 Apr 92 04:32:48 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <2525@contex.contex.com> frank@marvin.contex.com (Frank Perdicaro) writes:
| Regarding the Exabyte and hanging problems: Dave dont you remember the
| variable block size overwrite bug ( in 3.X ) you helped me with a few
| months ago?  It caused strange, persistent problems that could only be
| fixed with a reboot.   If I had to guess, I would guess the guy has
| found the same bug.

No, I don't.  What was the fix?  There *is* a bug in 3.3.X, where 
switching between fixed and variable block sizes does the wrong thing,
but it certainly didn't hang the system.

I just reviewed the change longs from 3.3.X to 4.0, and I don't see
anything that looks like this problem.  Of course, my checkin comments
aren't always all inclusive, but they are usually pretty verbose...

Exabyte doesn't support overwrite, except at BOT, or BOT side of FM.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi,comp.emacs
From: eric@joker.mil.ufl.edu (Eric M. Schwartz)
Subject: keyboard map for emacs on 4D/20 sgi
Followup-To: eric@mil.ufl.edu
Keywords: keyboard, emacs
Organization: Machine Intelligence Laboratory, University of Florida
Date: Wed, 8 Apr 92 12:54:46 GMT

Does anybody have the arrrow, home, end, Page Up and Page Down keys
working for a 4D/20 sgi terminal's keyboard when using emacs?  Do you have
a file for ---/lisp/term (like vt100.el but names something like iris-ansi.el)?
If no to second and yes to the first, how did you manage to do this?

Solutions will be summarized and posted.  Thanks in advance.

eric@mil.ufl.edu
Newsgroups: comp.sys.sgi
From: rck@fangio.asd.sgi.com (Robert Keller)
Subject: Re: xpsv
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: Fri, 17 Apr 1992 18:24:53 GMT

In article <30040@adm.brl.mil> beyer@bflsgu.fl.bs.dlr.de (R. Beyer) writes:
>So what is the advantage of having xvps if I have to buy DPS from SGI 
>anyhow ? If I buy DPS I get xpsview and do not need xpsv. Do I miss 
>something here ?

The implication is that xpsv is superior to xpsview.  I have never seen 
xvps, so I can't really comment on this.

If you don't want to get DPS, you can always get ghostscript 2.4 and 
ghostview 1.1.  Together they provide a very good (and inexpensive) 
way of previewing PostScript documents, even if they don't have all
the cool Adobe fonts.

...robert
From: grindley@helios.physics.utoronto.ca (Robin Grindley)
Newsgroups: comp.sys.sgi
Subject: Another f77 bug - will my programs ever compile?
Date: 17 Apr 92 01:06:24 GMT
Organization: University of Toronto Physics/Astronomy/CITA

If this gets a bit testy, i apologize, but i have been here a LONG time
today, and i am fed up. 

We originally had a problem with fortran ENTRY points not being recognized
by the debugger, which stymied us because we could not even put breakpoints
at the appropriate place to find out what was wrong. We were told to get
4.0.4 to fix this.

Today after MUCH hassle (not due to SGI, god be praised), we got 4.0.4 
installed, and i eagerly started recompiling code. To my anguish, code
which had compiled under 4.0.1 now DOES NOT compile under 4.0.4, and
the release notes did not mentions any approriate 'backwards compatibility'
flags. The problem is if you try to do a bitwise not of a parameter. The 
following code

      program frz

      integer const, var, dummy

      parameter (const = 'FF'X)

      var = 3

      write(*,'("before, var = ",I4)') var
      dummy = not(var)
      write(*,'("after var = ",I4)') var

      dummy = not(const)

      var = ior(var, dummy)

      var = ior(var,(not(const)))

      stop 
      end


will not compile, complaining on the not(const) lines:

	bad argument type to intrinsic not

(I also saw bad arg to intrinsic ior in the real code).
The not intrinsic does not change its arguments, so a parameter
should be fine. Am i going to have to go through all of my code and
put dummy=const, and use not(dummy) everywhere? If stonger type checking
was put on some intrinsics, then IT SHOULD BE IN THE RELEASE NOTES AT LEAST.
In this case i don't agree with the change, but at least i would be forewarned.
(Apologies if i did not RTFM hard enough, and there IS mention.)

Is this a bug, and should i be on guard for anything else?

robin grindley@cerebus.physics.utoronto.ca


-- 
  The opinions expressed above are fictional. Any resemblance betweens these 
  opinions and other opinions living or dead is purely coincidental.

			robin grindley@cerebus.physics.utoronto.ca
From: karron@karron.med.nyu.edu (Dan Karron (karron@nyu.edu))
Newsgroups: comp.sys.sgi
Subject: Re: 4 Have you ever seen this error.
Date: 7 Apr 92 22:49:14 GMT
Article-I.D.: adm.29948

Sorry, wrong name. 

Here is a piece of the man page...

karron:~/D.Image/D.Arenas/D.SharedProcs/D.Voronoi:266man collide

COLLIDE(1)                     Silicon Graphics                     COLLIDE(1)

NAME
     collide - look for name collisions between libraries

SYNOPSIS
     collide [-l] [-d] file  ...

DESCRIPTION
     When porting a large application a critical question is ``How do I know
     if names in this application conflict with names in libraries I must
     use?''  Collide answers that question by finding name collisions across
     archive libraries and object files.

     Given a list of files, collide finds all duplicate external names and
     writes those names to standard output.  There is no output if there are
     no conflicts.

     The -l (longform) option adds the object file names to the output; these
     are occasionally interesting.  This must be the first option to collide
     if it is specified at all.
| karron@nyu.edu (e-mail alias )         Dan Karron, Research Associate      |
| Phone: 212 263 5210 Fax: 212 263 7190  New York University Medical Center  |
| 560 First Avenue                       Digital Pager <1> (212) 397 9330    |
| New York, New York 10016               <2> 10896   <3> <your-number-here>  |
``Too busy doing to write about it, too busy writing to do anything about it.''
From: silvert@biome.bio.ns.ca (Bill Silvert)
Newsgroups: comp.sys.sgi
Subject: Re: Security hole in default /etc/passwd file under 4.0.x
Date: 6 Apr 92 13:05:51 GMT
Reply-To: silvert@biome.bio.dfo.ca (Bill Silvert)
Distribution: na
Organization: Habitat Ecology Div., Bedford Inst. Oceanography

In <j5bgc08@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:

>Come on, you are telling me that *anyone* who cares about security
>isn't going to look at the password file even once after they
>install the system?  Give me a break.  Or perhaps you are
>suggesting that we ship software with a root password as well?
>Should we set the PROM password for systems that support it as
>well?  Somewhere you have to draw the line.

Sure.  And what you are hearing from the net is advice on where to draw the
line.  Sure we should look at the password file, but when I got my PI last
year I was confused by unprotected system accounts like lp.  Since there
was no shell under 3.3.2 and I didn't understand about default shells, I
wasn't sure why the account was unprotected and I was worried about 
breaking printing if I locked the lp account.  Sure we should understand
that the root and guest accounts, etc., should be protected, but it isn't
at all clear what role the other accounts play, at least for inexperienced
system administrators.

>There are definite conflicts between security and usability.
>We don't deliberately ship systems with security holes, with
>the exception of a basicly wide open password file.  That isn't
>to say that we may not make mistakes, and that they may not be
>caught by us or our alpha sites, but we do try.

Not true.  My system was shipped in February 1991 with several known
security holes, such as the defective Mail command, and I was not informed
of the problem.  It ws only several months later that I found out about
this from a discussion on the net, even though SGI had posted a fix the
previous November (at that time I wasn't reading comp.sys.sgi, since I
didn't have an SGI system then).
-- 
------------------------------------------------------------------------
William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography
P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2.  Tel. (902)426-1577
InterNet Address: silvert@biome.bio.dfo.ca
From: sinkwitz@ifi.unizh.ch (Rainer Sinkwitz)
Newsgroups: comp.sys.sgi
Subject: Re: X11R5
Date: 14 Apr 92 19:25:25 GMT
Organization: University of Zurich, Department of Computer Science

In article <1992Apr14.152850.6046@thunder.mcrcim.mcgill.edu> panisset@thunder.mcrcim.mcgill.edu (Jean-Francois Panisset) writes:
>In article <jh0s81k@zola.esd.sgi.com> paquin@kahua.esd.sgi.com (Tom Paquin) writes:
>>In article <11228@gazette.bcm.tmc.edu>, rdargahi@wilkins.iaims.bcm.tmc.edu (Ross Dargahi) writes:
>>|> 
>>|> Anyone at SGI know when an X11R5 server will be available for the INDIGO's
>>
>>I don't have an answer for you, but I do have a question.  What
>>is it about an R5 server that you want?
>
>A tricky question. Together with a lot of people, I would probably say
>that I am mainly interested in the ASCII character "5", as a guarantee
>that I'm not falling too far behind the times (hey, I'm still running
>R3 on my RS/6000 :-( ). And since this is comp.sys.sgi, I guess demanding
>PEX would be considered a faux-pas... And since all my R5 clients seem
>to display fine on my R3 server, I guess I should be happy with an R4
>server (OK, so I don't get round buttons without Shape). Maybe
>the two things that come to mind are:
>- the font server stuff (although I'm not sure whether this depends on the
>  X server itself)

already there !!! (The server understands, only build the fs client from 
                    the sources)

>- the enhanced color models (same comment)
??????

There is lots of stuff of R5 already there, e.g. editres (all clients
understand it), xterm selections and cut-paste is O.K. like in R5, 
the Server uses .pcf fonts and X11R5 Fontserver paths. (I ran a fs on a
sun and was able to use the X11R5 Sun fonts)

Or, what do you think of (What's Release 4+):

     EDITRES(1)          X Version 11 (Release 4+)          EDITRES(1)

     NAME
          editres - a dynamic resource editor for X Toolkit
          applications

     SYNTAX
          editres [ -toolkitoption ...]


Would be nice to know what in the X11R5 RELNOTES applies already to 
the current IRIX 4.0.X release.

-- 
$$""$o  o$"""$   Rainer Sinkwitz, Multimedia Lab        sinkwitz@ifi.unizh.ch
$$  $$  $$o      University of Zurich, Switzerland       VOICE +41-1-257-4346
$$"$$o   ""$$o   Winterthurerstr. 190                     FAX +41-1-363-00-35
$$  $$  o   $$   CH-8057-Z\"urich          sinkwitz%ifi.unizh.ch@relay.eu.net
From: silvert@biome.bio.ns.ca (Bill Silvert)
Newsgroups: comp.sys.sgi
Subject: Re: caps lock LED
Date: 15 Apr 92 14:09:00 GMT
Reply-To: silvert@biome.bio.dfo.ca (Bill Silvert)
Distribution: na
Organization: Habitat Ecology Div., Bedford Inst. Oceanography

In <1992Apr14.204018.1535@lamont.ldgo.columbia.edu> dale@ldgo.columbia.edu (dale chayes) writes:

>The other day I did something (unknown, but no exotic software) that
>caused the caps-lock LED (in the upper right hand corner of my
>keyboard) to stop lighting even when the keyboard was sending all
>caps.

>IE: The keyboard was in caps-lock, but the LED didn't know it.

>I have no idea what I did to get into this state, but after I cycled
>the power (to replace a CD-ROM drive) the LED was back to normal
>behavior.

>Has anyone else see this?

Yes, it has happened to me.  It went away when I rebooted, which I do
frequently now that I have Irix 4.0.1 (although not as often as when
it was first installed, thank heavens!).
-- 
------------------------------------------------------------------------
William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography
P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2.  Tel. (902)426-1577
InterNet Address: silvert@biome.bio.dfo.ca
Newsgroups: comp.sys.sgi
From: rck@fangio.asd.sgi.com (Robert Keller)
Subject: Re: Help! I Can't See The Screen!
Organization: Silicon Graphics, Inc., Mountain View, CA
Date: Wed, 15 Apr 1992 00:53:24 GMT

senseman@lonestar.utsa.edu (David M. Senseman) writes:
>The experiment was to see if
>I could save diskspace by NFS mounting /usr/lib. 

eeek!!

>I restored /usr/lib from an Indigo XS24...
>Is there something simple I can do
>to restore the screen or must I reload the operating system?

I don't think so.  No simple solution.

Your 4D20 and XS24 have different graphics systems and therefore 
have a few different libraries (libgl_s to name just one).

It's probably be faster (and more robust) to just reinstall 
everything since every product you had installed which has files 
below /usr/lib is affected.  Be sure to set "neweroverride" in 
inst when overwriting your installed images.

...robert
Newsgroups: comp.sys.sgi
From: rck@fangio.asd.sgi.com (Robert Keller)
Subject: Re: turning off 'Confirm?' at system logoff?
Organization: Silicon Graphics, Inc., Mountain View, CA
Distribution: comp.sys.sgi
Date: Tue, 7 Apr 1992 22:13:05 GMT

porco@husc10.harvard.edu (John Porco) writes:
>I know why this is present.  I dont want it there.  

In my ~/.4Dmwmrc root menu description the logout entry causes the
_SGI_SESSION_PROPERTY to be removed from the root window.  This action
causes an immediate logout.

I'm not sure if this is the sort of thing that is guaranteed to work
this way forever.  In any case here's the interesting bit from my 
~/.4Dwmrc:

menu rootMenu
{
    "root menu"         f.title
    "refresh"           f.refresh
    "restart"           f.restart
    "reread"            f.exec "/usr/bin/X11/xrdb -load ~/.Xdefaults"
    no-label            f.separator
    "quit"              f.quit_mwm
    no-label            f.separator
    "logout"            f.exec "/usr/bin/X11/xprop -root -remove _SGI_SESSION_PROPERTY"
}

...robert
Newsgroups: comp.sys.sgi
From: melvin@ra.cgd.ucar.edu (Lee Melvin)
Subject: (NEW OWNER): troff/tbl/eqn missing on new indigo
Reply-To: melvin@ra.cgd.ucar.edu (Lee Melvin)
Organization: Climate and Global Dynamics Division/NCAR, Boulder, CO
Distribution: usa
Date: Thu, 16 Apr 1992 19:18:52 GMT

I'm installing an Indigo (the first in our division), and when I run
makewhatis I get lots of errors about troff, tbl, and eqn not being
present.  So,

Is *roff part of an optional software package (that I didn't get)?

Is *roff not distributed by SGI?  

Why does SGI include a makewhatis program but not the software (*roff) 
to make it functional?

If I can't get *roff from SGI, is there an anonymous ftp site I can grab
it from?

Thanks!

	- Lee




--
\   Lee Melvin        CGD/NCAR          (Weather freaks on the Flatirons)   /
 \  EMAIL: melvin@ncar.ucar.edu not to be confused with lee@ncar.ucar.edu  /
  \ PMAIL: who wants to know?   PHONE: likewise  MANTRA: Veni, veni, veni /
   \DISCLAIMER:  I'm not a scientist, they just let me play with the Y-MP/
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: PANIC: CPU x: KERNEL FAULT
Date: 6 Apr 92 22:04:52 GMT
Article-I.D.: zuni.j7i62ls
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Apr6.151527.5530@eagle.lerc.nasa.gov> mikef@sarah.lerc.nasa.gov (Mike J. Fuller) writes:
...

| I thought the major change in 4.0.1 was the window system, and I was willing
| to deal with the problems such drastic changes would cause.  However, I was
| not willing to deal with repeated kernel panics; this is entirely
| unacceptable in my environment, where some jobs need to run for months.  Is
| this one of those known problems which has been fixed in 4.0.{2,3,Pi,4,NaN},
| or should I open a call on it?

You should *always* open a call on something like this, without even
thinking about it.  Even if somebody tells you (here) that it is a known
problem, you may not get the release that fixes it if the TAC doesn't
associate you with the problem.

| I hate to complain like this, but just about everybody I know who has
| upgraded multiprocessor machines to 4.0.1 and uses them heavily has had some
| sort of OS trouble.  You would think that, for all the testing of 4.0 that
| SGI did internally, these sort of repeatable things would have cropped up.
| But I know I am probably asking too much -- the next thing you know I will
| want a 1-800 dialup number to search for known bugs and request patches for
| such problems.

*Report* the problems.  It is impossible for us to test every configuration,
in all the ways that all of the customers will use it, so we will always
miss some problems.  We do look for them, and there are a number of MP
systems in the company running 4.0.1, including sgi.sgi.com, our internet
gateway.  I don't remember any recent MP specific fixes for kernel panic's,
but then I don't hear about all the bug fixes, so that doesn't mean much,
particularly since I don't have an MP system.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: stephens@slowhand.wes.army.mil
Newsgroups: comp.sys.sgi
Subject: electropaint source
Date: 17 Apr 92 03:20:27 GMT


my curiosity has taken over ....

could some one tell me what algorithm is used to drive those delightful
paint chips in the screensaver "electropaint" ? 

is the source code available somewhere?

thanks
 mike stephens (stephens@slowhand.wes.army.mil)

	"Electropaint gets my vote for 'lava lamp' of the '90s"
From: glb@uvacs.cs.Virginia.EDU (Gina Bull)
Newsgroups: comp.sys.sgi
Subject: Re: Mail Problem on Indigo
Keywords: mail, Indigo
Date: 9 Apr 92 13:03:28 GMT
Article-I.D.: murdoch.1992Apr9.130328.9441
Distribution: na
Organization: University of Virginia Computer Science Department

Line 477 in the supplied /usr/lib/sendmail.cf file is:

R$*<$*..$Y>$*           $1<$2.$Y>$3                     tidy any double dot

That line should be:

R$*<$*..$Y>$*           $1<$2.$Y>$4                     tidy any double dot

The class that is matched with $Y on the left side is the third
pattern match.  In the rewrite, the original file uses $Y AND $3,
which creates a loop. I'm sure whoever wrote this ruleset intended
to use $4 there instead.

I don't use SGI's supplied sendmail.cf file, but I tried it out in
the test mode (/usr/lib/sendmail -bt -C/usr/lib/sendmail.cf) and
got a loop using the original line 477, and resolution using my
version of line 477.
From: steve@ecf.toronto.edu (Steve Kotsopoulos)
Newsgroups: comp.sys.sgi
Subject: Re: xmodmap FAQ
Date: 14 Apr 92 17:54:00 GMT
Organization: University of Toronto, Engineering Computing Facility

In article <30017@adm.brl.mil> pdi!shoshana@sgi.sgi.com (Shoshana Abrass) writes:
>
>  Even after reading the xmodmap manpage, and in fact executing the
>  exact xmodmap commands shown on said manpage, my caps-lock key is 
>  still stubbornly locking caps and my ctrl key is still ctrl'ing.
>  Manpage excerpt shown below:
>
>               !
>               ! Swap Caps_Lock and Control_L
>               !
>               remove Lock = Caps_Lock
>               remove Control = Control_L
>               keysym Control_L = Caps_Lock
>               keysym Caps_Lock = Control_L
>               add Lock = Control_L
>               add Control = Caps_Lock
>
>  But the keys still do the same old thing. Since I'm used to them  
>  being swapped, this is driving me nuts. Any pointers welcome.

I'm not sure if some FAQ is incorrect, but the xmodmap manpage is correct.

Re-read the manual again (you have the last 2 lines mixed up),
then try changing the last 2 lines to read:
	add Lock = Caps_Lock
	add Control = Control_L

It works for me :-)
-- 
Steve Kotsopoulos                   mail:   steve@ecf.toronto.edu
Systems Analyst                     bitnet: steve@ecf.UTORONTO.BITNET
Engineering Computing Facility      uucp:   uunet!utai!ecf!steve
University of Toronto               phone:  (416) 978-5898
From: slevy@lobachevskii.geom.umn.edu (Stuart Levy)
Newsgroups: comp.sys.sgi
Subject: Re: Irix 4.0.1 - why is gamma setable only by root?
Date: 13 Apr 92 20:43:45 GMT
Article-I.D.: news2.1992Apr13.204345.3677
Organization: Geometry Center, University of Minnesota

In article <12319@tamsun.tamu.edu> steve@bam-bam.tamu.edu (Steve Rikli) writes:
>...  According to the man page for /usr/sbin/gamma, only root is allowed
> to adjust its value.
>
>Why is this?  This isn't so in pre-4.0.1 IRIX, and I'm just
>curious what was being broken that necessitated the change.
>
>cheers,
>sr.
>--
>|| Steve Rikli, SysAdmin   |||  Visualization Lab               ||
>|| steve@archone.tamu.edu  |||  Texas A&M University            ||
>|| (409) 845-5691          |||  College Station, TX  77843-3137 ||

I found a couple things that may be worth knowing.

(a) you can allow anyone to set the gamma simply by making the file
	/etc/config/system.glGammaVal
    writable, but
(b) you may not want to.  I did this on an Indigo; someone reset the gamma
    to 1.0, a value that makes for nice-looking displays on other Irises
    but seems to confuse the Indigo RGB dithering algorithm.  For example,
    shades of gray became shades of magenta.  It took a while to discover why.

      Stuart Levy, Geometry Center, University of Minnesota
      slevy@geom.umn.edu
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: cron bug in 4.0.[1234]
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 7 Apr 92 19:13:37 GMT

In <29933@adm.brl.mil> lhdsy1!fred.lahabra.chevron.com!shc@uunet.uu.net (Steve Couturie) writes:
| > 1) when you send it a SIGHUP to get it to re-read the crontabs
| > 2) whenever time goes backwards (this is new in 4.0 and is most often
| > 	caused by an errant timed master/slave)
| > 3) time goes forward by more than 7 seconds.
| > 
| > Most of these cases really only happen when there is something wrong with
| > network time maintenance. If time is going backwards, cron will print
| > that it discovered this in its log (/usr/lib/cron/log) - if you
| > see a bunch of these, then you will need to restart cron.
| 
| ** Well, it happens a lot here.  I have to check the damn crons on all
|    SGI's here multiple times a day.  What a pain.  The 3.3.x cron doesn't
|    help (or at least, I do recall trying it and having it not help; 
|    maybe I'll try again -- I still have one machine here at 3.3.x.).
| 
|    It's not all the network time maintenance that's at fault.  It also
|    happens that some of the SGI boxes just don't keep time well, so the
|    timed or timeslave process just has to keep adjusting the time, and
|    sometimes (often?) that adjustment is backward.  (Our 240GTX is
|    particularly bad.)

If this is the case, something is seriously wrong.  Are  you saying
that when timed, timeslave, ntp, or whatever aren't running (and therefore
only the system interrupt and TOD clock are used), that time drifts?
If so, are you getting a lot of kernel messages on the console or
in SYSLOG?  kernel messages turn off all interrupts, including the
clock, so very many can really mess things up.  All but our oldest
machines seem to do quite well in the absence of bad time masters,
at least, around here.

|    Is a fixed version of cron available anywhere?  sgi.com???  Please?????

Not as far as I know.  Perhaps we could make it available via ftp
if enough people want it (I'm not completely clear on just what our
policy has been on things like this; a really nasty security or similar
bug would do it, but this isn't into that category).  It would have to be
for 4.0.X systems only, since I'm not sure any of us have ever tested the
new version under 3.3.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi