HDTenEightyP/NetNews huggingface dataset:
From: syscrc@gsusgi1.gsu.edu (Randy Carpenter)
Subject: Re: Need help with /usr/etc/lpd...
Organization: Georgia State University
Distribution: na
Date: Wed, 22 Jul 1992 21:25:37 GMT

bryan@pi.eai.iastate.edu (Bryan Manske) writes:
> 
> 
> >...and DOS machines over ethernet.
> 
> 
> >Dear Net.People:
> 
> >In the endless quest for a better network I find myself with yet another
> >set of problems.  The burden has fallen on me to coerce several dos machines
> >with WD8003E ethernet bords to use a DOS LPR executable to send print jobs
> >to a particular SGI which has a serial line to a laser printer (which is
> >configured properly, I might add).  Permissions are set up correctly for the
> >DOS machines to log in, /usr/etc/lpd -l is running, and SYSLOG looks like:
> 
> >...
> >Jul 21 20:12:08 pi lpd[12111]: ann.eai.iastate.edu requests recvjob pips
> >[...entries for other things...]
> >Jul 21 20:16:54 pi lpd[12111]: pips: Lost connection
> >...
> 
> >Then, nothing happens,... waiting a bit longer, nothing continues to happen.
> >The DOS machine burps out: "ERROR: CONNECTION CLOSED BY SERVER"
> 
> >I've R'd T F M, but either can't find the right F M, or am missing the
> >obvious.  (Belive me, I still remember how to read.  SPELLING, now thats
> >a different matter.)  I have also read in its entirity the DOS documentation.
> 
> >Vitals on the whole mess:
> 
> >-Personal Iris 4D/35 running 4.0.1
> >-NCSA TELNET ~ CLARKSON UNIVERSITY TCP PACKAGE  (CUTCP/CUTE) (for DOS)
> >-A fleet of various SGI rendering monsters already properly printing
> > via network printer connection to the PI using lp.
> >-One slightly frazzled individual (Me) trying to keep all of these
> > wonderful toys working and playing well with each other.
> 
> 
> >Any comments or pointers would be appreciated.
> 
> >Thanks.
> 
> >Bryan
> 
> 
> >-- 
> >Bryan Manske  (515) 296-9908        . Images of sorrow,
> >Engineering Animation, Inc.         . pictures of delight,
> >bryan@pi.eai.iastate.edu            . things that go to make up a life...
> >#include <caveat_opinion.h>         . 
> >#include <standard_disclaimer.h>    . 	         Home by the Sea, Genesis

I seem to recall that SGI's lpd(1) is a client-only version (however I can't
find it in the Release Notes).  Can anyone confirm this?

-- 
===========================================================================
Randy Carpenter            rcarpent@gsu.edu    $ mkdir matter; cat > matter
Georgia State University   (404) 651-2648      ksh: matter: cannot create  
Wells Computer Center                          $
Newsgroups: comp.sys.sgi
From: alan@hal.larc.nasa.gov (alan dare)
Subject: Visual distortion problem
Originator: alan@hal.larc.nasa.gov
Organization: NASA Langley Research Center, Hampton, VA  USA
Date: Fri, 24 Jul 1992 14:36:37 GMT


This program creates a visual distortion. When the monitor updates at a rate
twice as fast than the rate the program displays the graphic, one perceives
two lines. When the rates of the monitor and program agree, one perceives a 
single line. Question: is this a problem with the hardware or the  visual
system?

*-------------------CUT HERE------------------------------*
#include <gl.h>
main ()

{

	static float	line[2][2] = {
		{0.0,15.0},
		{0.0,-15.0}
	};

	float	i;

	prefposition(0, 1279, 0, 1023);
	noborder();
	winopen("SHOW");
	RGBmode();
	doublebuffer();
	gconfig();
	swapinterval(2);	/* Creates 30 Hz update rate */	

	while ( TRUE ) {
		if (i > 20.0)
			i = -20.0;
		else
			i+=0.2;

		cpack(0x00);
		clear();
		ortho2(-20.0,20.0,-20.0,20.0);
		pushmatrix();
		cpack(0xFFFFFF);
		translate(i,0.0,0.0);
		bgnline();
		v2f(line[0]);
		v2f(line[1]);
		endline();
		popmatrix();
		swapbuffers();
	}
}
*-------------------CUT HERE------------------------------*
-- 

