HDTenEightyP/NetNews huggingface dataset:
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: electronic submission of bug reports
Keywords: SGI, email, support
Date: 6 Apr 92 22:44:59 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <919@shrike.com>, flash@austin.lockheed.com (James W. Melton) writes:
> ...
> 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?

My unscientific surveys of requests in comp.sys.sgi over the years show
that the most of those asking for email bug reporting do not wish to pay
for support.  It seems to me that those who pay for support are generally
accomodated no matter how they want to communicate.  The support people
certainly circulate enough email, ftp dumps, tapes, faxes, and voice mail.

Too many people feel that the valuable service of reporting a bug pays for
getting general help.  Too many people don't know a computer bug from a
"hands problem."  This is why I generally disagree with suggestions for
general email support.

It is harder to squash free email help requests than it is to squash free
phone help requests.  People get irritated when you ignore their 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.
> ....

Many people, including me, prefer email.  Corporate management types
differ; they often don't know what it is, except some nasty computer thing
that only brings bad news, often semi-public and more enduring than verbal
abuse.

If you pay money for support and prefer email, then ask your sales
representatives to put it into the contract.  Ask for a lower price, on the
grounds that reading email is faster for the support people here and that
email is much cheaper than 800 phone line charges.  I doubt they'd go for
it, but it would set the tone for the negotiations.


Vernon Schryver,  vjs@sgi.com
From: pdi!shoshana@sgi.sgi.com (Shoshana Abrass)
Newsgroups: comp.sys.sgi
Subject: xmodmap FAQ
Date: 14 Apr 92 00:30:19 GMT


  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

  After executing this, xmodmap says:

     prompt> xmodmap -pm
     xmodmap:  up to 2 keys per modifier, (keycodes in parentheses):

     shift       Shift_R (0xc),  Shift_L (0xd)
     lock        Control_L (0xb)
     control     Caps_Lock (0xa),  Control_R (0x5d)


  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.

  OS 4.0.1, 4Dwm, 4D/20 <sigh>.

  -shoshana

 --                                                                      --
|  Shoshana Abrass                                      shoshana@pdi.com   |
|  Pacific Data Images, Sunnyvale CA            "Data is our middle name"  |
 --                                                                      --
Organization: Arizona State University
Date: Tuesday, 14 Apr 1992 12:48:17 MST
From: Jim Howard <ICSJHH@ASUACAD.BITNET>
Newsgroups: comp.sys.sgi
Subject:    Telnet to VMS

We're haveing problems telnet'ing to a Vax VMS system. The full screen
editing doesnt seem to keep the iris screen updated. We've tried several
different TERM settings and VMS set term settings? Any suggestions?
From: wes@uf.msc.edu (Wes Barris)
Newsgroups: comp.sys.sgi
Subject: Re: xwindows and videoframer
Date: 6 Apr 92 14:35:47 GMT
Article-I.D.: uc.1992Apr6.143547.5515
Reply-To: wes@msc.edu
Distribution: na
Organization: AHPCRC

In article <17578@oasys.dt.navy.mil>, kurhajet@oasys.dt.navy.mil (Robert Kurhajetz) writes:
|> Trying to locate assistance on taking a series of  xwd (x window dump ) files
|> that have been converted to sgi imagelib files out thru a videoframer to a
|> betacam recorder. The files will display but am having a problem with cut-off
|> of some of the image field - any help would be greatly appreciated.
|> 
|> The original xwd  files were written out at 640 x 480.
|> 

Make sure your SGI images are 720x486 in size.  You may want to experiment
with the "-n" option to the "display" program.

