HDTenEightyP/NetNews huggingface dataset:
From: fredv@abba.acs.uci.edu (Fred Velijanian)
Newsgroups: comp.sys.sgi
Subject: Re: problem with dvhtool and sash
Date: 15 Oct 92 15:03:38 GMT
Article-I.D.: news.2ADD884A.20897
Organization: University of California, Irvine

In article <r3gioac@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>In <2ADCA716.20325@news.service.uci.edu> fredv@abba.acs.uci.edu (Fred Velijanian) writes:
>
>| Using: Indigo R4000, Irix 4.0.5F
>| 
>| Recently I duplicated a system disk using dump/restore and booted
>| from this new disk. The only problem was that sash was not in the 
>| volume header, so I used CDROM's sash for booting. Then using
>| "dvhtool" I copied the /stand/sash to the header. (using the 
>| "vd" command and the "c /stand sash".)
>| 
>| However booting from the sash on disk now gives me a "execute format
>| error". What am I doing wrong?
>
>Sounds like you have the wrong sash on the disk somehow.
>
>The command:
>	strings /stand/sash | grep Version
>should come back with something like this.
>	SGI Version 4.0.5E ARCS  Aug 27, 1992
>The key part (for r4k indigos) is the word 'ARCS'.  If you see
>something like:
>	SGI Version 4.0.5D IP12  Aug 15, 1992
>(for almost any number after "IP"), then you have the wrong sash.
>
>If you have the wrong sash, I'd highly recommend re-installing
>eoe1, as there would appear to be something wrong with your
>disk copy procedure (whatever it was).
>--
>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

I tried strings and it does say 4.0.5E ARCS. 
sum reports 22185 254

The disk copy procedure was to mount the new partition as /mnt 
and then:   dump 0f - / | (cd /mnt; restore xf -) and then another
one for /usr.  (This is how I've been doing disk copies in BSD, 
first time ever for SYSV)

Any other ideas?

Thanks

Fred Velijanian
University of California, Irvine
fredv@uci.edu
From: john@sg25.aud.temple.edu (John W. Schwegler)
Newsgroups: comp.sys.sgi
Subject: Re: PLEASE! read the group before asking questions.
Date: 13 Oct 92 14:59:08 GMT


In message <r0s5rt0@zuni.esd.sgi.com> ,
 Dave Olson <olson@anchor.esd.sgi.com> writes:
> Recently there have been a series of requests for various pieces of
> information that have already been asked within the past few weeks.
> 
[omitted]
> I know that we don't have an FAQ for the group, but still, please
> check the recent articles before asking again.  I'm starting to
> reach the point where I won't answer some questions, just because
> they are too frequent (or were just answered recently).
> 

It is definitely time for an FAQ, folks. This whole issue comes up every
couple of months, and everyone says we need the FAQ, then the subject
is forgotten. I don't consider myself qualified to write the whole FAQ, *BUT*
I will start compiling material for it from my comp.sys.sgi archives for
most of the past year. Anyone willing to coordinate the effort? Otherwise,
[shuffle shuffle] ... I suppose I could do that as well.

> 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

Dave, you do wonderful things for this group, and I'd hate to see you burn
out on it just from the lack of an FAQ. If you have any suggestions, we'd
all be pleased to hear them.

______________________________________________________________________________
"Genius may have its limitations,       | John Schwegler
   but stupidity is not thus            | Temple U. Auditory Research Dept.
   handicapped."                        | john@sg25.aud.temple.edu
         - Elbert Hubbard               | (215) 221-3687 FAX 221-7523
From: blbates@aero36.larc.nasa.gov (Brent L. Bates ViGYAN AAD/TAB)
Newsgroups: comp.sys.sgi
Subject: Re:  purchase recommend
Date: 9 Oct 92 12:17:39 GMT


     Why not `upgrade' one of your existing platforms to a Crimson?  Around
here we refer to that as a `forklift' upgrade.  In other words, SGI hauls
out your old machine and brings in a new one.
     I've heard the Indigo with the R4000 CPU called `blackjack', could that
be what you are thinking of?

  Brent L. Bates				Phone:(804) 864-2854
  M.S. 361			  		  FAX:(804) 864-8469
  NASA Langley Research Center
  Hampton, Virginia  23681-0001
  E-mail: blbates@aero36.larc.nasa.gov or blbates@aero00.larc.nasa.gov