*********************************************************************
Alan Dare                     |  Internet : alan@hal.larc.nasa.gov
NASA Langley Research Center  |
From: siegel@mcclb0.med.nyu.edu
Newsgroups: comp.sys.sgi
Subject: HELP getting 2 toplevel shells working simultaneously
Date: 30 Jul 92 17:54:05 GMT
Organization: NYU Medical Center, New York, NY 10016, USA

I have been trying to write a small program to create an Application
Shell on one display and a TopLevel Shell on another display, and then
define some widgets in each. Strangely enough, I can do one of two
things without getting a Segmentation Fault:
a) XtAppInitialize on Display1, XtOpenDisplay on Display2, then do
a whole application on Display1 as long as I don't try to
XtAppCreateShell on Display2 (that causes Segmentation Fault); or
b) XtAppInitialize on Display1, XtOpenDisplay on Display2, then do a
whole application on Display2 as long as I don't define any widgets on
Display1 (that causes Segmentation Fault).

What's wrong? Do I need two Application Contexts? I tried this once
and it didn't seem to have any effect. Two application shells appears
to be illegal. Am I going to have to fork a new process to get the
second toplevel shell working? That sounds unnecessary to me. 

I would appreciate any suggestions.

Chris Siegel
NYU School of Medicine
NEW email: chris@mchip01.med.nyu.edu
Newsgroups: comp.sys.sgi
From: cohen@lindsay.psychiatry.uiowa.edu
Subject: Re: can lpr and lp share a printer?
Date: Thu, 30 Jul 1992 14:00:04 GMT
Organization: University of Iowa

In article <ntpvcrs@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson)
writes:
>In <1992Jul29.114520.1517@ringer.cs.utsa.edu> senseman@ricky.brainlab.utsa.edu
(David M. Senseman) writes:
>
>| In article <howarth.712364458@proto> howarth@rice.edu (Jack W. Howarth)
writes:
>| >             I am trying to discover if I can start up a lpd daemon to
>| >print to the same printer that already is being used by lp. The reason is
>| >that we have lp set up so that NFS can allow us to print remotely to the
>| >printer through lp from another Iris. However, no PC shareware supports
>| >lp for printing from a PC to a unix box; only lpr. 
>| 
>| I have a related question. I downloaded pcnfsd from sgi.com because 
>| I thought is was compiled to work with "lp" and not "lpr". Is this
>| true? When I try to use my SOSS "lpr" command from a DOS Machine,
>| it tells me that these no "lpd" printer attached (which is true) on the
>| host machine, but there is an "lp" printer attached.
>
>My guess is that pcnfsd is still looking for lpd style printers; I
>don't think we changed that.  Furthermore, we don't officially
>support running lpd on our systems, just using lpr for printing
>jobs on some other remote system that supports lpd.  It does work,
>but doesn't work with any of our normal printer tools, programs, etc.
>--
>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
>

My understanding is that PCNFSd looks only for lp printers.  You have
to have a script (set of scripts?) that will take the lp call and make it 
go to the lpr printers that you have defined.  This is supposedly simple,
however, I haven't been able to make it work.  The original 'standard' for
pcnfsd calls for ATT lp calls.

Newsgroups: comp.sys.sgi
From: raolson@cornflower.wpd.sgi.com (Robert Olson)
Subject: Re: indigo security
Reply-To: raolson@cornflower.wpd.sgi.com (Robert Olson)
Organization: sgi
Date: Mon, 27 Jul 1992 14:32:58 GMT

All Power Series machines have shipped with the prom password 
capability since mid-1991.  This corresponds to prom code 
revision 8.  Older Power Series machines can be upgraded with 
new proms - the marketing code is HU4-TRIX-1.0.  Buzz your 
sales rep for details.  No upgrade is available for yet older 
machines, such as the 4D60, 4D70 and so forth.

For those of you really concerned with secure systems, you might 
want to check out Trusted IRIX.  A friendly plug for my favorite 
product. 

I'm always interested in IRIX security related issues, so if you 
have questions or answers, please let me know.

Newsgroups: comp.sys.sgi
From: rlv@runge.mit.edu (Ralph Vinciguerra)
Subject: SCSI compatibility questions for Indigo
Summary: Differential SCSI? Will SunCDROM work.
Keywords: SCSI specs, CDROM
Organization: MIT Department of Mathematics
Distribution: usa
Date: Thu, 30 Jul 92 20:14:04 GMT