-- 
      o o o o o o o . . .   ________________________________ _____=======_T___
    o      _____           ||Wes Barris                    | | wes@msc.edu   |
  .][__n_n_|DD[  ====|____  |Minnesota Supercomputer Center| |(612) 626-8090 |
 >(________|__|_[___/_____]_|University of Minnesota_______|_|_FAX: 626-1596_|_
 _/oo OOOOOO o`  ooo   ooo  'o^o^o                    o^o^o` 'o^o         o^o`
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Troglodytism does not necessarily imply a low cultural level.
From: porco@husc10.harvard.edu (John Porco)
Newsgroups: comp.sys.sgi
Subject: turning off 'Confirm?' at system logoff?
Date: 8 Apr 92 00:02:49 GMT
Article-I.D.: husc10.PORCO.92Apr7170249
Distribution: comp.sys.sgi
Organization: Harvard Arts and Sciences Computer Services, Cambridge, MA


I noticed that upon execution of the 'Log Out' option under the system menu, 
/usr/bin/X11/endsession is executed in conjunction with /usr/sbin/confirm.

I know why this is present.  I dont want it there.  Can anyone tell me how to 
turn the confirmation query off??  I've tried the resource options 
              '*showFeedback:	-quit' 
for both mwm and 4Dwm, so that's not it.  Examination of system.chestrc shows 
that endsession is executed WITHOUT the 'confirm' option, but a quick 'ps -lef'
shows that endsession has forked 'confirm'.  


hints???

thanks
Xref: sparky comp.sys.sgi:6783 comp.emacs:1998
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: Bootable BRU tape?
Date: 9 Apr 92 06:51:28 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <29964@adm.brl.mil> pjf@osiris.cs.uoguelph.ca (Peter Jaspers-Fayer) writes:

| Using mkboottape, we hope to try to make our "disaster" backups bootable.
| I guess we can bring up a miniroot, but then how to include `bru` in that?

Backups aren't bootable.  bru *is* in the miniroot already (as are
cpio, tar, and in 4.0.1, the restore that goes with dump).

| The alternative is to go through most ofi an install, and then full restore.
| Seems a waste of time.  Anyone else looked into this?  Suggested reading?

It is.  System recovery is identical to software installation (in
terms of miniroot load and boot), but initstate is 3 instead of 2.
--
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
From: dsk@casbah.acns.nwu.edu (Daniel Katz)
Subject: vt100 description
Reply-To: dsk@nwu.edu
Organization: Northwestern University, Evanston, IL, USA
Date: Wed, 8 Apr 1992 18:50:01 GMT

Could someone please e-mail the location of the files which decribe
the terminal types, specifically the vt100 terminal?  I am also looking
for a vt102 description, or something I can put in the appropriate place
to make vt102 a recognized terminal type.

Thanks,
Dan

-- 
Dan Katz                                                       dsk@nwu.edu
Dept. of Electrical Engineering                             1(708)491-8887
Northwestern University, Evanston, IL, 60208                E pur si muove
From: senseman@lonestar.utsa.edu (David M. Senseman)
Newsgroups: comp.sys.sgi
Subject: Re: Indigo info/opinions sought
Date: 6 Apr 92 23:00:00 GMT
Distribution: na
Organization: University of Texas at San Antonio

In article <18757@bach.udel.edu> robeson@bach.udel.edu (Scott M Robeson) writes:
>In article <j5552e0@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>>|   9. Are you happy with your set-up? What don't you like?
>>
>>I'll leave this for other folks.  One of the most common complaints
>>seems to be that the 24 bit RGB dithered down to 8 bits often looks
>>rather cheap, particularly if you are double buffering; the answer is
>>to not do that (use colormap mode), or to pick your colors very carefully.
>
>There are now true 24 bit Indigoes running around, aren't
>there?  Of course this comes with a big increase in the price tag,
>but...   Any opinions from those currently using the XS24?
>
>-- 
We have 4 Indigos in my research lab -- 3 are XS24's the
other is an Entry-level, 8-bit dithering machine. (The
order to upgrade the Entry-level to an XS24 went in last
week :).

Except for a 'slight' problem with a slow NFS, the kids in the
lab LOVE the XS24's (especially when 7 of them are playing
battlezone ;-) The graphics are extremely good. Having used
the larger 19 inch screen for a number of years, I now prefer
the smaller 17 inch screen -- for one thing it fits on my desk.



-- 
              David Senseman (senseman@lonestar.utsa.edu)
From: norman@binah.cc.brandeis.edu
Newsgroups: comp.sys.sgi
Subject: attachcursor()
Date: 8 Apr 92 11:58:34 GMT
Reply-To: norman@binah.cc.brandeis.edu
Organization: Brandeis University

Hi,

  About a month ago, I reported here a gl bug involving
attachcursor().  It doesn't work in 4.0.1 !! At least
on our Personal Iris.  I was surprised when no one at
SGI cared to comment on it or check it out.

  Normally (in Irix 3.3) the cursor is "attached" to
the MOUSEX and MOUSEY valuators.  You can use attachcursor
to make the cursor move to other valuators besides the mouse.
If one attaches the cursor to GHOSTX and GHOSTY and don't
vary them , the cursor shouldn't move.  But, now in 4.0.1
the cursor always moves with the mouse regardless of
attachcursor.

  All of my programs which use attachcursor always worked
before, but don't work now.  I got an e-mail from another
user who says attachcursor no longer works on his machine
as well.

  This function isn't that important, but it would be nice
if it worked again.  Has something else changed that is
required before one uses attachcursor or is it really
broken ?

                J. Farley Norman
                norman@binah.cc.brandeis.edu
From: blbates@aero36.larc.nasa.gov (Brent L. Bates ViGYAN AAD/TAB)
Newsgroups: comp.sys.sgi
Subject: Re:  Is there an lp for the PC?
Date: 13 Apr 92 12:21:24 GMT


   We use lpr for ALL printing.  Printing locally, from SGI to Sun and Sun
to SGI.  We are doing this under IRIX 3.3.2, so I it had better work under
IRIX 4.0.X too!

  Brent L. Bates				Phone:(804) 864-2854
  NASA-Langley Research Center			  FAX:(804) 864-8469
  M.S. 361
  Hampton, Virginia  23665-5225
  E-mail: blbates@aero36.larc.nasa.gov or blbates@aero8.larc.nasa.gov
From: loki@frodo.physics.mcgill.ca (Loki Jorgenson)
Newsgroups: comp.sys.sgi
Subject: grcond core file
Date: 14 Apr 92 23:28:33 GMT


	I often observe core files in /usr/tmp of machines running both
IRIXv3.3 and 4.0.1, belonging to Xsgi.  There are accompanying messages
in /usr/adm/SYSLOG from grcond.  These files are often very large; 1 - 10M.

	I usually remove them by hand but they soon reappear.  They seem to
be associated with user login/logouts.

	In order to save space, I tried to create a root owned core file with
of zero size with permission 000 to block the dropping of cores.  This
didn't work.  Now I want to try making a soft link from /dev/null to
/usr/tmp/core.  This way, anything written to /usr/tmp/core will
disappear into the void.

	Is there a problem with this?  And why is this happening anyways?

-- 
'gards,
                                  _  _   
Loki Jorgenson                    O\/O        node:  loki@Physics.McGill.CA
Grad/Systems Manager           _/\_/\_/\_     BITNET: PY29@MCGILLA
Physics, McGill University       / \/ \       fax:   (514) 398-6526
Montreal Quebec CANADA         _/ _/\_ \_     phone: (514) 398-7027

                        -*  Beyond elitism  *-
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: trouble a bru'n
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 10 Apr 92 04:44:24 GMT

In <83675@bu.edu> jdh@bu-pub.bu.edu (Jason Heirtzler) writes:

| Our 4D-240 crashed last night and I had a rather disturbing
| experiance.  Maybe Dave or someone else would be willing to
| shed some light.
| 
| Our backups are done on 8mm tape.  When the machine crashed
| last night, several files were missing from the root partition,
| (why?) so I decided to reload from the backup tapes and be safe,
| rather than try to manually hunt down the missing files.
| 
| I booted off the 3.3 distribution tape (the machine was running
| 3.3.2 at the time of the crash) and spawned a subshell ("sh") from
| inst, but was unable to read anything from the bru tapes!
| 
|         inst> sh
| 	# cd /root/dev
| 	# bru -tf rmt/tps0d4
| 	bru: warning - assuming end of volume 1 (unknown size)
| 	[ then a prompt to enter volume 2 ]
| 
| If I boot single-user, I can read the tapes fine.   If I boot
| off the 3.3 distribution tapes I can't!  It seems reproducable,
| so what's the deal?  Obviously, this is nasty.

Always use the *latest* media appropriate for your os rev; in 
your case, either the 3.3.2 integral release, or the 3.3.2 or 3.3.1 maint
tapes with installation tools.

3.3.0 was shipped only to a few customers to support some new hardware,
or something like that, and all of them should have later upgraded to
at least 3.3.1.  3.3.0 had a bug for 8mm tapes where the default block
size was set to 512 bytes, due to a typing error on my part, instead of
the far more standard 1024 (which we have used in every release except
3.3.0).

If you can boot single user, I personally would *always* recommend that over
the miniroot.
--
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: hofmann@mira.tat.physik.uni-tuebingen.de (Bernhard Hofmann)
Newsgroups: comp.sys.sgi
Subject: Re: physical security
Date: 13 Apr 92 16:38:24 GMT
Organization: TAT (Theoretical Astrophysics Tuebingen), U. of Tuebingen, FRG

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>Given physical access to the machine and a screw driver, the determined bad
>guy can use the method often discussed for disabling the PROM password.
>(Don't ask me what it is, not because I wouldn't tell, but because I don't
>know.  It involves a jumper or a shorting wire or removing a chip from a
>socket.)

It should be possible to construct some locking mechanism to prevent
people from opening the box. Only the staff has a key. This ought to
be only little effort if the boxes have to be secured against theft
anyway.

Cheers,
Bernhard
Newsgroups: comp.sys.sgi
From: davea@quasar.wpd.sgi.com (David B.Anderson)
Subject: Re: Coredumps with GL popup menus, 4.0.2.
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 13 Apr 1992 16:29:36 GMT

In article <MARCA.92Apr12163224@wintermute.ncsa.uiuc.edu> marca@ncsa.uiuc.edu (Marc Andreessen) writes:
[ ]
>Here's the entire traceback:
>
>(dbx) where
>>  0 gl_wmfullscrn(0x1067cb80, 0x2, 0x10073698, 0x1067cb7c, 0x0, 0x0) [0xf054724]
>   1 ffs(0x1067cb80, 0x2, 0x10073698, 0x1067cb7c, 0x0, 0x0) [0x1007c544]
>(dbx)
>
>Note that I am _not_ calling ffs, or gl_wmfullscrn; the traceback just
>stops there.  This reflects a problem I brought up earlier in this
>group (and over the hotline): dbx's unwillingness to handle shared
>libraries adequately.  (Incidentally, I received useful responses from
>two SGI developers after my posting on struggles with dbx; a belated
>but sincere public note of thanks to them.)  I would urge SGI to make
>support for shared libraries in dbx a top priority --- SGI provides
>them, I'm developing with them, my application is going to ship with
>them, and I'd like to be able to debug problems as they occur with
>them.
[ ]

dbx has trouble with tracebacks thru static functions in
SVR3-style static shared libraries.   mkshlib(1) removes information
from the symbol tables and... dbx just does not deal with the situation
properly.  Sorry.  In some cases one can, *during debugging*, link
with the unshared libraries (but of course switch to linking
with the shared libraries as soon as possible).

We're working on dbx to make it support dynamic shared objects (SVR4-style).
I don't know if we'll ever fix the problem with dbx & static shared libs:
a question of resources....

Regards,
[ David B. Anderson  Silicon Graphics  (415)335-1548  davea@sgi.com ]



Newsgroups: comp.sys.sgi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: syslog fail to work
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 10 Apr 1992 06:31:50 GMT

In article <52947@mimsy.umd.edu>, dong@umiacs.umd.edu (Dong Chen) writes:
> Hello,
> I just noticed my syslog isn't working right.
> Normally the /usr/adm/SYSLOG will keep all the system activition.
> But I found that file has been empty for a few days, during witch I have 
> login and ftp and did a lot of other things.
> I checked the /adm/sys/SYSLOG is writeable by root and the syslogd is
> runing.
> What else could go wrong ?


Popular causes include:

    -running out of disk space.
	Once syslogd is unable to write to /usr/adm/SYSLOG,
	it won't try again until it is `killall -HUP syslogd`,
	either manually or by cron on Sunday morning.

	Yes, I'd like to see syslogd try again occassionally, but
	have never had time to hack something up.


    -installing IRIX 4.0* and failing to heed the nagging of
	from the system when it is rebooted to run `versions changed`
	and combine new and old configuration files.  In this particular
	case, the trouble is in /usr/spool/cron/crontabs/root.


Vernon Schryver,   vjs@sgi.com
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: Help needed with tftp
Date: 9 Apr 92 07:16:44 GMT
Distribution: na
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Apr8.195237.26770@biome.bio.ns.ca> silvert@biome.bio.ns.ca (Bill Silvert) writes:

| Since we have tftp up I figured it might be even easier than anonymous ftp
| for simple file exchanges with off-site users, who only need to use get
| and put.  Problem is, I have it set up so that tftp users can get files,
| but they can't put them.  The manual entry doesn't help me understand
| why put doesn't work.
| 
| The command in /usr/etc/inetd.conf that starts up tftpd is
| 
| tftp    dgram   udp     wait    guest   /usr/etc/tftpd  \
| 	tftpd -h /usr/ftp/pub/public -s -l

Did you do 'killall -HUP inetd' after changing the line (or rebooted)?
--
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
Xref: sparky comp.sys.sgi:6851 comp.unix.bsd:799
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi,comp.unix.bsd,comp.unix.question
Subject: Re: Socket, binding to reserve port - SGI, IRIX 4.0.0
Keywords: socket
Date: 13 Apr 92 20:33:51 GMT
Article-I.D.: sgi.jgmqo8s
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Apr13.170347.14097@gateway.novell.com>, terry@ithaca.npd.Novell.COM (Terry Lambert) writes:
> ...
> You ARE allowed to overwrite an SUID root file; it just won't stay SUID.
> ...


Do not count on this in System V.

Thank the Wizards of New Jersey, although they don't seem to realize
the consequences.


Vernon Schryver,   vjs@sgi.com
From: dalel@radian.uucp (Dale Lewis)
Newsgroups: comp.sys.sgi
Subject: Substitute for XAPPLRESDIR in SGI Xlib
Keywords: Xlib SGI XAPPLRESDIR
Date: 16 Apr 92 14:57:48 GMT
Followup-To: sender
Organization: Radian Corporation, Austin, TX


One of our programmers has said that he remembers that X
windows libraries on his Silicon Graphics Indigo do not look
at the XAPPLRESDIR environment variable to find the application
resources directory.  He says that they look for another variable
and that this is documented somewhere.
	Will some kind soul E-MAIL me, to tell me what this variable
is and where it is documented?  Thanks in advance.
-- 
|~~~~~\  /~~\  |~~~~~\ |~|  /~~\  |~\_|~|   Dale W. Lewis, Sys. Adm.
|  ~  / / /\ \ | [<>] || | / /\ \ | \ \ |   radian!dalel@natinst.com
|_|~|_\/_|~~|_\|_____/ |_|/_|~~|_\|_|\__|   Box 201088 Austin, TX 78720 
C   O   R   P   O   R   A   T   I   O   N   All opinions solely my own
Newsgroups: comp.sys.sgi
From: portuesi@tweezers.esd.sgi.com (Michael Portuesi)
Subject: Re: Why does 4.01 run so slow on a Personal Iris?
Reply-To: portuesi@tweezers.esd.sgi.com (Michael Portuesi)
Organization: Silicon Graphics, Inc.
Date: Thu, 9 Apr 92 17:04:00 GMT

In article <1992Apr9.095844@gojira.gsfc.nasa.gov>, dan sullivan writes:
>	We have 12 mb on a PI. Opening windows is much slower
>than under 3.3. Is this slowness on all SGI models? Our
>Indigo doesn't seem to be slow. Has GL speed been
>decreased, too?

The GL under 4.0.1 is comparable in performance to that
of 3.3 on the PI.

My (totally subjective) observations with the PI indicate
the biggest problem with performance has to do with
system memory.  4.0.1 simply uses more memory than
3.3 did, and on a PI 12 Mb is not enough to cut it for
serious work.  I'd suggest that you upgrade your system
to 16 Mb or more. 

Fortunately, the Personal Iris 4D/20 and 25 will accept
standard memory SIMMS (they must have the extra
chip for parity checking), so you can obtain extra memory
very cheaply.  You can also use certain types
of 4 Mb SIMMS in the PI as well (I know from experience
that Toshiba SIMMS will work), though you cannot
mix 1 Mb and 4Mb SIMMs in the same machine.  I have
a 4D/25 with 32 Mb memory and performance under 4.0.1
doesn't seem to be a problem -- it's not that much
slower than an Indigo to make me upset.

However, I have no idea what impact this do-it-yourself
advice may have on the terms of your service contract,
and it certainly isn't an official statement of SGI's upgrade
policies.  But I've done it and it works.

m.

Michael Portuesi   Silicon Graphics, Inc.   portuesi@sgi.com
From: lombardo@taurus.cs.nps.navy.mil
Newsgroups: comp.sys.sgi
Subject: ld error - HELP!
Date: 15 Apr 92 21:53:11 GMT
Organization: Naval Postgraduate School, Monterey CA

Hi,

  Can anyone assist with the following ld error:

/usr/bin/ld:
Warning: gp relocation out-of-range in .text section for relocation
   entry 2 for symbol: glxConfig
Warning: above gp relocation entry for non .sdata or .sbss symbol,
   symbol class(sc) number 268442036
All data will fit into the global pointer area
Best -G num value to compile all -count'ed objects
creating hyper with is 8200 (or greater)
Best -G num value calculation reliable only if all
-count'ed objects were compiled with -G num greater or
equal to maximum size of a literal pool item (8).

  Specifics:    C++, Motif, GLX, IRIX 4.0.1 & 4.0.3

Thanks in advance
Chuck

 ----------------------------------------------------------------------------
| Charles P. Lombardo			|           lombardo@cs.nps.navy.mil |
| Computer Science Department		|		 voice: 408-646-2102 |
| Naval Postgraduate School		|		 fax:   408-646-2814 |
 ----------------------------------------------------------------------------