HDTenEightyP/NetNews huggingface dataset:
From: edwin@cs.ruu.nl (Edwin Kremer)
Newsgroups: comp.sys.sgi
Subject: Re: strange problem running newaliases (or NFS mounting /usr/mail)
Date: 8 Apr 92 13:31:39 GMT
Organization: Utrecht University, Dept. of Computer Science

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

   | In <ianh.702543090@morgana> ianh@resmel.bhp.com.au (Ian Hoyle) writes:
   | 
   | | /usr/lib/aliases: line 19: cannot alias non-local names
   | 
   | Sounds like you have an alias with a period or other illegal
   | character in it.  I don't remember seeing anything else that
   | would cause this, although I'm not a sendmail wizard.

I'll drop in with another guess if you don't mind. Could it be that in
your configuration (central mail host, NFS mounted /usr/mail and delivery
__ONLY__ on the central mail host) you've modified the sendmail rewrite
rules to never deliver anything local, but instead always forward it to
the central mail host, **even** if the addressee would be considered a
local address???

If this is true, that the reason why you can't "newaliases" on the
Indigo: newaliases (link to sendmail) runs the sendmail.cf file to
see what address re-writing is needed and finds out that not even a
single address is parsed down to "local" and therefore refuses to alias
"non-local" names.

I'm not a sendmail wizard either, but hope this helps...


		regards,
						--[ Edwin ]--
-- 
Edwin Kremer, systems and network administrator.  [NIC-Whois handle: EHK3]
     Department of Computer Science,  Utrecht University,  The Netherlands
     Email: edwin@cs.ruu.nl                NeXT-mail: edwin@edge.cs.ruu.nl
Newsgroups: comp.sys.sgi
From: paquin@kahua.esd.sgi.com (Tom Paquin)
Subject: Re: X11R5
Organization: Silicon Graphics Inc.
Date: Tue, 14 Apr 92 02:16:47 GMT

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?

-- 

		-Tom
*****
Opinions are mine, etc.
From: corkum@csri.toronto.edu (Brent Thomas Corkum)
Newsgroups: comp.sys.sgi
Subject: Getting from showcase to rgb files to my Seiko printer
Date: 16 Apr 92 20:29:31 GMT
Organization: DVL, University of Toronto


 My problem is that I want to use showcase to add text to some images that