Well, I'm very excited to be receiving my first SGI machine on a network
of Sun SPARCS. But, I'm trying to reuse hardware and I find I'm in the dark
about SGI machines and their specs. So I have a few questions for some
seasoned SGI owner:

1) I have been told by an unreliable source that Indigos use
"differential SCSI". I'm just about to buy a couple Seagate ST41200 1.9G
drives, and my vendor says he can sell me these so-called differential SCSI
versions. What's the deal? Is this a real difference, or a marketing concept?
I thought the Indigo specs said "SCSI-II" and I'm all set using SCSI-II drives.

2)  I have a Sun (uh-oh) CD-ROM drive (SCSI). Will I be able to
either NFS remote mount it from my Sun network, or at least plug
it in directly? Or is there some fundamental difference from an SGI CDROM
drive, so can't load software or boot?

3) Perhaps I can use a remote SGI CDROM off my net attached to another SGI?
Can I boot diskless, plug in this above SCSI disk, and set it up as the
boot disk?

Thanks for your attention!
Post or e-mail as appropriate:
  rlv@ssl.tasc.com
  RLVinciguerra@tasc.com
From: rsherme@nswc-wo.navy.mil (Russel Shermer)
Newsgroups: comp.sys.sgi
Subject: snapshot under 4.0.4
Keywords: snapshot, 4.0.4, horrible death
Date: 22 Jul 92 18:23:48 GMT
Organization: Naval Surface Warfare Center - White Oak


Under 4.0.4 we've just tried to use snapshot.  It locks the entire
screen up so badly that xdm won't even reset from a hangup signal.
We had to reboot the machine.

Are others experiencing this problem with snapshot?  Is it only meant
to run under NeWS?

		---Russ
Newsgroups: comp.sys.sgi
From: sysmark@helios.physics.utoronto.ca (Mark Bartelt)
Subject: (non)z-buffering on Indigo/XS
Reply-To: mark@cita.toronto.edu
Organization: University of Toronto Physics/Astronomy/CITA
Date: Mon, 27 Jul 1992 13:18:15 GMT

A while ago I described a problem with Explorer on the Indigo/XS.  (It 
doesn't render properly on an XS with no z-buffer.)  I wanted to know
whether this was an Explorer bug, or an undocumented mis-feature.

I posted the same article (more or less) to comp.graphics.explorer, and
Roy Hashimoto of SGI replied:

| The Explorer Render module will run on machines without z-buffer graphics,
| but will not properly z-buffer the picture.  No effort is made to compensate
| by doing software z-buffering at a higher level than the GL.  I'm not sure
| if this is documented in the release notes.
|
| With the absence of the z-buffer, the priority of objects in the window will
| be their drawing order and not the viewing distance order.  Most scenes will
| look quite strange.

So now, at least, we understand what's going on.  However, this doesn't
necessarily make the fellow who bought the XS upgrade for his Indigo any
happier.  In fact, he's rather annoyed.  It seems that it would have been
helpful if two crucial bits of information had been available before he
spent the money:

First, as a couple of people have pointed out, you *lose* z-buffering if
you "upgrade" an Indigo from entry graphics to XS graphics without the
hardware z-buffer.  Although you still get virtual-24, you no longer get
the software z-buffering.  I haven't been able to find any place in any
hardcopy information provided by SGI (as opposed to comp.sys.sgi postings)
where this is explicitly stated (though there are a couple places where
one could, in theory, infer it), and we certainly weren't alerted to the
situation at the time we placed the order.

Secondly, even if we had known that we'd be losing z-buffering, it's not
clear from anything I've read (until Roy's comp.graphics.explorer post)
that Explorer wouldn't render properly on a system without z-buffering.
In fact, the Explorer release notes, under "Hardware Requirements", say
nothing about the need for a z-buffer.  It only says that one must have
a 24 bit plane (or virtual 24 bit plane) frame buffer.

So, although I'm not suggesting that SGI give us a free z-buffer for our
Indigo (though it *would* be nice ;-), I'd like to suggest that it seems
as if it ought to be possible for SGI to do a better job of providing its
customers with the technical information they need to make an informed
purchasing decision, so that customers aren't unhappy when they discover
that what they bought won't do the job they were led to believe it would.

Mark Bartelt                                                416/978-5619
Canadian Institute for                             mark@cita.toronto.edu
Theoretical Astrophysics                           mark@cita.utoronto.ca