Newsgroups: comp.sys.sgi
From: asphddg@cidsv01.cid.aes.doe.CA (Daniel Galuchon)
Subject: undestanding /etc/wtmp
Reply-To: dgaluchon@cid.aes.doe.CA
Organization: Environment Canada
Date: Fri, 9 Oct 92 13:41:25 GMT


  Hi, 
     I am trying to interpret the /etc/wtmp cryptic contents.
  'man wtmp' says that the second field is the /etc/inittab
  line number. On our system, this field appears as 
  'c0' or 'x[num]' or  'q[num]' or empty.
  As for the ut_type field, it is usualy 6 for rlogin or telnet.
  For 'ftp' there are always 2 lines, types 7 and 8.
  1- what are 'c0' x[num] w[num], and where are they
     located in the system? What does an empty second field means?
  2- why is there always a dead process entry (type 8)
     associated with ftp? And what is this number in the
     device name field (Example: ftp20152)?

  D. Galuchon    DOE/AES/CMISC      User Support Services
From: portuesi@tweezers.esd.sgi.com (Michael Portuesi)
Newsgroups: comp.sys.sgi
Subject: Re: Need Help in Showcase III - about inserting EPS files
Date: 7 Oct 92 17:21:15 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA


In article <feil.718451148@prles26>, feil@prl.philips.nl writes:
> portuesi@tweezers.esd.sgi.com (Michael Portuesi) writes:
> >From the online help card entitled "Importing Encapsulated
> >PostScript Files,"  accessed under the "Importing Objects"
> >item on the Help menu:
> 
> >	"If the EPS file was not saved with a preview image,
> >	IRIS Showcase displays a rectangle and a file name.
> >	This only affects the screen display; the image
> >	prints correctly."
> 
> Does Showcase version III is going to make use of Display
> Postscipt?

Unfortunately, I don't know exactly what Showcase version 3
will and won't do -- and the people developing it (who are
right across the hall from me) would get very upset with me
if I made commitments for them!

--
Michael Portuesi   Silicon Graphics, Inc.   portuesi@sgi.com
Newsgroups: comp.sys.sgi
From: jsivier@ux1.cso.uiuc.edu (Jonathon Sivier )
Subject: Need IRIS evaluation program
Organization: University of Illinois at Urbana
Date: Thu, 8 Oct 1992 19:47:48 GMT

   We are planning on purchasing a new SGI workstation and are trying to
determine which one will fulfill our requirements and fit within our budget.
Are there any demo programs which we can use to try out the different graphics
features and see what effect they have on performance.  Say a standard object
which moves around and displays what the current framerate is and allows you to
turn on and off  all the different graphics features, shading, lighting,
texturing, fog, etc.  This way we could run the same program on a variety of
machines and with all the different combinations of features and get a feel for
what effect they will have on the performance of the applicaitons we want the
machine for.  For the most part we use real-time interactive displays so the
update rate is very important.  I have spoken to the local sales person and
he says there is no such thing, but I find it hard to believe that no one has
done this.  If only SGI internally, I would think being able to objectively
compare the performance of different machines would be important.

   If anyone has any suggestions I would like to hear them.

Thanks.

Jonathan

-------------------------------------------------------------------
|  Jonathan Sivier               |  Ballo ergo sum.               |
|  jsivier@ux1.cso.uiuc.edu      |  (I dance therefore I am.)     |
|  Flight Simulation Lab         |	        - des Cartwright  |
|  Beckman Institute             |                                |
|  405 N. Mathews                |                                |
|  Urbana, IL  61801             |                                |
|  Work: 217/244-1923            |                                |
|  Home: 217/359-8225            |                                |
-------------------------------------------------------------------
Newsgroups: comp.sys.sgi
From: markm@portal.vpharm.com (Mark Murcko)
Subject: How to run parallel jobs across a network of SGI machines
Organization: Vertex Pharmaceuticals Incorporated
Date: Sat, 10 Oct 1992 19:07:00 GMT

      A question for the group on parallelization...

      It would be very useful to be able to run a job across
a network in parallel.  Say you have a few R4000s, a few 420s,
a few PI's, etc., and you have some kind of program that you
think ought to be fairly easy to parallelize.  How might one
attempt this over such a heterogeneous network?  I already
know about the existence of Linda, although I haven't yet
played with it.  Is that the best solution, or are there
other ways to tackle this problem?  Any insights welcome!

/ Mark
From: HERBER@fnal.fnal.gov (Randolph J. Herber, CD/DCD/USS, x2966)
Newsgroups: comp.sys.sgi
Subject: Re: file size limit (2^31?)
Date: 9 Oct 92 15:56:07 GMT