I capture off the screen. I then want to send them to my Seiko printer which
excepts rgb files. The problem is that showcase doesn't output rgb files
(why, I don't know???) but postscript files. Without recapturing a showcase
screen is there any way to EASILY get from an image modified in showcase
to a rgb file?

Brent
Newsgroups: comp.sys.sgi
From: daveh@xtenk.wpd.sgi.com (David Higgen)
Subject: Re: Need directory limits help ???
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 10 Apr 1992 19:53:10 GMT

In article <29993@adm.brl.mil>, fred@poly2.nist.gov (Frederick R. Phelan Jr.) writes:
> 
> Does anybody know where can I find the following info:
> 
> 1. The limit on how many files that can be stored in one
>    directory (with IRIX of course).

There is no hard limit. However, searches for entries get slow if you have
too many in a single directory. You should try to avoid going over a
couple of thousand, as a rule of thumb.

> 2. The limit to the size of a directory.

Don't really see why this matters... but given typical directory growth
patterns & the habits of efs, I would say about 12,582,912 bytes.

("*Approximately* four thousand nine hundred and twenty eight point one to one, 
Mr Spock?"   "I try to be accurate, Captain"...)

You would never want to use a directory of anything approaching this size!

> 3. The limit to the number of characters in
>    a file name including the path.

param.h:#define MAXPATHLEN      1024    /* maximum pathname length */

The maximum length of any individual pathname component is 255 bytes
(imposed by efs on-disk directory structures); defined in 
include/sys/fs/efs_dir.h


		Dave Higgen (daveh@xtenk.wpd.sgi.com)
From: gaumondp@ERE.UMontreal.CA (Gaumond Pierre)
Newsgroups: comp.sys.sgi
Subject: du: bug or unclear definition?
Keywords: du
Date: 9 Apr 92 15:42:48 GMT
Organization: Universite de Montreal

I have compared the results given by "du" and the accounting program "acctdusg".
Here is what I obtained:

% du -s
1894	.

% find $home -print | /usr/lib/acct/acctdusg 
04910	gaumondp	   1924

The difference between both program (30 blocks) correspond exactly to the space
occupied by sub-directories entries, including the home and parent ($home/..)
sub-directories.

Should it be considered as a bug in du?

-- 
Pierre Gaumond.        gaumondp@ERE.UMontreal.CA
Services Informatiques, Universite de Montreal. 
C.P. 6128, Succursale "A", Montreal,            
Quebec, Canada.   H3C 3J7                       
Newsgroups: comp.sys.sgi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: SLIP configuration aid wanted
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 16 Apr 1992 06:47:55 GMT

In article <1992Apr15.204029.14426@urz.unibas.ch>, doelz@urz.unibas.ch writes:
> > 
> Thanks, it worked out with netsnoop.

Good news.  Many of us would like to see netsnoop bundled in the some
basic or very low cost part of the system, because it helps solve such
problems.  If many customers demanded it, maybe the appropriate marketing
people would agree.  On the other hand, they might decide it is too
valuable, and put it in its own $10,000 option.   Such is life.

>                                      The problem I am now looking into is 
> tha handshake. I have a 7 wire communication on the interface, i.e., 
> 2/3, RTS/CTS, DTR/DSR, ans seem to get random hangups, in particular 
> with VAX systems (vt100). The interface analyzer seems to get no 
> extraordinary signals, and the handshake is still ok on other windows (i.e
> if I have multilpe connections, one window gets stuck and the other
> continues). 
> 
> The speed is currently 9600 baud. Dirct wire in between Mac and 320 9pin. 

Of course, the best way to cope with link hangups is to use `slip -c` to
"camp" on the line, causing slip to re-connect after each failure.  As I
recall, your VAX is doing the originating, so this might not help.  The
only cause I can suggest for such problems is cross talk between data lines
and DCD.  Decades ago I found resistors and cap's useful for keeping DCD
smooth with 9600 b/s over 500 foot runs of cheap 50-pair telephone cable.

If only one TCP circuit gets stuck but the link stays up, then the problem
is not directly related to SLIP.  I have seen data dependent problems in
ethernet drivers which only seem to happen under the pressure gatewaying
default 512-byte MTU TCP packets used by SLIP.  To investigate such A
problem, again use netsnoop, but filter out all traffic except that for the
two ports.  Such problems often appear as IP or TCP checksum error and
always as TCP retransmissions.

Other causes for individually stuck windows include control-S typed in
the window and so on, but I assume you know all about that.


Vernon Schryver,   vjs@sgi.com
From: gary@enigma.asd.sgi.com (Wizard of OZ)
Newsgroups: comp.sys.sgi
Subject: Re: Problem with pfa
Date: 8 Apr 92 23:16:03 GMT
Article-I.D.: twilight.ja8kpjo
Reply-To: gary@sgi.com
Organization: Silicon Graphics Computer Systems, Mountain View, CA

In article <29965@adm.brl.mil>, bob@caw2.4950tw.wpafb.af.mil (Bob Plested) writes:
|> From: bob@caw2.4950tw.wpafb.af.mil (Bob Plested)
|> 
|> I ran the Fortran accelerator on the following subroutine and got back
|> a routine with no executable statements. 
|> 
|> 	Subroutine vctrs (panel_count)
|> 
|> 	Integer i, panel_count
|> 	Real x(101), z(101), cnpt(100,2), nvec(100,2), len(100)
|> 
|> 	Common / geom / x, z
|> 	Common / deriv / cnpt nvec len

                            ^    ^
You need comma delimeters here. This is a variable named 'cnptnveclen'. 

|> 
|> Because (I guess) I pass the results of the do loop through common blocks,
|> the optimizer doesn't think I ever need them. But I do!
|> 

Truely the variables len, cnpt, and nvec have a scope of this routine and
CAN be optimized out. If you fix the typos, then they won't be optimized out.


|> Bob Plested                    bob@caw2.4950tw.wpafb.af.mil
|> 4950th Test Wing/FFDA              134.136.241.11 
|> (513) 257-6809 DSN 787-6809
|> 

-- 

Gary Griffin				I just hope I'm still dreamin'
gary@sgi.com				'cause if this is for real
					I'm gonna get very depressed
Think WORLDWIDE			
							Howard T Duck
From: frank@marvin.contex.com (Frank Perdicaro)
Newsgroups: comp.sys.sgi
Subject: Re: 'Drive'
Keywords: Demo Indigo Drive
Date: 14 Apr 92 16:19:14 GMT
Organization: Xyvision Design Systems

Yes, I know it, and I want a copy of it.  I also saw the clouds demo
( to the B52s no less ), and I want that.  Email me if you find it.


-- 
	 Frank E Perdicaro, Systems Admin, etc.		Xyvision Color Systems
      Legalize guns, drugs and cash...today.		101 Edgewater Drive
   inhouse: frank@marvin, x5572				Wakefield MA
outhouse: frank@contex.com, 617-245-4100x5572		018801285
From: dasilva@nervi.ced.berkeley.edu (Ruieta Da Silva)
Newsgroups: comp.sys.sgi
Subject: Re: Scanner Installation on Indigo (was PI)
Date: 13 Apr 1992 07:35:27 GMT
Organization: University of California
NNTP-Posting-Host: nervi.ced.berkeley.edu
Keywords: Scanner


On a similar note, is there any support for the 
Hewlett-Packard Scanjet IIC?

Deanan
From: doelz@urz.unibas.ch
Newsgroups: comp.sys.sgi
Subject: SLIP over LAT? (SLIP configuration aid wanted)
Date: 16 Apr 92 16:55:20 MET
Organization: University of Basel, Switzerland

In article <jjt6e0s@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> If only one TCP circuit gets stuck but the link stays up, then the problem
> is not directly related to SLIP.  I have seen data dependent problems in
> ethernet drivers which only seem to happen under the pressure gatewaying
> default 512-byte MTU TCP packets used by SLIP.  To investigate such A
> problem, again use netsnoop, but filter out all traffic except that for the
> two ports.  Such problems often appear as IP or TCP checksum error and
> always as TCP retransmissions.
>
It turns out that pinging with increasing packet size results in hangups 
if the packets are larger than 250. This problem can be overcome with starting
SLIP as -s 256 but admittedly on the MAC there are the two additional 
parameters MSS and MWIN which I am not sure how to interpret. MSS must be 
set to 128 in order to get it work, as MWIN, and suddenly protocol overhead 
is an issue. The documentation is not helpful on this one. I would appreciate 
further advice on this. 

On another issue; in the final stage I want to do SLIP over LAT. I.e., we have 
serial LAT connection in every laboratory, and if I implement 4DLT on an 
Indigo I imagine that this should get me the SLIP to the terminal servers and, 
finally, to the Macs. Preliminary testing has indicated that it sort of 
works (just the parameter problem as mentioned above). However, as SLIP is 
made for serial lines, and there are only 2 of them on an Indigo, are there 
restrictions on how many sl interfaces can be served by one box? What is 
the overhead for routed? How does 4DLT behave in case of 20 simultaneous 
sessions? Advice welcome. 

Regards 
Reinhard 
 

************************************************************************
    Dr. Reinhard Doelz            *     EAN     doelz@urz.unibas.ch
      Biocomputing                *     DECNET  20579::48130::doelz
Biozentrum der Universitaet       *     X25     psi%022846211142::embnet
   Klingelbergstrasse 70          *     FAX     x41 61 261- 6760 
     CH 4056 Basel                *     TEL     x41 61 267- 2076 or 2247   
************************************************************************
From: bmarsh@cod.NOSC.MIL (William C. Marsh)
Newsgroups: comp.sys.sgi
Subject: Re: Possible bug in Font Manager library ???
Date: 9 Apr 92 22:26:54 GMT
Article-I.D.: cod.3755
Organization: Naval Ocean Systems Center, San Diego


I have seen this same type of bug, but so far I have been able to program
around it.  In my case, the bug only occurred after an itimer() 'went off'
before I wrote something with the font I had registered.  By forcing a
write before setting up the itimer, there was no segmentation fault any
more.

Note: This is in a 4D35 running 4.0.1

Bill
-- 
Bill Marsh, Naval Ocean Systems Center, San Diego, CA
{arpa,mil}net: bmarsh@cod.nosc.mil
uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh
"If you are not part of the solution, you're part of the problem..."
Newsgroups: comp.sys.sgi
From: grendel@fen.arc.nasa.gov (Raymond E. Suorsa)
Subject: Re:  m_fork() v.s. sproc()... Which to use?
Keywords: m_fork sproc shared memory
Reply-To: grendel@windchime.arc.nasa.gov
Organization: NASA Ames
Date: Tue, 14 Apr 1992 17:45:59 GMT


Thanks to all who replied with hints.  I discovered that I am getting
poor speedups using m_fork() because the parallel part of the
algorithm is performing image processing operations which swamp each
processors local cache.  Thus a very high number of memory barriers (I
guess) and cache misses are occurring in each processor.  Thus, causing
the old shared memory/local cache bottle neck.

I was able to get the expected speedups by making the data set small
enough.

-Thanks again.


  __o   Ray Suorsa,
  \<,   grendel@windchime.arc.nasa.gov,
()/ ()  NASA/Ames (415)604-6334
From: k1w8221@sc.tamu.edu (Khalid Sarwar Warraich)
Newsgroups: comp.sys.sgi
Subject: debug process file, what is it?
Keywords: debug process file, question
Date: 10 Apr 92 17:24:43 GMT
Reply-To: k1w8221@sc.tamu.edu
Organization: Supercomputer Center, Texas A&M University

Hi,

I need help figuring out what a 'debug process file' is.  First some
background:

We have a personal IRIS running IRIX System V.3.  It has among other
partitions the following partition:

Filesystem                 Type     blocks    use    avail  %use   Mounted on
..
/debug                      dbg     103808   10576   93232   10%    /debug

If I cd into /debug and do a file on one of the files, I get the following
output (exact command typed in is "debug 00001"):

00001:            debug process file

There seems to be one file per active process.  For example when I do an ls
command, it will show me a file called 03001, a subsequent ls will  now show
that but show 03001 and so on.

My question:

What are these files?  Which process is generating them?  How can we turn them
off?  Should we turn them off?  Could we claim the disk space from /debug?
Are there other things I should be aware of?

E-mail is preferred, but I will read the group for my answer.

Thanks!

---
Khalid Sarwar Warraich
Supercomputer Center
Texas A&M University
warr@kashmir.tamu.edu
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 12:57:54 GMT
Reply-To: silvert@biome.bio.dfo.ca (Bill Silvert)
Distribution: na
Organization: Habitat Ecology Div., Bedford Inst. Oceanography

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

>| >|> But what excuse is there for leaving lp as an open account?
>| >
>| >The reason that lp is left open is that remote printing (when you
>| >use lp to print on a printer attached to another machine) works
>| >using "rsh" (remote shell) to the HOSTID == lp, which wouldn't
>| >work transparently if logging in as lp on the server required a
>| >password...

>For now, it is likely to stay as it is.  Certainly it isn't any worse
>on a properly configured system than any of the other open accounts.
>Those who care should password protect all open accounts.  There may
>be security problems with lp, we will certainly look into any that
>are reported, but the lack of a password on the lp account is not by
>itself a security problem.

This whole business baffles me.  The discussion began with a report that
an SGI maintenance person was able to login on the lp account as a regular
user, since its shell is /bin/sh -- I always thought that having an
unprotected ordinary account was a pretty big security problem!  Dave
seems to feel that letting anyone login on your machine is fine, unless
you are a real security nut.  I disagree.

In my opinion any account without a password should run a secure shell.
If an unprotected lp account is needed, why does it require /bin/sh?
-- 
------------------------------------------------------------------------
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: portuesi@tweezers.esd.sgi.com (Michael Portuesi)
Subject: Re: Lifeless imgprint
Organization: Silicon Graphics Inc.
Date: Mon, 13 Apr 92 16:54:54 GMT

In article <30000@adm.brl.mil>, dave@adcs00.fnal.gov (David Richardson) writes:
|>   I have a problem with imgprint (ImageVision Tools 1.0.2) on one of our
|> 4D25G's.  When we first upgraded to 4.0.3 (from 3.3.2), it worked just fine.
|>   But recently, when I run imgprint, it just dies.  No error messages in
|> SYSLOG, the console, or anywhere.  It does, however, dump a relatively small
|> core file.
|>   I transfered a new imgprint source from a machine that I knew was working,
|> but ended up with the same results.  All the other ImageVision Tools work
|> fine on this machine.

Has the system configuration changed between the time it used to
work and the time it started failing?  imgprint is somewhat sensitive
to the equipment you have installed on your system.  It does a check
to see if you have a printer installed (or available over the network)
which it can support, namely either the Kodak XL-7700, Seiko CH-5504,
or Seiko CH-5514 printer.  Using the System Manager, check to see
what printers are installed on the machine.  A program crash is not
exactly a proper response to a system with no printers installed, but
we have to start searching for the problem somewhere.

If the software is crashing even before it puts up a window on the
display, there may be some other kind of problem.  If this is the case,
please let me know more information about the problem and I'll try to
help you.

|>   I've called TAC three times over the past week and have not received a
|> return call (call ID Q3587).  I realize this isn't much to go on,
|> but I don't
|> know where to go from here.

I'm sorry that you had to wait to receive a response, but the
product support engineers who staff the Technical Assistance Center
are currently handling many more calls for product support than usual
from all of the people who are upgrading their systems to 4.0.x.
I know that's not a good thing to hear when something on your system
doesn't work, but it's a temporary situation that will get better
once people make the adjustment to IRIX 4.0.

m. 

-- 
Michael Portuesi   Silicon Graphics, Inc.   portuesi@sgi.com
From: flash@austin.lockheed.com (James W. Melton)
Newsgroups: comp.sys.sgi
Subject: Re: electronic submission of bug reports
Summary: Why not?
Keywords: SGI, email, support
Date: 6 Apr 92 06:08:09 GMT
Distribution: na
Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744


I guess I must be naive or something, but I don't understand what the
fuss is about electronic bug reports. I deal with many software vendors
who _PREFER_ to handle support via email.

If the concern is that people who have not purchased support will try
to use the email service, the same can be said about a telephone
hotline. If a valid machine serial number is not supplied, just junk
the letter. Volume should not be a problem; when "freeloaders" find
out their mail is being ignored, they will quit sending it and return
to posting questions to this newsgroup. Registered users should be
followed up by the assigned engineer anyway.

Someone noted that an email support system would be misused by people
who just wanted information, rather than reporting bugs. If this is
a valid use of the telephone hotline, why not communicate via email?

What I would really like to see is an official SGI position on whether
such a thing is possible, or why it cannot be supported. All of us out
here (IMHO) are in favor of electronic communication.

Just a thought....
-----
Jim Melton
in person:  (512) 386-4303            | "So far as we know, our
voice mail: (512) 386-4486            |  computer has never had
fax:        (512) 386-4223            |  an undetected error"
e-mail:     flash@austin.lockheed.com |
Newsgroups: comp.sys.sgi
Subject: Re: Questions about Explorer...
From: <SSHALER@MTUS5.BITNET>
Date: Saturday, 11 Apr 1992 10:54:36 EST
Organization: Computing Technology Services, Michigan Technological Univ.

There is a short (4-page) comparision between AVIS and Explorer in the
November 1991 issue of Advanced Imaging..

Stephenson, T. 1991. Visualization Environments Hands-On: Stardent's

AVS and SGI's IRIS Explorer. Advanced Imaging. Vol 6(11):32-37.

A couple of quotes..

"Both of these systems are remarkably similar in functionality and
their designs occupy the visualization high ground."

"Unlike AVS, Explorer uses a distributed, asynchronous execution model."


Stephen Shaler
Institute of Wood Research, Michigan Tech Univ.
Internet:  sshaler @ mtu.edu
From: ianh@resmel.bhp.com.au (Ian Hoyle)
Newsgroups: comp.sys.sgi
Subject: strange problem running newaliases (or NFS mounting /usr/mail)
Date: 6 Apr 92 06:51:30 GMT
Organization: BHP Research - Melbourne Laboratories, AUSTRALIA

I have a 340VGX running Irix 4.0.1. (the mail server ... see below)

I run newaliases to update the aliases.{pag,dir} files and it works just
fine with the result:

> newaliases
25 aliases, longest 11 bytes, 433 bytes total

If I run newaliases on the same file on my Indigo (again running 4.0.1) I get
the following:

>newaliases
/usr/lib/aliases: line 19: cannot alias non-local names
/usr/lib/aliases: line 22: cannot alias non-local names
/usr/lib/aliases: line 23: cannot alias non-local names
/usr/lib/aliases: line 24: cannot alias non-local names
/usr/lib/aliases: line 25: cannot alias non-local names
/usr/lib/aliases: line 26: cannot alias non-local names

etc, etc.

Why?? newaliases is linked on both machines to sendmail, and the checksum on
sendmail for both machines is identical.

I'm stumped :-() The only thing that is different on the two machines is the
sendmail.cf, but that shouldn't matter, should it??

Currently I have several machines that mount /usr/mail from a central
server. They send *all* mail to the server including locally deliverable
mail. I do this to avoid the possibility of a conflict if both the client
and server had opened the mail file for writing at the same time (would using
lockd avoid this problem since the client is NFS mounting /usr/mail??)

I guess the question is:

"What kind of locks does sendmail use and can I mount /usr/mail from 
client machines?",

	ian
--
               :   Ian Hoyle,  Senior Research Scientist
               :   Image Analysis Group
     /\/\      :   BHP Research - Melbourne Laboratories
    / / /\     :   245 Wellington Rd, Mulgrave, 3170, AUSTRALIA
   / / /  \    :   Phone    +61-3-560-7066
  / / / /\ \   :   E-mail   ianh@resmel.bhp.com.au
  \ \/ / / /   :   
   \  / / /    :  "Now I've got the bead on you with MY disintegrating gun.
    \/\/\/     :   And when it disintegrates, it disintegrates. (pulls trigger)
               :   Well, what you do know, it disintegrated."
               :        -- Duck Dodgers in the 24th and a half century