"Clothes not busy being worn are busy drying."  -  Dylan, on laundry day
Newsgroups: comp.sys.sgi
From: gln@iti.org (Glen Niebur)
Subject: Re: Need help getting GL over net to Macx
Organization: Mayo Foundation, Rochester MN. Campus
Date: 23 Jul 92 15:07:10 GMT

In <31491@adm.brl.mil> marks@ra.rl.af.mil (David Marks) writes:

>Chris,

>Be prepared to have several people at SGI tell you why what you want to do is
>a bad idea.  I have tried to convince them that users WANT to have gl programs
>work via X11, so it can be viewed on X-terms and other workstations' X-Servers.
>They will tell you to use VOGL (Very Ordinary GL), which is a gl compatible
>library which implements a large subset of GL.  VOGL is freeware from
>Austrailia, found at ftp.uu.net/graphics/vogl and somewhere at
>wuarchive.wustl.edu.
>   SGI thinks it is a BAD idea to provide folks GL functionality on top of xlib.

I think you are being more than unfair.  How do you propose that SGI make
your X terminal understand GL.  GL doesn't use X to display on SGI machines.
X is just a window manager for GL.  They would have to write drivers which
convert every thing they draw into the equivalent x thing and then pump it
over the network.  It would be so slow as to be useless for any application
worth using.

Granted SGI should have probably opened up the dgl protocol before now.  Even
IBM doesn't have dgl yet, even though they have gl.  I think many companies
will implement dgl and gl now that they have a chance, and then the X
consortium will be compelled to follow.

>They want you to WAIT until everyone (or I guess anyone) implements the proposed
>GL extensions to X.  Which is fine, whenever that happens, and even then, what
>about the 300,000,000 or so X-Terms which we users ALREADY own?

You could just get a the new X server from MIT and you would be on your way.

>   X must be too slow of a vehicle to qualify as worthy enough to transport GL
>calls which are usually chommped on by a gang of ASICs.

Exactly.  X is too slow to do anything much less GL.

--
Glen Niebur     | These sobering sights i've seen in the city of angels
Mayo Clinic     | have all been one rude awakening that was due to me
Biomechanics Lab|  ...in heaven
gln@mayo.edu    |            ~Natalie Merchant
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: question regarding uucp/(dialout/dialin modems) on SGI's
Date: 30 Jul 92 23:47:16 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <26028@life.ai.mit.edu>, sundar@fiber-one.ai.mit.edu (Sundar Narasimhan) writes:
> Hi, I just set up outgoing uucp from our SGI machine running IRIX 4.0.3.
> This seems to work fine for outgoing calls, but I'd like to receive
> incoming calls too. So, my question is:
> a. Is there a script that automatically edits inittab to do the right thing? 
> and reverts it to what it was once its done? Ideally, I'd like the default
> mode to be with the getty running ready to receive incoming calls. Then every
> hour or so, the  outgoing uucp called from cron turns the getty off, and does
> its thing. Right now, I have to manually do this which is a pain.
 
Don't fiddle with inittab.  Use /usr/lib/uucp/uugetty instead.
This is exactly what it is intended for.

> b. Is there a way to send an initialization string to a modem
> device from inittab/gettydefs? (with delays etc.)

The SGI uugetty can send answer-init strings to the modem.  

There is a selection of modem answering strings in the
standard place, /usr/lib/uucp/Dialers.

Many IRIS's use bidirectional modem lines.


Vernon Schryver,  vjs@sgi.com
From: daryl@andataco.UUCP (Daryl Beeson)
Newsgroups: comp.sys.sgi
Subject: 6u->9u solution
Date: 27 Jul 92 15:28:25 GMT
Organization: AnDATAco / San Diego, CA
X-Newsreader: Tin 1.1 PL4


From: daryl@andataco.com  (Daryl E. Beeson)


We carry three types of 9u expansion cards that try to cover the main
boards that would fit in a PowerSeries or Professional machine.  We have
used them for Xylogics controllers and various serial controllers. 

Unfortunately, they are not exactly inexpensive.  I'm not sure why,
other than possibly supply and demand.

FYI, our price for quantity 1-5 is $ 321.

Just drop me a note if you need further information.

daryl




 ----------------------------------------------------------------------------
 Daryl E. Beeson                         Andataco Computer Peripherals
 Senior Sales Engineer       		    1-800-334-9191 (Voice)       
 daryl@andataco.com                         1-619-453-9294  (fax) 
					    1-619-453-9191 (Voice Mail)
~