+From: Frank Perdicaro <frank@marvin.contex.com>
+Newsgroups: comp.sys.sgi
+Subject: Re: file size limit (2^31?)
+Date: 8 Oct 92 13:19:01 GMT

+In article <1992Oct7.141251.9394@cc.ic.ac.uk> cmaae47@cc.ic.ac.uk writes:
+>In article <1992Oct5.193943.8979@nrcnet0.nrc.ca>, cantin@nrccsb3 (Claude Cantin) writes:
+>- 
+>- It seems the largest file size we can create is 2147483647 characters (that's
+>- from ls -l command).  This is also 2**31...
+>- 
+>- Have we reached the file size limit?  Do R4000-based systems have that
+>- same limit?  
>
+>Currently, yes. Under unix files are byte-addressable, if the file is 2**31

....

+Think about it.  An 8 bit machine must be able to access files bigger
+than 2^8 bytes, right?  So this problem was solved during the Kennedy
+administration, and forgotten about.  Check out Charle Rupp's latest 
+book on operating system theory on why this is an easy problem, and 
+( I think ) Tanenbaum's book on MINIX on how to solve the problem.

+	 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

Consider: why is the file seeking system call called `lseek' and not `seek'?
The extension of this thought would result in a `llseek'.

In pre-Release 6 days, the UNIX operating system had a `seek' system call.
The offset was supplied as a 16-bit signed int.  `lseek' was added that
took a 2-element int array (so that the storage was effectively a 32-bit
integer) for the offset.  `llseek' could be added that took a int array
(so that the storage is effectively a 64-bit integer) for the offset.  

Of course, shorts could be 16-bit integers, ints could be 32-bit integers and
longs could be 64-bit integers.  And that would be ANSI C compatible also!
Then off_t could be a long and have the desired effect.

Randolph J. Herber, herber@fnalf.fnal.gov, +1 708 840 2966
(Speaking for myself and not for US, US DOE, FNAL nor URA.)
(Product, trade, or service marks herein belong to their respective owners.)
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: PROM level password???
Date: 7 Oct 92 04:19:06 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <3021@contex.contex.com> frank@marvin.contex.com (Frank Perdicaro) writes:

| In article <32910@adm.brl.mil> adaptive@cs.nps.navy.mil (zyda res acct) writes:
| >When I try to get into the PROM level on my Indigo through the system
| >maintenance menu I am prompted for a password. The problem is that I
| >never installed any passwords on the system since it came from SGI. I
| >perform all the systems admin duties so there isn't anyone else that
| >could have installed it. So, does anyone know how to get around this
| >password in order to get to the PROM level?

| On some very early Indigoes, one needed a soldering iron, solder, and
| wick to cure this.

On exactly 30 systems (by actual count).  Almost all of them went to
SGI field offices.

| On some later Indigoes, the factory mysteriously set the passwd to
| "sgi".  

This is untrue.  One of the last steps in the mfgr process is to
run resetenv in the PROM to reset all defaults, and we wouldn't
be able to get there if a PROM password was set.  I've been on
the line, and talked to all the mfg folks, and all are agreed this
has *never* happened in the factory.

I *have* heard from a couple of people that bought sales demo
systems that had the password set to sgi.  I have yet to find
out if the sales folks set it, or one of the people using the
demo system.


| The passwd can be cleared via use of nvram(1M).  