********************************************************************
*                                                                  *
*  Disclaimer:  	Opinions expressed in this document        *
* 	 		probably belong to someone else.           *
* 			Mine aren't very creative and              *
* 			usually cause ugly arguments!              *
*                                                                  *
********************************************************************
From: lsr-vax!art@uunet.uu.net (Art Hays - PSTAFF)
Newsgroups: comp.sys.sgi
Subject: Re: Memory upgrades for R4000 Indigos
Date: 25 Jul 92 20:54:46 GMT

Michael Portuesi <uunet!tweezers.esd.sgi.com!portuesi> writes:

> Before the inevitable flames about "abandoning" the
> Personal Iris line arrive, let me point out that
> producing the 4D/35 was very difficult from both an
> engineering and manufacturing standpoint.  The R3000A
> in the 4D/35 worked only with some unconventional hacks
> to meet cooling requirements, and the electronics module
> had to be redesigned to fit in the chassis.  An R4000
> upgrade would be frought with even more engineeering
> problems.  It would be difficult and costly for us to
> manufacture.

	And yet, the 4D35 box is bigger than the Indigo box.
Intuition suggests that something that works in a smaller box could also
work in a bigger box.

	While we are on the subject, another 'unupgradeable' machine is the
4D85 (an R2k machine).  We have three.  I believe there is no in-chassis upgrade;
only a trade-in is offered (if I'm wrong, I'd love to hear from someone).
This is a machine that has a big backplane with VME slots in a case similar
in size to the Crimson.

Art Hays, Nat. Eye Institute,			uunet!lsr-vax!art
Nat. Institutes of Health, Bethesda, MD		(301) 496-7143
Newsgroups: comp.sys.sgi
From: nathan@laplace.biology.yale.edu (Nathan F. Janette)
Subject: Re: Memory upgrades for R4000 Indigos
Reply-To: nathan@laplace.biology.yale.edu
Organization: Yale University, Department of Computer Science, New Haven, CT
Date: Mon, 27 Jul 1992 16:34:55 GMT

In article <1992Jul26.045223.11600@news.nd.edu> root@sanger.chem.nd.edu (Doctor  
Math) writes:

> I'm certainly not going to say that the machines are inferior from a
> technological standpoint. I am going to wonder about the sales folk, though.
> I have a fax from SGI quoting prices for machines. I want to get an R4000
> Indigo or a Crimson without a disk, RAM, or a monitor (we are retiring some
> elderly 4D/20s).  The cover page pointed out that the warranty would be
> void if ANY third-party stuff of ANY kind was installed.

Gee, all 90 days of it?

;-)

--
Nathan Janette		"I'm a NeXTstep man,
Dept MB&B, Yale Univ	 I'm a NeXTcube guy"
New Haven, CT
nathan@laplace.biology.yale.edu (NeXT)

Newsgroups: comp.sys.sgi
From: hillig@U.Chem.LSA.UMich.EDU (Kurt Hillig)
Subject: Re: late collision errors
Date: Thu, 30 Jul 92 17:28:30 EDT
Organization: Department of Chemistry, University of Michigan, Ann Arbor

In article <1992Jul30.190642.29534@aio.jsc.nasa.gov> strong@sweetpea.jsc.nasa.gov (Renee Strong 283-4257) writes:
>We keep getting TONS of late collision errors in our console windows. 
> [more stuff deleted]

Funny, I get these messages typically 2-8 times a day, and about
once a week I see a message like:

Jul 30 15:09:47 Uranium unix: core file access error

I understand that late collisions typically result from physical
net problems (over-length cable runs, bad connectors), but I don't
know what can cause a core access error (I've got plenty of free
disk space, it's not that).

Which FM is the one to R to find the interpretations of these
and similar messages? 

Newsgroups: comp.sys.sgi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: cc errors
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 27 Jul 1992 14:54:33 GMT

In article <1992Jul27.103035.26247@bernina.ethz.ch>, hoesel@igc.ethz.ch (Frans van Hoesel) writes:
> I don't like the lengthy error messages from the c-compiler.
> They fill the screen
> with lots of dashes even if one makes only a few mistakes. 
> This behavior is *NOT* what is described in the ansi-c manual from sgi.
> there is some page describing exactly what the format of the
> error messages is. The format described there is not the format I get.



I think the dashes for syntax errors are very nice.  They allow you to
see exactly where the compiler decided you are wrong.  There is no
other mechanism that will unambigiously show where the error is,
regardless of screen width, and without forcing you to manually count
characters.



Vernon Schryver,  vjs@sgi.com