Only if you can boot multi-user.  In this case, they can't.
(I've exchanged a number of email messages.)

| Except on a Crimsion with IO3B, where one still needs a chip puller.

Actually, simply pulling the battery on IO3's for about 30 minutes
will do the job (note that it is on the IO3, *not* the CPU board).


The general fix on Indigo's is to pull the cpu and graphics boards
out, pull the nvram chip (actually a serial EEROM in an 8 pin DIP
package, and socketed), put the boards back in, and boot.  The original
idea was to then stop in the PROM monitor, put the nvram back, and
reset all the nvram variables.  As finally executed, this is virtually
impossible on an Indigo w/o laying the system open on a bench; the
30 and 35 don't suffer from that problem, nor will future products.

Without the NVRAM, you lose the ethernet address, and for those
who need to boot or install across the net, the IP address.  The
lack of an ethernet address can be a nasty problem...
--
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: calvin@dinkum.mti.sgi.com (Calvin Vu)
Subject: Re: 4.0.3 FORTRAN missing .lok files
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 8 Oct 1992 16:49:30 GMT

In <1992Oct6.233150.7104@ml.csiro.au> peter@ml.csiro.au (Peter Campbell) writes:

| Am I correct in thinking that since 4.0.3 FORTRAN does not create the .lok
| file for indexed files?  This was not mentioned in the release notes.  
| 

	That's correct.  The old implementation which used the .lok file
for record locking did not work across NFS when several processes on
different machines accessing the same NFS-mounted file (the record lock
created by a process on one machine is ignored by a process on another 
machine).  The new scheme, which only worked after fixing several NFS and 
libisam bugs does not require the .lok file and will work across NFS.  When 
the .lok file is present (because it has been created by the old libisam) 
it is ignored and does not cause any detrimental effect.   That's why
I forgot to mention that fact in the release notes since it's pretty much
inconsequential whether the .lok file is present or not.

| Peter Campbell       peter@ml.csiro.au
| CSIRO Marine Labs, Hobart, Australia

--
Calvin H. Vu	
calvin@sgi.com   
Newsgroups: comp.sys.sgi
From: derek@iris40.houst.sgi.com (Derek Spears)
Subject: Re: MIDI software for SGI?
Reply-To: derek@iris40.houst.sgi.com (Derek Spears)
Organization: sgi
Date: Mon, 12 Oct 1992 21:14:00 GMT

In article <2051@celia.UUCP>, gray@celia.UUCP (Steve Gray) writes:
|> I seem to remember some discussions about MIDI software being developed at
|> SGI.  Can anyone help me out with the name of a product and/or a person to
|> contact?
|> 
|> Also, how about something to decode SMTPE time code which was being input 
|> through the audio port of an Indigo.  (I realize the if there is MIDI stuff
|> available, I could use a SMPTE to MIDI sync converter and then read the MIDI
|> time code through a serial port... but it would be nice to avoid the extra
|> hardware if all that was needed was synchronization.)
|> 
|> Thanks!

	SGI has a MIDI library if that is what you are looking for.
	If you are more interested in apps, The Blue Ribbon SoundWorks
	has ported their SuperJam! and Bars&Pipes Pro software to the SGI.
	I believe SuperJam! is in beta right know and B&P is probably slated
	for next year. Both were shown at SIGGRAPH this year in the SGI
	booth. You can give them a call at (404) 377-1514. They are in
	Atlanta so beware timezone diffs.

-- 

_____________________________________________________________________________

	Derek Spears			Thats it. No cute pictures.
	Applications Support		No fiery political statements.
	Silicon Graphics Inc.		Nothing about water skiing.

	derek@sgi.com			Oh wait.....
	(713) 293-9292			"Water Ski till ya drop!"
From: jeff@hobbes.contex.com (Jeff Carey)
Newsgroups: comp.sys.sgi
Subject: Re: bug in SCSI tape driver or tps man page ?
Date: 9 Oct 92 15:58:43 GMT
Organization: Xyvision Design Systems

In article <qrfii5g@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>In <qrbk0kc@sgi.sgi.com> jeremy@classic.asd.sgi.com (Jeremy Higdon) writes:
...
>
>| I think the man page is the way it should be, and the driver is wrong, but
>| that's just my opinion.
>
>I agree with Jeremy, and this will almost certainly be fixed in the next
>major release (by one of us).

So, my current tally, again:
1. "man tps" "TAPE MOVEMENT CRITERIA" note 4. will be changed to describe
	the way the tpsc driver currently works.
2. the tpsc driver will be changed to act exactly as the "man tps"
	"TAPE MOVEMENT CRITERIA" note 1. reads.

Is this correct?
or, should #2 read:
2. the tpsc driver will be changed to act exactly as the "man jagtape"
	"TAPE MOVEMENT CRITERIA" note 1. reads, and the "man tps" man page
	"TAPE MOVEMENT CRITERIA" note 1. will be changed to match.

No need to answer that, I'll be reading the man pages again at the next
major release, anyway, because...

I'll be changing the number of backward space file marks I have to do
to leave the tape at a desired position, again, in the next major release.


Thanks to both of you for all the help,

-jeff

P.S.
A colleague here is surprised how long I've kept this thread going; he
wondered how long I could keep it going.  (Hopefully, all is solved, for now.)
After seeing this, he says he wonders why he sometimes gets NO response
after posting suspected C++ bug reports, etc.

-- 
Jeff Carey
jeff@contex.com       (or: contex!jeff@uunet.uu.net)
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: trouble with dd and exabytes
Date: 11 Oct 92 20:56:23 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Oct9.194651.4782@dxcern.cern.ch> burow@dxcern.cern.ch (Burkhard Burow) writes:
| We're having trouble using dd to read/write to some exabyte drives. 
| 
| e.g. on IRIX Release 4.0.4 System V z [a Crimson]
| 
| z> dd if=/dev/mt/tps1d3nrnsv bs=3600 of=/dev/null
| dd: read error: I/O error
| 0+0 records in
| 0+0 records out

3600 bytes is an unusual block size.  Are you sure that is
what the blocking factor actually is?  If you ask for more
bytes than the blocksize, you get the 'right' amount back,
but if you ask for too little, you get an error (and a console
message).  Have you looked for tape error messages in /usr/adm/SYSLOG?
What happens if you use a much larger blocksize (like 64k)?

Also, mt blksize will tell you what the blocksize is (for the
current block, when in variable block mode, obviously that doesn't
promise anything about the rest of the tape).

| we have similar troubles with a 4D/460 running 
| IRIX Release 3.3.3L System V rec03

The 8500 definitely isn't supported on 3.3.  If it works, fine, but
otherwise we don't want to hear about it ;)
--
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: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
Newsgroups: comp.sys.sgi
Subject: Re: Bug in SGI's malloc?
Date: 16 Oct 92 16:03:02 GMT
Reply-To: cmaae47@cc.ic.ac.uk
Organization: Imperial College of Science, Technology and Medicine

In article <1992Oct14.141028.23584@sol.ctr.columbia.edu>, shenkin@still3.chem.columbia.edu (Peter Shenkin) writes:
- 
- I have a question:  does this bind-real-space-on-access scheme also
- apply to statically allocated arrays? 

Basically, yes. But what do you mean by statically allocated arrays in 
Fortran ? Named common blocks ? Local arrays in a program (rather than
a subroutine) ?

- For example, if I have a
- large Fortran program which statically allocates arrays too large
- to fit in phys+swap, but I only use part of them, will this program
- also load uneventfully, but die if I try to access what doesn't fit?

Yes, depending on the virtual memory accounting scheme. 

- And now that I come to think of it, isn't this the way VMS works?

No, VMS has a page file quota, a login count quota and a process depth 
limitation, and will (afaik) dot swap space around on all available disk 
blocks. You can therefore limit the amount of overcommitment of resources.

On unix you cannot do that. Assume you want people to be able to edit 
program and data files, compile and run a program. read news and mail,
use some wordprocessing etc, (but no X). Say you want to support 10 users
concurrently. You need:

2 Logins per user (so that they can kill a hung session themselves)
10 concurrent processes per login (ever tried troff with less ?)
20 Mbytes maximum (virtual) memory per process (say, you cant do a 
   lot with that, but you have to set a limit)

... 4 Gbyte swap space to guarantee your users can do that.

With VMS you do not have the deep nesting of processes, and if you limit
your users to 50 Mbyte drop file quota than half a Gigabyte would suffice.

50 Mbyte is a lot on VMS already, be cause the code is smaller (not RISC)
and the machines (generally) slower, so people keep their arrays to a size
that allows them to view the output in this life.

                                    Thomas
-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ cc.ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic.cc on Janet)
*   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain
From: simon@lia.di.epfl.ch (Simon Leinen)
Newsgroups: comp.sys.sgi
Subject: Re: more questions about /dev/plp
Date: 14 Oct 92 10:23:57 GMT
Organization: DI-LIA -- Ecole Polytechnique Federale de Lausanne
In-reply-to: olson@anchor.esd.sgi.com's message of 14 Oct 92 05:57:43 GMT
X-Md4-Signature: dd3ca4287dabad53f33f3a7ec8be4d95

olson@anchor.esd.sgi.com (Dave Olson) writes:

   We ship gpsinterface now which is known to work over parallel
   ports, even unidirectional ones, as it doesn't need to do the
   chatting.

We have an HP IIISi connected to the (bidirectional) parallel port of
an Indigo, and gpsinterface works *almost* perfectly (I had to modify
it to send Control-D's between jobs).

   Transcript (or more accurately, the part thereof that wants to chat
   with the printer) should theoretically be able to work over the
   parallel port on Indigo and other SGI systems with bidirectional
   parallel ports, but we've never tested that, and I suspect that
   there would be some problems.

The HP IIISi doesn't seem to know that it can write to the parallel
port - at least I haven't been able to read anything from /dev/plp.
Since this printer is already quite sophisticated, I assume that most
other printers don't have/use bidirectional parallel ports either.

This is really a pity because if you want to know what's going wrong
in the printer, you have to download a PS error handler and waste
paper.  I have never tried transcript with the HP, but if it wants to
"chat", i.e. expects the printer to respond over the parallel port,
this probably won't work.
-- 
Simon.