Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01256; 2 Nov 89 6:29 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01047; 2 Nov 89 6:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01021; 2 Nov 89 5:54 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18466; 2 Nov 89 5:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA24000; Thu, 2 Nov 89 02:42:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Nov 89 10:40:56 GMT From: gem.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!sam@tut.cis.ohio-state.edu Subject: vt100 emulator ? Message-Id: <223000003@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there a VT-100 emulator for the Personal Iris (4sight)? If so, where can it be obtained?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08416; 2 Nov 89 13:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07264; 2 Nov 89 12:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07204; 2 Nov 89 11:46 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29165; 2 Nov 89 11:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA11994; Thu, 2 Nov 89 08:27:02 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Nov 89 15:21:15 GMT From: Bill Lasher Organization: Penn State University Subject: fsck; init state 3 Message-Id: <89306.102115W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have a room of 20 Personal IRIS's being used as a student lab. Each machine has a drive, so student files and application software is scattered all over the room. Each machine is mounting several other machines. 1. We were having several bizzare problems, such as df reporting disks full when they weren't, hung network spool queue's, etc. We implemented a nightly fsck, and that seems to fix the problems. The thing is that fsck reports 31 blocks missing every time, even if we run it right after it has been run. Do we really have a problem, or is this common? 2. In /etc, there is a file called rc3, which is for init state 3. The comments say it is just like init state 2, but with remote file sharing. Does anyone know what this is about? Should we be using it, and if so, how? Is it possible that this is related to problem 1? I would appreciate any suggestions.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01749; 2 Nov 89 21:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01726; 2 Nov 89 21:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01685; 2 Nov 89 21:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12645; 2 Nov 89 20:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA17054; Thu, 2 Nov 89 17:33:08 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Nov 89 22:44:40 GMT From: Bill Lasher Organization: Penn State University Subject: Genealogy software Message-Id: <89306.174440W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know of a good genealogy software package for the MAC? Any comments would be appreciated.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00471; 2 Nov 89 23:10 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00424; 2 Nov 89 23:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00408; 2 Nov 89 22:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13206; 2 Nov 89 22:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA23264; Thu, 2 Nov 89 19:12:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Nov 89 02:23:49 GMT From: "Roger B.A. Klorese" Organization: MIPS Computer Systems, Sunnyvale, CA Subject: Re: waiting for `man'........ Message-Id: <30694@servitude.mips.COM> References: <8911010343.AA18890@> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911010343.AA18890@> art@lsr-vax.UUCP (Art Hays - PSTAFF) writes: >>Date: 31 Oct 89 02:01:00 GMT >>From: Dave Ciemiewicz >>Organization: Silicon Graphics, Inc., Mountain View, CA >> >>I'm sorry to say that the desparately desired -k and -w (apropos and whatis) >>features from BSD have not been implemented in the 3.2 man. As SGI's licensing >agreements with AT&T require us to ship preformatted manual pages. > > I would like to know why SGI's licensing agreement precludes shipping >unformatted manual pages. This is an inconvenience. I briefly checked >a few other vendors here (Sun, Convex, Ultrix) and they ship unformatted pages. The difference is their porting base. Version 7 from AT&T (and accordingly, BSD) allows the shipment of man page "source" to binary licensees. System V licensing considers the source of manual pages to be "source", and requires the vendor to (a) buy an additional redistribution license to ship this "source" to binary customers, and (b) ascertain that the customer has a valid source license from AT&T to permit them to have this "source". As a result, it is very difficult for us shippers of SysV based software to send manual page source to our customers. -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I want to live where it's always Saturday." -- Guadalcanal Diary   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00621; 2 Nov 89 23:42 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab00424; 2 Nov 89 23:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00408; 2 Nov 89 22:43 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13251; 2 Nov 89 22:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA24358; Thu, 2 Nov 89 19:31:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Nov 89 03:26:51 GMT From: Jason Heirtzler Organization: Boston University Distributed Systems Group Subject: how do you do your remote backups ? Message-Id: <41875@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL If you're doing multi-volume backups remotely, but not to another SGI (maybe a Sun), and you think your method is pretty reliable, I'm interested in hearing how you're doing it. bru doesn't seem like it handles multiple volumes correctly if you are writting to a pipe, ie # bru cvm -f - -s 120M | rsh host dd bs=20k of=/dev/rmt8 The ideal solution would be 4.3 dump (does anyone have this?) If there's significant interest, I'll summarize to the net ------------------------------------------------------------------------- Jason Heirtzler (617) 353-2780 jdh@bu-pub.bu.edu Information Technology Boston University ..!harvard!bu-cs!bu-it!jdh   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01139; 3 Nov 89 8:38 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00808; 3 Nov 89 8:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00672; 3 Nov 89 8:18 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16249; 3 Nov 89 5:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA14031; Fri, 3 Nov 89 01:59:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Nov 89 22:24:26 GMT From: Andrew Hume Organization: AT&T Bell Laboratories, Murray Hill NJ Subject: versatec Message-Id: <10089@alice.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL i am trying to find out how to attach a 36in colour versatec plotter to either an SGI 4D/240 or a MIPS M2000. i have spoken to salespeople from sgi, mips, and versatec. silence for over three months, other than a suspicion that someone must have connected a versatec to an SGI somewhere. does anyone have any clue? does anyone know of, or have, a versatec attached to a VME bus? please email any repsonse to andrew@research.att.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00538; 3 Nov 89 4:22 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00470; 3 Nov 89 4:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00456; 3 Nov 89 4:04 EST Received: from mirsa.inria.fr by SMOKE.BRL.MIL id ab15794; 3 Nov 89 3:44 EST Received: from kwai.inria.fr by mirsa.inria.fr with SMTP (5.59++/IDA-1.2.8) id AA03609; Fri, 3 Nov 89 09:31:55 +0100 Received: by inria.fr with X.400; 03 Nov 89 09:31:59+0100 Received: by ch; 03 Nov 89 09:31:04+0100 Date: 03 Nov 89 09:31:04+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: RE: 3.2. df on non-SGI drives Message-Id: <77*doelz@urz.unibas.ch> We run the UCX connection software on YOGI, a VAX-HSC cluster (VMS 5.1 and 14 giga disk) , and normal convex unix on CONVEX. Here's my df on it (120GTX, 2x380 megs) modl [/] % df Filesystem Type blocks use avail %use Mounted on /dev/root efs 33075 29601 3474 89% / /dev/tmp efs 38000 28249 9751 74% /tmp /dev/usr2 efs 43200 35582 7618 82% /usr2 /dev/usr efs 251790 227136 24654 90% /usr yogi:/extra12/doelz nfs 7128576 5445120 1683456 76% /yogi_doelz yogi:/extra8/mehler/pdblib nfs 1344640-1755776 3100416-130% /yogi_pdb yogi:/week nfs 5868544-2023680 7892224 -33% /yogi_week yogi:/day nfs 7128576 4339584 2788992 61% /yogi_day convex:/people nfs 367774 111924 255850 30% /convex_people convex:/mnt nfs 485998 348998 137000 72% /convex_mnt convex:/tmp nfs 81278 8278 73000 10% /convex_tmp /dev/biozen efs 79800 64708 15092 81% /biozen /dev/software efs 193800 182157 11643 94% /software /dev/profi2 efs 50470 20187 30283 40% /profi2 /dev/profi efs 235600 233029 2571 99% /profi /debug dbg 307672 71032 236640 23% /debug modl [/] % Isn't it nice to have negative disk usage ? This means that I have to write something on the disk in order to get it empty ... (BTW: on the convex, disk usage is reported OK for YOGI disks). :-) Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00538; 3 Nov 89 4:23 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab00470; 3 Nov 89 4:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00456; 3 Nov 89 4:04 EST Received: from mirsa.inria.fr by SMOKE.BRL.MIL id aa15830; 3 Nov 89 3:56 EST Received: from kwai.inria.fr by mirsa.inria.fr with SMTP (5.59++/IDA-1.2.8) id AA04496; Fri, 3 Nov 89 09:56:31 +0100 Received: by inria.fr with X.400; 03 Nov 89 09:56:33+0100 Received: by ch; 03 Nov 89 09:56:06+0100 Date: 03 Nov 89 09:56:06+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: man, apropos, help Message-Id: <78*doelz@urz.unibas.ch> Hi, A while ago, Dave Ciemiewicz posted a quite useful "apropos" utility as an archive.It takes a while to build the tables, and it does report some strange hits, but this is far better than nothing. The utility does still work under 3.2, and I like it a lot. Thus, there are a few gimmicks involved. E.g., modl [/] % apropos manual man (1) - print entries from the on-line reference manuals; find manual entries by keyword route (1M) - manually manipulate the routing tables whereis (1) - locate source, binary, and or manual for program xman (1) - display manual pages There is something called XMAN. Besides, the man page of Xman sounds nice, but there is no xman, Xman etc. on my 3.2. (?). A real joke is the "help" man mage. Try it, and you'll get HELP(1) Silicon Graphics HELP(1) NAME help - ask for help SYNOPSIS help [args] DESCRIPTION Help finds information to explain a message from a command or explain the use of a command. Zero or more arguments may be supplied. If no arguments are given, help will prompt for one. ... (stuff deleted. )... GREAT - thats what we're looking for, right ? The only problem is a line at the end stating the following : BUGS The help(1) command does not work and is not shipped on IRIS-4D products. Page 1 Release 3.2 July 1989 :-) Reinhard.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01385; 3 Nov 89 15:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00972; 3 Nov 89 15:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00929; 3 Nov 89 14:59 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa28293; 3 Nov 89 13:25 EST Received: from cmcl2.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP id AA20909; Fri, 3 Nov 89 13:26:03 EST Received: by cmcl2.NYU.EDU (5.61/1.34) id AA10367; Fri, 3 Nov 89 12:57:01 -0500 Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA09084; Fri, 3 Nov 89 11:14:33 EST Date: Fri, 3 Nov 89 11:14:33 EST From: Rod Paul Message-Id: <8911031614.AA09084@dasys1.UUCP> To: info-iris@BRL.MIL, jdh@cs.bu.edu Subject: Re: how do you do your remote backups ? > From: Jason Heirtzler > If you're doing multi-volume backups remotely, but not to another > SGI (maybe a Sun), and you think your method is pretty reliable, > I'm interested in hearing how you're doing it. > > bru doesn't seem like it handles multiple volumes correctly if you > are writting to a pipe, ie > > # bru cvm -f - -s 120M | rsh host dd bs=20k of=/dev/rmt8 Have you tried the -Nuser@host (I beleive this is the flag) option to "bru"? Where host is the machine with the tape device.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac01385; 3 Nov 89 15:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00972; 3 Nov 89 15:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00950; 3 Nov 89 15:00 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28912; 3 Nov 89 13:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA11867; Fri, 3 Nov 89 10:33:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Nov 89 14:26:00 GMT From: David Wood Organization: New York University Subject: Re: how do you do your remote backups ? Message-Id: <17280023@acf4.NYU.EDU> References: <41875@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I while back someone posted gnutar with sgi patches (through anonymous ftp from I forget where). If you are interested though you can anonymous ftp what I have on our 4d/80GT from cmcl2.nyu.edu (128.122.128.2) in pub/iris/sgigtar.tar.Z. We just began using it to dump to a remote tape on an VAX 785 and it seems to work fine. The only thing is that you should keep a copy (bru) of the binary on a cartridge somewhere in case the disk with the gnutar binary crashes. ------------------------------------------------------------------------- David Wood wood@acf2.nyu.edu New York University ...!uunet!cmcl2!wood 212-998-3029 "Brain. Brain. What is brain?" Kara the Eymorg, "Spock's Brain", Stardate 5432.3 -------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac02153; 3 Nov 89 16:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01385; 3 Nov 89 15:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01009; 3 Nov 89 15:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00910; 3 Nov 89 14:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15040; Fri, 3 Nov 89 11:21:35 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Nov 89 18:52:52 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: versatec Message-Id: <44006@sgi.sgi.com> References: <10089@alice.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <10089@alice.UUCP>, andrew@alice.UUCP (Andrew Hume) writes: > > i am trying to find out how to attach a 36in colour > versatec plotter to either an SGI 4D/240 or a MIPS M2000. > i have spoken to salespeople from sgi, mips, and versatec. > silence for over three months, other than a suspicion > that someone must have connected a versatec to an SGI > somewhere. does anyone have any clue? does anyone > know of, or have, a versatec attached to a VME bus? > > please email any repsonse to andrew@research.att.com I decided to post this so that others could get the info, andrew. There is a controller that we sell called something like 'Controller for Parallel Interface' in our price book. This was released to support Centronics interface printers. It also has the capability to run Versatec Greensheet interface. Versatec sells plotters with the Greensheet and Centronics interfaces, BTW. It consumes a VME slot. SGI also has /dev/vp0 for you. This assumes connection to the Versatec port on the controller. Now, here's the problem; There was no demand for this interface for a long time, so rather than consume an option slot on the I/O panel with a cable taking Greensheet to the I/O panel, we left it out and decided to do it if and when there was sufficient customer demand to use up that limited resource on the I/O panel. It made sense at the time, you see. Now, if you buy this board, you could either make up an internal cable to go to the I/O panel, etc. or you could remove an empty slot on your I/O panel and run the cable from the plotter directly to the board. Do this being forewarned that the machine will no longer pass FCC, and that there is no *good* strain relief for that cable at the board itself and (as if it needs saying) this sort of set-up is not supported by SGI, officially. Perhaps it is time we used up the option slot on the I/O panel to bring this to the outside world? Please e-mail me if you are interested in having this done. I'll forward this to Marketing to see if it gets the official OK to productize this capability of the controller and its driver. It will take a while to officially productize this seemingly trivial thing, but it means new bills of materials, more Safety Agency testing (FCC, CSA, TUV, VDE, UL, etc.), DVT and so on. Thanks. markb -- Mark Bradley "Faster, faster, until the thrill of I/O Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA 94039-7311 ---Hunter S. Thompson ******************************************************************************** * Disclaimer: Anything I say is my opinion. If someone else wants to use it, * * it will cost... * ********************************************************************************   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02862; 3 Nov 89 16:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00972; 3 Nov 89 15:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00939; 3 Nov 89 15:00 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28897; 3 Nov 89 13:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA11917; Fri, 3 Nov 89 10:34:32 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Nov 89 14:10:00 GMT From: David Wood Organization: New York University Subject: Re: how do you do your remote backups ? Message-Id: <17280022@acf4.NYU.EDU> References: <41875@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL /* acf4:comp.sys.sgi / jdh@bu-cs.BU.EDU (Jason Heirtzler) / 10:26 pm Nov 2, 1989 */ If you're doing multi-volume backups remotely, but not to another SGI (maybe a Sun), and you think your method is pretty reliable, I'm interested in hearing how you're doing it. bru doesn't seem like it handles multiple volumes correctly if you are writting to a pipe, ie # bru cvm -f - -s 120M | rsh host dd bs=20k of=/dev/rmt8 The ideal solution would be 4.3 dump (does anyone have this?) If there's significant interest, I'll summarize to the net ------------------------------------------------------------------------- Jason Heirtzler (617) 353-2780 jdh@bu-pub.bu.edu Information Technology Boston University ..!harvard!bu-cs!bu-it!jdh /* ---------- */   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00446; 3 Nov 89 18:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00273; 3 Nov 89 17:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00222; 3 Nov 89 17:19 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa04500; 3 Nov 89 16:20 EST Received: Fri, 3 Nov 89 16:20:14 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 3 Nov 89 16:20:14 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8911040020.AA12098@aero4.larc.nasa.gov> To: alice!andrew@ucbvax.berkeley.edu, info-iris@BRL.MIL Subject: Re: versatec I was given the impression that the versatec plotters were a 'supported' device on SGI equipment. Do you use a Centronix interface to the plotter? Maybe it was only on the 3000's that it was supported. I remember seeing a note some where in the 3130 manuals about versatec plotters being supported. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01415; 3 Nov 89 20:13 EST Received: by VMB.BRL.MIL id al01111; 3 Nov 89 20:03 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02153; 3 Nov 89 16:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01428; 3 Nov 89 15:30 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01959; 3 Nov 89 14:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA16389; Fri, 3 Nov 89 11:41:48 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Nov 89 19:17:05 GMT From: "Calvin H. Vu" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Upgrading to 3.2 Message-Id: <44008@sgi.sgi.com> References: <8911010803.aa25007@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911010803.aa25007@SMOKE.BRL.MIL>, XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: > > 2) We have a medium sized fortran program (MOPAC 5.0, 25000 lines > of code, -static dependent). After compiling it with the 3.2 > compiler it went into infinite loops even for water-molecules. > The 3.1d version worked fine. We use the following compilation > flags: '-static -g -vms'. First I thought it was an optimizer > problem (using '-O2'), but the problem stays using '-g'. This > is really a problem, because we and probably two or three other > SGI customrs might want to run large fortran programs. > Martin has spent some more time on this problem and found out that it was the use of -vms option that caused the problem. From 3.2 release that confusing option is being phased out, is no longer documented in the man page, and is replaced by -vms_cc (to mean VMS carriage control). Most people think that -vms is some kind of magic flag that gives you instantaneous VMS compatibility and I'm tired of explaining what -vms is supposed to mean every other day so I tried to phase it out. And, what do you know, as soon as I try to kill it, it acts up %-(. Anyway, the problem is not at all related to the size of the program. If anybody out there are still using -vms, please switch to -vms_cc. The only difference between the two options is that one works and one doesn't. > Regards > Martin Knoblauch Thanks, Martin. You're great. - calvin   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00089; 3 Nov 89 21:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01577; 3 Nov 89 21:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01545; 3 Nov 89 20:51 EST Received: from gatech.edu by SMOKE.BRL.MIL id aa26977; 3 Nov 89 12:48 EST Received: from hydra.gatech.edu by gatech.edu (5.58/GATECH-8.6) id AA02557 for ; Fri, 3 Nov 89 12:01:52 EST Received: by hydra.gatech.edu (4.12/2.5) id AA13214; Fri, 3 Nov 89 11:45:11 est Date: Fri, 3 Nov 89 11:45:11 est From: "SCHREIBER, O. A." Message-Id: <8911031645.AA13214@prism.gatech.edu> To: info-iris@BRL.MIL Subject: tek 4014 emulator for 4D120GTX Cc: ccsupos@prism.gatech.edu I would like to open a tektronikx 4014 window on an iris 4D120GTX. Is it possible? Thanks.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00469; 3 Nov 89 22:53 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00393; 3 Nov 89 22:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00351; 3 Nov 89 22:24 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07972; 3 Nov 89 20:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA08129; Fri, 3 Nov 89 17:12:03 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Nov 89 00:47:28 GMT From: Geoff Collyer Organization: Statistics, U. of Toronto Subject: Re: fsck; init state 3 Message-Id: <1989Nov4.004728.10673@utstat.uucp> References: <89306.102115W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Bill Lasher: > The thing is that fsck reports 31 blocks missing every time, even if > we run it right after it has been run. Do we really have a problem, > or is this common? We are considering buying a 4D210 but we are concerned by reports from other departments here and from SGI's sales people that SGI's fsck is ``unreliable'' or that it can take multiple passes to clean a damaged filesystem. Some people locally claim that the problem is inherited from MIPS or System V, but until the SGI machines arrived, I had never encountered or heard reports of such problems on machines with working hardware (I've been working on Unix machines, including PDP-11s, VAXen, Suns and IBM 370s, since fsck was invented). Can any of you offer evidence that SGI's or MIPS's (production) fsck always corrects severely damaged filesystems in one attempt (or admits defeat and gives up)? Do you have evidence that SGI's or MIPS's fsck has ever claimed to have repaired a filesystem which then turned out to be damaged? Proof would be nice, but strong evidence will suffice. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00928; 4 Nov 89 0:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00654; 4 Nov 89 0:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00597; 3 Nov 89 23:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09579; 3 Nov 89 22:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA17352; Fri, 3 Nov 89 19:46:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Nov 89 01:04:28 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 3.2. df on non-SGI drives Message-Id: <44037@sgi.sgi.com> References: <77*doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here's one of many small porting problems SystemV.3-based NFS implementors must solve. The NFS protocol defines three numbers to do with disk space usage: blocks total capacity of the filesystem bfree free blocks in fs bavail free blocks available to non-superuser But V.3's statfs(2) call provides df(1), e.g., with only two numbers: blocks total number of blocks in fs bfree total number of free blocks For NFS servers serving the Berkeley Fast File System, bavail < bfree, typically by ten percent of capacity. Prior to 3.2, we discarded NFS's bavail number, passing blocks and bfree back via their statfs namesakes. In 3.2, we chose to pass NFS's bavail back to df via statfs's bfree member. This ensures that df's "avail" column agrees between SGI clients and servers such as Suns that export Berkeley FFS. Most mere mortals are interested in free blocks available to non-superuser, and don't want to be tantalized by the ten percent reserved for root. AT&T V.4 adopts Sun's statfs structure and the FFS, so there will be enough pigeon-holes for the NFS protocol numbers when that millenium arrives. The original posting about funny numbers from df didn't say so, but the server in question was an SGI 31XX running release 3.6. This old version of NFS server code incorrectly set bavail to (blocks - bfree), so that df would get the "avail" column value from statfs's bfree, and would compute "use" from the statfs numbers as "use" = blocks - bfree = blocks - (blocks - bfree) = bfree Thus, "use" and "avail" are exchanged when using df on a 4D client running 3.2 that mounts from a 3000-series server running 3.6. The bug is in the server's NFS implementation; a change to the SGI NFS client implementation exposed it. In article <77*doelz@urz.unibas.ch>, doelz@urz.unibas.ch (Reinhard Doelz) writes: > We run the UCX connection software on YOGI, a VAX-HSC cluster (VMS > 5.1 and 14 giga disk) , and normal convex unix on CONVEX. Here's my df on it > (120GTX, 2x380 megs) > > modl [/] % df > Filesystem Type blocks use avail %use Mounted on > yogi:/extra12/doelz nfs 7128576 5445120 1683456 76% /yogi_doelz > yogi:/extra8/mehler/pdblib nfs 1344640-1755776 3100416-130% /yogi_pdb > yogi:/week nfs 5868544-2023680 7892224 -33% /yogi_week > yogi:/day nfs 7128576 4339584 2788992 61% /yogi_day The overlarge "avail" entries for yogi:/extra8 and yogi:/week make me wonder whether the VAX-HSC/VMS server isn't setting NFS's bavail number incorrectly. It would be interesting to see the output of a VMS df-equivalent. Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.brl.MIL id ac00089; 4 Nov 89 1:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00928; 4 Nov 89 0:24 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00707; 3 Nov 89 23:57 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09851; 3 Nov 89 23:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA19244; Fri, 3 Nov 89 20:21:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Nov 89 22:48:47 GMT From: Operator Organization: Division of EMBA, University of Vermont Subject: flight Message-Id: <1326@uvm-gen.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi! I picked up the diffs that someone sent in for dog - trying to get it to run point to point. I copied everything from the source directories into my home directory, then compiled. There were a lot of changes from the executable that we have on the system: the planes had gouraud shading the time of day reflected that of the real world, there was a wingman's view, etc. However, it wouldn't fly correctly. In simple level flight, without my having moved the mouse, the flight path would start oscillating by about 20 degrees in both the horizontal and the vertical direction. I would really like to get the improved version running ( with point to point dog!! ). Can anybody tell me what is wrong and/or what I can do to fix it? operje@griffin.uvm.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00355; 4 Nov 89 1:49 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab00089; 4 Nov 89 1:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00943; 4 Nov 89 0:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09849; 3 Nov 89 23:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA19421; Fri, 3 Nov 89 20:23:39 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Nov 89 22:55:18 GMT From: Operator Organization: Division of EMBA, University of Vermont Subject: LaTeX Message-Id: <1327@uvm-gen.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have a nice X-windows LaTeX previewer on our sun3. When I try to run it in a window on one of the iris's, the letters all have extra dark areas around them - not symmetrically around the letters, but apparently random. Anybody have a fix for this problem?? operje@griffin.uvm.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01748; 4 Nov 89 6:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01683; 4 Nov 89 6:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01668; 4 Nov 89 6:12 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13309; 4 Nov 89 6:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA09238; Sat, 4 Nov 89 02:55:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Nov 89 20:16:06 GMT From: "Mark V. Meuer" Organization: University of Minnesota, Minneapolis Subject: Dvi file previewer Message-Id: <16775@umn-cs.CS.UMN.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A long time ago someone said they had a DVI file previewer for the Iris and that they would post an address where it could be snarfed by ananymous FTP. Well, it's been a number of months and either I missed it or it was never posted. If someone has such a program PLEASE let us know! Thanks! -mark Mark Meuer | 1200 Washington Ave. So. Geometry Supercomputer Project | Minneapolis, MN 55415 meuer@geom.umn.edu | (612) 624-1867 -- Mark Meuer | 1200 Washington Ave. So. Geometry Supercomputer Project | Minneapolis, MN 55415 meuer@geom.umn.edu | (612) 624-1867   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00647; 5 Nov 89 2:39 EST Received: by VMB.BRL.MIL id ac00509; 5 Nov 89 2:33 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00213; 4 Nov 89 21:30 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00186; 4 Nov 89 21:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01935; 4 Nov 89 19:07 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA14056; Sat, 4 Nov 89 15:55:47 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Nov 89 18:03:54 GMT From: Bill Lasher Organization: Penn State University Subject: Re: fsck; init state 3 Message-Id: <89308.130355W0L@PSUVM.BITNET> References: <89306.102115W0L@PSUVM.BITNET>, <1989Nov4.004728.10673@utstat.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Correction and clarification: A few days ago I posted a note stating that fsck was reporting 31 missing blocks every time we ran it, even if we ran it consecutively. I have since been told by SGI that we were running fsck improperly (we were not unmounting everything beforehand). We are new to UNIX, and I admit the error. I have since unposted the original note. The basic problem remains, however. We have had several strange problems that did not get corrected by rebooting; running fsck appears to correct them. This seems unusual, since fsstat is run at bootup, and will run fsck if it finds a problem. However, (being new to UNIX), I did not want to look a gift horse in the mouth. SGI told me that running fsck without unmounting was giving me a wrong impression of what fsck was doing. Again, I am new to UNIX, and may be missing something, but my "revised" question is: 1. If the file system is dirty, why isn't it caught at reboot by fsstat, and fixed by fsck? 2. If the file system is not dirty, what is fsck doing that rebooting did not do? I would appreciate any insight. I also asked in my original note if anyone knew whether init state 3 should be used if you are doing remote file sharing. SGI tells me that there is no need to use it on their system.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00647; 5 Nov 89 2:39 EST Received: by VMB.BRL.MIL id ad00509; 5 Nov 89 2:34 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00213; 4 Nov 89 21:30 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ac00186; 4 Nov 89 21:06 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02016; 4 Nov 89 19:36 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15193; Sat, 4 Nov 89 16:18:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Nov 89 23:59:01 GMT From: George Elkins Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: man, apropos, help Message-Id: References: <78*doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > A while ago, Dave Ciemiewicz posted > a quite useful "apropos" utility as an archive. It takes a while to build Where can I get this apropos utility? I have used such a command a lot in bsd unix, and was disappointed that it did not exist on Irises. George Elkins   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05073; 6 Nov 89 4:17 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04959; 6 Nov 89 3:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04957; 6 Nov 89 3:29 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa16920; 6 Nov 89 2:41 EST Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 1377; Mon, 06 Nov 89 02:36:56 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 06 Nov 89 08:37:23 Date: Mon, 6 Nov 89 08:34:08 +0100 (Central European Time) From: Knobi der Rechnerschrat Subject: Wanted: 327x emulation for 31xx-console, 4D-console and (dumb) VT100 To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8911060241.aa16920@SMOKE.BRL.MIL> Hallo, very soon we will get a ethernet TCP/IP connection to our IBM-3090 running MVS. This will provide us with the ability to run either teletype like terminals or terminals capable of doing 3270-stuff. To utilize our workstation and terminal equipment properly, I need the following pieces of software. a) a 327x emulator for the IRIS 31xx console b) a 327x emulator for the IRIS 4D console c) a 327x emulator for VT-100 like terminals Has anybody heard of public domain software doing this. We probably will need to have the source available, because I think we will have problems getting c). It should be PD, because we have no money to spend for such stuff. Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET:   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02052; 6 Nov 89 19:42 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01597; 6 Nov 89 19:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab01548; 6 Nov 89 18:57 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01183; 6 Nov 89 13:26 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA21431; Mon, 6 Nov 89 10:17:15 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Nov 89 17:26:12 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: man, apropos, help Message-Id: <44057@sgi.sgi.com> References: <78*doelz@urz.unibas.ch>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article , elkins@topaz.rutgers.edu (George Elkins) writes: > > A while ago, Dave Ciemiewicz posted > > a quite useful "apropos" utility as an archive. It takes a while to build > > Where can I get this apropos utility? I have used such a command a > lot in bsd unix, and was disappointed that it did not exist on Irises. > > George Elkins Here is a copy of the apropos utilities shar file. It is written for the IRIS-4D. It something I wrote a while ago. It works for the most part. As Herr Doelz pointed out, there are some bugs. Some people out there have posted variants that they feel are faster. I make no warranties as to functionality of these tools. Despite all this they are useful. The scripts provided are: makewhatis - creates the 'whatis' database apropos - searches the 'whatis' database for a string The reason makewhatis takes so long (10-15 minutes) to build the whatis database is that it must unpack and scan every single manual page on the system. BSD implementations are faster as they do not need to unpack the manual pages. A robust, somewhat faster implementation should be available in the next IRIX feature release after 3.2. #---- Cut Here 8< ------------------------------------------------------------- # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by ciemo on Wed Mar 8 19:12:24 PST 1989 # Contents: apropos mkwhatis echo x - apropos sed 's/^@//' > "apropos" <<'@//E*O*F apropos//' #! /bin/sh # # NAME # apropos - find the apropriate manual pages for a give keyword # # SYNOPSIS # apropos keyword [...] # # DESCRIPTION # apropos searches its database of manual page descriptions # for those which match the specified keywords. The search # provided is an implied "or" of the keywords. # # apropos uses a database called whatis located in the manual # page tree. This database is created using the tool mkwhatis(1). # # This functionality of this version is based on William Joy's # version from UC Berkeley. # # SEE ALSO # mkwhatis(1) # # FILES # /usr/catman/whatis # # CAVEATS # Since apropos gets its information from a "static" database, it # is possible for apropos to report the existence of manual pages # which are not on the system. # # AUTHOR # Dave Ciemiewicz (ciemo) # # COPYRIGHT (C) 1989, Silicon Graphics, Inc., All rights reserved. # This file is a product of Silicon Graphics, Inc. and is # provided for unrestricted use provided that this legend is # included on all tape media and as a part of the software # program in whole or part. Users may copy or modify this file # without charge, but are not authorized to license or distribute # it to anyone else except as part of a product or program # developed by the user. # # THIS FILE IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND # INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS # FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, # USAGE OR TRADE PRACTICE. # # This file is provided with no support and without any # obligation on the part of Silicon Graphics, Inc. to assist in # its use, correction, modification or enhancement. # # SILICON GRAPHICS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO # THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY # THIS FILE OR ANY PART THEREOF. # # In no event will Silicon Graphics, Inc. be liable for any lost # revenue or profits or other special, indirect and consequential # damages, even if Silicon Graphics has been advised of the # possibility of such damages. # USAGE="Usage: apropos keyword [...]" WHATIS=/usr/catman/whatis if test $# -eq 0; then echo $USAGE 1>&2 exit 2 fi if test ! -r $WHATIS; then echo $0": can't open "$WHATIS 1>&2 exit 1 fi for keyword in $* do egrep -i '^'$keyword'|[^a-zA-Z0-9_]'$keyword $WHATIS done | sort -u @//E*O*F apropos// chmod u=rwx,g=rx,o=rx apropos echo x - mkwhatis sed 's/^@//' > "mkwhatis" <<'@//E*O*F mkwhatis//' #! /bin/sh # # NAME # mkwhatis - make manual page "whatis" database for use with apropos # # SYNOPSIS # mkwhatis [filename] # # DESCRIPTION # mkwhatis scans the preformatted manual page trees (/usr/catman), # parses the manual pages, and strips out the NAME section information # to create the "whatis" database used by apropos(1). # # By default, mkwhatis creates the file, /usr/catman/whatis. Another # file may be created as the database by specifying its filename on # the command line. You must run mkwhatis as root to create the # whatis file. See su(1M). # # The format of the whatis file created is based on that used by # William Joy's UC Berkeley version of apropos. # # SEE ALSO # apropos(1) # # FILES # /usr/catman/whatis # # CAVEATS # This program is S...L...O...W. Expect execution times of about # 10-15 minutes. The reason is that EVERY manual page on the system # is read. # # You must run mkwhatis as root. # # AUTHOR # Dave Ciemiewicz (ciemo) # # COPYRIGHT (C) 1989, Silicon Graphics, Inc., All rights reserved. # This file is a product of Silicon Graphics, Inc. and is # provided for unrestricted use provided that this legend is # included on all tape media and as a part of the software # program in whole or part. Users may copy or modify this file # without charge, but are not authorized to license or distribute # it to anyone else except as part of a product or program # developed by the user. # # THIS FILE IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND # INCLUDING THE WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS # FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING, # USAGE OR TRADE PRACTICE. # # This file is provided with no support and without any # obligation on the part of Silicon Graphics, Inc. to assist in # its use, correction, modification or enhancement. # # SILICON GRAPHICS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO # THE INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY # THIS FILE OR ANY PART THEREOF. # # In no event will Silicon Graphics, Inc. be liable for any lost # revenue or profits or other special, indirect and consequential # damages, even if Silicon Graphics has been advised of the # possibility of such damages. # USAGE="Usage: mkwhatis [filename]" WHATIS=/usr/catman/whatis case $# in 0) ;; 1) WHATIS=$1;; *) echo $USAGE 1>&2 exit 2 ;; esac cd /usr/catman find * -type "f" -print | while read f do pcat $f | col -b | sed -e 's/ / /g' -e 's/ */ /g' -e 's/^ *//' | nawk ' BEGIN {name=0; count=0} $1 ~ /[0-9a-zA-Z_]+\([1-8][a-zA-Z]*\)/ { match($1, /\([1-8][a-zA-Z]*\)/) section = substr($1, RSTART, RLENGTH) next } $1 ~ /NAME/ {name=1; next} $1 ~ /SYNOPSIS|SY.*SIS/ {finish()} # SYNOPSIS is a common typo $2 ~ /SYNOPSIS|SY.*SIS/ {finish()} # SYNOPSIS is a common typo $1 ~ /DESCRIPTION/ {finish()} $2 ~ /SPECIFICATION/ {finish()} /^[ \t]*$/ {next} { if (name==1) nametext = nametext " " $0 next } function finish() { if (filenm ~ /g_man/) section="(3G)" # No section on GL man pages partscount = split(nametext, parts, " -") printf "%-24s", parts[1] " " section for (i=2; i<=partscount; i++) { printf " -%s", parts[i] } printf "\n" exit } ' filenm=$f done | sed -e 's/\([A-Za-z]\)- \([A-Za-z]\)/\1\2/g' -e 's/^ *//' | sort -u > $WHATIS @//E*O*F mkwhatis// chmod u=rwx,g=rx,o=rx mkwhatis exit 0 #---- Cut Here 8< -------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00918; 6 Nov 89 22:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00790; 6 Nov 89 22:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab00631; 6 Nov 89 21:51 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11791; 6 Nov 89 19:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15377; Mon, 6 Nov 89 16:28:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Nov 89 22:37:22 GMT From: David A Higgen Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: fsck; init state 3 Message-Id: <44104@sgi.sgi.com> References: <89306.102115W0L@PSUVM.BITNET>, <1989Nov4.004728.10673@utstat.uucp>, <89308.130355W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89308.130355W0L@PSUVM.BITNET>, W0L@PSUVM.BITNET (Bill Lasher) writes: > > The basic problem remains, however. We have had several strange problems that > did not get corrected by rebooting; running fsck appears to correct them. This > seems unusual, since fsstat is run at bootup, and will run fsck if it finds a > problem... > ....but my "revised" question is: > > 1. If the file system is dirty, why isn't it caught at reboot by fsstat, and > fixed by fsck? > > 2. If the file system is not dirty, what is fsck doing that rebooting did not > do? > What are the "strange problems"? Are they repeatable? or at least do you have any program/sequence-of-events that induces them with some probability in reasonable time? Obviously we can't rule out the possibility of a filesystem bug; but the filesystem does seem quite robust in production releases. What version is this? Feel free to email me info and queries & we'll try to get to the bottom of it. Dave Higgen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00918; 6 Nov 89 22:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00790; 6 Nov 89 22:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00752; 6 Nov 89 21:52 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12800; 6 Nov 89 20:54 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA20065; Mon, 6 Nov 89 17:42:21 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Nov 89 01:41:00 GMT From: cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!sam@tut.cis.ohio-state.edu Subject: Re: vt100 emulator ? Message-Id: <223000004@uxe.cso.uiuc.edu> References: <223000003@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL RE: xterm under irix 3.2 In the meantime, let me ask if anyone can tell me where one finds the key mapping for the VT100 "do" key (so important to the eve editor, etc.) when using "xterm" under Irix 3.2 on the SGI?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01268; 6 Nov 89 22:50 EST Received: by VMB.BRL.MIL id ac01151; 6 Nov 89 22:44 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00946; 6 Nov 89 18:07 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa00499; 6 Nov 89 17:37 EST Received: from mirsa.inria.fr by ADM.BRL.MIL id aa00268; 6 Nov 89 11:15 EST Received: from kwai.inria.fr by mirsa.inria.fr with SMTP (5.59++/IDA-1.2.8) id AA27914; Mon, 6 Nov 89 16:46:17 +0100 Received: by inria.fr with X.400; 06 Nov 89 15:45:30+0100 Received: by ch; 06 Nov 89 16:45:47+0100 Date: 06 Nov 89 16:45:47+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: df and UX (was Re: df) Message-Id: <81*doelz@urz.unibas.ch> Sorry to confuse the situation but the df really seems to read crazy values on the iris. (Regarding the information from Brendan Eich, I began to under- stand why the convex reads false values as well, but this doesn't explain the negative values on the iris. on the iris it reads Filesystem Type blocks use avail %use Mounted on yogi:/week nfs 5868544 5241984 626560 89% /yogi_week yogi:/day nfs 7128576 5933056 1195520 83% /yogi_day on the convex it reads Filesystem kbytes used avail capacity Mounted on yogi:/day 3564288 2966528 597760 83% /yogi_day yogi:/week 7128576 2620864 4507712 37% /yogi_week on yogi it looks like yogi > sh dev d$day Total blocks 891072 Sectors per track 51 Total cylinders 1248 Tracks per cylinder 14 Host name "HSC000" Host type, avail HS50, yes Free blocks 149439 Maximum files allowed 152083 Extend quantity 5 Mount count 1 yogi > sh dev d$week Total blocks 891072 Sectors per track 51 Total cylinders 1248 Tracks per cylinder 14 Free blocks 563427 Maximum files allowed 111384 Total blocks 891072 Sectors per track 51 Free blocks 563505 Maximum files allowed 111384 Extend quantity 5 Mount count 1 (This is a two-volume disk). - Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01559; 6 Nov 89 23:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01485; 6 Nov 89 23:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01426; 6 Nov 89 23:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13575; 6 Nov 89 22:10 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA24931; Mon, 6 Nov 89 18:55:52 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Nov 89 23:42:28 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: man, apropos, help Message-Id: <44113@sgi.sgi.com> References: <78*doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <78*doelz@urz.unibas.ch>, doelz@urz.unibas.ch (Reinhard Doelz) writes > ...[help(1)]... > thats what we're looking for, right ? The only problem is a line > at the end stating the following : > > BUGS > The help(1) command does not work and is not shipped on IRIS-4D products. If you try the "help" command on a vanilla SVR3 machine (e.g. an 386 PC running SVR3.2), you will find the help(1) command is, IMHO, a waste of time. It says nearly nothing about a small number of uninteresting topics. During the initial SVR3 port to MIPS chips, someone here spent time working on help(1). Because its implementation left much to be desired, its database was not impressive, and in any case seemed less useful than apropos(1), the port was dropped. We've been talking about apropos(1) for ages. It will be wonderful when Ciemo's implementation is available. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00245; 7 Nov 89 4:36 EST Received: by VMB.BRL.MIL id ad02009; 7 Nov 89 0:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02052; 6 Nov 89 19:42 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab01791; 6 Nov 89 19:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08548; 6 Nov 89 16:40 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA03684; Mon, 6 Nov 89 13:26:28 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Nov 89 20:31:21 GMT From: David A Higgen Organization: Silicon Graphics, Inc., Mountain View, CA Subject: fsck Message-Id: <44094@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > (from) Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu > We are considering buying a 4D210 but we are concerned by reports from > other departments here and from SGI's sales people that SGI's fsck is ^^^^^^^^^^^^^^^^^^ > ``unreliable'' or that it can take multiple passes to clean a damaged > filesystem. Some people locally claim that the problem is inherited > from MIPS or System V, but until the SGI machines arrived, I had never > encountered or heard reports of such problems on machines with working > hardware (I've been working on Unix machines, including PDP-11s, VAXen, > Suns and IBM 370s, since fsck was invented). > > Can any of you offer evidence that SGI's or MIPS's (production) fsck > always corrects severely damaged filesystems in one attempt (or admits > defeat and gives up)? Do you have evidence that SGI's or MIPS's fsck > has ever claimed to have repaired a filesystem which then turned out to > be damaged? Proof would be nice, but strong evidence will suffice. Note first of all that the SGI and MIPS fscks will be quite different since MIPS don't use SGI's Extent Filesystem. As one of the kernel engineers here who works frequently on filesystem-related topics, I have no reason based on personal experience to believe that SGI's fsck is less reliable than other sysV fscks. I have never suffered any of the type of problems you postulate, (on an SGI machine, that is... I sure did once on a S*N !!). We do of course from time to time find & fix minor bugs in it: but this is usually due to some quite obscure & pathological case (eg something screwed up during a development phase). But the *released* fsck seems reliable in normal use. I suspect this may be one of those "folklore" tales that spring up, perhaps because someone got bitten by bad hardware or something like that. BTW, you say SGI *salespeople* are putting this out? I would very much appreciate the name of the person involved... either they have some wrong impressions, or if they DO have a demonstrated instance I want to see it so I can fix it!! Dave Higgen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02869; 7 Nov 89 9:04 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02687; 7 Nov 89 8:53 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02490; 7 Nov 89 8:38 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa19659; 7 Nov 89 7:39 EST Received: Tue, 7 Nov 89 07:39:09 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 7 Nov 89 07:39:09 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8911071539.AA22699@aero4.larc.nasa.gov> To: ccsupos%prism@gatech.edu, info-iris@BRL.MIL Subject: Re: tek 4014 emulator for 4D120GTX On the 3000's there is a command called wsiris. With the proper options you get a tekronix 4014 window. I have used this before and it does an ok job. I don't know if it is on the 4D's thou. This command is in the documentation for the 3000's. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08581; 7 Nov 89 13:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08447; 7 Nov 89 12:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08371; 7 Nov 89 12:39 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa27970; 7 Nov 89 11:55 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA10501; Tue, 7 Nov 89 08:52:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Nov 89 16:45:30 GMT From: john howell Organization: Deere & Co. Technical Center, Moline,IL Subject: Volume Rendering Software? Message-Id: <139@suntc.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I would like to do some Volume Rendering of finite element results in a solid finite element model. I have seen demonstrations of just such a feature display on an SGI GT. Does anyone know of software available that produces these types of renderings? Do I need the Alpha Blending planes in the GT to produce these images? Thanks. John ======================================================================== John Howell uucp: uunet!suntc!jrh Deere & Company MCImail: 360-4047 Technical Center CompuServe: [76666,2505] 3300 River Drive FAX: (309)765-3807 Moline, IL 61265 Voice: (309)765-3784 ========================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12366; 7 Nov 89 15:32 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab11795; 7 Nov 89 15:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa11344; 7 Nov 89 15:08 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa02643; 7 Nov 89 14:29 EST Received: Tue, 7 Nov 89 14:29:00 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 7 Nov 89 14:29:00 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8911072229.AA24111@aero4.larc.nasa.gov> To: info-iris@BRL.MIL, suntc!jh34607@uunet.uu.net Subject: Re: Volume Rendering Software? I was told that the Alpha Blending planes are simulated in software, if you don't have the hardware. Is this true? Please correct me if I am wrong. I was told this by an SGI person involved with software mainly and a little hardware. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14857; 7 Nov 89 18:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14830; 7 Nov 89 18:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab14672; 7 Nov 89 18:04 EST Received: from nrtc.northrop.com by SMOKE.BRL.MIL id aa09427; 7 Nov 89 17:41 EST Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa13321; 7 Nov 89 14:42 PST Date: Tue, 7 Nov 89 13:36:40 PST From: Fletcher Robinson To: info-iris@BRL.MIL Subject: terminal emulation ... Message-ID: <8911071741.aa09427@SMOKE.BRL.MIL> When using TELNET to communicate with a VAX, the VAX interegates to discover what terminal it is connecting to. Is there some way to allow the SGI to respond to the VAX and set up terminal emulation in the window shell to make the VAX think it is connecting to an ANSI standard terminal?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14975; 7 Nov 89 19:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14926; 7 Nov 89 18:49 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14907; 7 Nov 89 18:38 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa10090; 7 Nov 89 18:16 EST Received: from UKACRL.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 4296; Tue, 07 Nov 89 18:15:48 EST Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 2374; Tue, 07 Nov 89 16:36:09 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 6454; Tue, 07 Nov 89 16:36:08 GM Via: UK.AC.OX.VAX; 7 NOV 89 16:36:05 GMT Date: Tue, 7 NOV 89 16:35:46 GMT From: HCART%VAX.OXFORD.AC.UK@cunyvm.cuny.edu To: INFO-IRIS@BRL.MIL Subject: Yet more printer queue questions... Message-ID: <8911071816.aa10090@SMOKE.BRL.MIL> I have had difficulties in the past with the print queue on a 3130 unexpectedly halting. This is due to some kind of interference by the QUANTA package which runs on the m/c. I have two queries: 1. Has anyone else experience of similar problems running QUANTA? If so, are there any fixes that can be applied? 2. I can restart the print queue by typing nohup sleep 10000000 < /dev/ttyf3 & at the console. However, if I type the same thing at another terminal, it has no effect, even though I am logged on as root. Why does unix want me to issue the instruction only from the console? Hugh Cartwright.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25696; 8 Nov 89 13:07 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa25236; 8 Nov 89 12:56 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa24943; 8 Nov 89 12:40 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa13427; 8 Nov 89 12:11 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA27814; Wed, 8 Nov 89 06:03:18 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Nov 89 00:30:25 GMT From: "Gavin A. Bell" Subject: Re: Volume Rendering Software? Message-Id: <1296@odin.SGI.COM> References: <8911072229.AA24111@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL VoxelLab, a simplified versions of Vital Image's VoxelView volume rendering system, will be shipped at no extra charge with every machine as soon as it is ready; I believe it will also be shipped to 4D customers who are on software maintenance. Before you die-hard 3000 owners ask, no, it doesn't work on the 3000. VoxelLab is meant to whet your appetite for volume rendering; it has some limitations (256x256x256 maximum data set size, will only use one CPU on multi-CPU GTX's) but is great if your application is fairly simple. If you need a full volume rendering system, Vital Images will sell you one. Right now, they don't come cheap; there isn't enough volume. I have a feeling VoxelLab may change that. About alpha bitplanes: Many people seem confused about this issue. I'll probably confuse it even more, but here goes: There is no software emulation of alpha bitplanes. However, you don't (necessarily) need alpha bitplanes to get transparency. For example, the ipaint demo fades an image into the framebuffer by combining the incoming color with the color already in the framebuffer. The equation it uses is: newcolor = color * blendvalue + oldcolor * (1 - blendvalue) (in GLspeak, it sets blendfunction(BF_SA,BF_MSA)) None of the three values in this blending function come from the alpha bitplanes (color and blendvalue are given using the c4f or cpack functions, and oldcolor is stored in the framebuffer bitplanes). There are possible blending functions that do use the value stored in the alpha bitplanes (these are the DA arguments to blendfunction). VoxelView will use the alpha bitplanes to do fancy kinds of blending; VoxelLab will not. I hope this made sense. I should also add that I am not an Official Spokesperson for Silicon Graphics, and that this posting is neither an offer to sell nor a solicitation of an offer to buy or sell any securities. --gavin   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab25696; 8 Nov 89 13:07 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab25236; 8 Nov 89 12:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25121; 8 Nov 89 12:45 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00208; 8 Nov 89 12:14 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA24357; Wed, 8 Nov 89 05:06:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Nov 89 05:19:37 GMT From: Alex Woo Organization: NASA Ames Research Center, Mtn Vw CA 94035 Subject: NFS problem between IRIX and NeXT Message-Id: <3729@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are using a NeXT and an Ultrix VAXStation 3200 as file servers for an IRIS 4D/70 and an IRIS 4D/25. The NeXT and the Ultrix machine communicate perfectly and the IRIS's and the Ultrix machines are ok. But it appears that file name substitution is failing on the IRIX machines when using the NeXT disks. For instance, 'ls' works but 'ls *' fails to find a match. Also, IRIX 'make' usually fails with error number 1. It is as if noglob has been set. Does anyone have a definitive answer why this occurs? Any workarounds? Thanks. ====================================================================== Alex Woo, MS 227-2 | woo@pioneer.arc.nasa.gov NASA Ames Research Center | woo@ames-nas.arpa Moffett Field, CA 94035 | {seismo,topaz,lll-crg,ucbvax}! Phone: (415) 694-6010 | ames!pioneer!woo ====================================================================== {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!pioneer!woo ======================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27638; 8 Nov 89 13:55 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa27343; 8 Nov 89 13:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27173; 8 Nov 89 13:34 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01601; 8 Nov 89 13:11 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA11597; Tue, 7 Nov 89 16:53:43 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Nov 89 00:02:45 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: df and UX (was Re: df) Message-Id: <44197@sgi.sgi.com> References: <81*doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <81*doelz@urz.unibas.ch>, doelz@urz.unibas.ch(Reinhard Doelz) writes: > on the iris it reads > Filesystem Type blocks use avail %use Mounted on > yogi:/week nfs 5868544 5241984 626560 89% /yogi_week > yogi:/day nfs 7128576 5933056 1195520 83% /yogi_day > > on the convex it reads > Filesystem kbytes used avail capacity Mounted on > yogi:/day 3564288 2966528 597760 83% /yogi_day > yogi:/week 7128576 2620864 4507712 37% /yogi_week Note that SGI's df(1) follows SystemV's counter-intuitive unit conventions and uses 512-byte block units by default (use -k to get 1024-byte units and a "kbytes" heading). So the SGI and Convex numbers for yogi:/day agree: 3564288 (kbytes) = 7128576 (half-kbytes) / 2. But is /day really a 3.5GB partition on yogi? Stranger still is the fact that yogi:/day seems to the SGI client to have 7128576 blocks (half-kbyte units) of capacity; that's magically the same as yogi:/week's capacity in kbytes, according to the Convex. The Convex sees yogi:/week as having twice its server capacity: > on yogi [a Vax/VMS running HSC NFS] it looks like > yogi > sh dev d$day > Total blocks 891072 Sectors per track 51 > Total cylinders 1248 Tracks per cylinder 14 > Host name "HSC000" Host type, avail HS50, yes > Free blocks 149439 Maximum files allowed 152083 > Extend quantity 5 Mount count 1 > yogi > sh dev d$week > Total blocks 891072 Sectors per track 51 > Total cylinders 1248 Tracks per cylinder 14 > Free blocks 563427 Maximum files allowed 111384 > Total blocks 891072 Sectors per track 51 > Free blocks 563505 Maximum files allowed 111384 > Extend quantity 5 Mount count 1 > (This is a two-volume disk). Ah. Notice that 3564288 * 1024 / 891072 = 4096. That is, both Convex and SGI seem to take the VMS capacity's unit as 4K. (I'm inferring that "show dev" on VMS gives numbers in half-K sector units, so the 891072 is total sectors, and the d$day partition is 435MB in size.) That means that the HSC server code on your Vax is setting the NFS statfs numbers like so: nfs.bsize = 4096 (bytes) nfs.blocks = 891072 (sectors) Which, I believe, violates the NFS protocol: the NFS statfs block counts (nfs.blocks, nfs.bavail, nfs.bfree) should be in units of nfs.bsize bytes. Both SGI and Convex conform to the protocol, scaling the NFS numbers into their statfs(2) counterparts, which df prints: df.blocks = nfs.blocks * nfs.bsize / 512 (SGI) df.kbytes = nfs.blocks * nfs.bsize / 1024 (Convex) or = 891072 * 4096 So part of your problem is an HSC server bug. The negative numbers mentioned in an earlier posting could result from overflow in the (SGI) df.blocks computation, above. We're fixing our code to prefer truncation error to overflow; the next release after 3.2 should contain this fix. But notice that overflow is unlikely unless the server violates the protocol or exports a huge disk. Why the Convex thinks yogi:/week is 7.1GB, I cannot explain. Perhaps the curious repetition of Total blocks in the VMS "show dev" output for d$week provides a clue. Could the Convex be summing d$day's and d$week's totals to get yogi:/week's apparently-doubled capacity? Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17183; 8 Nov 89 4:29 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17002; 8 Nov 89 3:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa16982; 8 Nov 89 3:15 EST Received: from mirsa.inria.fr by SMOKE.BRL.MIL id aa14818; 8 Nov 89 2:53 EST Received: from kwai.inria.fr by mirsa.inria.fr with SMTP (5.59++/IDA-1.2.8) id AA09212; Wed, 8 Nov 89 08:54:53 +0100 Received: by ch with X.400; 08 Nov 89 08:03:22+0100 Date: 08 Nov 89 08:03:22+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: help on non-sgi machines Message-Id: <82*doelz@urz.unibas.ch> Thanks for all the replies concerning help(1) ... I wouldn't do jokes about that if I weren't convinced that vanilla users sometimes do type help in order to get basic information. On our convex, it looks like % help CONVEX INFO SYSTEM MAIN MENU ============================ 1. Contact other users or machines 2. Use UNIX online help 3. Execute Commands 4. Edit, find, print, modify, analyze, and archive files 5. Develop programs 6. Check user, job, or system status 7. Modify system and file accessibility 8. Perform arithmetic calculations ... without wanting to advertise competitor's products, I suggest that SGI could replace the odd help with something which will automatically start up a toolbox on the graphics console which looks like the system management tool on 3.2 but has more general features. - Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab27638; 8 Nov 89 13:55 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab27343; 8 Nov 89 13:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27225; 8 Nov 89 13:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01736; 8 Nov 89 13:13 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA11864; Wed, 8 Nov 89 09:59:40 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Nov 89 17:16:39 GMT From: Andrew Simms Organization: Princeton University Subject: Looking for information on CELTIC TECHNOLOGIES Message-Id: <11395@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There was a company called Celtic Technologies that used to make a simple RS170 film recorder. We happen to have one of these (it is 2 or 3 years old), but we have no documentation and the company seems to have disappeared. If anyone can help us find the company or get a copy of the documentation, it would be greatly appreciated. If there is interest, I will post a summary of information. ---------------------------------------------------------------------- Andrew Simms ams@acm.princeton.edu System Administrator Program in Applied and Computational Math Princeton University Princeton, NJ 08544 609/258-5324 or 609/258-6227 609/258-1054 (fax)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28494; 8 Nov 89 14:23 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27898; 8 Nov 89 14:12 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27841; 8 Nov 89 14:02 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa02014; 8 Nov 89 13:21 EST Received: Wed, 8 Nov 89 13:22:07 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 8 Nov 89 13:22:07 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8911082122.AA27811@aero4.larc.nasa.gov> To: prevost@eos.arc.nasa.gov Subject: Re: Volume Rendering Software? Cc: info-iris@BRL.MIL I was told that the Alpha Blending simulation software wasn't available on the PI, only the higher end machines. It didn't make sense to me either, but the SGI person insisted that it was there on the machine I was concidering. (4D/210 or 220) I will probably raise the question to her again. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04586; 8 Nov 89 19:55 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa04455; 8 Nov 89 19:24 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04433; 8 Nov 89 19:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01428; 8 Nov 89 18:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA27049; Wed, 8 Nov 89 13:57:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Nov 89 16:33:18 GMT From: Donald Bouchard Organization: University of Pennsylvania, Philadelphia, PA Subject: TeX on Iris 4D Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have tried to install TeX on a SGI 4D. After deciding on a file structure and changing the necessary files I encountered an error in the Make. The error was in compilation of ../ctex/extra.c it complained about the following blurb of code: #ifdef SYSV /* Sys V compatibility */ #define index strchr #define rindex strrchr extern int *sprintf(); #else extern char *sprintf(); #endif The error was a redefinition of sprintf. I commented this line out re-Make'd and the initex file was created so I could make virtex. When running virtex, presumably the final version when loaded with the plain.fmt file the output was as follows: # ../../bin/tex /usr/users/db/tex/te_systems This is TeX, C Version 2.95 (no format preloaded) (/usr/users/db/tex/te_systems.tex (/usr/users/db/tex/upletterhead.tex) Underfull \hbox (badness 10000) in paragraph at lines 3--3 []\seasfont School Underfull \hbox (badness 10000) in paragraph at lines 3--3 \seasfont of Underfull \hbox (badness 10000) in paragraph at lines 3--3 \seasfont Arts The Underfull \hbox errors occurred for every word or group of words in the file. Has anyone seen this behavior? Has anyone fixed this behavior? Thanks in advance, Donald Bouchard Internet: bouchard@d.chem.upenn.edu Department of Chemistry AT&T: (215) 898 4886 University of Pennsylvania Philadelphia, PA 19104-6323   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05489; 8 Nov 89 22:38 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05419; 8 Nov 89 22:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05365; 8 Nov 89 22:02 EST Received: from ew09.nas.nasa.gov by SMOKE.BRL.MIL id aa02822; 8 Nov 89 21:26 EST Received: by ew09.nas.nasa.gov (5.61/1.34) id AA20898; Wed, 8 Nov 89 18:04:55 -0800 Date: Wed, 8 Nov 89 18:04:55 -0800 From: "Eric L. Raible" Message-Id: <8911090204.AA20898@ew09.nas.nasa.gov> To: info-iris@BRL.MIL Cc: creon@orville.nas.nasa.gov, yamo@orville.nas.nasa.gov, yamo@orville.nas.nasa.gov, yamo@orville.nas.nasa.gov, hultquis@orville.nas.nasa.gov, uselton@prandtl.nas.nasa.gov Subject: ools with multiple inheritance Reply-To: raible@orville.nas.nasa.gov We are contemplating using an object oriented language for our next project on Iris 4D's. To this end, does anyone have either: 1) a version of common lisp with a fast version of CLOS (PCL might be okay) that runs on the 4D's 2) a version of C++ that has multiple inheritance. That runs on the 4D's. A solid port of g++ (1.36) would be just fine. 3) any other suggestions for object oriented languages that *run* on the 4D, and an explanation of why it is better than 1 or 2.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05660; 8 Nov 89 23:09 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa05283; 8 Nov 89 22:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05210; 8 Nov 89 21:44 EST Received: from ew09.nas.nasa.gov by SMOKE.BRL.MIL id aa02852; 8 Nov 89 21:34 EST Received: by ew09.nas.nasa.gov (5.61/1.34) id AA20905; Wed, 8 Nov 89 18:05:13 -0800 Date: Wed, 8 Nov 89 18:05:13 -0800 From: "Eric L. Raible" Message-Id: <8911090205.AA20905@ew09.nas.nasa.gov> To: info-iris@BRL.MIL Cc: yamo@orville.nas.nasa.gov, yamo@orville.nas.nasa.gov, yamo@orville.nas.nasa.gov Subject: ools with multiple inheritance Reply-To: raible@orville.nas.nasa.gov We are contemplating using an object oriented language for our next project on Iris 4D's. To this end, does anyone have either: 1) a version of common lisp with a fast version of CLOS (PCL might be okay) that runs on the 4D's 2) a version of C++ that has multiple inheritance. That runs on the 4D's. A solid port of g++ (1.36) would be just fine. 3) any other suggestions for object oriented languages that *run* on the 4D, and an explanation of why it is better than 1 or 2.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05722; 8 Nov 89 23:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05660; 8 Nov 89 23:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05621; 8 Nov 89 23:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03551; 8 Nov 89 22:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15733; Wed, 8 Nov 89 19:05:10 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Nov 89 14:09:27 GMT From: "K. V. Rao" Subject: Clean Hardcopy of scrsave files Message-Id: <3752@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am having trouble getting clean hardcopy of scrsave files on our seiko 5312 printer and an Apple Laserwriter NTXII. A background pattern of black dots shows up for both outputs. The Seiko plotter is connected to a parallel port on a PI, the PostScript printer is connected to a serial port on a 240GTX. Have been using lp to print the files saved by srsave I reported this to the SGI hotline - but have not received any answers yet. This has been true for all versions of the operating system including 3.2. Does anybody else have the same problem? Please send e-mail to rao@amelia.nas.nasa.gov. Will summarize response if any to the net.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05722; 8 Nov 89 23:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac05660; 8 Nov 89 23:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab05621; 8 Nov 89 23:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03553; 8 Nov 89 22:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15773; Wed, 8 Nov 89 19:05:58 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Nov 89 14:12:27 GMT From: "K. V. Rao" Subject: Clean hardcopy from scrsave using lp Message-Id: <3753@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am having trouble getting clean hardcopy of scrsave files on our seiko 5312 printer and an Apple Laserwriter NTXII. A background pattern of black dots shows up for both outputs. The Seiko plotter is connected to a parallel port on a PI, the PostScript printer is connected to a serial port on a 240GTX. Have been using lp to print the files saved by srsave I reported this to the SGI hotline - but have not received any answers yet. This has been true for all versions of the operating system including 3.2. Does anybody else have the same problem? Please send e-mail to rao@amelia.nas.nasa.gov. Will summarize response if any to the net. -- K. V. Rao (317) 230-5908 Advanced Turbomachinery Department Allison Gas Turbine Division Indianapolis, IN 46206-0420   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13701; 9 Nov 89 12:57 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12738; 9 Nov 89 11:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa12633; 9 Nov 89 11:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05361; 9 Nov 89 10:58 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA27219; Thu, 9 Nov 89 07:52:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Nov 89 15:34:31 GMT From: Mark T Vandewettering Organization: Princeton Univ. Computing and Information Technology Subject: malloc problems revisited Message-Id: <11421@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I know this has been hashed out in the newsgroups before, but I still have to reach a viable resolution for a program that I am working on. This program allocates around 400K polygons, containing roughly 50 bytes each. Yet, when drawn, the paging activity on the system goes through the roof. Eventually, the program dies with by being unable to allocate any more pages. We have 16 megabytes of memory on an SGI 240GTX, OS 3.1g. I have tried using -lmalloc to get the Berkeley one as well. Does anyone have any good ideas as to how get around this problem? Is there a problem in the library routines as well that prevents drawing of more than a fixed number of polygons. As an aside, I am using the builtin lighting model. Hope someone can help. Mark (markv@cs.uoregon.edu)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19804; 9 Nov 89 19:42 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19468; 9 Nov 89 18:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19435; 9 Nov 89 18:17 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20564; 9 Nov 89 18:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA23820; Thu, 9 Nov 89 14:39:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Nov 89 20:34:21 GMT From: Bill Lasher Organization: Penn State University Subject: Re: fsck Message-Id: <89313.153421W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Some of you may have been following the fsck question I posted last week. Thanks to help from several of you, including some people at SGI, I finally decided the REAL problem was our system administration. One of the people at SGI thought the following might be of interest to others, and suggested I post it. The original note follows: ========================================================================= Date: 9 November 1989, 14:16:04 EST From: Bill Lasher (814) 898-6391 W0L at PSUVM Subject: Re: fsck, init state 3 To: dunlap at sgi.sgi.com In-Reply-To: dunlap%bigboote.csd AT sgi.com -- Thu, 9 Nov 89 11:06:55 PST Our most recent problem (the RPC timeout) I think was caused by the way we implemented the nightly reboot. We scheduled them 5 minutes apart, figuring that would be enough time. I found out today that one machine was still in the process of restarting when the YP server he was communicating with started to reboot. This caused the system to hang. Rebooting did in fact clear things up, but it took some time. Part of the problem is that the time on each machine is not exactly the same (a diference of a couple of minutes). We are going to set all machines to the same time, and change the reboot interval to 10 minutes. I think we got thrown off the track because running fsck nightly changed the total time it took for the systems to reboot, and things just happened to work out O.K. Also, we probably weren't patient enough earlier to let reboot do it's thing; when reboot didn't work, we tried fsck, which did work because it took longer to finish up, and by the time it was done the network wasn't as busy (or something like that.) I think we were also in a hurry to get things fixed, and as a result got sloppy (ie, running fsck without unmounting, etc.). Some of our problems may come back, but we will handle each of them separately as they occur, and try to be more careful. I suspect some of the earlier problems (the full disks, hung spool queues) showed up because we were letting the systems run for a week at a time without rebooting, and things just got a little messy. We had planned from the beginning to have them reboot every night, but we had too many other things going on to get it implemented. We'll just take it from here and see what happens. Best regards, Bill ======================================================================== END OF ORIGINAL NOTE You may not follow all the details, but you probably get the general idea. I think it's a good example of what can happen when an experienced computer user gets his first UNIX/networked system. Bill "If I knew what I was doing, I wouldn't have had to ask the question!"   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20244; 9 Nov 89 21:25 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20045; 9 Nov 89 21:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab20019; 9 Nov 89 20:49 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22385; 9 Nov 89 20:44 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA05447; Thu, 9 Nov 89 17:41:35 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Nov 89 01:40:37 GMT From: gem.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!sam@tut.cis.ohio-state.edu Subject: Re: vt100 emulator ? Message-Id: <223000006@uxe.cso.uiuc.edu> References: <223000003@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL actually, that is the VT100 "PF4" key I'm trying to locate in "xterm".   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20532; 9 Nov 89 22:28 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20045; 9 Nov 89 21:04 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20019; 9 Nov 89 20:49 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22379; 9 Nov 89 20:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA05468; Thu, 9 Nov 89 17:41:48 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Nov 89 01:40:40 GMT From: gem.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!krogh@tut.cis.ohio-state.edu Subject: Re: tek 4014 emulator for 4D120GTX Message-Id: <223000005@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL With the release of Irix 3.2 you can use xterm which supports Tek 4014 emulation.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20790; 9 Nov 89 23:51 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20681; 9 Nov 89 23:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20647; 9 Nov 89 23:02 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23391; 9 Nov 89 22:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA12954; Thu, 9 Nov 89 19:40:38 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Nov 89 02:15:45 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: fsck Message-Id: <44418@sgi.sgi.com> References: <89313.153421W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89313.153421W0L@PSUVM.BITNET>, W0L@PSUVM.BITNET (Bill Lasher) writes: > ... Part of > the problem is that the time on each machine is not exactly the same (a > diference of a couple of minutes). We are going to set all machines to > the same time... Timed(1m) or timeslave(1m) can be used to synchronize time on the machines. In a simple network (i.e. without gateways separating machines), just turning it on should be enough to keep time synchronized to within 75msec. The next release after 3.2 will have improvements to the deamons and the kernel which should allow timed or timeslave to keep time 10 or more times tighter. Time-skew of seconds, not to mention minutes, is a royal pain for make(1) combined with NFS. It should be noted that the 4.3 BSD release of timed left something to be desired in both implementation and protocol. The implementation in the newer "network" release may be better, although the protocol, having been released, is unfixable. The IRIX version is heavily hacked from the 4.3 release, and seems to servicable. It's been about a year since time went crazy among the thousands of IRIS's in the SGI network for reasons other than operator error. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20987; 10 Nov 89 0:11 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab20790; 10 Nov 89 0:01 EST Received: from [192.5.23.3] by VMB.BRL.MIL id aa20753; 9 Nov 89 23:41 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23656; 9 Nov 89 23:28 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15245; Thu, 9 Nov 89 20:16:35 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Nov 89 20:33:09 GMT From: Jody Winston Organization: Shell Development Company, Bellaire Research Center, Houston, TX Subject: mapping a pattern onto a NURB surface Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Where can I find some information on mapping a pattern onto a NURBS surface? -- Jody Winston jody@shell.uucp ...!{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!jody Shell Development Company, Bellaire Research Center P.O. Box 481, Room 2202, Houston, TX 77001 (Voice: 713 663-2993)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21735; 10 Nov 89 3:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21688; 10 Nov 89 3:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21656; 10 Nov 89 3:01 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25276; 10 Nov 89 2:58 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA26641; Thu, 9 Nov 89 23:49:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Nov 89 16:33:18 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: ools with multiple inheritance Message-Id: <1342@odin.SGI.COM> References: <8911090204.AA20898@ew09.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL SGI currently sells our port of the AT&T C++ 1.2.1 compiler. We have the AT&T C++ 2.0 compiler running in house, and will be releasing it sometime next year (1990). You could buy the current product, then get it updated when we release 2.0... There does exist a "working" version of g++ for the mips chip (thus it will work on the 4D). It doesn't play with dbx though, so you have to resort to more primitive debugging techniques. kipp hickman silicon graphics inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21956; 10 Nov 89 4:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21789; 10 Nov 89 3:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21769; 10 Nov 89 3:31 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25349; 10 Nov 89 3:13 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA27519; Fri, 10 Nov 89 00:01:26 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Nov 89 16:19:43 GMT From: Jean-Francois Lamy Subject: Re: TeX on Iris 4D Message-Id: <89Nov9.111920est.2747@neat.cs.toronto.edu> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There are several such sprintf and similar redefinitions in the file (nuke the attempts, anything that relies on the return status is suffering from brain-rot and ought to be exposed). Other things need to be changed (the definition of schar, as I recall). If you want to compile from the source, a version of TeX 2.991 (the latest stable one, 2.992 is considered to be beta) that works on SGIs can be found on neat.cs.toronto.edu pub/tex.tar.* (it also works on Suns, DS3100s, uVaxen, and so on). Does your underfull hbox problem occur on every file you try? I would start by checking that the creation of the .fmt file proceeded with absolutely no error (in particular when loading the hyphenation stuff). Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23022; 10 Nov 89 9:51 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22866; 10 Nov 89 9:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22851; 10 Nov 89 8:55 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28211; 10 Nov 89 8:43 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15121; Fri, 10 Nov 89 05:31:12 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Nov 89 02:24:20 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: fsck Message-Id: <1365@odin.SGI.COM> References: <89313.153421W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89313.153421W0L@PSUVM.BITNET>, W0L@PSUVM.BITNET (Bill Lasher) writes: > Our most recent problem (the RPC timeout) I think was caused by the way > we implemented the nightly reboot. We scheduled them 5 minutes apart, > figuring that would be enough time. I found out today that one machine > was still in the process of restarting when the YP server he was > communicating with started to reboot. This caused the system to hang. > Rebooting did in fact clear things up, but it took some time. Part of > the problem is that the time on each machine is not exactly the same (a > diference of a couple of minutes). We are going to set all machines to > the same time, and change the reboot interval to 10 minutes. > You might consider running timed on all of your machines which have it. Timed will average the network time of all other machines on your local area network which are running timed. Timed will then make incremental time adjustments to your machine's time to bring it into line with the network average. You can configure your 4D to run timed after rebooting by doing: su /etc/chkconfig timed on exit You can manually run timed by doing su timed -M exit This should help prevent the drift problem you are currently seeing. Unfortunately, if you only have one machine running timed, it won't do you much good to timed. See the timed manual page for more information. --- Ciemo   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23463; 10 Nov 89 12:02 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23314; 10 Nov 89 11:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23300; 10 Nov 89 11:12 EST Received: from relay.cs.net by SMOKE.BRL.MIL id aa29342; 10 Nov 89 10:57 EST Received: from relay2.cs.net by RELAY.CS.NET id ac15788; 10 Nov 89 9:01 EST Received: from gmr.com by RELAY.CS.NET id ab22017; 10 Nov 89 9:56 EST Date: Fri, 10 Nov 89 09:44 EST From: JORDAN%gmr.com@relay.cs.net Subject: Please steer in right direction To: info-iris@BRL.MIL X-VMS-To: NET%"info-iris@brl.MIL" Message-ID: <8911101057.aa29342@SMOKE.BRL.MIL> I am in search of 2 types of "info" bulletin boards. In this vacuous area in which I work & play, little helpful computer info gets around. I would appreciate any responses. 1. I know of a person very skilled at using SG architecture machines, and is very familiar with the Graphics Library. Are there any effective job hunting bulletin boards out there? 2. I am very interested in stuff going on with the Amiga PC's. Are there any cool Amiga info type comm's out there? Thanx so much... ted   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23602; 10 Nov 89 12:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23571; 10 Nov 89 12:29 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23567; 10 Nov 89 12:21 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00118; 10 Nov 89 12:13 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA28288; Fri, 10 Nov 89 09:08:35 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Nov 89 16:31:24 GMT From: "SCHREIBER, O. A." Organization: Georgia Institute of Technology Subject: Re: tek 4014 emulator for 4D120GTX Message-Id: <3302@hydra.gatech.EDU> References: <223000005@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL How do you open a tek window with xterm under version 3.2? Thanks -- Olivier Schreiber (404)894 6147, Office of Computing Services Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccsupos ARPA: ccsupos@prism.gatech.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24734; 10 Nov 89 18:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24480; 10 Nov 89 18:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa24466; 10 Nov 89 17:49 EST Received: from hydra.gatech.edu by SMOKE.BRL.MIL id aa02897; 10 Nov 89 17:35 EST Received: by hydra.gatech.edu (5.61/3.0) id AA08824; Fri, 10 Nov 89 17:33:34 -0500 Date: Fri, 10 Nov 89 17:33:34 -0500 From: "SCHREIBER, O. A." Message-Id: <8911102233.AA08824@prism.gatech.edu> To: gem.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!krogh@tut.cis.ohio-state.edu, info-iris@BRL.MIL Subject: Re: tek 4014 emulator for 4D120GTX How does one go about using it? I can open the xterm window but it does not seem to be a tek4014. Thanks for your help Olivier Schreiber (404)894 6147, Office of Computing Services Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccsupos ARPA: ccsupos@prism.gatech.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25248; 10 Nov 89 22:05 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25200; 10 Nov 89 21:54 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25159; 10 Nov 89 21:39 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04358; 10 Nov 89 21:29 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA03859; Fri, 10 Nov 89 18:24:30 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Nov 89 16:44:23 GMT From: Phil Johnson Organization: Intergraph Corp. Huntsville, Al Subject: Real World Personal IRIS Message-Id: <7392@ingr.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I would like to get some idea of what the real world needs to run a Personal IRIS workstation. Basically, I am interested in how much memory and disk space is needed, what size display, do you use color or monochromatic, etc. I am interested in either standalone or networked disk-based workstations. Please email your responses and I will post the results in a week or two. Thanks for your help. -- Philip E. Johnson UUCP: usenet!ingr!b3!sys_7a!phil MY words, VOICE: (205) 772-2497 MY opinion!   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25754; 11 Nov 89 0:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25414; 10 Nov 89 23:11 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25383; 10 Nov 89 22:58 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04710; 10 Nov 89 22:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA07994; Fri, 10 Nov 89 19:39:36 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Nov 89 18:33:49 GMT From: Paul Mielke Organization: Silicon Graphics, Inc. Subject: Re: malloc problems revisited Message-Id: <1374@odin.SGI.COM> References: <11421@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <11421@phoenix.Princeton.EDU>, markv@phoenix.Princeton.EDU (Mark T Vandewettering) writes: > > I know this has been hashed out in the newsgroups before, but I still > have to reach a viable resolution for a program that I am working on. > > This program allocates around 400K polygons, containing roughly 50 bytes > each. Yet, when drawn, the paging activity on the system goes through > the roof. Eventually, the program dies with by being unable to allocate > any more pages. We have 16 megabytes of memory on an SGI 240GTX, OS 3.1g. > 400k polys * 50 bytes/poly = 20 * 10**6 bytes = 20 megabytes If your program actually needs to reference all 400k polys very frequently, you're going to have a paging problem no matter what flavor of malloc you use. Your only hopes are 1) locality of reference or 2) buy more memory. The problem you mention of the program eventually dying with an allocation failure sounds like your program's virtual space is growing without bound. Does your program continue to malloc memory throughout its life or does it allocate the 400k polys once and for all? If the virtual space of a program grows without bound, malloc will eventually fail for lack of swap space in which to store the expanded virtual space. There are several ways to find out what's going on: ps -l and look at the SZ:RSS column. This gives the number of pages (4kb) of total virtual space and current resident space for each process. 'swap -l' will tell you how much of your swap space is currently allocated. Watch the numbers as your program runs. 'df /debug' gives you more or less the same information as 'swap -l'. The 'avail' and 'use' on 'df /debug' tell you the allocation of the sum total of physical memory and swap space. > I have tried using -lmalloc to get the Berkeley one as well. Does > anyone have any good ideas as to how get around this problem? Is there > a problem in the library routines as well that prevents drawing of more > than a fixed number of polygons. > > As an aside, I am using the builtin lighting model. > > Hope someone can help. > > Mark (markv@cs.uoregon.edu) Paul Mielke paulm@sgi.com Advanced Systems Division (415) 962-3447 Silicon Graphics, Inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26823; 11 Nov 89 5:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26724; 11 Nov 89 5:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa26703; 11 Nov 89 5:01 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06964; 11 Nov 89 4:58 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA27997; Sat, 11 Nov 89 01:54:56 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Nov 89 22:04:45 GMT From: Rex Espiritu Organization: NBC Computer Imaging, New York, NY Subject: dks0d1s0 Unrecoverable device error: Write fault. retrying xfer Message-Id: <2447@nbc1.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Our SGI IRIS 4D/120S keeps getting these intermittent messages on its console: dks0d1s0 Unrecoverable device error: Write fault. dks0d1s0 retrying xfer If anyone knows what might be causing this, please contact me. -- M. Rex Espiritu, Jr. National Broadcasting Company, Inc. rex@nbc1.ge.com 30 Rockefeller Plaza, Room 1615W {uunet!crdgw1,ge-dab,philabs}!nbc1!rex New York, NY 10112 (212) 664-5390 ``Where there is no vision, the people shall perish.'' --Is   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27814; 11 Nov 89 10:59 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27715; 11 Nov 89 10:17 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa27699; 11 Nov 89 10:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08762; 11 Nov 89 9:58 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA10742; Sat, 11 Nov 89 06:51:36 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Nov 89 12:09:31 GMT From: Gary Klaassen Organization: York U. Computing Services Subject: Transfer Personal IRIS images to VCR Message-Id: <5025@yunexus.UUCP> References: none Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We are considering getting a Personal Iris to do 3D colour graphics. We would like to transfer the images, frame by frame if necessary, to NTSC video (VHS and super VHS) for animation. We have been told that SGI sells a board that will do this, but it takes up the VME slot, which means if you want a tape drive, it has to be external. Does anyone know of any alternatives such as using RGB output? If that is possible, what extra hardware is required? Is a genlock feature required? Thanks in advance, G. Klaassen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00849; 11 Nov 89 23:00 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00810; 11 Nov 89 22:50 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00789; 11 Nov 89 22:32 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13469; 11 Nov 89 22:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18107; Sat, 11 Nov 89 19:29:02 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Nov 89 19:31:16 GMT From: Dave Olson Subject: Re: dks0d1s0 Unrecoverable device error: Write fault. retrying xfer Message-Id: <1396@odin.SGI.COM> References: <2447@nbc1.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL rex@nbc1.UUCP (Rex Espiritu) writes: >Our SGI IRIS 4D/120S keeps getting these intermittent messages on its console: > dks0d1s0 Unrecoverable device error: Write fault. > dks0d1s0 retrying xfer This error message indicates that the disk drive's embedded SCSI controller returned an error; the OS is merely reporting it. The error was unrecoverable (by the drive), so the OS is retrying. If you don't get another message, the OS retry was successful. This could indicate an intermittent drive error, or a soft media error, although that would usually be reported as a media error. If you'll send me mail telling me which type of disk drive you have, I might be able to give you more specific info for your particular drive. For those who really want to know, a scsi cmd returned a check condition error, a request sense command then returned the info that the primary error was 4, with an additional sense code of 3. Dave Olson It's important to keep an open mind, but not so open that your brains fall out. -- Stephen A. Kallis, Jr.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03580; 12 Nov 89 15:52 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03530; 12 Nov 89 15:31 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03515; 12 Nov 89 15:22 EST Received: from tank.uchicago.edu by SMOKE.BRL.MIL id aa19878; 12 Nov 89 15:06 EST Received: by tank.uchicago.edu Sun, 12 Nov 89 14:07:38 CST Date: Sun, 12 Nov 89 14:07:38 CST From: Ameet Raval Message-Id: <8911122007.AA04705@tank.uchicago.edu> To: info-iris@BRL.MIL Subject: 3rd party NFS software I would appreciate a list of vendors of NFS software for pre-4D IRIS systems, specifically for IRIS 2500T's, which supply NFS for less than $1500.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07994; 13 Nov 89 9:10 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07768; 13 Nov 89 9:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07624; 13 Nov 89 8:43 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa29687; 13 Nov 89 8:33 EST Received: Mon, 13 Nov 89 08:33:59 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 13 Nov 89 08:33:59 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8911131633.AA13927@aero4.larc.nasa.gov> To: gem.mps.ohio-state.edu!wuarchive!mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!gklaass@tut.cis.ohio-state.edu, info-iris@BRL.MIL Subject: Re: Transfer Personal IRIS images to VCR There are several companies out there that sell devices that connect to the RGB output of your computer and then connect to your video tape recorder. However, all the ones I have seen record "live" that is what every is drawn on the screen however fast or slow that is that is the way it gets recorded. That is what I have heard about, if there is anything else out there I would like to know about it. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09012; 13 Nov 89 9:52 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa07063; 13 Nov 89 8:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa06809; 13 Nov 89 8:02 EST Received: from [128.155.20.81] by SMOKE.BRL.MIL id aa27838; 13 Nov 89 7:48 EST Received: Mon, 13 Nov 89 07:50:20 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 13 Nov 89 07:50:20 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8911131550.AA13767@aero4.larc.nasa.gov> To: info-iris@BRL.MIL, psuvm!w0l@psuvax1.cs.psu.edu Subject: was Re: fsck now reboot Why do you reboot your systems every night? Around here I don't know of anyone who does that once a week let along every night. During summer months I shut down our IRIS for the weeked because they shut the air conditioning off on weekends. However, during the winter I leave it up all the time and only reboot if there is a problem. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09308; 13 Nov 89 10:14 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab09012; 13 Nov 89 10:03 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08885; 13 Nov 89 9:47 EST Received: from CORNELLC.CIT.CORNELL.EDU by SMOKE.BRL.MIL id aa01420; 13 Nov 89 9:21 EST Received: from PSUVM.BITNET by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 5306; Mon, 13 Nov 89 09:22:05 EST Date: Mon, 13 Nov 89 09:22 EST From: "Bill Lasher (814) 898-6391" Subject: Re: was Re: fsck now reboot To: blbates@aero4.larc.nasa.gov Cc: info-iris@BRL.MIL In-Reply-To: blbates AT aero4.larc.nasa.gov -- Mon, 13 Nov 89 07:50:20 EST Message-ID: <8911130921.aa01420@SMOKE.BRL.MIL> I guess I originally got the idea at my last place of employment; they had an IBM mainframe which they IPL'd every night, just to keep things clean. As far as why I think we need to do it, there are a couple of reasons: 1. We do have occasional problems that rebooting seems to fix. Things would start to go wrong after 4 or 5 days if we didn't reboot; doing it nightly seems to have fixed those problems. 2. I think we have problems in the first place because of the environment. We are running a student lab, which runs 7 days/week. Student files are spread out all over the net, so our S.E. from SGI wrote a routine which will mount the user's files when they log on. Unfortunately, we can't unmount them automatically when they log off, so the user has to issue a command which does the unmount for them; then they can log off. Obviously, people forget, so we end up with several files mounted on each machine at the end of the day. Rebooting is the easiest way to clean up. Also, students have a tendency to do things that make programs crash more frequently than you might expect. Temporary files and other wierd things get left floating around, and rebooting cleans that up. Since students don't have root priveliges, automatic rebooting seems the prudent thing to do. I'm not sure nightly reboots are really necessary, but I can't see the harm in doing it. I would be interested in your comments. Sincerely, Bill   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16441; 13 Nov 89 15:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15348; 13 Nov 89 14:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15207; 13 Nov 89 14:37 EST Received: from jvnca.csc.org by SMOKE.BRL.MIL id aa09559; 13 Nov 89 14:21 EST Received: from jvncf.csc.org by jvnca.csc.org id AA04672; Mon, 13 Nov 89 14:23:28 EST Return-Path: Received: by jvncf.csc.org id AA17127; Mon, 13 Nov 89 14:22:50 EST Date: Mon, 13 Nov 89 14:22:50 EST From: Richard Shaginaw lac11205 Message-Id: <8911131922.AA17127@jvncf.csc.org> To: info-iris@BRL.MIL For Messrs Klaasen and Bates, and all others wishing videotape output: Your RGB signal (taken directly from the back of your monitor) must undergo scan-rate conversion and resolution reduction before conversion to a composite signal for recording. Several manufacturers have scan converters that meet these needs with varying degrees of sophistication. A real-time scan converter does the scan conversion and averaging fast enough to permit real-time recording; this, however, has several drawbacks. Chiefly, your VCR will record at whatever speed the IRIS is advancing the animation; on a busy or underpowered machine this looks terrible. A high-resolution scan converter from LyonLamb, Photron, YEM, or others also permits single-frame animation, provided you also have a VCR controller such as the LyonLamb MiniVas. The scan converter contains a frame buffer that stores each image as it's converted; it will transmit this image in NTSC format to your VCR, which the MiniVas can direct to capture a single frame. The whole process can be controlled by the IRIS; the scan converters and the MiniVas have serial ports that accept simple commands, which can be sent from the program that advances your frames one at a time. The MiniVas also sends codes that can instruct your program when a frame-record is complete, so that the program can proceed to load the next image, signal the scan converter, signal the MiniVas, block for its return code,.... A decent system should cost $20K-30K. Most areas have video integrators that serve area TV stations and production houses; most of these have experience with workstation-based systems. ----------------------- LyonLamb Video Animation Systems, Inc. 4531 Empire Avenue Burbank, CA 91595 818-843-4831 Photron Limited Dogenzaka 2-9-7 Shibuya-Ku Tokyo 150, Japan 03-486-3471 Yamashita Engineering Manufacture, Inc. James Grunder and Associates, Inc., distributor 5925 Beverly Mission, KS 66202 913-831-0188 ------------------------------------------------------------------------------- The John von Neumann National Supercomputer Center -- User Services Group Richard J. Shaginaw JVNC Applications Software Analyst P.O. Box 3717 Consortium for Scientific Computing Princeton, NJ 08543 ------------------------------------------------------------------------------- Internet Address: shaginaw@jvnca.csc.org 609-520-2000 Bitnet Address: shaginaw@jvncc FAX: 609-520-1089 ===============================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17779; 13 Nov 89 15:50 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15348; 13 Nov 89 14:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab15233; 13 Nov 89 14:39 EST Received: from TACOM-EMH2.ARMY.MIL by SMOKE.BRL.MIL id aa09791; 13 Nov 89 14:23 EST Received: (from user GJACKSON) by tacom-emh2.army.mil; 13 Nov 89 14:25:18 EST Subject: Re: Transfer Personal IRIS images to VCR To: info-iris@BRL.MIL From: GJACKSON@tacom-emh2.army.mil Date: 13 Nov 89 14:25:18 EST Message-ID: <8911131423.aa09791@SMOKE.BRL.MIL> The recording of graphics from the Iris to a VCR involves several pieces of equipment. If you are interested in creating animations by recording the graphics frame by frame and then playing back in real time, here is what you will need: a) A color encoder or an RGB scan converter. The color encoder combines a ntsc compatible RGB signals (640 X 483 pixels, 30Hz interlaced) into a single ntsc output signal. This hardware will work fine if you are able to change the high resolution (1280 X 1024 pixels, 60Hz non-interlaced) RGB monitor outputs to the ntsc compatible RGB via software control. A reasonably good color encoder costs about $2000. If you cannot change the RGB outputs or absolutely require the higher resolution, you are forced to get a real-time digital scan converter. This device runs about $18000. Either device gives you a recordable ntsc output signal. b) The second device you will need is a frame by frame animation controller. These typically costs about $6000. This piece requires the use of an RS232 port from the computer. On cue from the computer, the controller controls the editing functions of the VCR to insert a single frame onto the video tape. c) The next thing you need is a VCR that is compatible to the controller in item b). These are not your typical "home" models. They have to be editing decks. The low end of the capable 3/4 inch systems costs about $6000. d) You asked about the need for a Genlock. It depends on the quality of video you expect. You could get away without one for awhile and still get reasonable animations (not broadcast quality). The best general solution for this is to get a black burst generator. I give these as just one solution for a possible animation station configuration. The right solution for you really depends on your exact needs in this technology. There is a corporation now forming that is going into the business of scientific and engineering visualization. Part of their business plan includes providing others the service of setting up animation stations like the one I just described (there seems to be only a handful of experienced people able to provide this). The corporation is to be called Visual Computing Group. Today its services can be obtained via James Banister of Animated Technologies Incorporated, phone (213)675-0770. Tell him Gerry told you to call. Hope this was helpful ... Gerry Gerald Jackson * If you know exactly what it is US Army TACOM * you are doing, how much it costs Attn: AMSTA-RYA * and when it will be done, then Warren, MI 48397-5000 * you really can't call it ph. (313)574-5032 * research, can you ?!?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19770; 13 Nov 89 17:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19516; 13 Nov 89 17:14 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19400; 13 Nov 89 16:55 EST Received: from wugate.wustl.edu by SMOKE.BRL.MIL id aa14498; 13 Nov 89 16:09 EST Received: from castor.wustl.edu by wugate.wustl.edu with SMTP (5.61++/IDA-1.2.8) id AA20423; Mon, 13 Nov 89 12:38:28 -0600 Received: by castor.wustl.edu (5.52/SGI) id AA00479; Mon, 13 Nov 89 12:18:37 CST Date: Mon, 13 Nov 89 12:18:37 CST From: "Martin S. Weinhous" Message-Id: <8911131818.AA00479@castor.wustl.edu> To: info-iris@BRL.MIL Subject: 3rd party RAM, disk, and software query Cc: weinhous@castor We need to augment our two 4D120GTXs with ... SOFTWARE: C++, Pascal, LISP, and PHIGS+ RAM: power series SIMMS DISK: ESDI and/or SCSI MISC: video frame grabber Given that SGI's present prices are ..., well "high," we would appreciate comments on 3rd party sources for the above. Specifically: Has anyone implemented any c++ on a power series Iris? Which one? How well does it work? Is SGI's c++ their own? How well does it work? Does the gnu c++ work on the power series? Any general comments on Pascal, LISP Phigs+? Who is getting Power Series RAM from what company(s)? At what prices? How does performance compare for ESDI and SCSI disks on a 120GTX? Is it different for a 240? Who is getting disks from what company(s)? At what prices? Has anyone had experience with the SGI video boards? How well do they function as frame grabbers? What are the "good" alternatives? (We need a good S/N ratio for accurate digitization of x-ray images.) As these questions are of general interest, I promise to sumarize the responses and post them to info-iris. Thanks in advance. -- Marty Weinhous <...!uunet!wucs1!dinorah!weinhous>   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20396; 13 Nov 89 18:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20197; 13 Nov 89 18:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20131; 13 Nov 89 17:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15877; 13 Nov 89 16:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA26437; Mon, 13 Nov 89 13:41:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Nov 89 21:01:08 GMT From: Bill Lasher Organization: Penn State University Subject: Re: was Re: fsck now reboot Message-Id: <89317.160108W0L@PSUVM.BITNET> References: <8911131550.AA13767@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Brent Bates writes: > Why do you reboot your systems every night? Around here I don't know >of anyone who does that once a week let along every night. During summer >months I shut down our IRIS for the weeked because they shut the air >conditioning off on weekends. However, during the winter I leave it up >all the time and only reboot if there is a problem. >-- I guess I originally got the idea at my last place of employment; they had an IBM mainframe which they IPL'd every night, just to keep things clean. As far as why I think we need to do it, there are a couple of reasons: 1. We do have occasional problems that rebooting seems to fix. Things would start to go wrong after 4 or 5 days if we didn't reboot; doing it nightly seems to have fixed those problems. We schedule it with a cron. 2. I think we have problems in the first place because of the environment. We are running a student lab, which runs 7 days/week. Student files are spread out all over the net, so our S.E. from SGI wrote a routine which will mount the user's files when they log on. Unfortunately, we can't unmount them automatically when they log off, so the user has to issue a command which does the unmount for them; then they can log off. Obviously, people forget, so we end up with several files mounted on each machine at the end of the day. Rebooting is the easiest way to clean up. Also, students have a tendency to do things that make programs crash more frequently than one might expect. Temporary files and other wierd things get left floating around, and rebooting cleans that up. Since students don't have root priveliges, automatic rebooting seems the prudent thing to do. I'm not sure nightly reboots are really necessary, but I can't see the harm in doing it. I would be interested in any comments.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab20396; 13 Nov 89 18:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac20197; 13 Nov 89 18:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20143; 13 Nov 89 17:49 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16633; 13 Nov 89 17:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA27795; Mon, 13 Nov 89 14:02:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Nov 89 21:12:20 GMT From: Andrew Simms Organization: Princeton University Applied Math Subject: Re: 4D/20, 4D/25 --> 4Mbit chips Message-Id: <11504@phoenix.Princeton.EDU> References: <3729@amelia.nas.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone been able to install 4 megabit simms in a personal iris? Can the 4D/25 handle such a part? What do you need to do in order to use 4 megabit chips? Can you mix 4 Megabit and 1 Megabit in the same machine? Thanks in advance. --Andrew Simms ************************************************************************* System Administrator, PACM 208/258-5324 208/258-1054 (fax) ams@acm.princeton.EDU   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21437; 13 Nov 89 22:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21411; 13 Nov 89 22:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21383; 13 Nov 89 22:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa21919; 13 Nov 89 21:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA16495; Mon, 13 Nov 89 18:43:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 02:38:43 GMT From: tom rohling Organization: Univ. of Cincinnati, College of Engg. Subject: logging on Message-Id: <2830@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone (SGI - are you listening??) have any idea why it takes so long (4 - 5 seconds!) for our 4D to realize that you have incorrectly entered your login name or password? At first I figured it was just the way things are, and what can you about it. Then when we were upped to OS version 3.1415..... I thought it may be fixed, nope. Well maybe after it became a 120GTX running 3.1D, nope. It's not like we have an excessive passwd file, there are only eight (that's 8) accounts on the machine and when you add in the system accounts it comes to a grand total of about 15 lines in /etc/passwd. All the other UNIX based machines recognize almost instantly that you've goofed so what gives? What could it possibly be doing for this amount of time??????? On days when the ole' brain is not at 100% and it takes a few iterations to login, it becomes a tad annoying when those few iterations take about 20 to 30 seconds (which seem alot longer) just to login. We have not (*yet*) recieved 3.2 but I know the checks in the mail, so I still have hope. A good explanation of this would be appreciated. Much obliged, Tom Rohling University of Cincinnati ========================================================================= If you've built something from the inside out, then you should have no trouble penetrating from the outside in. - Love & Rockets tune =========================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22171; 14 Nov 89 0:51 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa22028; 14 Nov 89 0:30 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa22014; 14 Nov 89 0:17 EST Received: from umrvma.umr.edu by SMOKE.BRL.MIL id aa23726; 14 Nov 89 0:01 EST Received: from UMRVMA.BITNET by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 4690; Mon, 13 Nov 89 23:03:15 CST Received: by UMRVMA (Mailer R2.04) id 4689; Mon, 13 Nov 89 23:03:09 CST Date: Mon, 13 Nov 89 22:57:08 CST From: "Bob B. Funchess" Subject: Long login delay To: info-iris@BRL.MIL Message-ID: <8911140002.aa23726@SMOKE.BRL.MIL> "Why does it take the system so long to realize that the login is incorrect?" I haven't OFFICIALLY been told this, but I've been assuming that's not a bug, it's a feature: hacker programs designed to try to guess passwords can only retry once every 5 seconds or so, since the delay is about that long. We actually hope this ISN'T fixed. It seems a more reasonable method than the "3-try limit" that some mainframes use, since waiting 20 or 30 seconds to get your password right after 5 tries is better than waiting 5 minutes for the system to let you try again after messing up 3 times. It doesn't seem that the "problem" is related to the size of the passwd file, since it recognizes a correct login instantaneously on a human timescale. < Bob S090726@UMRVMA.UMR.EDU Funchess >   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24666; 14 Nov 89 8:20 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa23443; 14 Nov 89 6:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa23414; 14 Nov 89 6:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26769; 14 Nov 89 6:29 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA16577; Tue, 14 Nov 89 03:29:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 02:17:21 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: 3rd party RAM, disk, and software query Message-Id: <1419@odin.SGI.COM> References: <8911131818.AA00479@castor.wustl.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911131818.AA00479@castor.wustl.edu>, weinhous@CASTOR.BERKELEY.EDU ("Martin S. Weinhous") writes: > We need to augment our two 4D120GTXs with ... > SOFTWARE: C++, Pascal, LISP, and PHIGS+ > RAM: power series SIMMS > DISK: ESDI and/or SCSI > MISC: video frame grabber > Given that SGI's present prices are ..., well "high," we would > appreciate comments on 3rd party sources for the above. > > Specifically: Has anyone implemented any c++ on a power series > Iris? Which one? How well does it work? Is SGI's c++ their own? The current C++ offering is a port of the AT&T C++ translator version 1.2.1 with some bug fixes by SGI. We have also modified our dbx to support unmangled C++ variables and members of structures and classes which helps immensely in the debugging of C++ code. The translator works on all members of IRIS-4D series, including the 4D/120GTX. The price is $1995. I think AT&T charges $2500 for a source license. You won't get the dbx mods with an AT&T source license. Also, the C++ translator works with all of the compiler tools including the profiling tools: pixie and prof. Pixie and prof allow you to do a line-by-line execution analysis of your C++ application. > How well does it work? We have been using the C++ translator internally at SGI for over a year. The IRIS WorkSpace (TM SGI), the visual systems administration tools, and wsh were all written in C++. The developers who wrote these applications did it on just about every model of IRIS-4D. Personally, I'm hooked. Most of my own personal development projects have been done in C++. > Does the gnu c++ work on the power series? The IRIS-4D compilers run on all SGI IRIS-4Ds. If you find a port of g++ for an IRIS-4D, it should run on any of the IRIS-4Ds including your power series systems. > Any general comments on Pascal, LISP Phigs+? The SGI Pascal is the MIPS Pascal compiler. Currently, the compiler is an ANSI/ISO Level 0 implementation with extensions from MIPS. Look for more extensions in the future. For LISP, both Franz LISP and IBUKI Common LISP are available. I don't know the relative merits either one. From the SGI Geometry Partners directory: IBUKI 1447 North Shoreline Blvd. Mountain View, CA 94043 (415) 961-4996 Franz, Inc. 1995 University Avenue Berkeley, CA 94704 (415) 548-3600 For a PHIGS+ implementation, SGI offers Figaro from Template Graphics Software. The upcoming 2.0 release includes the PHIGS+ extensions. The price for the development environment is $3000. The price for the run-time environment is $700. I hope this is of some help.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22832; 14 Nov 89 3:54 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa22604; 14 Nov 89 2:30 EST Received: from explorer.dgp.toronto.edu by VMB.BRL.MIL id aa22561; 14 Nov 89 2:19 EST Received: from pavel by explorer.dgp.toronto.edu via UNIX id AA15210; Tue, 14 Nov 89 02:20:43 EST Message-Id: <8911140720.AA15210@explorer.dgp.toronto.edu> From: pavel@dgp.toronto.edu (Pavel Rozalski) Date: Tue, 14 Nov 89 02:20:41 EST Reply-To: pavel@dgp.toronto.edu To: info-iris@vmb.brl.mil Subject: Some questions on security on an Iris 4D Cc: pavel@explorer.dgp.toronto.edu I was just taking a look at one of the local Iris 4D's shipped with IRIX 3.2 and thought I would run some find commands. Here are some findings and comments. Set GID: -rwxr-sr-x 1 root wheel 94256 Sep 27 17:52 /etc/fuser ---x--s--x 1 root wheel 8240 Sep 27 17:52 /etc/killall -rwxr-sr-x 1 root wheel 61488 Sep 27 17:52 /etc/savecore -rwxr-sr-x 1 bin wheel 20528 Sep 27 17:52 /etc/whodo Probably none of the above need to be set GID - killall will only do stuff if the UID is root anyway. Set UID: -rwsrwsr-x 1 lp bin 53296 Sep 27 17:55 /usr/lib/accept -rwsrwsr-x 1 root bin 69680 Sep 27 17:55 /usr/lib/lpadmin -rwsrwsr-x 1 lp bin 57392 Sep 27 17:55 /usr/lib/lpmove -rwsrwsr-x 1 root bin 102400 Sep 27 17:55 /usr/lib/lpsched -rwsrwsr-x 1 lp bin 49200 Sep 27 17:55 /usr/lib/lpshut -rwsrwsr-x 1 lp bin 53296 Sep 27 17:55 /usr/lib/reject The above all have to do with line printer administration - since they all should probably be run by root, there is probably no reason they should be set UID. -rwsrwsr-x 1 lp bin 57392 Sep 27 17:53 /usr/bin/cancel -rwsrwsr-x 1 lp bin 57392 Sep 27 17:53 /usr/bin/disable -rwsrwsr-x 1 lp bin 12336 Sep 27 17:53 /usr/bin/enable -rwsrwsr-x 1 lp bin 69680 Sep 27 17:53 /usr/bin/lp -rwsrwsr-x 1 lp bin 65584 Sep 27 17:53 /usr/bin/lpstat User lp commands - probably some of these need to be set UID if you want to put up with lp and friends. -rwsr-xr-x 1 root wheel 151728 Sep 27 17:56 /usr/sbin/gr_osview This works just as well when it isn't set UID (as far as I could tell). -rwsrwsr-x 1 root bin 471216 Sep 27 18:06 /usr/lib/vadmin/disks -rwsr-xr-x 1 root bin 467120 Sep 27 18:06 /usr/lib/vadmin/networking -rwsr-xr-x 1 root bin 438448 Sep 27 18:06 /usr/lib/vadmin/printers -rwsrwsr-x 1 root bin 352432 Sep 27 18:06 /usr/lib/vadmin/serial_ports -rwsrwsr-x 1 root bin 454832 Sep 27 18:06 /usr/lib/vadmin/users -rwsr-xr-x 1 root wheel 53296 Sep 27 17:53 /usr/bin/crontab -rwsr-xr-x 1 root wheel 77872 Nov 6 16:20 /usr/bin/under -r-sr-xr-x 1 root wheel 73776 Sep 27 17:54 /usr/etc/ping -rwsr-xr-x 1 root wheel 94208 Sep 27 17:54 /usr/etc/timedc -rwsr-xr-x 1 root wheel 155696 Sep 27 17:56 /usr/sbin/bru -rwsr-xr-x 1 root wheel 131184 Sep 27 17:56 /usr/sbin/edge -rwsr-xr-x 1 root bin 274608 Sep 27 18:07 /usr/sbin/systemdown -rwsr-xr-x 1 root bin 372912 Sep 27 18:07 /usr/sbin/vadmin I don't know about the above. I doubt very much that edge, a debugger, must be set UID... Writeable files: drwxrwxrwx 3 root mail 512 Nov 6 14:31 /usr/mail drwxrwxrwx 2 root mail 512 Nov 6 14:31 /usr/mail/:saved Do you really want to keep around a mail system that *requires* permissions like that? Not only is mail forgery trivial but I doubt if it is desirable to have users store their files there. -rw-rw-rw- 1 root wheel 0 Sep 27 18:39 /usr/lib/cron/at.deny -rw-rw-rw- 1 root wheel 0 Sep 27 18:39 /usr/lib/cron/cron.deny Not sure about those two. -rw-rw-rw- 1 root wheel 0 Nov 9 23:20 /usr/lib/aliases.dir -rw-rw-rw- 1 root wheel 1024 Nov 9 23:20 /usr/lib/aliases.pag Bad hole - lets average user redirect anyone's mail and get sendmail to run any program as daemon. Not safe. I can provide details. -rw-rw-rw- 1 bin bin 652 Sep 27 18:06 /usr/sbin/IRIS_Visualizer -rw-rw-rw- 1 bin bin 377 Sep 27 18:07 /usr/sbin/quickmodel -rw-rw-rw- 1 bin bin 374 Sep 27 18:07 /usr/sbin/quickpaint -rw-rw-rw- 1 tutor 997 910 Sep 27 17:57 /usr/tutor/getstart/textfile -rw-rw-rw- 1 root wheel 3 Nov 9 23:20 /etc/syslog.pid -rw-rw-rw- 1 root wheel 0 Nov 13 21:57 /etc/rmtab Not sure about those. I doubt if many of the above files should have the permissions they are shipped with. Perhaps someone at SGI could confirm which of those files really need to be set UID or world writeable. Pavel Rozalski UUCP: ..!uunet!dgp.toronto.edu!pavel Bitnet: pavel@dgp.utoronto Internet/Ean: pavel@dgp.toronto.{edu,cdn}   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27459; 14 Nov 89 10:45 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25669; 14 Nov 89 9:32 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa25662; 14 Nov 89 9:23 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01393; 14 Nov 89 8:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA23492; Tue, 14 Nov 89 05:47:23 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 12:53:55 GMT From: "Adam W. Feigin" Organization: National Cancer Institute, Frederick Subject: 3.2 Installation Misfortunes Message-Id: <1391@fcs280s.ncifcrf.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just finished upgrading our 4D/70GT to 3.2; installation went okay, although the documentation leaves much to be desired. Now, its time to restore our user files...... Lo and behold ! The new release can't read/write multiple volumes on the VME QIC-02 cartridge tape anymore !! I have no idea why SGI would break something as fundamental as this. We've been doing multiple-volume backups/restores on our 4D/70 using the VME QIC-02 under 3.1 for over a year, and it worked fine. Anyone have any idea how I'm going to restore my users files ?? Any help is appreciated. AWF -- Internet: adam@ncifcrf.gov Adam W. Feigin UUCP: {backbonz}!ncifcrf!adam Senior Systems Manager Mail: P.O. Box B, Bldg 430 National Cancer Institute-Supercomputer Center Frederick, MD 21701 Frederick Cancer Research Facility   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02213; 14 Nov 89 14:19 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01195; 14 Nov 89 13:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00865; 14 Nov 89 13:31 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10003; 14 Nov 89 13:16 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA09417; Tue, 14 Nov 89 10:09:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 16:41:25 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 3rd party RAM, disk, and software query Message-Id: <44580@sgi.sgi.com> References: <8911131818.AA00479@castor.wustl.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911131818.AA00479@castor.wustl.edu>, weinhous@CASTOR.BERKELEY.EDU ("Martin S. Weinhous") writes: > We need to augment our two 4D120GTXs with ... ... > MISC: video frame grabber ... The Live Video Digitizer is a frame grabber board which will work with your GTX quite nicely. It can do lots of nifty things, including letting you watch soap operas in a window while you hack away. One interesting demo allows the overlay of geometry on a live video image, for instance using pieces of "flight" to shoot missles at live planes coming in from a VCR. This is a shipping product which is available >now<. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04440; 14 Nov 89 16:26 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02811; 14 Nov 89 15:01 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02714; 14 Nov 89 14:44 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12170; 14 Nov 89 14:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA14895; Tue, 14 Nov 89 11:28:37 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 18:03:55 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Long login delay Message-Id: <44585@sgi.sgi.com> References: <8911140002.aa23726@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911140002.aa23726@SMOKE.BRL.MIL>, S090726@UMRVMA.UMR.EDU ("Bob B. Funchess") writes: > "Why does it take the system so long to realize that the login is incorrect?" > > I haven't OFFICIALLY been told this, but I've been assuming that's not a bug, > it's a feature...[but is a securty patch]. > > < Bob S090726@UMRVMA.UMR.EDU Funchess > You're right. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05015; 14 Nov 89 17:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04060; 14 Nov 89 16:05 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03891; 14 Nov 89 15:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14643; 14 Nov 89 15:34 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18583; Tue, 14 Nov 89 12:20:49 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 18:22:16 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Some questions on security on an Iris 4D Message-Id: <44588@sgi.sgi.com> References: <8911140720.AA15210@explorer.dgp.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911140720.AA15210@explorer.dgp.toronto.edu>, pavel@DGP.TORONTO.EDU (Pavel Rozalski) writes: > I was just taking a look at one of the local Iris 4D's shipped with > IRIX 3.2 and thought I would run some find commands. Here are some > findings and comments. > > Set GID: > > -rwxr-sr-x 1 root wheel 94256 Sep 27 17:52 /etc/fuser > ---x--s--x 1 root wheel 8240 Sep 27 17:52 /etc/killall > -rwxr-sr-x 1 root wheel 61488 Sep 27 17:52 /etc/savecore > -rwxr-sr-x 1 bin wheel 20528 Sep 27 17:52 /etc/whodo > > Probably none of the above need to be set GID - killall will only do > stuff if the UID is root anyway. One assumes that your "wheel" is an addition to your /etc/groups, and is defined as 0. If not, all of the files with group "wheel" were changed at your site. Killall should be sgid=sys, because it is a great program. It will kill anything you have permission to kill. It is an extremely simple and fast replacement for the usual `ps -le | grep blah-de-blah | xargs kill` Fuser is also usefully sgid=sys. Savecore seems a little odd, since it should only be run by root. > ... > Writeable files: > > drwxrwxrwx 3 root mail 512 Nov 6 14:31 /usr/mail > drwxrwxrwx 2 root mail 512 Nov 6 14:31 /usr/mail/:saved This is a bug. They should be 775, since all of the programs that need to muck with these directories are sgid=mail. > -rw-rw-rw- 1 root wheel 0 Sep 27 18:39 /usr/lib/cron/at.deny > -rw-rw-rw- 1 root wheel 0 Sep 27 18:39 /usr/lib/cron/cron.deny > > Not sure about those two. This is a bug, or a local problem like the following: > -rw-rw-rw- 1 root wheel 0 Nov 9 23:20 /usr/lib/aliases.dir > -rw-rw-rw- 1 root wheel 1024 Nov 9 23:20 /usr/lib/aliases.pag > > Bad hole - lets average user redirect anyone's mail and get sendmail > to run any program as daemon. Not safe. I can provide details. This does not happen here on a machine with 3.2 installed "clean" (i.e. the disks scrubbed). Is it possible that some script, .profile, etc of yours does a `umask 0`? > I doubt if many of the above files should have the permissions they > are shipped with. Perhaps someone at SGI could confirm which of those > files really need to be set UID or world writeable. > > Pavel Rozalski > UUCP: ..!uunet!dgp.toronto.edu!pavel > Bitnet: pavel@dgp.utoronto > Internet/Ean: pavel@dgp.toronto.{edu,cdn} Other people should comment on the other files. In general, this is an interesting list. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05688; 14 Nov 89 19:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05593; 14 Nov 89 18:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05586; 14 Nov 89 18:10 EST Received: from uxa.cso.uiuc.edu by SMOKE.BRL.MIL id aa17358; 14 Nov 89 17:45 EST Received: by uxa.cso.uiuc.edu (5.61+/IDA-1.2.8) id AA13449; Tue, 14 Nov 89 13:20:37 -0600 Date: Tue, 14 Nov 89 13:20:37 -0600 From: Homayoon Akhiani Message-Id: <8911141920.AA13449@uxa.cso.uiuc.edu> To: info-iris@BRL.MIL Cc: ha90353@uxa.cso.uiuc.edu real-time needed At Aviation Research Lab of University of Illinios, we have a setup consisting of IRIS 3000's series. We have a real-time interactive flight simulator. We need to be able to detect certain events in milliseconds range. The program consists of a big loop, which creates a frame and check for different events. To record the time of the event, we use times() function however, if the generation of the frame takes a long time then the timestamp for the event would be invalid. The events are joysticks activites send through a serial port from AT machine. The events will go into a queue till the main loop get the event detection part and start processing the events. Is there anyway to setup an interupt service or anything else to make the IRIS timing more accurate ? ( HOW ? ) ( It is not a good idea to time stamp the events with the AT, because then the AT clock and the IRIS clock must be synchronized. ) Homayoon Akhiani University of Illinois Urbana/Champaign ha90353@uxa.cso.uiuc.edu akhiani@s.cs.uiuc.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05688; 14 Nov 89 19:09 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05656; 14 Nov 89 18:58 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05654; 14 Nov 89 18:49 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17909; 14 Nov 89 18:30 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA00459; Tue, 14 Nov 89 15:21:01 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 22:46:46 GMT From: "Bernard J. Duffy" Organization: University of Maryland, Baltimore County Subject: Re: vt100 emulator ? Message-Id: <2518@umbc3.UMBC.EDU> References: <223000003@uxe.cso.uiuc.edu>, <223000004@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <223000004@uxe.cso.uiuc.edu> sam@uxe.cso.uiuc.edu writes: > >RE: xterm under irix 3.2 > >In the meantime, let me ask if anyone can tell me >where one finds the key mapping for the VT100 "do" >key (so important to the eve editor, etc.) when >using "xterm" under Irix 3.2 on the SGI? Coming from a VAX/VMS environment with may faculty users in the same boat, I had a need to find the EDT keypad. If you send the terminal an = (I believe since I can't tested in with the hp workstation I'm using now), the keypad should be enable to be the DEC VT100 type. The numbered buttons as well as the . (period) and enter are direct maps. The PF buttons are the 4 function buttons labeled F9-F12 (the set of 4 right above the del-back space button of the main keyboard). This is documented, but I can't remember where (probably the Owner's Guide or the man page for wsh). I'd normally spend more time of making this message more correct, but can't right now and I thought the info/hint was more important. for your enjoyment, Bernie Bernie Duffy Systems Programmer II | Bitnet : BERNIE@UMBC2 Academic Computing - L005e | Internet : BERNIE@UMBC2.UMBC.EDU Univ. of Maryland, Baltimore County | UUCP : ...!uunet!umbc3!bernie Baltimore, MD 21228 (U.S.A.) | W: (301) 455-3231 H: (301) 744-2954   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05852; 14 Nov 89 19:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05786; 14 Nov 89 19:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05780; 14 Nov 89 19:35 EST Received: from forsythe.Stanford.EDU by SMOKE.BRL.MIL id aa18316; 14 Nov 89 19:20 EST Received: by Forsythe.Stanford.EDU; Tue, 14 Nov 89 16:20:27 PST Received: by SLACVM (Mailer R2.03B) id 6718; Tue, 14 Nov 89 16:20:25 PST Date: Tue, 14 Nov 1989 15:56 PST From: Len Sweeney To: info-iris@BRL.MIL Subject: Stereo questions Message-ID: <8911141920.aa18316@SMOKE.BRL.MIL> We are considering a sterio system, but still have a couple of misgivings. Is the multisinc Mitsubishi monitor they use for stereo as good as the standard monitor for normal (non-stereo) viewing? Is the CrystalEyes visor rugged enough to survive in a moderately chaotic environment? Can it survive being dropped, or thoughtless cleaning techniques? I'd appreciate anyone willing to share their experience in these areas. Len Sweeney LES@SLACVM.BITNET les@citsgi.SLAC.Stanford.EDU   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07342; 15 Nov 89 1:43 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa07107; 15 Nov 89 0:51 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07105; 15 Nov 89 0:35 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa20987; 15 Nov 89 0:14 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA21784; Tue, 14 Nov 89 21:04:06 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 22:34:08 GMT From: "C. Harald Koch" Organization: Alias Research, Inc., Toronto, Canada Subject: TTY minor device numbers Message-Id: <619@alias.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL What is the difference between the ttyd*, ttym*, and ttyf* devices? What do the various bits in the minor device number really do? From scouring the manuals, I have managed to find that ttym* is meant for modems, which probably means that an open() call won't return until DCD is set. I can't find anything else, other than an obscure reference to the Owner's Guide (which doesn't say anything useful). aTdHvAaNnKcSe, -- C. Harald Koch Alias Research, Inc., Toronto ON Canada chk%alias@csri.utoronto.ca chk@gpu.utcs.toronto.edu chk@chk.mef.org   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11254; 15 Nov 89 9:52 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab10397; 15 Nov 89 9:24 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab10206; 15 Nov 89 9:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26204; 15 Nov 89 8:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18333; Wed, 15 Nov 89 05:34:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 18:49:29 GMT From: Paul Mielke Organization: Silicon Graphics, Inc. Subject: Re: logging on Message-Id: <1432@odin.SGI.COM> References: <2830@uceng.UC.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <2830@uceng.UC.EDU>, trohling@uceng.UC.EDU (tom rohling) writes: > > Does anyone (SGI - are you listening??) have any idea why it takes so > long (4 - 5 seconds!) for our 4D to realize that you have incorrectly > entered your login name or password? At first I figured it was just the > way things are, and what can you about it. Then when we were upped to OS > version 3.1415..... I thought it may be fixed, nope. Well maybe after it > became a 120GTX running 3.1D, nope. ... stuff omitted ... > > A good explanation of this would be appreciated. > > Much obliged, > > Tom Rohling > University of Cincinnati > This is a feature, not a bug. The login program does a sleep(4) after each invalid login attempt. The idea is to make it harder to break into a system with a program that attempts to guess passwords. Sorry to disappoint you, but it still works that way in 3.2. Regards, Paul Mielke paulm@sgi.com Advanced Systems Division (415) 962-3447 Silicon Graphics, Inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11569; 15 Nov 89 10:02 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab10763; 15 Nov 89 9:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10707; 15 Nov 89 9:31 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26726; 15 Nov 89 8:59 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA19579; Wed, 15 Nov 89 05:57:04 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Nov 89 03:48:06 GMT From: Douglas Wells Organization: Connection Technologies, Harvard, MA Subject: Looking to rent some SGI equipment Message-Id: <564@contek.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I'm looking for companies that provide Silicon Graphics equipment for short term (one year or less) rental or lease. Any suggestions? Thanks in advance. -- Doug Wells ...!cloud9!contek!dmw dmw@contek.UUCP   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12197; 15 Nov 89 10:23 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa10397; 15 Nov 89 9:24 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa10206; 15 Nov 89 9:08 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa26200; 15 Nov 89 8:45 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18201; Wed, 15 Nov 89 05:32:48 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 17:58:04 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc. Subject: Re: 3.2 Installation Misfortunes Message-Id: <1427@odin.SGI.COM> References: <1391@fcs280s.ncifcrf.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > I just finished upgrading our 4D/70GT to 3.2; installation went okay, > although the documentation leaves much to be desired. Could you be more specific about problems in our documentation? You can e-mail them to me and I'll pass them on to our Tech Pubs group or you can fill out the customer feedback cards supplied in the documents. Our Tech Pubs people are fairly conciencous and are concerned about improving the quality of the documentation. Thanks. --- David Ciemiewicz   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20561; 15 Nov 89 22:35 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa20358; 15 Nov 89 21:43 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20340; 15 Nov 89 21:25 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13555; 15 Nov 89 21:01 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA04787; Wed, 15 Nov 89 17:55:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Nov 89 23:18:31 GMT From: Ted Wilcox Organization: Silicon Graphics, Inc. Subject: Re: Transfer Personal IRIS images to VCR Message-Id: <1440@odin.SGI.COM> References: <5025@yunexus.UUCP>, none Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <5025@yunexus.UUCP>, gklaass@yunexus.UUCP (Gary Klaassen) writes: > > > > We are considering getting a Personal Iris to do 3D colour graphics. > We would like to transfer the images, frame by frame if necessary, to > NTSC video (VHS and super VHS) for animation. > > We have been told that SGI sells a board that will do this, but it > takes up the VME slot, which means if you want a tape drive, it has > to be external. I'm surprised no-one has mentioned this yet. The internal tape drives for the Personal Iris are SCSI devices, so they don't need the VME slot. So, you can have your tape drive and your genlock too. > Thanks in advance, G. Klaassen Ted. ted@sgi.com {sun|decwrl|pyramid|ucbvax}!sgi!ted   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab13424; 21 Nov 89 16:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad13137; 21 Nov 89 16:13 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa13049; 21 Nov 89 16:00 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa25514; 21 Nov 89 15:41 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA23447; Tue, 21 Nov 89 12:18:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Nov 89 03:22:01 GMT From: unknown Organization: Stanford University Subject: Clearpoint memory (Re: 3rd party RAM, disk, and software query) Message-Id: References: <8911131818.AA00479@castor.wustl.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just learned from one of our third party suppliers that Clearpoint is now (finally!) making memory both for most of the SGI product line, including the 4D/2x0. Comparing the current cost of the Clearpoint memory with the price we paid SGI when we bought our 220 (to be fair, this was back in July when the memory market prices were still a little high, SGI's prices may be lower now), we would have saved almost $10K in hardware and support on the 24MB board.. Even so, the 4D/2x0 memory costs more than twice as much per Meg as the 4D/60/70/80 memory. But even so, it is a LOT less expensive than SGI's. Also, it comes with a lifetime warranty. I'm told that some SGI salespeople have on occasion mentioned Clearpoint when they are pressed to the wall on pricing against DEC and SUN. Our experience with Clearpoint has been pretty good. Once, we had a 16MB board go flakey on a Sun-3. After making sure I wasn't a foo-foo head, they FedEx'ed a new board out without waiting for the return of the bad one. Of course, caveat administrator. One always runs the risk of finger pointing with third-party hardware. Personally, I wouldn't get third party anything unless I felt comfortable pulling it out if problems develop. Disclaimer: I has no association with Clearpoint other than as a customer. I has on occasion flamed about the high cost of SGI add ons. I must admit that SGI's pricing on these things is much better than it used to be. Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@thrush.stanford.edu) (415) 723-4940   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08360; 15 Nov 89 7:31 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa08285; 15 Nov 89 7:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa08263; 15 Nov 89 6:56 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa23669; 15 Nov 89 6:44 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA12566; Wed, 15 Nov 89 03:31:42 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Nov 89 09:06:32 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: TTY minor device numbers Message-Id: <44706@sgi.sgi.com> References: <619@alias.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <619@alias.UUCP>, chk@alias.UUCP (C. Harald Koch) writes: > What is the difference between the ttyd*, ttym*, and ttyf* devices? What do > the various bits in the minor device number really do? ttyd* use RD,TD, and SG RS-232-C fashion. DTR & RTS will be + when the device is open, unless HUPCL has been fiddled. ttym* is the same ttyd*, except that DCD is waited for on open (unless NODELAY is set--used by uugetty), and causes SIGHUP and forced-close upon a falling edge. ttyf* is the same as ttym*, except CTS controls output as RS-232-C directs, and RTS follows the industry practice, non-RS-232-C-standard flow control scheme. That is, RTS low tells the device to stop talking. > From scouring the manuals, I have managed to find that ttym* is meant for > modems, which probably means that an open() call won't return until DCD is > set. I can't find anything else, other than an obscure reference to the > Owner's Guide (which doesn't say anything useful). > -- > C. Harald Koch Alias Research, Inc., Toronto ON Canada > chk%alias@csri.utoronto.ca chk@gpu.utcs.toronto.edu chk@chk.mef.org Essentially the preceding words are in text and tables in at least one of the manuals. I know because I regularly get the help necessary to find them, and because we spent lots of memorable time arguing over exactly what would be enough but not so much as to be confusing. Unfortunately, I must have a mental block about where these words are, because I can NEVER find them without help. Use ttym for slow modems. Use ttyf for fast modems which want "hardware flow control", such as TB's. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16124; 15 Nov 89 13:31 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa15093; 15 Nov 89 13:00 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14956; 15 Nov 89 12:38 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa02222; 15 Nov 89 11:20 EST Received: from UKACRL.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 7402; Wed, 15 Nov 89 11:10:47 EDT Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 2056; Wed, 15 Nov 89 15:33:34 GMT Received: Via: UK.AC.MRC.NIMR; 15 NOV 89 15:32:03 GMT Via: uk.ac.mrc.nimr; Wed, 15 Nov 89 15:33:22 GMT Date: Wed, 15 Nov 89 15:33:22 GMT From: NMR Center Users Message-Id: <8911151533.AA23938@uk.ac.mrc.nimr> To: info-iris@BRL.MIL Subject: Contour plots Does anyone know of any packages/subroutines to produce a contour plot on an HPGL plotter from a two-dimensional array. If you do not have one, but know from where I could obtain a public domain program I would still be extremely grateful for a reply. (If you have a routine for displaying contour maps on the IRIS screen that would still very useful.) Yours optimistically, Chris Bauer (nmr@uk.ac.mrc.nimr) MRC Biomedical NMR Centre, National Institute for Medical Research, Mill Hill, LONDON NW7 1AA.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19353; 15 Nov 89 17:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17850; 15 Nov 89 15:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17808; 15 Nov 89 15:14 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07718; 15 Nov 89 14:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA10942; Wed, 15 Nov 89 11:36:43 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Nov 89 16:57:27 GMT From: Thant Tessman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Stereo questions Message-Id: <44711@sgi.sgi.com> References: <8911141920.aa18316@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911141920.aa18316@SMOKE.BRL.MIL>, LES@SLACVM.BITNET (Len Sweeney) writes: > We are considering a sterio system, but still have a couple of misgivings. > > Is the multisinc Mitsubishi monitor they use for stereo as good as the > standard monitor for normal (non-stereo) viewing? The Mitsubishi is much nicer that the standard Hitatchi monitor. > > Is the CrystalEyes visor rugged enough to survive in a moderately > chaotic environment? Can it survive being dropped, or thoughtless > cleaning techniques? I don't know about cleaning solvents, but the things are pretty rugged, including (to some degree) water proof. thant P.S. I don't speak officially for SGI. -- There are 336 dimples on the standard golf ball.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab19353; 15 Nov 89 17:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab19132; 15 Nov 89 16:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab19114; 15 Nov 89 16:42 EST Received: from [128.155.20.81] by SMOKE.BRL.MIL id aa10398; 15 Nov 89 16:31 EST Received: Wed, 15 Nov 89 16:32:50 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 15 Nov 89 16:32:50 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8911160032.AA24144@aero4.larc.nasa.gov> To: nmr%NIMR.MRC.AC.UK@cunyvm.cuny.edu Subject: Re: Contour plots Cc: info-iris@BRL.MIL You might be able to get an old version of PLOT3D. This program does all sort of contouring on the IRIS. This software was written at Ames Research Center. The new versions are for US disemination only. You could send mail to pierce@prandtl.nas.nasa.gov to see if you can get a new version, if not he may be able to tell you how to get an old version of it. The most recent version is 3.6 I hope that helps. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19514; 15 Nov 89 17:18 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19132; 15 Nov 89 16:57 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19114; 15 Nov 89 16:42 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10393; 15 Nov 89 16:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18314; Wed, 15 Nov 89 13:28:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Nov 89 20:55:00 GMT From: "David M. McQueen" Organization: New York University Subject: two surprises on upgrading to IRIX 3.2 Message-Id: <17280027@acf4.NYU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We have recently upgraded to IRIX 3.2 and I notice (so far) two peculiarities: (1) It seems to be impossible to force a stowed window to stay at a location other than the original stowed location. Even after dragging the icon to a new position, upon reopening and restowing, the icon goes back to the location it had when first stowed. Does anyone know how to make a positioned-by-hand icon stay at that position through subsequent reopenings? If the solution involves modifying some postscript file, please do not be too terse; I still find postscript to be somewhat obscure. (2) We have several programs which employ the textport to input data to a graphics program to alter the image. They all tucked the textport (a window about 40 characters wide by 3 lines high) unobtrusively into the lower left hand corner of the screen, an area into which our image never went. After recompiling and relinking PREVIOUSLY WORKING CODE, I find the textport window is now a very obtrusive 80 characters wide by 7 lines high centered at the bottom of my image area. Has anyone experienced this problem, and if so, have you figured out a remedy? Dave McQueen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19940; 15 Nov 89 18:38 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa19874; 15 Nov 89 18:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19870; 15 Nov 89 18:19 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa11349; 15 Nov 89 17:56 EST Received: Wed, 15 Nov 89 17:57:49 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 15 Nov 89 17:57:49 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8911160157.AA24392@aero4.larc.nasa.gov> To: mcqueen%nyu-acf4.arpa@BRL.MIL Subject: Re: two surprises on upgrading to IRIX 3.2 Cc: info-iris@BRL.MIL (1) Gee that is annoying. SUN windows works the way you would like it to work, as you were hoping the SGI windows would work. If you put a window and its icon in specific places you would think that they would return to those places. I guess SGI has some catching up to do. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20655; 15 Nov 89 22:52 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab20561; 15 Nov 89 22:41 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20520; 15 Nov 89 22:25 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14101; 15 Nov 89 22:14 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA09659; Wed, 15 Nov 89 19:13:47 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Nov 89 02:58:01 GMT From: Timothy Hall Organization: Boston University Subject: more surprises on upgrading to IRIX 3.2 Message-Id: <42727@bu-cs.BU.EDU> References: <17280027@acf4.NYU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Another very annoying thing about 3.2 is that 4sight will get into a state where I cannot get an active window. I'm not sure what I do to get it in this state, but it happens fairly often. The only way I know of to fix the situation is to logout and login again. -Tim Hall tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21184; 16 Nov 89 0:54 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa21152; 16 Nov 89 0:44 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa21142; 16 Nov 89 0:34 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15259; 16 Nov 89 0:14 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15779; Wed, 15 Nov 89 21:05:39 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Nov 89 04:39:48 GMT From: Andrew Simms Organization: Princeton University Subject: 4D 200 series memory Message-Id: <11569@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL For those who expressed interest to me via email about 4D/200 series memory, I just received a 24 Meg. sample for my 4D/240GTX. It has now burned in overnight and it is working just fine. The supplier is Impediment 617/837-8877--the cost is $225/megabyte. ---------------------------------------------------------------------- Andrew Simms ams@acm.princeton.edu System Administrator Program in Applied and Computational Math Princeton University Princeton, NJ 08544 609/258-5324 or 609/258-6227 609/258-1054 (fax)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03905; 16 Nov 89 14:12 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03557; 16 Nov 89 14:01 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa03493; 16 Nov 89 13:40 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa02593; 16 Nov 89 13:31 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA29843; Thu, 16 Nov 89 10:11:59 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Nov 89 17:34:10 GMT From: Thant Tessman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: two surprises on upgrading to IRIX 3.2 Message-Id: <44797@sgi.sgi.com> References: <8911160157.AA24392@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911160157.AA24392@aero4.larc.nasa.gov>, blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854") writes: > > (1) Gee that is annoying. SUN windows works the way you would > like it to work, as you were hoping the SGI windows would > work. If you put a window and its icon in specific places > you would think that they would return to those places. > I guess SGI has some catching up to do. I was waiting for someone else to respond to the original posting. I wasn't expecting Brent L. Bates to do it first. First, copy from /usr/NeWS/lib/user.ps to user.ps in your own home directory. Next, look for the three lines in your copy of user.ps that look like: %% whether icons are automaticly tidied up is controled by TidyState % UserProfile /TidyState /Always put % default state % UserProfile /TidyState /Never put % pre- 4D3.2 release behavior Change them to make it look like: %% whether icons are automaticly tidied up is controled by TidyState % UserProfile /TidyState /Always put % default state UserProfile /TidyState /Never put % pre- 4D3.2 release behavior There are other goodies in there to change as well if you like. thant -- There are 336 dimples on the standard golf ball.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06136; 16 Nov 89 17:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05811; 16 Nov 89 16:55 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05600; 16 Nov 89 16:34 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07953; 16 Nov 89 15:38 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA08551; Thu, 16 Nov 89 12:23:07 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Nov 89 19:17:58 GMT From: Arthur David Olson Organization: NIH-LEC, Bethesda, MD Subject: Wanted: help with IRIX 3.2/XV11R3 challenge Message-Id: <9203@elsie.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Elsie is our Sun 3/280 running SunOS 4.0.3. If I log in to elsie from the console of our SGI IRIS 4D/70G and try to drop pixels into an X window, things go awry--in particular, only the low-order four bits of the pixels being written seem to make it to the window. I've attached a typescript showing the problem (the incorrect results are marked with ">>>>"s). If you can tell me what I'm doing wrong, I'd appreciate hearing from you by electronic mail. -- Arthur David Olson ado@alw.nih.gov ADO is a trademark of Ampex. Script started on Thu Nov 16 14:16:02 1989 elsie$ cat try.c #include #include #define WIDTH 20 #define HEIGHT 1 Display * display; int screen_number; Visual * visual; Window root_window; Window window; GC default_gc; XImage * ximage; char data[WIDTH][HEIGHT]; main() { int x, y; display = XOpenDisplay((char *) NULL); if (display == 0) abort(); root_window = DefaultRootWindow(display); screen_number = XDefaultScreen(display); visual = DefaultVisual(display, screen_number); default_gc = DefaultGC(display, screen_number); window = XCreateSimpleWindow(display, root_window, 300, 300, WIDTH, HEIGHT, 2, 0, 1); XMapWindow(display, window); XSync(display, 0); (void) printf("Tap RETURN when the window is in place.\n"); (void) getchar(); ximage = XCreateImage(display, visual, 8, ZPixmap, 0, (char *) data, WIDTH, HEIGHT, 8, 0); if (ximage == 0) abort(); for (x = 0; x < WIDTH; ++x) for (y = 0; y < HEIGHT; ++y) XPutPixel(ximage, x, y, x); XPutImage(display, window, default_gc, ximage, 0, 0, 0, 0, WIDTH, HEIGHT); ximage = XGetImage(display, window, 0, 0, WIDTH, HEIGHT, (unsigned long) ~0, ZPixmap); for (x = 0; x < WIDTH; ++x) for (y = 0; y < HEIGHT; ++y) (void) printf("data[%d][%d]\t%d\n", x, y, XGetPixel(ximage, x, y)); return 0; } elsie$ cc -g try.c -lX11 -o try elsie$ try Tap RETURN when the window is in place. data[0][0] 0 data[1][0] 1 data[2][0] 2 data[3][0] 3 data[4][0] 4 data[5][0] 5 data[6][0] 6 data[7][0] 7 data[8][0] 8 data[9][0] 9 data[10][0] 10 data[11][0] 11 data[12][0] 12 data[13][0] 13 data[14][0] 14 data[15][0] 15 >>>> data[16][0] 0 >>>> data[17][0] 1 >>>> data[18][0] 2 >>>> data[19][0] 3 elsie$ exit script done on Thu Nov 16 14:16:47 1989   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06136; 16 Nov 89 17:06 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab05811; 16 Nov 89 16:56 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05670; 16 Nov 89 16:36 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08239; 16 Nov 89 15:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA09817; Thu, 16 Nov 89 12:42:05 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Nov 89 17:51:54 GMT From: Bill Lasher Organization: Penn State University Subject: More suprises with IRIX 3.2 Message-Id: <89320.125154W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL 1. The page down and page up keys don't work in vi anymore. These were far more convenient than ctrl-b and ctrl-f. 2. On the good side, jot is a nice improvement.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06222; 16 Nov 89 17:17 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04954; 16 Nov 89 16:10 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04889; 16 Nov 89 15:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03705; 16 Nov 89 13:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA00692; Thu, 16 Nov 89 10:23:03 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Nov 89 14:55:00 GMT From: "David M. McQueen" Organization: New York University Subject: Re: two surprises on upgrading to IRIX 3.2 Message-Id: <17280028@acf4.NYU.EDU> References: <17280027@acf4.NYU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I received several FAST responses from personnel at SGI (thank you Brendan, Michael, Scott) on my IRIX 3.2 surprise #1. In case there is interest in this out there, look in /usr/people/4Dgifts/.4sight for interesting (and understandable) examples of how to make the desktop look and act the way you want it to. Thanks again, Dave McQueen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06489; 16 Nov 89 17:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05361; 16 Nov 89 16:34 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05092; 16 Nov 89 16:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07270; 16 Nov 89 15:23 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA07947; Thu, 16 Nov 89 12:13:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Nov 89 21:06:17 GMT From: Mike Walker Organization: NASA Langley Research Center, Hampton, Va. 23665 Subject: Cyberspace under 4Sight Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone succeded (or even tried) to get Don Hopkins cyberspace deck working under 4Sight? Patches, instructions, pointers, comments, or almost anything else would be appreciated... Thanks, Mike -- Mike Walker AS&M Inc/NASA LaRC (804) 864-2305   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00488; 16 Nov 89 22:58 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00234; 16 Nov 89 22:08 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00199; 16 Nov 89 21:47 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11855; 16 Nov 89 20:46 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA29039; Thu, 16 Nov 89 17:35:56 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Nov 89 01:20:36 GMT From: Pablo Fernicola Organization: UF CIS Department Subject: IRIX 3.2 features description request Message-Id: <21240@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Sometime ago I posted a message asking for a description of the new features/ improvements in IRIX 3.2, but nobody posted anything. Are there any radical changes? Is there anything new? Do I have to ask Silicon Graphics for the upgrade? Will they send me a upgrade notice? -- pff@beach.cis.ufl.edu - Pablo Fernicola - Machine Intelligence Laboratory - UF IF YOU CARE ENOUGH TO READ SIGNATURES ... I am graduating next year and I am looking for a job. MS/BS EE, my graduate work incorporates OO-DBMS/Graphics/Robotics/AI   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00585; 16 Nov 89 23:19 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa00336; 16 Nov 89 22:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00305; 16 Nov 89 22:10 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12471; 16 Nov 89 21:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA03687; Thu, 16 Nov 89 18:44:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Nov 89 01:43:47 GMT From: lhary meyer Organization: Whole Earth 'Lectronic Link, Sausalito, CA Subject: Re: Stereo questions Message-Id: <14599@well.UUCP> References: <8911141920.aa18316@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL To answer your questions... 1. The Mitsubishi monitor used for stereo is BETTER then the standard monitor! It's brighter, converges better, and sharper! You'll like it. 2. StereoView (CrystalEyes) glasses are moderately rugged. Obviously they have glass lenses, which can be cracked. The rest of the unit is quite strong and unlikely to be damaged in any lab environment. We are coming up with a fixed price lens replacement cost, and do it in one day. .....Lhary Meyer, StereoGraphics   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01189; 17 Nov 89 1:22 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa01019; 17 Nov 89 0:40 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01006; 17 Nov 89 0:28 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13462; 16 Nov 89 23:33 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA09987; Thu, 16 Nov 89 20:27:23 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Nov 89 17:42:29 GMT From: Michael Toy Organization: Silicon Graphics, Entry Systems Division Subject: Re: two surprises on upgrading to IRIX 3.2 Message-Id: <1479@odin.SGI.COM> References: <17280027@acf4.NYU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <17280027@acf4.NYU.EDU>, mcqueen@acf4.NYU.EDU (David M. McQueen) writes: > > We have recently upgraded to IRIX 3.2 and I notice (so far) two peculiarities: > > (1) It seems to be impossible to force a stowed window to stay at > a location other than the original stowed location. > ... > Dave McQueen I thought I had posted a reply to this, but it seems to have been dropped. I'll post again and apologize in advance for the double posting in case both get through. Point #1, icons stack themselves in neat little rows when you stow windows. This new feature (or mis-feature, depending on your expectations) is described in the release notes (relnotes -p eoe1 -c 5) and in the 4sight Programmer's Guide, in the default "user.ps" file in /usr/NeWS/lib and in the example customization log in account "4Dgifts". Or, if you don't care to learn about any new features, you can tell 4sight to have the pre 3.2 behavior by adding the line UserProfile /TidyState /Never put to the file "user.ps" in your home directory. Michael Toy   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03541; 17 Nov 89 8:27 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa03338; 17 Nov 89 8:16 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03171; 17 Nov 89 8:05 EST Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa17995; 17 Nov 89 7:43 EST Received: Fri, 17 Nov 89 07:43:04 EST by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 17 Nov 89 07:43:04 EST From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8911171543.AA00011@aero4.larc.nasa.gov> To: sgi!thant%horus.esd.sgi.com@ucbvax.berkeley.edu Subject: Re: two surprises on upgrading to IRIX 3.2 Cc: info-iris@BRL.MIL Good, quick, precise responce. Good job. I am sorry for under estimating SGI's windows. (How many SGI heart attack's did this note cause. :-) ) -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19107; 18 Nov 89 7:13 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa19028; 18 Nov 89 7:02 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19003; 18 Nov 89 6:51 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13115; 18 Nov 89 6:48 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA27114; Sat, 18 Nov 89 03:38:51 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Nov 89 00:17:23 GMT From: "SCHREIBER, O. A." Organization: Georgia Institute of Technology Subject: Difference between 4D120GTX and 4D220 Message-Id: <3590@hydra.gatech.EDU> References: <8911171543.AA00011@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL What difference is there between 4D120GTX (what we have here, Power Series) and 4D220 (Power Series?). I could call an sgi rep during the week but I need the information before Monday. Thanks for the info. Olivier Schreiber (404)894 6147, Office of Computing Services Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccsupos ARPA: ccsupos@prism.gatech.edu -- Olivier Schreiber (404)894 6147, Office of Computing Services Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccsupos ARPA: ccsupos@prism.gatech.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19277; 18 Nov 89 7:44 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa18944; 18 Nov 89 6:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa18899; 18 Nov 89 6:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12940; 18 Nov 89 6:19 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA24425; Sat, 18 Nov 89 02:58:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Nov 89 17:18:45 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: More suprises with IRIX 3.2 Message-Id: <1504@odin.SGI.COM> References: <89320.125154W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL >> 1. The page down and page up keys don't work in vi anymore. These were far >> more convenient than ctrl-b and ctrl-f. If you look at the wsh man page, it will point you to the bindkey man page, which documents the default key bindings that wsh uses. page-up and page-down are now bound to the scroll-bar page-up and page-down functions. home and end are similarly found. To undo a default binding, reverting the key to sending data, do this: bindkey -l page-up bindkey -l page-down >> 2. On the good side, jot is a nice improvement. Thanks. kipp hickman silicon graphics inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab19277; 18 Nov 89 7:44 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab18944; 18 Nov 89 6:48 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab18899; 18 Nov 89 6:29 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12944; 18 Nov 89 6:20 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA24408; Sat, 18 Nov 89 02:57:50 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Nov 89 19:01:59 GMT From: sgi!shinobu!odin!chromavac!miq@ucbvax.berkeley.edu Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: More suprises with IRIX 3.2 Message-Id: <1509@odin.SGI.COM> References: <89320.125154W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89320.125154W0L@PSUVM.BITNET> W0L@PSUVM.BITNET (Bill Lasher) writes: >1. The page down and page up keys don't work in vi anymore. These were far >more convenient than ctrl-b and ctrl-f. Page Up and Page Down now work in a wsh window to scroll the window. You can use these keys within vi with the command "bindkey" BINDKEY(1) Silicon Graphics BINDKEY(1) NAME bindkey - function key binding facility for use with wsh(1G) SYNOPSIS bindkey [ -r key[,binding] ... ] bindkey [ -l key[,binding] ... ] DESCRIPTION bindkey is a program which provides an interface to the wsh(1G) function key binding facilities. key is the name of a key on the keyboard; type bindkey without arguments to obtain a list of valid keys. The following are valid bindkey keys: f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12 print-scrn scroll-lock pause insert home page-up end page-down left-arrow up-arrow down-arrow right-arrow Just bind ^F and ^B to Page Up and Page Down and it will funtion the same in vi. "What is the greatest joy?" "The joy of duty!" Miq Millman -- miq@sgi.com or {decwrl,pyramid,ucbvax}!sgi!miq 415 960 1980 x1041 work   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20004; 18 Nov 89 9:32 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa19944; 18 Nov 89 9:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19923; 18 Nov 89 9:11 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14311; 18 Nov 89 9:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA03515; Sat, 18 Nov 89 05:56:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Nov 89 03:38:53 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Transfer Personal IRIS images to VCR Message-Id: <1523@odin.SGI.COM> References: <8911131633.AA13927@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911131633.AA13927@aero4.larc.nasa.gov>, blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854") writes: > > There are several companies out there that sell devices that connect to > the RGB output of your computer and then connect to your video tape recorder. > However, all the ones I have seen record "live" that is what every is drawn > on the screen however fast or slow that is that is the way it gets recorded. > That is what I have heard about, if there is anything else out there I > would like to know about it. You don't need any other type of converter. You need an animation controller and a single frame VTR. Display the frame, record it, and move to the next one. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20377; 18 Nov 89 11:00 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa20264; 18 Nov 89 10:39 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa20219; 18 Nov 89 10:26 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14747; 18 Nov 89 10:17 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA06862; Sat, 18 Nov 89 07:05:23 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Nov 89 17:18:42 GMT From: "Mark V. Meuer" Organization: University of Minnesota, Minneapolis Subject: Updating directory views Message-Id: <17093@umn-cs.CS.UMN.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL How can I get a directory view that has been opened in the WorkSpace to re-sync itself with its directory? What happens is that I'll open a view, call up the editor from that view and create a new file from within the editor and write it to disk. Unfortunately, the file does not show up as an icon in the view unless I kill the view and re-open a new one for the directory. We are running 3.2 IRIX. It think that the 3.2 beta version we had would automatically sync the views. Thanks for any help! -mark -- Mark Meuer | 1200 Washington Ave. So. Geometry Supercomputer Project | Minneapolis, MN 55415 meuer@geom.umn.edu | (612) 624-1867   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02960; 19 Nov 89 12:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02576; 19 Nov 89 11:28 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa02538; 19 Nov 89 11:12 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24063; 19 Nov 89 11:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA19737; Sun, 19 Nov 89 07:50:58 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Nov 89 15:08:02 GMT From: Andrew Simms Organization: Princeton University Subject: Re: Transfer Personal IRIS images to VCR Message-Id: <11628@phoenix.Princeton.EDU> References: <8911131633.AA13927@aero4.larc.nasa.gov>, <1523@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Mark Callow writes... > You don't need any other type of converter. You need an animation controller > and a single frame VTR. Display the frame, record it, and move to the > next one. > -- > From the TARDIS of Mark Callow > msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc And my response is: WAIT WAIT WAIT not necessarily. There has been a bit of traffic lately about animation and so forth on the net and most of it hasn't given the big picture on making animations. I get the feeling that a lot of people interested in making animations have hit the same walls I did in trying to put together a system that works: 1. Lots of products not marketed specifically at the sci-vi interest group 2. Lots of sleazy video salespeople who have no idea why anyone would buy a 100k+ plus machine that doesn't run lotus but are more than happy to sell you something. So, in a long nutshell, here is the big picture: There are two major arenas in the animation field: frame by frame and realtime. Frame by frame utilizes a device called an animation controller. This box controls a high priced VTR called an editing deck. It can cause the VTR to record extremely short segments of video onto a tape. The net result is a film in the tradition stop action photography. It can produce beautiful results. The second arena is called real time. Here you record images from your iris to a VTR as they are displayed. This type of animation is excellent for demonstrations and animations that are slow enough for your SGI to display in real time. This type of animation doesn't require an editing deck, but the better deck you buy the better results you will get. HARDWARE NEEDED. What you need depends on what you want to do. There are a couple inheirant problems with animation and you must choose the right hardware to solve the problems. These are the problems: 1. The Iris has a high resolution monitor/display. Video decs are low resolution devices. In order to display your Iris screen on standard TV format device, you need to: A. Reduce the resolution of the iris image to NTSC (TV), SuperVHS (a newer higher resolution standard), or another format suitable for your VTR. This process requires a scan converter (Lyon Lamb makes an expensive one, we ended up buying an RGB Technologies box). B. Cut a small window out of your iris screen and transmit it to your VTR. SGI (and other companies) makes a simple card called a genlock option that does this. When this board is on the RGB lines going to monitor change from their normal high-res signal to RS-170, a low resolution RGB signal. I believe (but since I am at home and can't look, that a composite signal is provided as well). 2. Are the movies you wish to make slow enough that your Iris can display the results in real time? If not, you will need to go frame by frame. For this, you need an animation controller. There are several types. A. Lyon Lamb and others make a NTSC/SuperVHS level animation controllers. These are meant to use low resolution images and as such you run into problem 1. Some animation controllers will only accept a composite signal. Therefore if you have solved problem 1 such that you only have RS170 you may need an additional device called an encoder which will take the RGB signal and create a composite signal suitable for the majority of animation controllers. This class of controllers work in the following fashion. You feed the controller an appropriate video signal. The lyon lamb is controlled by your iris via an RS232 cable and it uses software you get to write yourself or purchase. When your frame is ready, you issue a record command. Then you prepare the next frame, record, prepare, record... until it is done. B. Abacus and others make a different type of controller. This device sits on your ethernet and has a 1.2 Gigabyte disk on it. You write software that FTPs your image to the Abacus. It stores sequential frames on disk, and then it will write them out to a VCR. I believe that the transfer is accomplished by constructing a frame on the Abacus's internal frame buffer then it issues a record command to your VTR while displaying the image. This is an expensive device. You do not need a scan converter for this option but you will need an editing deck. Perhaps someone can comment as to whether or not Abacus will provide a deck. It should also be noted that this device cannot do real time recording. C. SGI's new product. SGI now has a card that is an animation controller. It may only work on a Power Series (SGI please confirm) and promises to be a nifty product for those who will only be using an SGI to make movies. It may also be capable of displaying video images on your high-res display while you work (so you can watch CNN while you work like all the cia folks). I believe it can do both frame by frame and realtime animation. SOFTWARE We are writing our own for the stuff we bought, so I don't have much info. It would make this message far more useful if someone would comment on what's available. WHAT I BOUGHT The group here needs to do both frame by frame and realtime animations. We also decided we needed better than NTSC resolution so we went with supervhs. So, we got a Panasonic AG7500A 1/2" VTR, an RGB Technologies Scan converter, a Sony 1342 s-vhs monitor and we upgraded our Lyon Lamb Mini-vas to the SuperVHS edition. Our realtime results have been excellent. When we have our minivas back from upgrade, I will know about frame by frame quality. FINAL THOUGHTS Insist on on-site demonstrations and/or have your dealer leave stuff with you for evalutation. Otherwise you will end up with a pile of stuff you can't even pay graduate students to use. As far as sources for this stuff, I will prepare a list and post it or mail it to those who are interested. Andrew Simms ams@acm.princeton.edu System Administrator Program in Applied and Computational Math Princeton University Princeton, NJ 08544 609/258-5324 or 609/258-6227 609/258-1054 (fax)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03763; 19 Nov 89 15:53 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa03469; 19 Nov 89 15:06 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03432; 19 Nov 89 14:48 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25913; 19 Nov 89 14:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA00220; Sun, 19 Nov 89 11:35:39 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Nov 89 18:48:35 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Difference between 4D120GTX and 4D220 Message-Id: <44985@sgi.sgi.com> References: <8911171543.AA00011@aero4.larc.nasa.gov>, <3590@hydra.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <3590@hydra.gatech.EDU>, ccsupos@prism.gatech.EDU (SCHREIBER, O. A.) writes: > > > > What difference is there between > 4D120GTX (what we have here, Power Series) > and 4D220 (Power Series?). I could call an sgi rep during the week > but I need the information before Monday. > A POWERSeries machine with the 'GTX' suffix indicates a box with the graphics subsystem. There are actually two flavors of this, the 'GTX' and the 'GTXB'. The 'GTXB' comes without the alpha planes to reduce cost (this >doesn't< mean that you can't do alpha blending, it means you can't store alpha values with each pixel). If you don't know what the alpha planes are used for, you probably don't need them. The 4D/120 machine uses 2 R2000/R2010 processors running at 16.667MHz. Rated performance is 20 Drhystone MIPS, 2 DP Linpack MFLOPS. For many applications, this is an excellent machine. The 4D/220 machine uses 2 R3000/R3010 processors running at 25Mhz. Rated performance is 40 Dhrystone MIPS, 8 DP Linpack MFLOPS. Performance is stunning. All POWERSeries machines have the same graphics performance with the GTX option (i.e., performance is graphics subsystem limited, not CPU limited). -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03763; 19 Nov 89 15:53 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ab03560; 19 Nov 89 15:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03479; 19 Nov 89 14:59 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25956; 19 Nov 89 14:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA00163; Sun, 19 Nov 89 11:34:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Nov 89 18:38:54 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: IRIX 3.2 Release Notes (Part 1 of 3) Message-Id: <44982@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Enclosed as a copy of the relevant portions of the 3.2 release notes which come with every 3.2 release (you can get these with the "relnotes" command). It is broken in three parts, because of the size. Glue them together before using. I've taken the liberty of compressing the output by removing extraneous empty lines. These are chapters 3, 4, 5, 6, 7 and 8. One thing unmentioned in the release notes is a development caveat that we follow that I believe you will find out when running the system: the next release has to be at least as fast as the last one (and it had damn well better be faster!). These release notes are: Copyright (c) 1989 Silicon Graphics Computer Systems All Rights Reserved -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb ------------------- cut here --------------------- IRIX 3.2 Release Notes, as posted to USENET in comp.sys.sgi (Part 1 of 3) Copyright (c) 1989 Silicon Graphics Computer Systems All Rights Reserved >>>>>>>>>> 3.2 Release notes, Chapter 3 >>>>>>>>>> - 1 - 3. Major_Enhancements_and_Compatibility This chapter describes the major enhancements of the 4D1-3.2 software release, summarizes compatibility issues for the program development tools, and provides a description of the subsystems provided with this release. This chapter is divided into the following sections: o Major Enhancements o Compatibility of Program Development Tools o Description of 4D1-3.2 Subsystems - 2 - 3.1 Major_Enhancements 3.1.1 Software_Enhancements The 4D1-3.2 release provides these major software enhancements: o The IRIS WorkspaceTM The Workspace is a graphically organized iconic interface to UNIXTM that allows quick and easy access to the file system. System administration tasks are greatly simplified via the System Manager, which is included in the Workspace package. o Visual Login The console login now is visual by default. See pandora(1) and the IRIS-4D System Administrator's Guide for information about configuring the console login. o Visual Administration/System Manager The System Manager offers a suite of icon-driven tools for administering the UNIX system under the IRIX Workspace. The System Manager is built on top of standard UNIX commands and file formats. Using those standard commands directly will not interfere with the System Manager. o QuickPaintTM (by Alias Research) QuickPaint is a color paint program employing a rich variety of brush types, sizes, and shapes, as well as many brush functions. o QuickModelTM (by Alias Research) QuickModel is a 3-D modeling package that gives the user the ability to quickly create solid objects, render them, and interactively view them in real time. o Personal VisualizerTM (Wavefront's renderer) The Personal Visualizer is a rendering package that allows the user to import 3-D models and create photorealistic renditions of them under different lighting, material, and other scene characteristics. The Personal Visualizer features ray tracing capabilities. - 3 - o NURBS NURBS is a major new GL feature that allows direct rendering of Trimmed Non-Uniform Rational B-Spline Surfaces. This new feature is offered through a combination of software, firmware, and hardware on all 4D platforms. o Logical Operations (Personal IRIS only) Logical operations (logicop) is a new GL feature that allows GL application to perform boolean pixel operations. o User-level SCSI devices drivers. See ds(7M) in the IRIS-4D Programmer's Reference Manual for more information. o Support for the use of all serial ports on Power Series systems. 3.1.2 Hardware_Enhancements The 4D1-3.2 release provides support for the following hardware and firmware: o 4D/210GTX 4D/210S A new member of the Power Series. It has a single processor MIPS R3000/R3010 running 25 MHz. o Personal IRIS Turbo New 20 Mhz CPU board with higher performance. Two surface mount daughter boards added to GR1 to increase the graphics performance. o RE2 New Raster Engine chip is supported on Personal Iris models including Turbo. It has the following new features: logical operations on a Personal IRIS, pixel unpacking, screen mask, better antialiased lines. o Diskless Workstations without hard disks. The 4D/20 and 4D/25 can both operate as diskless workstations. Diskless workstations require special installation. o SCSI 1/2" Tape - (Personal IRIS only). o Industry Standard (IBM compatible) floppy disk drive - Personal IRIS only. - 4 - 3.2 Compatibility_of_Program_Development_Tools The following tables describe compatibility between software releases 4D1-3.1 and 4D1-3.2 and between releases 4D1-2.0 and 4D1-3.2. In these tables, source means source files, whether FORTRAN, C, or another language. Application libraries means not only archive libraries of object files (.o files), but also individual object files. Executables means executable binaries (not shell command files). Release 4D1-3.2 is compatible with release 4D1-3.1 with one exception: programs linked under release 4D1-3.1 using the shared library /usr/lib/libfm_s.a which were not also linked with the shared library /usr/lib/libgl_s.a must be relinked to run under release 4D1-3.2. Binaries linked with the non-shared versions of libfm.a or libgl must be relinked. 3.2.1 Upwards_Compatibility _______________________________________________________ | |_________________________________________| |4D1-3.1 | Compilation | Tools | Execution | |Generated | Environment | Environment | Environment | | | (cc, f77, | (nm, | | | | ar, ld) | strip, | | | | | dbx, edge, | | | | | lint, | | | | | stdump, | | | | | size, dis) | | _______________________________________________________| |____________|_____________|_____________|_____________| |application | yes | yes | yes | |libraries | | | | | | | | | |____________|_____________|_____________|_____________| |executables | NA | yes | yes, | | | | | unless the | | | | | non-shared | | | | | versions | | | | | of libgl.a | | | | | or libfm.a | |____________|_____________|_____________|_____________| - 5 - _______________________________________________________ | |_________________________________________| |4D1-3.0 | Compilation | Tools | Execution | |Generated | Environment | Environment | Environment | | | (cc, f77, | (nm, | | | | ar, ld) | strip, | | | | | dbx, edge, | | | | | lint, | | | | | stdump, | | | | | size, dis) | | _______________________________________________________| |____________|_____________|_____________|_____________| |application | yes | No for nm, | yes | |libraries | | dbx, edge, | | | | | stdump, | | | | | dis. Yes | | | | | for strip, | | | | | size | | | | | | | |____________|_____________|_____________|_____________| |executables | NA | No for nm, | yes, | | | | dbx, edge, | unless the | | | | stdump, | non-shared | | | | dis. Yes | versions | | | | for strip, | of libgl.a | | | | size | or libfm.a | |____________|_____________|_____________|_____________| - 6 - _______________________________________________________ | |_________________________________________| |4D1-2.0 | Compilation | Tools | Execution | |Generated | Environment | Environment | Environment | | | (cc, f77, | (nm, | | | | ar, ld) | strip, | | | | | dbx, edge, | | | | | lint, | | | | | stdump, | | | | | size, dis) | | _______________________________________________________| |____________|_____________|_____________|_____________| |application | yes | No for nm, | yes | |libraries | | dbx, edge, | | | | | stdump, | | | | | dis. Yes | | | | | for strip, | | | | | size | | | | | | | |____________|_____________|_____________|_____________| |executables | NA | No for nm, | No if | | | | dbx, edge, | graphics. | | | | stdump, | Yes | | | | dis. Yes | otherwise. | | | | for strip, | | |____________|_____________|_____________|_____________| 3.2.2 Backwards_Compatibility You can safely assume that software generated in 4D1-3.2 will not work with previous system software releases. - 7 - 3.3 Description_of_4D1-3.2_Subsystems 3.3.0.1 Execution_Only_Environment_Tape_1 eoe1.sw.acct This is the System V Process Accounting package. It is used to monitor system resource usage on a per-user basis. When Process Accounting is installed and turned on, a record is kept of every command that is executed along with data on the resources the command used. Report generating scripts are then run which produce periodic reports of system utilization. This package is useful when it is desired to monitor usage patterns in systems with large numbers of users. eoe1.sw.cdsio This is the driver for the VME Serial Expansion board. It is required for systems with that option installed. eoe1.sw.crypt This subsystem contains the crypt and makekey programs which, along with the editors ed and vi, implement a simple text encryption system. eoe1.sw.dfm This is a subset of IRIX utilities dealing with directory and file management. It is generally required in all systems. eoe1.sw.editors This subsystem contains the standard IRIX text editors and is generally required on all systems. eoe1.sw.hyper This is the driver for the HyperNet VME interface and is required only on systems with that option installed. eoe1.sw.ikc This is the driver for the VME Parallel Expansion interface and is required only by systems with that option installed. - 8 - eoe1.sw.ipc This subsystem contains utilities useful in controlling the System V Inter Process Communications facility. It consists of two utilities: ipcrm and ipcs. eoe1.sw.lp This subsystem contains the Line Printer Spooling package and is required on any system that will be used with printers, either locally or over a network. eoe1.sw.mast This subsystem contains vital graphics software and is generally required on workstations. On some systems, this subsystem will be empty however. eoe1.sw.perf This subsystem contains the System Activity Reporting (SAR) package. This facility is useful for monitoring processor activity and IRIX system performance. It may be used in either an interactive mode or as a background data collector/report generator. This subsystem is not required, but may be useful in diagnosing system performance problems. eoe1.sw.spell This subsystem contains a dictionary and command that checks spelling. eoe1.sw.tcp This subsystem contains programs and files that implement the TCP/IP family of networking facilities. It is generally required on all systems even if they will be used in a stand-alone environment. eoe1.sw.terminf This is the Terminfo terminal database. It contains files describing the capabilities of hundreds of different types of terminals and is used by the vi editor as well as many common terminal- oriented applications. A few common terminals may be used without this subsystem. eoe1.sw.ts This is the driver for the ISI VME quarter-inch cartridge tape controller. It is required on systems with that option installed. - 9 - eoe1.sw.unix This subsystem contains the core IRIX commands and files and is required on all systems. - 10 - eoe1.sw.usrenv This subsystem contains a subset of the standard IRIX commands and is generally required on all systems. eoe1.sw.uucp This is the traditional UUCP communications package which implements a point-to-point networking facility. This is only required for sites where UUCP is used but it also contains facilities that may be useful for systems with modems. eoe1.sw.xm This is the driver for the Xylogics VME 1/2" tape controller and is required only on systems with the controller installed. eoe1.man.relnotes This is an on-line readable copy of the IRIX release notes. eoe1.man.unix This is an on-line copy of the IRIX user's manual. Entries may be viewed with the ``man'' command. 3.3.0.2 Execution_Only_Environment_Tape_2 eoe2.sw.NeWS This is the 4Sight window manager and is required by all workstations. This subsystem contains the ``standard'' NeWS fonts. Courier Icon Courier-Bold Iris Courier-BoldOblique Screen Courier-Oblique Screen-Bold Cursor Times-Bold Helvetica !Times-BoldItalic Helvetica-Bold Times-Italic Helvetica-BoldOblique Times-Roman Helvetica-Oblique type eoe2.sw.NeWSimg This is an image database for the 4Sight image demonstration programs. - 11 - eoe2.sw.X11 This is the run-time X11 windowing package. It is required to run X11 applications. This subsystem includes the following fonts that are required to run X, along with some terminal emulator fonts expected by xterm users: 6x10 cursor 6x12 Terminal 6x13 Terminal-Bold 8x13 Terminal-BoldNormal 8x13b TerminalNormal 9x15 eoe2.sw.Xdemos These are demonstration programs that make use of the X windowing system. You must install eoe2.sw.X11 in order for these programs to work. eoe2.sw.Xfonts These are a set of fonts which were shipped with X11 Release 2. They are no longer a part of X, but some older X programs require these fonts to be in place. apl German sup arrow Greek supsup chess Hebrew swd chp ipa sym cyr krivo vbee Cyrillic lat vctl dancer met vg fcor micro vgb fg mit vgbc fg-Bold oldera vgh fg-Oblique plunk vgi fgone rot vgvb fgone-Bold runlen vgl fgone-Oblique sansserif vmic fgs sansserif-Bold vply fqxb sansserif-Oblique vr fr serif vrb fr-Bold serifb vri fr-Oblique serifi vsg frone stan vsgn frone-Oblique stempl vshd frthree sub vxms frtwo subsub xif - 12 - eoe2.sw.demos This is the standard SGI demonstration package. It has been enhanced and expanded with this release and features a new menu driven front end called ``buttonfly''. Some programs may not image properly on machines with eight bit-planes or without a Z-buffer. eoe2.sw.envm This is the IRIX Workspace package, a user-friendly alternative to the standard IRIX command shell. eoe2.sw.gltools This subsystem contains a collection of simple tools that perform a variety of graphics related functions on a workstation. Complete source code for these tools is contained in the dev.sw.gifts subsystem described in the next section. These tools include: blanktime ipaste cedit istat clock loadmap dialwarp mag gamcal mousewarp gamma savemap ical scrsave icut showmap imgexp snapshot interp textcolors eoe2.sw.moredemos This is an extension of the eoe2.sw.demos subsytem and contains more demonstration programs. These programs are segregated here due to disk space requirements. eoe2.sw.moregltools This is an extension of the eoe2.sw.gltools subsystem and contains commands that implement simple image processing functions. The complete source to these commands is contained in the def.sw.gifts subsystem described in the next section. - 13 - eoe2.sw.optfonts These are additional fonts that are not required by the base system but may be desirable for some applications. Boston NewCenturySchoolbook-Bold Charter-Black NewCenturySchoolbook-BoldItalic Charter-BlackItalic NewCenturySchoolbook-Italic Charter-Italic NewCenturySchoolbook-Roman Charter-Roman Symbol Kanji eoe2.sw.sysadm This is a system administration package that does not require graphics and is intended for use primarily on server machines. eoe2.sw.vadmin This is a graphical interface to the standard IRIX administration utilities. It provides user-friendly tools for managing printers, users, disks, networks and other common administrative functions. eoe2.man.X11 This is an on-line version of the IRIX user's manual entries that describe the commands in the eoe2.sw.X11 subsystem. eoe2.man.demos This is an on-line version of the IRIX user's manual section 6, which describes the demonstration programs. 3.3.0.3 Development_Option dev.sw.G0libraries This subsystem contains versions of all of the standard programming libraries compiled with the -G 0 option. These versions of the libraries are generally not required. dev.sw.cc This subsystem is contains all of the standard IRIX commands and files for compiling and debugging C programs. - 14 - dev.sw.cedgetut This contains files that accompany documentation on how to use Edge the IRIX window-based debugger, when programming in C. dev.sw.crypt This subsystem contains the file libcrypt.a for use by programs that perform data encryption. dev.sw.debug This contains the IRIX kernel debugger and is useful only to those developing kernel device drivers. dev.sw.giftssrc This subsystem contains a multitude of sample programs in source code form including the source for all of the eoe2.sw.gltools and eoe2.sw.moregltools subsystems described in the previous section. While the installation of this subsystem is not required, many developers have found the example programs to be extremely useful in learning about the GL, TCP/IP, and Generic SCSI interfacing. dev.sw.rcs This contains the Revision Control System (RCS) which is a set of programs that may be used to control a source code development project. With RCS, changes to source files are kept in a database with comments such that previous versions of a particular file may be retrieved. dev.sw.sccs This contains the Source Code Control System which is identical in purpose although different in use to RCS described above. dev.man.cc This contains all of the programmer's reference manual in an on-line readable format. - 15 - 3.4 Subsystem_Sizes This is a list of all the subsystems and their sizes. Default Install indicates subsystems that are are installed by default when you install using automatic mode, or you select default. To install subsystems that are not installed by default, you must select them with manual installation features. ___________________________________________________________________ subsystem Personal IRIS 4D Data Power Default IRIS & Station Series Power Server ___________________________________________________________________ eoe1.sw.acct 896 896 896 896 no eoe1.sw.cdsio 50 50 50 50 yes eoe1.sw.crypt 52 52 52 52 yes eoe1.sw.dfm 1053 1053 1053 1053 yes eoe1.sw.editors 619 619 619 619 yes eoe1.sw.hyper 194 194 194 194 no eoe1.sw.ikc 36 36 36 36 yes eoe1.sw.ipc 214 214 214 214 yes eoe1.sw.lp 1386 1386 1386 1386 yes eoe1.sw.mast 0 312 0 0 yes eoe1.sw.perf 1090 1090 1090 1090 yes eoe1.sw.spell 867 867 867 867 no eoe1.sw.tcp 7601 7601 7601 7601 yes eoe1.sw.terminf 1637 1637 1637 1637 no eoe1.sw.ts 31 31 31 31 no eoe1.sw.unix 26894 23455 25612 24531 yes eoe1.sw.usrenv 990 990 990 990 yes eoe1.sw.uucp 2088 2088 2088 2088 no eoe1.sw.xm 67 67 67 67 no eoe1.man.relnotes 284 284 284 284 yes eoe1.man.unix 4003 4003 4003 4003 yes ___________________________________________________________________ TABLE 1. S4-EOE1-3.2 - 16 - _____________________________________________________________________ subsystem Personal IRIS 4D Data Power Default IRIS & Station Series Power Server _____________________________________________________________________ eoe2.sw.NeWS 12791 11911 11493 11493 yes eoe2.sw.NeWSimg 12879 12879 12879 12879 no eoe2.sw.X11 17628 17628 17628 17628 no eoe2.sw.Xdemos 2143 2143 2143 2143 no eoe2.sw.Xfonts 3072 3072 3072 3072 no eoe2.sw.demos 4047 4569 2013 2013 yes eoe2.sw.envm 6828 6828 6828 6828 yes eoe2.sw.gltools 1048 3144 0 0 yes eoe2.sw.moredemos 4981 4733 4378 4378 no eoe2.sw.moregltools 2718 7778 188 188 no eoe2.sw.optfonts 4617 4617 4617 4617 no eoe2.sw.sysadm 533 533 533 533 yes eoe2.sw.vadmin 7875 7875 7875 7875 yes eoe2.man.X11 663 663 663 663 no eoe2.man.demos 378 378 378 378 yes _____________________________________________________________________ TABLE 2. S4-EOE2-3.2 ____________________________________________________________________ subsystem Personal IRIS 4D Data Power Default IRIS & Station Series Power Server ____________________________________________________________________ dev.sw.G0libraries 15097 13692 15097 15097 no dev.sw.cc 19308 17452 19222 19222 yes dev.sw.cedgetut 16 16 16 16 no dev.sw.crypt 32 32 32 32 yes dev.sw.debug 848 556 848 556 no dev.sw.giftssrc 4486 4486 4486 4486 no dev.sw.rcs 1846 1846 1846 1846 no dev.sw.sccs 1496 1496 1496 1496 no dev.man.cc 3121 3121 3121 3121 yes ____________________________________________________________________ TABLE 3. S5-DV01-3.2 >>>>>>>>>> 3.2 Release notes, Chapter 4 >>>>>>>>>> - 1 - 4. Additions This chapter describes additions to IRIX, the Graphics Library, 4Sight, and networking in the 4D1-3.2 software release. Also, it describes a new command for reading these release notes on-line. 4.1 On-Line_Release_Notes Release notes have been added to the on-line documentation. When you install the on-line documentation for a product, you will be able to view the release notes on your screen as you would an on-line manual page. However, unlike the on- line manual pages, the printed hard copy of these release notes is more up to date than the on-line version. The relnotes command accepts the following argments: -h describes how to use relnotes -p product displays the chapters or chapter numbers for a given product -c chapter displays a given chapter To see a description of how to use the on-line release notes tool, type: relnotes -h To see which product have on-line release notes installed, type: relnotes To see which chapters of a product are installed, enter the command below, but replace the word product with a product name generated when you type the previous command. renotes -p product To see a specific chapter of product, replace the words product and chapter in the next command: relnotes -p product -c chapter To page through a chapter, press and to quit, press or . See relnotes(1) for more information. 4.2 Additions_to_IRIX The 4D1-3.2 software release provides these additions to the IRIX operating system. o The IRIS-4D Series Owner's Guide and these release notes document a new way to back up and restore your system. This new system supports incremental backup and - 2 - recovery across multiple tapes. o pmake(1) and smake(1) are enhanced versions of make that create targets in parallel. o As of the system software release 4D1-3.2, on the Personal IRIS computers, the SCSI disk driver attempts to negotiate synchronous SCSI mode with the drive when it is opened. When supported by the drive, this results in greater disk throughput, and better SCSI bus utilization when multiple devices are attached to the SCSI bus. If problems occur because of this (due to use of unsupported drives that don't properly handle this negotiation), you may disable this negotiation by changing the scsi_syncenable variable in the file /usr/sysgen/master.d/scsi as described by the comments in that file, and linking a new kernel with lboot(7M). Of currently supported drives, the Imprimis 94171 (Wren IV 344 MB), 94221 (Wren V 190 MB half high), and 94191 (Wren VI 760 MB) drives all support synchronous mode. The Toshiba MK156FB (156 MB) and Imprimis 94161 (Wren III 155 MB) do not support synchronous mode, but do handle the negotiation correctly. o IRIX now has the capability to force a user process to run only on a particular CPU on a Power Series multiprocessor system. This facility is provided at the IRIX command level by the new command runon, which can be used as a prefix to a command at the shell level. For example, you can run vi on CPU 1 by using the following command: runon 1 vi myfile This facility is also available as a system call from within a user program: #include main() { int cpunumber = 1; sysmp(MP_MUSTRUN, cpunumber); /* * At this point, this process will run only on * cpu 1 except when it needs to run on another * cpu to access hardware that only exists on * the other cpu. */ /* * To revert to normal behavior (the process runs - 3 - * on whatever cpu is available), make the following * call: */ sysmp(MP_RUNANYWHERE,); ... } Refer to the manual pages runon(1) and sysmp(2) for further information. 4.2.1 System_Configuration_Files The 4D1-3.2 software release contains some enhancements to /etc/passwd. When you install your new software, a file called /etc/passwd.N is installed. Use diff to compare the two files. Then use a text editor, such as vi, to edit /etc/passwd.N to include the pertinent login/password information so users can login. Rename /etc/passwd.N to /etc/passwd. See Section 2.4, ``Finishing Up the Installation'', for more information about dealing with ``.N'' and ``.O'' files. 4.3 Additions_to_Documentation o Administrator's Guide for Diskless Workstations explains how to be the system administrator for one or more IRIS-4D/20 diskless workstations. It includes instructions for setting up a server for diskless workstations, common changes to the diskless tree, and configuring a disk upgrade. o STREAMS Primer and STREAMS Programmer's Guides provide comprehensive reference documentation for using STREAMS. The primer provides a high level, technical overview of STREAMS. The programmer's guide contains information on the use of the STREAMS mechanism at user and kernel levels. o Modeling on the IRIS-4D accompanies the Graphics Library Programming Guide and contains color plates that illustrate some of the features and capabilities of the IRIS-4D for 3-D modeling. o Silicon Graphics Server Owner's Guide is the new owner's guide for all Silicon Graphics servers. It explains how to set up the server, back up and restore data, recover from a system crash, maintain hardware and software, and perform the first few administrative tasks. This information used to be combined with information on Silicon Graphics workstations, in the IRIS-4D Series Owner's Guide. With the new server guide, you no longer need to sort through material intended for workstations. - 4 - 4.4 Additions_to_Demos Several demos, which used to be shipped with the GT, have been added for Personal IRIS and Power Series (GTX) systems: _______________________________________________________________ buttonfly 3D graphical interface to other demos solidview display and interact with finite element data lathe interactive simulation of a lathe flip interactive rotation of lit objects (replaces spin) boing a ``rubber planets'' simulation New demos for the Personal IRIS, GT, and GTX: ______________________________________________________ Demo Description ______________________________________________________ flyray an interactive ray-tracer logo watch a Silicon Graphics logo being grown newton enhanced version of jello (more polyhedra) gview display the results of radiosity calculations Demos installed on the Personal IRIS only: _____________________________________ house interactively display a house Demos installed on GT and Power Series only (need alpha bitplanes): ___________________________________________________________ Demo Description ___________________________________________________________ mir mirrored objects using z- and alpha-buffer tricks shadows objects casting shadows on each other 4.5 Additions_to_Networking The 4D1-3.2 release provides these additions to networking: o On Power Series multiprocessor systems, the processor which receives network interrupts can be reassigned. - 5 - The variable network_processor in the file /usr/sysgen/master.d/kernel defines this processor. Processor numbering begins at 0. On multiprocessor systems, the default is to use processor 1. To reassign the network processor, change this value and use lboot(1M) to create a new kernel. On single processor systems, the default value of 0 must not be changed. The specified processor receives all interrupt levels which are generated by networking devices, including all Ethernet and HyperNET VME boards. Currently, this is only IRQ4. If any unsupported VME boards which generate IRQ4 are installed in a multiprocessor system, the network processor should be reassigned to 0 to insure compatibility with the software driver. 4.6 Additions_to_the_Graphics_Library 4.6.1 NURBS With the IRIX 3.2 software release comes a major new GL feature: direct rendering of Trimmed Non-Uniform Rational B-Spline Surfaces. This new feature is offered through a combination of software, firmware, and hardware on all IRIS-4D platforms. NURBS surfaces and trimming curves of up to 8th order are supported (except for the Personal IRIS which supports up to 4th order surfaces). Tessellation of trimmed NURBS surfaces is based not only of the shape and the view, but also on a user-settable parameter which controls the size of polygons generated. This gives a smooth speed/quality tradeoff that the user may adjust adaptively. Routines supporting this new feature may be used in both immedate mode and display-list mode. This interface is compliant with the PHIGS+ specification. The new routines are: bgnsurface bgntrim endsurface endtrim getnurbsproperty setnurbsproperty nurbscurve nurbssurface pwlcurve See the Graphics Library Programmer's Guide for more information. - 6 - 4.6.2 Rendering o colorf is a new GL routine to specify fractional colorindex values using floating point arguments. Use it to draw shaded colorindex images. o logicop (only on the Personal IRIS with RE2) is a new GL routine to specify logical operations to be performed on pixels drawn by graphic primitives. 4.6.3 Anti-Aliasing Release 4D1-3.2 expands drawing of antialiased primitives and includes the new feature of subpixel positioning for point, line and polygon vertices. Certain capabilities may not exist on all hardware configurations (see manual pages for details). o pntsmooth is a new GL routine to cause all points to be drawn with antialiasing. o linesmooth allows you to set antialiasing of lines on or off. New development should use linesmooth instead of smoothline. o subpixel is a new GL routine to invoke subpixel positioning of all lines and points, typically used with linesmooth and pntsmooth for highest quality of line and point drawing. 4.6.4 Lighting lmcolor (Personal IRIS and GT) provides a quick way to change the properties of the current material. 4.6.5 Event_Queue There is a new device, called QFULL. When it is queued, a QFULL event will be inserted in the event queue of a GL program at the point at which a queue overflow occurred. The QFULL event will be returned by qread(3G) at the point in the input queue at which data was lost. 4.6.6 Menus o setpup is a new routine that allows you to affect the display characteristics of a pop up menu. It allows you to grey out entries that you don't want to be active, then later re-enable them without recreating the whole menu. o defpup and addtopup calls now understand a %l option for an entry. It will place a seperating line between entries in the menu. - 7 - 4.6.7 Windows swinopen is a new GL routine which creates a subwindow, or a window within another window (called the parent of the subwindow). Subwindows maintain a fixed geometrical relationship with their parent window, that is, the subwindow moves as the parent window is moved. 4.6.8 Graphics_Peripherals o videocmd is a new GL routine which initiates command transfers to video peripherals. Use this to initialize and request frame transfers from the Live Video Digitizer option board on the GTX o IRISphere devices have been added to o STR_RECT is a sybol definded for use in setmonitor/getmonitor to support StereoGraphics stereo hardware. This new video mode allows 1280x492x2 resolution. 4.6.9 Configuration/Compatibiltiy o getgdesc is a new GL routine that allows a program to inquire about characteristics of the graphics system upon which it is running. Use this to configure your software at run time based upon the capabilities of the current graphics system. o glcompat: A new compatibility mode has been added: GLC_ZRANGEMAP. It controls whether the domain of the z-range arguments to lsetdepth, lRGBrange, and lshaderange is graphics system dependent or independent. o gversion now recognizes the RE2 and Turbo Graphics on the Personal IRIS. >>>>>>>>>> 3.2 Release notes, Chapter 5 >>>>>>>>>> - 1 - 5. Changes This chapter describes changes to IRIX, graphics, networking, 4Sight, and Program Development tools in system software release 4D1-3.2. 5.1 Changes_to_IRIX The 4D1-3.2 release includes these changes to IRIX: o The sysadm versions of backup and restore are no longer supported. These utilities have been replaced with new tools, which are documented in Appendix A, ``Backing Up and Restoring Your System'' and Appendix B, ``Recovering From a System Crash'' o The beer backup utility is no longer supported. o Printer device support has been modified for software release 4D1-3.2 to comply more closely with System V rules for printer drivers. Some of the lp commands now have different pathnames and might have additional options. When you update to software release 4D1-3.2, remove your old printer definitions. Then re-install the printer definitions using the Printer Administration tool, which is included with the System Manager. See the IRIS-4D System Administrator's Guide for more information about using the System Manager. Old printers will still work even if you don't perform this procedure. However, administering printer definitions in the future will be more difficult. o snapshot(6D), a tool to save a portion of the screen in an image file, replaces snap(1G). snapshot is much easier to use. o Several changes have been made to the libmalloc routines that are available when a program is linked with the -lmalloc or -lmpc (the multiprocessing library) directives. Two options have been added to the mallopt(3X) routine, which allows user control of malloc's allocation algorithm. When malloc(3X) requires additional space it uses the sbrk(2) system call. It always requests enough memory for the current malloc request rounded up to a minimum block size: that size can now be specified via an M_BLKSZ argument to mallopt. - 2 - Additionally, malloc will now abort its search for a free block of memory and call sbrk(2) for memory to satisfy a request after it has searched 100 blocks to no avail. The number of blocks to search can be changed by calling mallopt to change the M_MXCHK parameter. Along with the above change, various algorithmic changes were made to reduce fragmentation and to speed up memory coalesing when memory is returned via free(3X). The changes now ensure that memory allocated to the user will always be (minimally) double-word aligned. o The Extent File System code in IRIX has been enhanced in software release 4D1-3.2 to support files bigger than 256 megabytes. In the new software, files are limited by the size of the disk (the largest Silicon Graphics currently ships has 1.2 Gbytes unformatted capacity) and the fact that offsets into the file are represented by 32-bit integers. The 32-bit limitation puts the ceiling at 2 Gbytes. o The IRIX kernel has been enhanced to allow pages of page table entries and user structures in the kernel to be pageable. This means fewer pages are wired down by the kernel, so that in situations where the system is short on physical memory, more memory is available to hold user program text and data. o The graphical system monitor, gr_osview(1), has been significantly enhanced. It provides additional information, much more flexible display modes (including strip charts) and is configurable from a command file to make the greater flexibility easy to use. Refer to the gr_osview(1) manual entry for a ---------- end of Part 1   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03650; 19 Nov 89 15:32 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id ac03560; 19 Nov 89 15:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab03479; 19 Nov 89 14:59 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25969; 19 Nov 89 14:51 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AB00195; Sun, 19 Nov 89 11:35:17 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Nov 89 18:39:47 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: IRIX 3.2 Release Notes (Part 2 of 3) Message-Id: <44983@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL -------------------- cut here ------------------- detailed description the new features. o The IRIX emulation library for the Sequent parallel programming primitives (m_fork et al.). has been expanded to include the m_park_procs, m_rele_procs, and m_sync primitives. These allow the master process to suspend all the parallel child processes during long sections that are single threaded and then resume them before entering a parallel session. After calling m_park_procs, the child processes will no longer be scheduled and so will not consume any processing time until m_rele_procs is called by the master process. Refer to the m_fork(3P) manual entry for more information. - 3 - 5.2 Changes_to_Documentation o IRIS-4D System Administrator's Guide has been completely revised for this release. It explains how to use advanced IRIX utilities and other standalone programs to keep an IRIS-4D Series workstation or server running smoothly. It contains theory of operation, background information, and step-by-step procedures that supplement the newly revised IRIS-4D and server owner's guides. o The Graphics Library User's Guide and the GT Graphics Library User's Guide have been combined into a single volume for the IRIS-4D series workstations. The combined volume is titled the Graphics Library Programming Guide and contains information for writing GL programs for all IRIS-4D series workstations. 5.3 Changes_to_Graphics 5.3.1 The_Default_Color_Map The default color map, which is loaded by 4Sight, has changed for this software release. The color map is a system wide resource, which allows the mapping of an arbitrary color index pixel to any desired combination of red, green, and blue. There is only one color map per system. Therefore, all color index programs that are running at the same time share the same color map. The first 256 entries of the color map have been re-designed using an abstract color model such that: o multiple programs can aesthetically coexist on the screen o double-buffered applications look good on minimal systems o programs written to the X Window System standard can use the color map Because the colormap is shared, a program that rewrites entries in the colormap will potentially affect other programs in a multi-window environment. This is especially true on minimal configuration systems where the only entries in the map are the bottom 256. The previous colormap arrangement did not provide a structure and methodology to avoid this; the new one does. - 4 - With this color map, application programs can specify colors as if running on a full color system; library routines take care of mapping requested colors to the nearest available color. The abstract color model does a good job of matching desired colors. However, the model breaks down if a program manipulates the color map. Many programs that appear to need to manipulate the color map can be changed to redraw the image using new colors instead. This doesn't work for programs that depend on colormap animation, where the colormap manipulations are only a part of the image rendering concept, or if the color indexies are used by the hardware, as for depth queueing. An example of this is when ramps are used for shaded polygons or depth-queued lines. A minimally-configured Personal Iris has only 8 color bit planes, which means that a double buffered program running on these machines has only four bits per buffer. Four bits means only sixteen colors, which are the first sixteen colors in the colormap. Both maps have the first eight colors as defined by the GL. Following those colors in the pre 4D1-3.2 color map was a grey ramp running from dark to light. This severely limited the colors options available to double buffered applications on a minimal system, since only the first 16 were available. The usable greys were all very dark and looked out of place when used with the primary and secondary colors the GL defines. The 4D1-3.2 color map organization has some pastels in the second eight color slots. These mix nicely with the first eight primary an secondary colors. By dithering out of the first 16 colors you can achieve a fairly wide spread of both hue and saturation. Dithering in the pre 4D1-3.2 color map produces mainly dark muddy tones, not generally considered satisfying. X clients are traditionally black and white, or use a minimal notion of color. Some newer, more ambitious, X clients really want and use many more colors; some even use 24-bit style colors. The new color map organization doesn't help the more greedy X client but it does set aside 16 colors for the X server to manage. These colors are conveniently located on a power of two, and are expected to meet most X clients demands. - 5 - If you run X these 16 colors are reserved for the X server and are not directly available to users. If you never use or run X, you can freely do what you want with them. The library /usr/lib/libgutil.a contains the routines to map full color requested to color map indicies. abstract color model. The routines come in two flavors, those with floating point arguments between 0 and 1, and those with integer arguments between 0 and 255. Use whichever is most natural. ci = rgb(r,g,b); /* set and return a color index * approximating the given r,g,b */ ci = rgbi(ri,gi,bi); ci = hsv(h,s,v); /* set and return a color index * approximating the given h,s,v */ ci = hsvi(hi,si,si); ci = grey(shade); /* set and return a color index * approximating the given shade * of grey */ ci = greyi(shadei); Each routine figures out what index is the closest to the color requested, sets that as the current color, and returns the index it found. A few simple operations, based on some tables, give the returned value. Programs that do not fit into the abstract color map scheme typically need large ramps. In the colorful part of the map, 140 contiguous entries go unused by the default window manager and most standard tools. Thus an ``antisocial'' application program can freely write numerous entries and only destroy the appearance of other applications, not the window system itself. This range of colors starts just after the grey ramp at color index 56 and continues through color index 195. The window system uses color indicies 196-255. Some standard tools like cedit use a few colors from the middle of this range, but only in small areas so remapping is likely to leave them intelligible. 5.3.2 Changes_to_4Sight o wsh(1G) now provides a text selection facility that allows text to be transferred from the display of one wsh window and sent as input to any other wsh window. It also has an improved scroll bar with a proportional thumb. - 6 - o The Window Manager has improved aesthetics and controls, and better support for multi-windowed applications. The window borders have been changed to accommodate strectch controls at each corner of the window. The window borders and toolchests have also been given a rounded appearance matching the aesthetics of the WorkSpace and Visual Administration tools. Stowed windows (icons) are now arranged in neat rows instead of randomly across the screen. Enhanced versions of the preference features previously found in the 4DGifts have been incorporated into the window manager. These features provide automatic placement and sizing of windows for any application and allow for windows of the same type to be neatly stacked. For example, all wsh windows can be neatly stacked up. A Close entry has been added to the menu together with a corresponding border control. This entry is designed for multi-windowed applications. Close closes the window and, if notification is enabled, notifies the client. If the window being closed is the last window of the application, Close becomes equivalent to the existing Quit entry which closes the window and kills the application. All these new features are described in the 4Sight Programmer's Guide. 5.3.3 Changes to the Graphics Library and Distributed Graphics Library o The GL viewport routine allows application programs to use a viewport that is _32K in both X and Y while in feedback mode. The viewport is limited to -XSCREENMAX to 2*XSCREENMAX in X and -YSCREENMAX to 2*YSCREENMAX in Y while not in feedback mode. o The smoothline routine now is obsolete and has been replaced with a functionally equivalent routine called linesmooth. o The lsetdepth routine replaces setdepth, which is now obsolete. The depth range now defaults to the entire range supported by the hardware on which the program is running. The limits of the depth range are returned by the getgdesc routine. - 7 - o The lshaderange routine replaces shaderange, which is now obsolete. The depth range of the default shade range is now the entire range supported by the hardware on which the program is running. o The lRGBrange routine replaces RGBrange, which is now obsolete. o The getdepth routine is now obsolete. It is not guaranteed to return correct values if lsetdepth is used to set the depth range; only works correctly when setdepth is used viewport in feedback mode allows range supported by feedback datatype. o Documentation that was previously released indicated that blending was available only if 2 bitplanes were installed. This has been corrected. o GT/GTX now correctly depthqueues when the depth range is reversed (Znear > Zfar). The other models still fail. o The size of the graphics input event queue has been increased from 51 elements to 101 elements. o zfunction now works across the entire IRIS-4D product line. 5.3.4 Changes_to_the_Distributed_Graphics_Library The changes to the Distributed Graphics Library are the same as the changes to the Graphics Library with these additions: o The arguments to winmove and winposition arguments have been changed from shorts to longs. Although this does not affect GL programs, it will break DGL programs that call these routines. Such DGL programs linked with a pre-4D1-3.2 libdgl.a will not work with 4D1-3.2 DGL servers, and DGL programs linked with a 4D1-3.2 libdgl.a will not work with pre-4D1-3.2 DGL servers. o The environment variables DISPLAY and NEWSSERVER are no longer used for determining the default DGL server. The environment variable DGLSERVER is now used instead. The "decimal_address.port" host format, typically used along with NEWSSERVER, is no longer accepted. o dglopen can now return ESRCH (no such process) if the window manager is not running on the server. - 8 - o The protocol for popup callback functions ("%f") has been changed to allow callback functions to call other DGL routines. Any old DGL programs that used callbacks will not work with the new DGL server and new DGL programs will not work with the old DGL server. The incompatibility arises only when the callback occurs, not when the program is run. 5.3.5 Changes_to_4Dgifts This section contains information about a wealth of source code examples, which you receive as ``gifts'' from Silicon Graphics, Inc. These gifts are not installed or updated by default. To use them, you must first install them using inst(1M). For information about using inst and the manual installation features, see Chapter 2, ``Software Installation'' or the IRIS-4D System Administrator's Guide. Once installed, you find these source code examples in a sample user account directory called /usr/people/4Dgifts. 4Dgifts is set up as a sample user account for two reasons: o to allow you to learn by example o to allow you to be productive while you are becoming familiar with the NeWS environment and the ability to customize that environment with PostScript You should find a README file in virtually every directory in and including 4Dgifts. Much of what is discussed below is covered in greater detail in the README files. Read the file /usr/people/4Dgifts/README to gain a more complete understanding of the remainder of this section. 5.3.5.0.1 Disclaimer This reinstatement of a source code repository is a major coup for people that use Silicon Graphics Inc., systems. Although there is a disclaimer in the file /usr/people/4Dgifts/README file, which states ``It is essential to understand that these gifts are unsupported by Silicon Graphics Inc., the fact is we continue to receive many requests, suggestions, etc for these gifts. - 9 - We welcome any and all such input. However, we are the final arbiters as to what additions or changes will be implemented. The main subdirectories in 4Dgifts are: examples kermit and iristools The examples directory contains various subdirectories housing an assortment of code examples: Fortran graphics programs written in Fortran devices digitizer and dial and button box programs, as well as a program that uses the /dev/scsi generic SCSI driver. fontmanger includes sample programs demonstrating usage of the fontmanager library, libfm.a grafix various C graphics programs. hllapi ibm-link for the SGI 3270 emulation package. light on-line versions of the lighting programs discussed in chapter 9 of the Graphics Library Programming Guide. nurbs contains 4 nurbs sample programs: one written in C, one for the DGL, on in Fortran, and one in Pascal. tcp contains programs that communicate with remote systems such as the IRIS and 4.3BSD computers. trackball contains 4 components of code for a Virtual Trackball Implementation: routines to calculate the virtual trackball, event-queue handling, drive a user-interface, and a simple program to use the other 3. unix contains fundamental examples of system programming. video contains programs demonstrating usage of various video modes. - 10 - The kermit directory holds the public domain source and documentation for kermit, a file transfer protocol that is useful when you need to send files to and from an IRIS/UNIX computer and non-unix configurations like VMS or DOS based machines. The iristools directory contains a super-set of special image libraries, image processing utilities, and graphics tools that used to exist, in the 3000 family-line of computers, under /usr/people/gifts/mextools. This source was used to build the binaries that now reside in /usr/sbin (i.e., cedit, showmap, ipaste, mag, etc.). In other words, every executable in /usr/sbin with a source file under iristools was built from that exact source (including the two libraries libgutil.a and libimage.a under iristools). Beyond this, the directory /usr/people/4Dgifts is setup to work as a sample NeWS user login account replete with many template .ps files to help you understand the extent to which you can customize NeWS environment. Along with a more substantial user.ps, file there is a startup.ps file, as well as a subdirectory /usr/people/4Dgifts/.4sight. This directory contains nine additional startup.ps files that show you how to create your own user-defined icons, window colors, menu fonts, etc.. These files have comments throughout them to help describe what they do. There are many ways you can change and alter all of the possible startup variables. 5.3.5.1 Special_Gifts ./iristools/imgtools/snapshot.c This program allows you to interactively grab part or all of of an image on the screen and dump it into an image file. It is the next generation of icut. By default, it is loaded in /usr/sbin as a gltool. See snapshot(6D). This image file can then be put back up on the screen with ipaste(1G), or sent to a supported printers with lp(1). ./{.workspace/*, README.wspace} There is an initial setup for a version of workspace with 4Dgifts that resides in the directory .workspace. The file README.wspace describes more of what is currently included. ./examples/grafix/{zrgb.c, zrgbmenu.c, zcmapmenu.c} ./examples/Fortran/{zrgb.f, zrgbmenu.f, zcmapmenu.f} - 11 - These programs demonstrate aspects of zbuffering in various implementations. Of particular note are the zcmapmenu versions which include a powerful example in the main infinite loop of how to write code that does NOT eat up extra CPU cycles (provided one does not need the animation to continue when the input focus is elsewhere) ./examples/devices/{iisc.c, inquire.c} Two programs that use the the /dev/scsi generic SCSI driver. Be sure to also consult the README file in this directory. 5.3.5.2 Installing_the_Gifts To install the 4Dgifts, login as root, type inst, and follow the instructions on your screen. Refer to Chapter 2, ``Installing Software'' for a detail discussion of inst. Choose the manual installation features, and explicitly select this subsystem dev.sw.giftssrc. Once you have specified that you wish to use the manual installation features, type: select from the "Manual>" menu and enter yes dev.sw.giftssrc Now 4Dgifts will be included when you run the install menu item. The size of this account (uncompiled) is approximately 4095 blocks or about 2.17 MBytes. 5.3.5.3 Setting_Up_4Dgifts_as_a_User_Login_Account Upon successful completion of loading the dev.sw.giftssrc subsystem from the Development tape (see below) you need to perform one more modification in order to set up /usr/people/4Dgifts as its own account: 1. Login as root. 2. Edit the file /etc/passwd. Duplicate the ``guest'' passwd line. Change every occurrence of the word ``guest'' on this duplicate line to be ``4Dgifts'' instead. 3. Write the changes and exit the editor. 4. Now logout of the console screen entirely and login as 4Dgifts. You will see things startup in a different way than they do for guest root or any of the other "default" login accounts. The intent here is that you copy - 12 - ~4Dgifts/{.4sight, user.ps, startup.ps} into you own home directory and play with changing whatever parts you wish to make it place and define things more in the way you prefer. 5.3.6 Changes_to_Demos The directory structure of /usr/demos has been re-organized. All demo executables have been moved from /usr/demos into /usr/demos/bin, and all data used by the demos has been moved into /usr/demos/data. Several old demos have been dropped from distribution, including revolution, jet, demomakemap, superbreak and spin. Buttonfly(6D) is a fancy interface to the demos, and is new with the IRIX 3.2 release. Running /usr/demos/buttonfly is the easiest way to run the demos. For Workspace users, the directories /usr/demos/applications, /usr/demos/cpu, /usr/demos/graphics, /usr/demos/image, and /usr/demos/old have scripts inside them to run the demos with appropriate data. All of the demos have manual pages, which can be seen using either the standard man command, or through buttonfly's popup menus. All of the demos now have information slides, which give you a brief description of what the demo is doing. These can be accessed through buttonfly's popup menus or from the Workspace. 5.3.7 Changes_to_the_NeWS_Gifts The NeWS gifts are now under /usr/NeWS/clientsrc, and you can compiled them yourself. - 13 - 5.4 Changes_to_Networking The 4D1-3.2 software release includes these changes to networking: o An improved multiprocessor implementation of System V STREAMS allows the use of all serial ports on Power Series systems. For information on how to utilize the additional ports, see ``Attaching a Terminal, Modem, or Dumb Printer'' in the IRIS-4D System Administrator's Guide, duart(7), and inittab(4). Developers note that all STREAMS drivers must obey the conventions for maintaining mutual exclusion on multiprocessor systems. These conventions are discussed in Appendix F, ``STREAMS on the IRIS-4D'' of the STREAMS Programmer's Guide. o System V STREAMS queue and stream structures are now allocated dynamically. The static allocations have been removed from the kernel master file. o For security, a user's .rhost file must be owned by the user or by root and must be writable by only the owner or root. Use the command: chmod go-w $HOME/.rhost to prevent others from writing to the file. $HOME is the pathname of the user's home directory. o rshd(1M) now logs unsuccessful accesses to syslog(1M). The new -L option allows you to log successful accesses, too. To enable -L, append it to the rshd entry in /usr/etc/inetd.conf. See rshd(1M) in the IRIX System Administrator's Reference Manual for more information. o The following daemons now look for .options files in /etc/config: named(1M) rpc.passwd(1M) to allow customers to specify different startup options. See network(1M) and the daemons' manual pages for details. - 14 - o For proper system startup, all network interfaces on the IRIS must have a valid address-hostname entry in /etc/hosts. ifconfig(1M) converts a hostname into an Internet address by looking in /etc/hosts only. It does not use named(1M) or Yellow Pages. 5.5 Changes_to_Program_Development_Tools The C runtime startup routine now returns (to the environment) the value returned from the C main function. Release 4D1-3.1 returned zero to the environment regardless what value was returned from the main function. It is essential that every program call exit or return a meaningful value from its main function. If a meaningful value is not returned, a garbage value is returned to the environment. This change was made to conform to the proposed ANSI C standard. 5.5.1 Changes_to_dbx A great deal of information was added to the dbx man page and help file /usr/lib/dbx.help. The information in them might be helpful to you/ The tags command was added to dbx. It uses ctags(1) data. It is like the func command except that tags can find C macros (those with arguments) as well as functions. The ccall command was added. It (as well as expression evaluation) allows interactive calls to functions in the program being debugged. In this release only constant arguments may be supplied to the function being called. By default, anonymous blocks (in C {} delimited compound statements) in functions are now not shown on stack traces. Set the dbx variable $hide_anonymous_blocks to 0 to show all internal blocks. The syscall command was added to allow breakpointing your program on entry-to or return-from any system call. To intercept a call to exit(2), enter the command syscall catch call exit. See the man page for further details. The hed command can be used to edit the dbx history file with your favorite editor. Commands left in the edit session when you exit the editor are automatically submitted to dbx immediately. C casts to pointers and integral types can now be used in expressions. See the EXPRESSIONS and HINTS sections of /usr/lib/dbx.help for further information. - 15 - A number of new commands and command-clauses relating to debugging multiple-process applications and multiple- processor applications are available. See the man page sections on ``Multiple process debugging'' and ``Process Group Debugging Facilities''. The $promptonfork debugger variable now controls a more flexible and usable facility. If 0, then when a program forks or sprocs neither it nor the child stops (that is, the fork is essentially invisible). If 2 then the child is added to the process list automatically and both parent and child stop. If 1 then you are asked whether to add the child to the process list; the parent is left stopped and the child is left stopped (is ignored and runs) if you answered y (n). 5.6 Changes_Affecting_the_Tablet_and_Dial_and_Button_Box Starting in software release 4D1-3.2, the tablet device and dial+buttons device will no longer be pointed to by the devices /dev/tablet and /dev/dials. We have removed these dependencies and the device links themselves in order to standardize the queue interface for alternate input devices. Basically, all I/O to these devices should go through the daemons associated with those devices. The daemons alone will have the knowledge of what physical port input devices are connected to and hardware command sequences associated with those devices. >>>>>>>>>> 3.2 Release notes, Chapter 6 >>>>>>>>>> - 1 - 6. Bug_Fixes This chapter describes bug fixes to 4Sight, IRIX, and program development tools. A Silicon Graphics software change request (``SCR'') number appears after many of the bug fixes in this chapter. 6.1 Bug_Fixes_to_IRIX o If more than the maximum number of concurrent at(1) jobs were simultaneously submitted, previous versions of the software queued the excess jobs, but failed to start them after the running at(1) jobs completed. (SCR 5564) o When cron(1M) was killed and restarted in previous releases of IRIX, it would forget about any at(1) jobs that were submitted to the previous incarnation of cron(1M), but were still in the future. This no longer happens. (SCR 6865) o If a process that takes a long time to complete is started with at(1) and then killed prematurely, cron(1M) dies. This is fixed. (SCR 6910) o The line printer spooler model interface scripts supplied in /usr/spool/lp/model work properly with the Yellow Pages as of Release 3.2. (SCR 3832) o In previous releases, the system initialization scripts would generate an error message every time the system was booted if the line printer spooler was not installed. This no longer happens in Release 3.2. (SCR 4430) o Manual entries which require preprocessing by eqn(1) now received that treatment in Release 4D1-3.2, so some on-line manual entries (e.g. eqnchar(5)) look better than in previous releases. (SCR 5031) o Some inconsistencies in the disk statistics reported by the -d option of sar(1) have been corrected in Release 3.2. (SCR 5465) o The mount(1M) command now has a -h option that works analogously to umount -h. Refer to the mount(1M) manual entry for more information. (SCR 5591) o Some formatting problems in the signal(2) manual entry have been corrected. (SCR 5738) - 2 - o The mt status command now shows when the tape in the drive is write protected when that information is available from the drive. (SCR 5766) o The ps(1) manual entry now documents the page size in the description of the SZ and RSS fields output by ps -l. (SCR 5769) o The manual entries uname(1) and uname(2) now correctly describe the format of version and release number fields. (SCR 5777) o If any process has a modem-control port (tty[mf]*) open on a CDSIO 6-port board and if DCD is false on that port, then no port on the entire board gets any output interrupts. This is fixed in Release 4D1-3.2. (SCR 5844) o There is now a manual entry for flock(3B). (SCR 5864) o In previous releases, the system kernel configuration program lboot(1M) assumed that all controllers were numbered within their type starting at zero. That is, the first controller of a particular type would be numbered 0, the second would be numbered 1 and so forth. If the system configuration files specified, for example, a single controller of a particular type with controller number 1, then lboot(1M) would create a kernel that would not work properly. This has been remedied in Release 3.2. (SCR 5866) o The man(1) command now allows the user to specify an alternate paging program through the PAGER environment variable. (SCR 5883) o When running four copies of the same graphics program on a four CPU system in Release 3.1, the scheduler does not give fair service to the four processes. At any given time, one of them gets scheduled much less often than the other three. This has been fixed in Release 3.2. (SCR 5911) o The select(2) system call can now be used on pipes and all character devices, in addition to sockets and streams devices. (SCR 5421) o The system ID returned by the sysinfo program is 64 bytes long. Many people have requested a shorter ID. In Release 4D1-3.2 there is a new option to sysinfo(1), -s, which provides a 32-bit ID number that can be used to identify a particular machine. This new short ID is - 3 - also returned by a new library routine sysid(3C). (SCRs 4593, 5917) o In previous releases, the file system checker fsck(1M) required a temporary file when checking a file system greater than 500 megabytes in size. It prompted the user for the file name to be used. This caused problems during software installations, since fsck(1M) was being executed with standard input and output redirected to /dev/null. In Release 4D1-3.2, fsck(1M) no longer requires the use of a temporary file under any circumstances. (SCR 5921) o Release 4D1-3.1 PowerSeries and PowerStation machines (multiprocessors) could get the system panic "out of action blocks" under certain heavy load conditions. This no longer occurs in Release 3.2. (SCR 5927) o The EFS file system code in previous releases does not correctly handle file systems in which each cylinder group contains more than 32767 blocks. This has been fixed. (SCR 5968) o The hinv(1) command, which lists the hardware present on a machine, did not correctly report the controller and unit numbers for SCSI floppy disk drives. This is fixed. (SCR 5979) o The hinv(1) command correctly reports the presence of the CG2 and CG3 Genlock boards in Release 3.2. (SCR 6014) o The sysmips(2) manual entry has been changed to document the MIPS_FPSIGINTR call, which allows a program to get a SIGFPE signal whenever a floating point exception occurs. (SCR 6016) o The libraries /usr/lib/libsun.a and /usr/lib/libbsd.a have been changed in Release 3.2 to require a good deal less data space. This means that programs linked to these libraries will have smaller data segments in Release 3.2. (SCR 6199) o Some formatting problems in the output of sar(1) have been corrected in this release. (SCRs 6258, 6273) o The values of the constants FLT_MAX and FLT_MIN in /usr/include/limits.h are correct in this release. (SCR 6268) - 4 - o In Release 4D1-3.1, csh(1) filename completion does not look right on VT100 compatible terminals. When an ESC is typed to complete a filename, the filename is completed correctly, but there was an error in the way the command line got updated on the terminal that resulted in some characters getting erased. This problem has been corrected. (SCR 6270) o The script /dev/MAKEDEV, which is used to create all the required special files in the /dev directory, has been modified in Release 3.2 so that it does not recreate or change the ownership or permissions on any special files that already exist in /dev when MAKEDEV is executed. This fixes several problems, among them the fact that the line printer spooling subsystem would no longer work after MAKEDEV was executed, since it reset the ownership on some /dev files required by lp. (SCR 6306) o In previous releases, the passwd(1) command would turn a blank line in /etc/passwd into a line '::0:0:::' the next time it was invoked after the addition of the blank line. This creates a user name '' (null) with a uid of 0 (root) and no password. This behavior has been corrected in 3.2. Blank lines are preserved and are treated as comments by all programs that use getpwent(3) to access the password file. (SCR 6315) o The wall(1) command in previous releases would sometimes create normal data files in the /dev directory. This no longer happens. (SCR 6318) o Several bugs were fixed in 3.2 that resulted in file systems remaining busy at system shutdown time. This would cause the unmount to fail (umount(1M)) which in turn would cause the system to think that the file systems in question were dirty and run fsck(1M) on them on the next boot, even though the system was shut down in an orderly fashion. (SCR 6393) o In Release 4D1-3.2, the file /usr/lib/acct/holidays gives the (United States) holidays for calendar year 1989. (SCR 6395) o On Release 3.1, an ordinary user could cause /etc/passwd to become an empty file by setting 'ulimit 0' (using sh(1)) and then using the passwd(1) command to change his password. This bug is fixed in 3.2. (SCR 6407) - 5 - o The declaration of m_set_procs on the m_fork(3P) manual page has been corrected to indicate that it returns an int. (SCR 6411) o The more(1) command no longer prints an error message when given a null file. (SCR 6412, 6812) o In Release 4D1-3.1, the default permissions on the directory '/' shipped on new systems were 'rwxrwxrwx' (777). Allowing users other than root to have write access to '/' is a serious security breach. Starting with 3.2, the permissions on '/' on new disks are 'rwxr-xr-x' (755). (SCRs 6448, 6604) o A bug was fixed in the driver for the IKON parallel printer controller board that could cause parallel printers not to work properly under some conditions. (SCR 6510) o The header file /usr/include/sys/sysmp.h now nests an include of /usr/include/sys/types.h, since sysmp.h references caddr_t. Both header files have nesting protection, so this change will not break any existing code that includes one or both of these files. (SCR 6517) o In Release 4D1-3.1, if the mt rewind command is issued when the SCSI tape is not positioned at a file mark, the tape will seek forward to the next file mark before rewinding. In Release 4D1-3.2, the tape will rewind immediately without any other positioning activity. (SCRs 6546, 6567) o A bug that could cause the swap(1M) command to hang the system when used to delete a swap partition (the -d option) has been fixed. (SCR 6555) o A bug in the Release 4D1-3.1 HyperNET driver that could cause system crashes when transferring large amounts of data has been fixed. (SCR 6561) o More detail has been added to the manual page for the sproc(2) system call (shared address space fork) to provide better information about how traditional process issues (delivery of signals, exit of child processes and so forth) are handled for processes created by sproc(2). (SCR 6597) o The man(1) command in Release 4D1-3.1 sometimes shows the same manual entry several times. For example, the command "man man" would display the following entries: - 6 - man(1), man(5) and then man(5) again. This no longer happens in Release 3.2. (SCR 6660) o Kernel crash dumps would sometimes hang indefinitely when dumping to ESDI drives using 4D1-3.1 software. This problem has been fixed. (SCR 6672) o The library routines getpwent(3) and getgrent(3) that access the passwd(4) and group(4) files now support a comment syntax: '#' in the first column. Several potential security breaches having to do with the handling of very long lines in /etc/passwd were also fixed. (SCR 6724) o There is a bug in certain revision levels of the firmware on Interphase 4201 ESDI disk controllers that causes the system to print the message "MACSI mode timeout" and hang. This typically occurs only during very heavy disk activity, involving lots of small transfers. If this error occurs on your system, contact Silicon Graphics to get your disk controller upgraded with firmware that corrects the problem. (SCR 6739) o The kernel driver module for the SCSI floppy disk drive is no longer automatically linked into IRIX kernels. On systems that have the floppy drive installed, the system administrator must edit the file /usr/sysgen/system and then run the lboot(1M) program to relink the operating system. Find the line in /usr/sysgen/system that looks like: "*INCLUDE: smfd".Change that line by simply removing the leading asterisk (*), which will converts the line from being a comment to a command that causes the floppy disk driver module to be included in the kernel. After making this change, run the command /etc/init.d/autoconfig, answering 'y' to the question "Automatically reconfigure the operating system (y or n)?". This is a shell script that executes lboot(1M). When this command completes, reboot the system using the reboot(1M) command. (SCR 6740) o In previous releases, vi(1) dumps core if the TERM variable is set to a terminal type that is not present in the terminfo(4) database. In Release 4D1-3.2, vi(1) will use terminal type 'dumb' in this situation. (SCRs 5104, 5959, 6765) o In previous releases, the system could not be booted into single-user mode if the file /etc/inittab was missing and the system console had been switched from - 7 - the graphics monitor to the diagnostic console. In 3.2, the system can be booted into single-user mode even if /etc/inittab is missing. (SCR 6781) o In previous releases, there are cases in which IRIX erroneously prints the message "DANGER - out of swap space". This has been fixed in 3.2. (SCR 6784) o When booting the system into an initstate other than the default after a system crash, it is no longer necessary to enter the boot command with the special initstate twice. In Release 4D1-3.2, the system doesn't have to shutdown again if it finds the root file system dirty. It runs fsck(1M) as before, but fsck remounts the root file system and the boot continues. (SCR 6786) o When invoked from within curses(3X), vi(1) did not always format its text correctly in previous releases. (SCR 6813) o The manual entry for usmalloc(3P) was changed to indicate that the header file malloc.h is required to access the functions documented in usmalloc(3P). (SCR 6874) o Some programs that linked with -lmalloc would continue to grow in virtual size even though all malloced segments were freed. This no longer happens. (SCR 6870) o When using ulimit(2) to get the maximum possible break value for the calling program, previous versions of IRIX would return a negative number. This has been fixed. (SCR 6893) o The list of timezones that the 'syssetup datetime' menu under sysadm(1) recognizes has been enhanced to include all the European, Pacific and East Asian timezones. It previously only included American time zones. (SCR 4032, 6894) o The uname(1) command now correctly distinguishes between the IP5 (16MHz 2-processor CPU), the IP7 (25MHz 2-processor CPU) and the IP9 (25MHz single processor CPU) in the output generated with the -m option. (SCR 7010) o Ldopen(3) did an uninterruptible sleep. The sleep is now interruptible. (SCR 6854) - 8 - 6.2 Bug_Fixes_to_Program_Development_Tools o The functionality of pixie_mp has been absorbed into pixie. Use pixie as you normally would. If the program is a "normal" one, just one Counts file is produced. If the program calls sproc, (e.g. a Fortran multi- processing program, or one that calls m_fork(3P)) then you automatically get multiple Counts files. (SCR 6771) o In C, an undefined structure member reference could generate an error message with some garbage in it. Now, it generates a message with the correct field name. (SCR 6383) o The function rint(3M) was added to libm. (SCR 6370) o dbx now identifies file types which cannot be debugged. If you attempt to use dbx to debug a directory, for example, dbx prints a message that identifies the file as a directory. (SCR 5311) o (edge) Problems with windows were fixed. (SCRs 4036, 4694) o (dbx) Added an optional ``pid '' clause to many dbx commands to reduce the need to type the ``active'' command. (SCR 4753) o (dbx) If one tried to set a breakpoint in shared- library code, the message ``no executable code found at line "prog.c":260052304'', for example, would appear. This problem has been fixed. (SCR 5453) o (dbx) If $promptonfork is 0, dbx no longer stops when the process forks. (SCR 6374) o (dbx) The man page now mentions the px alias. In addition, the manual page and the help file have much new information on dbx commands and expressions. (SCR 6881) o (ar) When a file name longer than 15 characters is presented to ar(1) it is truncated to 15 characters. Attempts to replace with the original name will fail. Now ar(1) mentions the partial match so one can tell why the match failed. (SCR 6736) o (uopt) The optimizer was fixed to eliminate a ``no case matches value in case statement'' message on legal - 9 - programs. Some such programs caused uopt to dump core. (SCRs 4918, 5577) o A prototype must be in scope at both the calling and called sites for the prototype argument promotions to work correctly unless the prototype matches the default argument promotions. A function definition using prototype form is its own prototype. Using old-style function declarations/definitions and prototype declarations/definitions for the same function will usually yield an erroneous program. (SCR) 5002 o The following development libraries were moved to the development image of the distribution: /usr/lib/libcrypt.a /usr/lib/libdgl.a /usr/lib/libutil.a (SCR 5781) o (mkshlib) mkshlib was creating shared library archive object files with garbage in the cprmask[] fields of the object header. This made binary comparisons with earlier releases really difficult. Now the fields are initialized correctly. (SCR 5919) o ar(1) was moved to the execute only portion of the ---------- end of Part 2   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03650; 19 Nov 89 15:32 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa03560; 19 Nov 89 15:21 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03477; 19 Nov 89 14:59 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25953; 19 Nov 89 14:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA00215; Sun, 19 Nov 89 11:35:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Nov 89 18:40:54 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: IRIX 3.2 Release Notes (Part 3 of 3) Message-Id: <44984@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL -------------------- cut here ------------------- distribution for wider availability to customers. (SCR 5975) o The ar(1) man page now mentions explicitly which operand is taken as the archive name. (SCR 6840) o (cc) In C in earlier releases a return from main() would always return 0. Now any return value from main() is correctly returned to the environment. This matches the proposed ANSI C standard. User programs which fail to either exit(2) or return a value from main() will return a useless garbage status to their environment. (SCR 6031) o (cc) A bug in ccom prevented typedef's to pointers to functions with prototypes from working. (SCR 6278) The test case is: typedef int (*Fcnptr )(int); Fcnptr _tkFcnCallEvent_fcn ; This resulted in errors such as: ccom: Error: t.c, line 3: redeclaration of Fcnptr Fcnptr _tkFcnCallEvent_fcn ; -------------------------^ ccom: Error: t.c, line 3: syntax error Fcnptr _tkFcnCallEvent_fcn ; - 10 - -------------------------^ o (cc) The bogus message: ``ccom: Warning: idbg.c, line 5100: illegal member use: u_format'' no longer occasionally appears associated with user source errors. (SCR 6385) o (prof) -clock is now documented correctly in the prof(1) man page. (SCR 6385) o (unix and m_fork and pixie) Now multi-processing programs get their own block counts by thread. (SCR 6772) o (fsplit) fsplit(1) now works with blank lines between subroutines. (SCR 7025) o (libc) strtod(3) now has a prototype in to match atof(3). This is non-standard and these will be moved to for a future release. (SCR 7091) o (f77) The following program did not work correctly due to the forced misalignment of a and b off of double boundaries. (SCR 7141) c change i to anything beside double, bug still occurs. c order of common seems significant. double precision a, b integer i common /x/ i, a, b data i/0/ a = -79.0 b = 79.0 print *, i, a, b end Code generation has been corrected to handle this correctly. 6.3 Bug_Fixes_to_Graphics o Microcode bug with either backface or Tmesh on 4D/20s is fixed. (SCR 6487) o Personal IRIS - Self-intersecting polygon fills now work correctly. (SCR 6943) o Double buffered depthcued polygons and lines were not dithered on the Personal IRIS because of inaccuracies resulting from floating point roundoff. Now depthcued as well as gouraud shaded polygon and lines are - 11 - dithered in both RGB and colorindex modes. The Personal IRIS with an RE1 chip and 24 bitplanes can not dither in colorindex mode. (SCR 6496) o Personal IRIS - The source code was optimized to improve line performance using bgnline, v,v,.. endline calls. (SCR 6833) o Personal IRIS - The line stipple was advanced one pixel too far at junction of two line segments. The stipple is correctly backed up one bit. (SCR 6702) o Personal IRIS - Wide lines and curveit no longer cause stray lines to be drawn. (SCR 6669) o Personal IRIS - Picking no longer causes systems to hang when the last element in the pick buffer is negative. (SCR 6547) o When you try to render polygons that have nearly 256 vertices and are non-monotonic in screen space on the IRIS-4D GT or GTX with graphics from non-GT's, the window manager sometimes crashes. This has been fixed. (SCR 6944) o An error in 4x4 matrix inversion that caused some invertible matrices to be inverted incorrectly was corrected. This error may have produced incorrect lighting in rare instances. (SCR 6836) o The man pages now document the limit for points per polygon The current limit is 255 on the 4D/XX machines for the polf, poly, pmv, pdr, and any other polygon- related commands. (SCR 3750) o The gamma(6T) man page now correctly represents the 4D product. (SCR 4583) o The winconstraints(3g) man page now states that winconstraints must be called AFTER winopen(). (SCR 4723) o Certain GL routines are only available on the GT. Yet there is no mention of this on the man pages (e.g. blendfunction(3G)). Hence, the new "GL Reference Guide" (007-1203-010), which contains the printed versions of the GL man pages, is therefore really the "*GT* GL Reference Guide". Non-GT customers could get really confused. The man pages now mention system- specific restrictions. (SCR 4954) - 12 - o There was no clear explanation of how the lmbind uses the current matrix on the viewing stack to do the modeling and viewing transformation of the light. This is discussed in the Graphics Library Programming Guide. (SCR 5012) o The mathematical implementation of lighting has been explained in the the graphics documentation. (SCR 5013) o The GF3 card now checks whether the zbuffer board is installed. (SCR 5099) zbuffer(TRUE); printf("zbuffer: %d0, getzbuffer); This will return 1 if zbuffer is installed and 0 if not. o The curve commands and the lighting commands used the same matrix stack space causing failures due to interference. (SCR 5160) o An exec() of a process that did a ginit caused a kernel panic. (SCR 5541) o The gammaramp(3G) man page now mentions the "4D" implementation of gammaramp. (SCR 6005) o In 3.1C or earlier, the screenmask was incorrectly set, and as a result the top scan line could not be written to. This is fixed in 3.1D. A second related bug was that sbox was not always setting the right pixels in conjunction with the screen mask. This is fixed in 3.2. (SCR 6078) o The gversion man page has been changed to reflect the actual string returned. (SCR 6139) o Concave bowtie polygons now fills correctly on 4D/20. (SCR 6204) o Fudge() now work correctly with keepaspect(). (SCR 6211) o The shaderange equation is now correct in the GT Graphics Library User's Guides (SCR 6223) o The man page for blendfunction() had the source and destination reversed. (SCR 6224) o The Graphics Library Programmer's Guide incorrectly stated that the blending section applied only to GT systems that have alpha planes. Blending does work on GT systems without alpha planes. (SCR 6249) - 13 - o The man page for lRGBrange has been included in the release. (SCR 6304) o Binding a light in multiple windows went into an infinite loop. (SCR 6424) o The 4Sight User's Guide incorrectly stated that ismex() always returns TRUE(1). It returns TRUE only if 4Sight is running, otherwise it returns FALSE(0) (SCR 6430) o The text of the GL Programming Guide was changed to reflect the correct returned value for blkread(3G). (SCR 6432) o Unqdevice did not work correctly. (SCR 6469) o The GT and GTX implementation of the GL routine feedback() would crash the pipe if invoked with a buffer size greater than 32k (shorts). (SCR 6576) o Patches did not work in mmode(MVIEWING) on the GT. All forward difference matrix calculations are no longer done in the graphics hardware. (SCR 6638) The non-GT library did not have rectread and rectwrite enabled. (SCR 6791) o Writemask did not reset properly when switching manually. Writemask was being reset to 4095 instead of 1 when leaving overdraw. (SCR 6792, 6794) o The c3s command didn't work on the GTX due to 3 way transfers from short address boundaries.. (SCR 6819) o The lsetdepth() man page did not reflect the difference between the Personal Iris and the Power Series graphics. (SCR 6842) o Self-intersecting polygon fills did not work correctly. (SCR 6943) o Picking mode now works on the 4D GT. (SCR 6847) o Short integers weren't sign extended on the GTX product line. (SCR 6863) 6.4 Bug_Fixes_to_the_Installation_Tools The manual page has been updated to correctly document that install(1) claims the '-f' option must be used in conjunction with '-s', '-o' or - 14 - o The help file has been updated and now correctly states that spacecheck can be defeated with: set spacechk off (SCR 5849) o The installation tool properly clears empty products out of the installation history. (SCR 5871, 6720) o Non-graphics terminals get a default screen size of 24 lines so the installation screens do not scroll off the screen. (SCR 5895, 6717) o Distcp -n now supports writing tape without the standalone tools. (SCR 5960, 6694) o Installation documentation have been corrected to support loading of the miniroot from tape on non- Personal Iris machines. (SCR 6358) o The installation tools no longer make the assumption that all computers are workstations. Therefore, graphics dependent code is not installed on servers with exception of IP6 based servers. (SCR 6570) o GL development headers are no longer inadvertently being shipped. (SCR 6618) o Uname and versions no longer report the operating system revision name differently. (SCR 6665) o The installation tools no longer incorrectly handle symbolic links set up by the user before installation. (SCR 6666) o distcp now correctly copies distribution data from tape to disk. (SCR 6692) o The installation tools no longer have several screens where text wraps around the end of the line. (SCR 6747) o The installation tools now forcefully rewind the tape any time there is a possibility that the tape has not been rewound. (SCR 6988) o Network installation fails if the remote login account on the remote host sends spurious output to the screen during a login session. The Release Notes document how to test for this condition and work around it if it exists. (SCR 7137) >>>>>>>>>> 3.2 Release notes, Chapter 7 >>>>>>>>>> - 1 - 7. Known_Problems_and_Ways_to_Work_Around_Them This chapter describes known problems and ways to work around them the 4D1-3.2 release. 7.1 IRIX o The Revision 10 firmware in IRIS-4D Series workstation and servers does not display memory size when you power up your system. To see the memory size, enter the following command at the PROM monitor prompt (>>) and type: hinv o The IRIX version of vi was enhanced in this release to allow the user to control the intercharacter timeout. This timeout is the length of time that vi waits after receiving an escape (ESC) for another character comprising an escape sequence. For example, many popular types of terminals use escape sequences consisting of ESC followed by several characters to represent single keypresses of terminal arrow keys. Vi needs to be able to distinguish the typing of the ESC key from an escape sequence generated by pressing an arrow key. This is done by waiting for the number of milliseconds specified by the 'timeout' variable after the ESC arrives. If no other characters arrive before the timeout expires, then the ESC is treated as if just the ESC key was pressed. The default setting of 'timeout' is 200 milliseconds. When vi is used in a network environment or through modems, it may be necessary to increase the timeout value in order for escape sequences to be recognized. The timeout variable can be set from within vi or ex, by issuing a set command. For example: :set timeout=400 sets the intercharacter timeout to 400 milliseconds. The current value of 'timeout' can be displayed by :set timeout or :set all A set command for timeout can also be added of the user's .exrc file. o Systems equipped with the VME-based ISI QIC-02 quarter inch cartridge tape controller ) cannot make multi- volume backup tapes using the tar, bru or cpio commands; use the hinv command to determine which type of tape drive you have on your system. This is due to the inability of the controller to recover data after it has been sent to the tape drive when the data on the tape media spans the physical end-of-tape mark. - 2 - Multi-volume backup will function on all other SGI- supplied quarter inch cartridge drives as well as the VME-based 1/2" tape drives. These include the 60 MB and 150 MB SCSI tape drives. See Appendix A, ``Backing Up and Restoring Your System'' for more information. o On machines configured as servers, during heavy use, the following message might appear on the console: WARNING: mfree map overflow. Lost items at . This indicates a data array in the kernel is too small for the amount of machine usage. The size of this array can be increased by editing the file: /usr/sysgen/master.d/kernel, and increasing the parameter SPTMAP. Increasing this parameter from 50 to 100 should be sufficient. After this modification, it is necessary to reconfigure the kernel, and reboot. /etc/init.d/autoconfig prompts for configuring the new kernel. See lboot(1M) for instructions for reconfiguring the kernel. o On machines configured as servers, which make heavy use of disk storage, it may be possible to increase the performance of the system by increasing the size of the IRIX disk buffer cache. This can be done by editing the file: /usr/sysgen/master.d/kernel, and increasing the parameter NBUF from 100 to 200 (or more). Whether this will yield any performance gain is entirely application-dependent, however, this modification has proven beneficial for applications which generate large amounts disk traffic. After the modification, it is necessary to reconfigure the kernel, and reboot. The simplest way to reconfigure the kernel is to run /etc/init.d/autoconfig. See lboot(1M) for instructions for reconfiguring the kernel. o On machines configured as servers, the maximum number of processes allowed to be in execution may prove to be too small. When the number of active processes is at the maximum, attempts to create new processes (e.g., issuing a command from the shell), will fail. This maximum number of processes is a configurable parameter, given by the NPROC parameter in the file /usr/sysgen/master.d/kernel. As shipped, the NPROC entry is 80 + (MAXUSERS * 16), which yields 96 processes active at any time. Increasing this number to perhaps 300, should remedy the problem of running out of processes. Another way to increase this parameter is to increase the MAXUSERS definition, found in the file /usr/sysgen/system. Note that increasing - 3 - the MAXUSERS definition has effects on sizes of other kernel structures. After the modification is made to the NPROC or MAXUSERS parameters, it is necessary to reconfigure the kernel, and reboot. See lboot(1M) for instructions for reconfiguring the kernel. o If you are using non-standard disk partitions, you will have to create the device special files that reference them, since the device special files corresponding to disk partitions 2, 3, 4, 5, 11, 12, 13, 14, and 15 are no longer created by MAKEDEV. These device special files were the ones in the /dev/dsk and /dev/rdsk directories whose names ended in s2, s3, s4, s5, s11, s12, s13, s14, and s15. For example, /dev/dsk/dks0d2s3, /dev/rdsk/ips1d1s5, and /dev/dsk/xyl0d2s12 used to be created by MAKEDEV, but are no longer. MAKEDEV is a script in the /dev directory that creates all the device special files that are located therein. MAKEDEV was changed in order to save inodes, since these devices were never used in standard configurations. If you need to use them, you must create them manually using mknod. To create the above example devices, you would use mknod as follows: # mknod /dev/dsk/dks0d2s3 b 22 67 # mknod /dev/rdsk/ips1d1s5 c 4 85 # mknod /dev/dsk/xyl0d2s12 b 6 44 Device file names are represented by XXXCdNPP, where XXX refers to disk type (dks is SCSI disks, major number 22; ips is ESDI disks, major number 4; xyl is SMD disks, major number 6), C refers to controller number, N refers to device address (also known as disk number), and PP refers to partition name. For our purposes, the partition number is the partition name without the leading s, i.e. partition name s2 references partition number 2. The minor number can be found using the following equations: For SCSI: (N * 32) + partition number For ESDI and SMD: (C * 64) + (N * 16) + partition number These devices will have to be recreated whenever MAKEDEV is executed. Note that MAKEDEV is always executed when installing IRIX. Refer to mknod(1m), dks(7), ips(7), and xyl(7) for more information. o There is a bug in the bstream(1) buffering filter: if the last input block is less than the current output blocksize, the block is dropped. In other words, any fragment of a block at the end of the input file will not be written to the output. No warning message is generated to indicate that data has been lost and the - 4 - program still exits with normal status in this case. The manual entry says that such trailing partial blocks will be padded with zeros to the size of a complete block and written out, but this is not true of the software shipped in release 3.2. Note that this is not a problem when using bstream(1) to process the output of tar(1) or cpio(1), since these programs never write partial blocks. When the input to bstream(1) is from a program that does not do output blocking, however, data may be silently lost. o The initialization file for pmake(1) contains some invalid entries. To fix them, edit /usr/include/make/system.mk. At the end of the file, the ``.sh.out'' rule needs to remove its target. The entry should read: .sh.out : rm -f $(.TARGET) cp $(.IMPSRC) $(.TARGET); chmod a+x,u+w $(.TARGET) (The first character for the rm and cp lines is a tab.) The rules and command lines for ``.o.a'' and ``.u.b'' should be deleted. 7.2 Program_Development_Tools o The C language expression: x >= y + 1 where x and y are unsigned (y may be an expression) is incorrectly compiled as x > y. The resulting code will work correctly for all values of y except 0xffffffff. Similarly, x < y+1 is transformed to x <= y, which is wrong if y is 0xffffffff. In either case, the way to get around this is to assign y + 1 to a variable and test x against the variable. o When compiling a C program the message ``symbol table full'' might appear. Instructions to increase the size of the table were inadvertently left off of the message. The default table size is 5000 symbols. To increase the symbol table to 12,000 symbols (for example) add the following option to the cc(1) command: -Wf,-XNd12000 o The following routine float f(float x) { return((x > 0.5) ? 1.0 : 0.0); } Returns an incorrect value. The problem is specific to ``float'' arguments and returned values. Nearly any change to the source (such as assigning the result of the query operator to a temporary and returning the temporary) will work around the problem. - 5 - 7.3 Networking o The Visual Administration networking tool currently works properly if you are using the default ifconfig(1M) netmask. (If your network topology uses subnets, the netmask will need to be different.) The network tool does not handle non-default netmasks and will disable the ``nets'' view in the tool. You can access only to the ``hosts'' view. If you want your system to use a netmask other than the default value, you need to take the following steps. 1. Add the following line to the file /etc/config/ifconfig-1.options. If this file does not exist then you need to create it. netmask mask Specify mask as a hex number 0x.. 2. Reboot your system. 3. To confirm the new netmask, type: ifconfig interface_name Replace interface_name with: __________________________________________________________ ec0 4D/20,4D/25 (Personal IRIS & DataStation) et0 4D/1x0, 4D/2x0 (Power Series) enp0 4D/50-80 7.4 Diskless_Personal_IRIS o The 4D/20 and 4D/25 Diskless workstations for a particular class and their server must be in same sub- net. 7.5 HyperNET o Running HyperNET between two workstations on the same adapter used to cause any IRIS-4D to crash while transferring large amounts of data. 7.6 Graphics o The window system now supports the imakebackground() function, but there are some problems with its use: 1. Killing an imakebackground program is supposed to cause the window manager to repaint the currently defined window "root" as set by the "Windows" menu, "Window Style" submenu, and its "More Roots" - 6 - submenu, the default being the familiar sky-blue "Plain Root". The repaint often does not happen, leaving the screen background black. The way to work around this is to select "Redraw All" from the "Windows" menu. (You may have to select "Redraw All" two times). 2. Use of imakebackground programs on 4D50G, 4D60G systems is not recommended because window painting errors can result when the complexity of the window layout results in a clip list that is too large to be supported by the graphics hardware. This problem does not occur on any Personal IRIS, GT, or GTX systems. o If you run any double-buffered RGB mode program (such as Visualizer or QuickModel) at the same time as any double-buffered colorindex mode program (such as the IRIS WorkSpace), the window that doesn't contain the cursor is displayed with incorrect colors. o On GT's, programs that do prefsize, winopen, winconstrains should have a sleep after the winopen to avoid small verticle lines at the bottom of the window. If you see these lines, move the window and they will go way. 7.7 4Sight When 4Sight receives a request from a remote machine to create a NeWS window, it tries to convert the machine's Internet address into a name. 4Sight use the Domain Name Server (named(1M)) or /etc/hosts to do this. (It does not use the Yellow Pages.) If there is a problem doing this conversion, 4Sight might not be able to start up or create windows. The file /usr/etc/resolv.conf specifies the Internet addresses of machines running the name server (see resolver(4) for details). If the file does not exist, the named on the local machine is tried before using the /etc/hosts file. If the resolv.conf file exists but is not setup properly (e.g., it contains addresses of nonexistent machines), 4Sight gives up and prints an error message in /usr/adm/SYSLOG. If all the name servers in resolv.conf become unreachable after 4Sight starts, 4Sight will not be able to create windows. Error messages in /usr/adm/SYSLOG with the format "getsocketpeername: Can't find name for ..." indicate a name service failure. - 7 - The name service failures may be transient; try to create the window again. If it consistently fails, make sure the ethernet cable is still plugged in and the name servers listed in resolv.conf are reachable. Use ping(1M) and nslookup(1M) to check for reachability. If the name server is not used, make sure /etc/hosts has entries for ``localhost'' and all the remote hosts that access your IRIS. For information on setting up named and resolv.conf, see the TCP/IP User's Guide and resolver(4). 7.8 X11_Window_System The performance and functionality of the X11 Window System product on the 4D/[50,60,70,80]G (non GT or GTX) platforms is less than that of the other product lines due to hardware limitations. We suggest upgrading your system to a GT (Graphics Turbo) if you are going to make extensive use of the X11 Window System product. >>>>>>>>>> 3.2 Release notes, Chapter 8 >>>>>>>>>> - 1 - 8. Documentation_Errors_and_Notes This chapter contains errors in the documentation, suggestions for workking around certain problems, and additional notes for this release. Generally, on-line documentation, such as the man pages is more up-to-date than the printed hard copies. This is not true for this document. 8.1 Documentation_Errors 8.1.1 IRIX o Section 3.2, ``Booting the Workstation'' of the IRIS-4D Series Owner's Guide fails to mention fully how to boot an IRIS-4D from a ASCII terminal attached to port 1 (ttyd1). Booting from an ASCII terminal is necessary when you don't have a graphics console or you want to run diagnostics without graphics running on the graphics console. To boot your IRIS-4D from an an ASCII terminal, you must set the PROM Monitor environment variable ``console.'' To set this variable, enter the following command at the PROM Monitor prompt: setenv console d NeWS is not automatically started when you boot from an ASCII terminal. To run NeWS, enter the following command once you have logged on: /etc/gl/restartgl This executes the graphics console daemon, grcond, which starts up the NeWS server. When you boot from an ASCII terminal, the console wsh window doesn't appear on the graphics console screen. This window is synonymous with the PROM Monitor environment variable ``console,'' which is now set to run on the ASCII terminal and not the graphics console. o The hardcopy of the find(1) manual page mentions the -prune option, which is not implemented in software release 4D1-3.2. The online version of the find(1) manual page is correct. See man for information about viewing the online manual pages. 8.1.2 Program_Development_Tools 8.1.2.1 C_Language_Reference_Manual - 2 - 8.1.2.1.1 Chapter_6_-_Declarations The following paragraph updates the description of prototypes in Section 6.4, "Meaning of Declarators." This new description supersedes the paragraph beginning, "A parameter-type-list..." A parameter-type-list declares the types of, and may declare identifiers for, the formal parameters of a function. When a function is invoked for which a function prototype is in scope, each actual parameter is converted to the type of the corresponding formal parameter specified in the function prototype. If the list terminates with an elipsis (...), only the parameters specified in the prototype have their types checked; additional parameters are converted according to the default argument promotions (see Section 5.1). Otherwise, the number of parameters appearing the in parameter list at the point of call must agree in number with those in the function prototype. A prototype must be in scope at both the calling and called sights for the prototype argument promotions to work correctly unless the prototype matches the default argument promotions. A function definition using prototype form is its own prototype. Using old-style function declaration/definitions and prototype declarations/definitions for the same function often yields an erroneous programs. 8.1.2.1.2 Chapter_10_-_Compiler_Control_Lines Section 10.4, ``Conditional Compilation'' incorrectly states that you should use #elif between a #if directive and #else or #endif directives if we have more than 2 conditionals. See cpp(1) for more information. 8.1.2.2 dbx_Reference_Manual There are several features in dbx newer than presented in the reference manual. The man page and help file /usr/lib/dbx.help have been extensively revised to document dbx properly. Both of the on-line documents are more complete than the reference manual. Though there is considerable overlap between the man page and the help file, there is some information in each that is not in the other. 8.1.2.3 Porting_Applications_to_the_IRIS-4D_Family In general, statements in Section 1 and 2 about the GT are also true for the Personal IRIS. See the GL manual pages for up-to-date information. 8.1.2.3.1 Section_2_-_IRIS_3000_to_4D_Conversion_Tutorial Section 6.2, ``Cross-hair Cursors'' states that color 3 is used for the cross-hair cursor. The GT and Personal IRIS use color 1. See mapcolor(3G). - 3 - 8.1.2.4 Porting_FORTRAN_Code_to_IRIS-4D_Workstations 8.1.2.4.1 Chapter_3_-_Code_Compatibility Section 3.3, ``I/O Compatibility'' should mention that the IRIS-4D FORTRAN compiler does not support a BUFFERED specifier to the OPEN statement. Instead, use setbuf() to set a buffer and size. 8.2 Installing_the_Dial_and_Button_Box Some changes have been made that affect the installation of the Dial and Button box. To install the dial and button box an additional change must be made to the line that begins with diald. Step number 3 fails to mention that /dev/console should be changed to /dev/null just as x is changed to 234. Step number 4 should mention when you cycle the power on the Dial and Button box, the LED's indicate the knob numbers and the lights illuminate when you press them. In addition, the box says ``ready'' when you reboot or log in. To restart the dial daemon, log out then log back in. 8.3 TCP/IP_User's_Guide' There are errors in Chapter 5 of the TCP/IP User's Guide Version 2.0, ``BIND Name Server Operations'' is not mentioned in the Guide's errata sheet. Section 5.9, ``Standard Resource Record Format'', describes 2 address classes, IN and ANY. The ANY address class is not supported by BIND version 4.8. The description of the HINFO resource record in Section 5.9 and the HINFO examples in the sample file in Section 5.11.7 mistakenly use the address class ANY; they should use IN instead. 8.4 Graphics_Library_Reference_Manual The newly printed GL Programmer's Guide does not document these GL routines: - 4 - attachcursor blankscreen blanktime blendfunction curson/cursoff deflinestyle defpattern getcpos getgdesc getlsrepeat getlstyle getlwidth getmonitor getothermonitor getpattern getplanes greset gversion linewidth logicop lsrepeat pntsmooth popattributes pushattributes sbox sboxf setlinestyle setmonitor setvideo subpixel videocmd wmpack See the GL manual pages for a description of these routines. 8.5 Graphics_Library_Reference_Manual o zfunction() is implemented on all 4D products. However, the GL reference manual says that it is only on the 4D-GT machines. o The blkqread(3G) man page says that the return value of blkqread is the number of events returned. In fact, it is the number of shorts returned (twice as big as the other number would be). ---------- end of Part 3   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05946; 20 Nov 89 0:28 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa05660; 19 Nov 89 23:46 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa05627; 19 Nov 89 23:39 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29331; 19 Nov 89 23:32 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA28919; Sun, 19 Nov 89 20:26:58 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Nov 89 18:54:42 GMT From: "Gavin A. Bell" Subject: Re: Transfer Personal IRIS images to VCR Message-Id: <1532@odin.SGI.COM> References: <8911131633.AA13927@aero4.larc.nasa.gov>, <1523@odin.SGI.COM>, <11628@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL If there is enough interest, I am willing to type in and post the marketing hype and specs for SGI's newest video product, which is designed specifically for both real-time and frame-by-frame recording on all 4D products (it comes as both an add-in board, or a separate box; the board works only in GTX-type machines). I hesitate to go ahead and post they hype for two reasons: first, I don't want to bother spending half an hour being a stenographer if there is little interest, and I don't want to offend anybody by posting something very commercial. --gavin   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07576; 20 Nov 89 6:17 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa07271; 20 Nov 89 5:25 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07249; 20 Nov 89 5:15 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01511; 20 Nov 89 5:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA17014; Mon, 20 Nov 89 01:55:13 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Nov 89 04:18:52 GMT From: Andrew Hume Organization: AT&T Bell Laboratories, Murray Hill NJ Subject: Re: Transfer Personal IRIS images to VCR Message-Id: <10164@alice.UUCP> References: <8911131633.AA13927@aero4.larc.nasa.gov>, <1523@odin.SGI.COM>, <11628@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL in general, i agree with simms's comments. we do animation via a recorder (1" SONY BVH2500) that can record a frame at a time. (it is expensive..... ~$80K). there is a well defined if inconvenient (38.4KB RS422) remote control interface. regrettably, our 4D240 cannot generate 38.4KB (i mean kilobaud here) reliably. this deck gives fabulous video; its what the networks use.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab13137; 21 Nov 89 16:07 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12873; 21 Nov 89 15:56 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa12864; 21 Nov 89 15:43 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa25172; 21 Nov 89 15:35 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA23387; Tue, 21 Nov 89 12:18:14 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Nov 89 19:59:02 GMT From: unknown Organization: Stanford University Subject: Re: Transfer Personal IRIS images to VCR Message-Id: References: <8911131633.AA13927@aero4.larc.nasa.gov>, <1523@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL ams@gauss.Princeton.EDU (Andrew Simms) writes: B. Abacus and others make a different type of controller. This device sits on your ethernet and has a 1.2 Gigabyte disk on it. You write software that FTPs your image to the Abacus. It stores sequential frames on disk, and then it will write them out to a VCR. [ ...] It should also be noted that this device cannot do real time recording. Not completely true. I've used an Abekas (note the non-Webster spelling) machine that took NTSC video input, digitized and stored it on its big mama disk. It handled both realtime and frame by frame animation. Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@thrush.stanford.edu) (415) 723-4940   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08072; 20 Nov 89 7:14 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa07636; 20 Nov 89 6:33 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa07604; 20 Nov 89 6:21 EST Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa01824; 20 Nov 89 6:13 EST Received: from cmcl2.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP id AA11617; Mon, 20 Nov 89 06:13:12 EST Received: by cmcl2.NYU.EDU (5.61/1.34) id AA29192; Mon, 20 Nov 89 05:05:15 -0500 Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA11177; Mon, 20 Nov 89 03:48:55 EST Date: Mon, 20 Nov 89 03:48:55 EST From: Rod Paul Message-Id: <8911200848.AA11177@dasys1.UUCP> To: info-iris@BRL.MIL, shinobu!odin!krypton!gavin@sgi.sgi.com Subject: Re: Transfer Personal IRIS images to VCR Here's one person interested in hearing more about SGI's new video product...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00091; 20 Nov 89 8:54 EST Received: from VMB.BRL.MIL by VMB.brl.MIL id aa09193; 20 Nov 89 8:35 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa09004; 20 Nov 89 8:22 EST Received: from inria.inria.fr by SMOKE.BRL.MIL id aa03535; 20 Nov 89 8:11 EST Received: from text.inria.fr by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA00552; Mon, 20 Nov 89 14:10:08 +0100 (MET) Received: by ch with X.400; 20 Nov 89 14:07:43+0100 Date: 20 Nov 89 14:07:43+0100 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: video on gtx Message-Id: <108*doelz@urz.unibas.ch> Here's another person interested in hearing about SGI's first video product ... (I wouldn't call the genlock reseonable so far)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04619; 20 Nov 89 11:20 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04183; 20 Nov 89 11:09 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa03907; 20 Nov 89 10:50 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08807; 20 Nov 89 10:47 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA03754; Mon, 20 Nov 89 07:35:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Nov 89 15:31:36 GMT From: Pablo Fernicola Organization: UF Machine Intelligence Laboratory Subject: Limit on windows? Message-Id: <21259@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there a limit on the number of windows that can be opened using winopen()? Is about 100 windows okay? We are running a Personal Iris with 8 Megs of memory, is the number of windows memory dependent? -- pff@beach.cis.ufl.edu - Pablo Fernicola - Machine Intelligence Laboratory - UF IF YOU CARE ENOUGH TO READ SIGNATURES ... I am graduating next year and I am looking for a job. MS/BS EE, my graduate work incorporates OO-DBMS/Graphics/Robotics/AI   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05105; 20 Nov 89 11:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04917; 20 Nov 89 11:47 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04840; 20 Nov 89 11:34 EST Received: from jvnca.csc.org by SMOKE.BRL.MIL id aa09925; 20 Nov 89 11:28 EST Received: from jvncf.csc.org by jvnca.csc.org id AA13557; Mon, 20 Nov 89 11:27:41 EST Return-Path: Received: by jvncf.csc.org id AA22191; Mon, 20 Nov 89 11:27:20 EST Date: Mon, 20 Nov 89 11:27:20 EST From: Richard Shaginaw lac11205 Message-Id: <8911201627.AA22191@jvncf.csc.org> To: info-iris@BRL.MIL Regarding the Simms posting -- you won't need a scan converter if you're using the SGI CG2 board with your image compressed to a quarter of the screen. Alternatively, if you wish to create full-screen images and animate them, you need a scan converter, in which case you don't need a CG2 board. I read Simms's article as saying you need both scan conversion AND the CG2, which makes no sense. I'll re-post my comments, which are fairly accurate: --------------------------------- For Messrs Klaasen and Bates, and all others wishing videotape output: Your RGB signal (taken directly from the back of your monitor) must undergo scan-rate conversion and resolution reduction before conversion to a composite signal for recording. Several manufacturers have scan converters that meet these needs with varying degrees of sophistication. A real-time scan converter does the scan conversion and averaging fast enough to permit real-time recording; this, however, has several drawbacks. Chiefly, your VCR will record at whatever speed the IRIS is advancing the animation; on a busy or underpowered machine this looks terrible. A high-resolution scan converter from LyonLamb, Photron, YEM, or others also permits single-frame animation, provided you also have a VCR controller such as the LyonLamb MiniVas. The scan converter contains a frame buffer that stores each image as it's converted; it will transmit this image in NTSC format to your VCR, which the MiniVas can direct to capture a single frame. The whole process can be controlled by the IRIS; the scan converters and the MiniVas have serial ports that accept simple commands, which can be sent from the program that advances your frames one at a time. The MiniVas also sends codes that can instruct your program when a frame-record is complete, so that the program can proceed to load the next image, signal the scan converter, signal the MiniVas, block for its return code,.... A decent system should cost $20K-30K. Most areas have video integrators that serve area TV stations and production houses; most of these have experience with workstation-based systems. ----------------------- LyonLamb Video Animation Systems, Inc. 4531 Empire Avenue Burbank, CA 91595 818-843-4831 Photron Limited Dogenzaka 2-9-7 Shibuya-Ku Tokyo 150, Japan 03-486-3471 Yamashita Engineering Manufacture, Inc. James Grunder and Associates, Inc., distributor 5925 Beverly Mission, KS 66202 913-831-0188 ------------------------ P.S. I'm also interested in the SGI video board. ------------------------------------------------------------------------------- The John von Neumann National Supercomputer Center -- User Services Group Richard J. Shaginaw JVNC Applications Software Analyst P.O. Box 3717 Consortium for Scientific Computing Princeton, NJ 08543 ------------------------------------------------------------------------------- Internet Address: shaginaw@jvnca.csc.org 609-520-2000 Bitnet Address: shaginaw@jvncc FAX: 609-520-1089 ===============================================================================   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01876; 20 Nov 89 17:40 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00867; 20 Nov 89 16:27 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa00793; 20 Nov 89 16:08 EST Received: from [128.32.133.1] by SMOKE.BRL.MIL id aa00260; 20 Nov 89 15:49 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA23403; Mon, 20 Nov 89 12:32:34 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Nov 89 19:52:22 GMT From: Betsy Zeller Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Updating directory views Message-Id: <45022@sgi.sgi.com> References: <17093@umn-cs.CS.UMN.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL There is something very wrong with your workspace, if your directory views are not staying *perfectly* up to date with your file system. Can you please check a few things for me. 1. Make sure that the new file is not appearing out of sight when you create it -- new files appear at the end of the directory view. 2. do a ps -ef | grep fam, and see if anything comes up 3. check the permissions on the directory that is giving you problems, and pass that information on to me 4. Open a directory view on another directory, and see if you have the same kind of problem there. 5. (Not that this should make any difference ) Is this directory NFS mounted? Any information that you can send me will be appreciated. Please keep me posted as to what you find out. The WorkSpace is supposed to accurately track the filesystem, and up till now ( as far as I know ), it has been doing so. Betsy Zeller betsy@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02647; 21 Nov 89 7:47 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01911; 21 Nov 89 6:13 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa01899; 21 Nov 89 6:03 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25151; 21 Nov 89 5:50 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA18551; Tue, 21 Nov 89 02:46:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Nov 89 18:46:21 GMT From: "Gavin A. Bell" Subject: Re: Transfer Personal IRIS images to VCR Message-Id: <1543@odin.SGI.COM> References: none, <5025@yunexus.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL gklaass@yunexus.UUCP (Gary Klaassen) writes: >We are considering getting a Personal Iris to do 3D colour graphics. >We would like to transfer the images, frame by frame if necessary, to >NTSC video (VHS and super VHS) for animation. Since several people have mailed me asking for information on the new VideoCreator product, I've decided to post the information. This information was sent out to the SGI sales force as a sales guide. Note that this product was only recently announced; it is expected to be available in quantity starting in March 1990. ----------------------------- On October 30th, at AutoFact, Silicon Graphics announced a new video interface product for the IRIS 4D workstation family called VideoCreator. VideoCreator is the second member of the 4Deo family of video interface solutions. The first product, the Live Video Digitizer, works with the POWER Series and lets users integrate live video images with real-time 3-D graphics on the same workstation. DESCRIPTION VideoCreator provides a complete, integrated video output solution which allows users to record computer-generated images from their IRIS 4D workstations directly onto standard video tape and disk recorders. The product consists of a VME board that plugs directly into Professional and POWER Series systems. For additional flexibility, the board can reside in a stand-alone box which connects to any of the workstations, including the Personal IRIS. Product features include real-time scan conversion, which allows the user to record onto video tape any image that appears on their high-resolution screen. In addition, VideoCreator allows applictions to record individual frames of computer-generated imagery sequentially, a key step in the process of creating computer animation. Unlike the Genlock option, this function can be performed in the "background" allowing the workstation to be used for other tasks while recording is taking place. SCAN CONVERSION Scan conversion is a commonly used term for taking a high resolution video signal (like the one used to drive IRIS workstation monitors) and lowering the resolution to be compatible with standard television equipment and recorders. Scan converters have been available from third parties like Lyon Lamb, Folsom Research, and RGB technologies for prices ranging from $13,000 to $26,000. VideoCreator's integrated scan converter allows images appearing on the workstation's high resolution screen to be recorded onto video tape in real-time. Scan conversion provides the simplest way to record computer generated images onto video tape. Since no special software is needed, it is the ideal solution for engineers and scientists who want to capture on video tape an interactive session with general purpose software. In addition, scan conversion provides anti-aliasing effects which can smooth lines and edges beyond what mighe be achievable by rendering images directly (frame-by-frame) to television resolution. FRAME-BY-FRAME Frame-by-frame recording is the method traditionally employed to produce computer generated animation. VideoCreator's television resolution VME frame buffer allows application software to render and output images without affecting the workstation's display. This means users can monitor the frame-by-frame recording process while running other applications on the workstation at the same time. VideoCreatorR CONTROL Most computer animation interfaces require the user to purchase an additional piece of equipment called a "VCR controller". The VCR controller allows the workstation to send commands to the VCR directly so that recording does not require the presence of an operator. Such equipment costs from $3,000 to $4,000. A unique feature of VideoCreator is Videomedia's V-LAN VCR control interface. The V-LAN system consists of a transmitter (that resides on the VideoCreator board) and a receiver connected togehter via a proprietary LAN (coax) interface. A customer wishing to use the V-LAN interface must purchase separately a receiver specifically matched to the VCR they will be using. Applications software can send VCR control commands directly to VideoCreator. VideoCreator's V-LAN transmitter sends those commands to the receiver via the coax interface. The receiver then converts those commands into ones understood by the specific VCR being controlled. In this way application software can have full control over the VCR, eliminating any need for operator intervention while doing frame-by-frame recording. CONFIGURATIONS VideoCreator is available for all Silicon Graphics workstations, including the Personal IRIS, Professional and POWER series. The product consists of a 9U VME board that plugs directly into the Professional and POWER series systems. For additional flexibility the board can reside in a stand-alone box which connects to any of the workstations. PRICING Description Price VideoCreator NTSC video $9,950 output, 9U VME board VideoCreator NTSC video $12,000 output, external box (required for Personal IRIS) NOTE: A V-LAN receiver must be purchased separately in order to use the VCR controller interface. The receiver should be purchased from the customer's local video dealer (where they purchased the VCR) or from Videomedia directly. Prices run from $1,000 to $1,650 depending on the type of VCR used. FEATURES BENEFITS Real-time scan conversion "What you see is what you get" video recording, application S/W independent Frame-by-frame recording Can be done in "background" without tying up workstations display Videomedia's V-LAN VCR Lower cost, complete integrated controller solution from one vendor Genlockable output Eliminates need for separate genlock board True RS-170 or EURO RGB Ability to connect to broadcast video output quality color encoders and produce a broadcast quality signal 24 bit true color output Maximize color quality of recording Support for RGB, composite Flexible output formats NTSC and S-VHS or PAL video output QUESTIONS AND ANSWERS Does VideoCreator produce broadcast quality video signals? No it does not. The composite NTSC and S-VHS signals are "industrial quality". They are acceptable for recording directly to high-end consumer and low-end professional video recorders. For broadcast quality the user is encouraged to use a broadcast quality color encoder along with VideoCreator. Why is VideoCreator so expensive? Much of the expense associated with VideoCreator is for the integrated scan conversion feature, that makes video recording easy and simple for unsophisticated video users. Third party scan converters cost form $13,000 to $26,000. Therefore, VideoCreator provides scan conversion, "background" frame-by-frame recording, and deck control all for less than what you pay for many scan converters on the market today. When can I get one? VideoCreator should be shipping in quantity in March 1990.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05808; 21 Nov 89 10:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04333; 21 Nov 89 9:19 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa04262; 21 Nov 89 9:07 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02328; 21 Nov 89 9:02 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA27767; Tue, 21 Nov 89 05:51:09 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Nov 89 02:13:02 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Transfer Personal IRIS images to VCR Message-Id: <1556@odin.SGI.COM> References: <11628@phoenix.Princeton.EDU>, <8911131633.AA13927@aero4.larc.nasa.gov>, <1523@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <11628@phoenix.Princeton.EDU>, ams@gauss.Princeton.EDU (Andrew Simms) writes: > Mark Callow writes... > > You don't need any other type of converter. You need an animation controller > > and a single frame VTR. Display the frame, record it, and move to the > > next one. > > -- > > From the TARDIS of Mark Callow > > msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc > > And my response is: WAIT WAIT WAIT not necessarily. > Thanks for your informative response. I was trying to say only that the same RGB to NTSC box should do regardless of whether you wanted to record real time or single frame. Obviously I wasn't clear enough. -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13424; 21 Nov 89 16:24 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac13137; 21 Nov 89 16:13 EST Received: from adm.brl.mil by VMB.BRL.MIL id aa13032; 21 Nov 89 15:59 EST Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa25392; 21 Nov 89 15:37 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA22476; Tue, 21 Nov 89 12:05:36 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Nov 89 19:52:14 GMT From: Robert Viduya Organization: Office of Computing Services, Georgia Tech Subject: Re: Updating directory views Message-Id: <3678@hydra.gatech.EDU> References: <17093@umn-cs.CS.UMN.EDU>, <45022@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > > There is something very wrong with your workspace, if your directory views > are not staying *perfectly* up to date with your file system. Can you > please check a few things for me. > 1. Make sure that the new file is not appearing out of sight > when you create it -- new files appear at the end of the directory > view. > > 2. do a ps -ef | grep fam, and see if anything comes up > > 3. check the permissions on the directory that is giving you > problems, and pass that information on to me > > 4. Open a directory view on another directory, and see if you > have the same kind of problem there. > > 5. (Not that this should make any difference ) Is this directory > NFS mounted? > Actually, NFS mounts do make a difference. The fam daemon runs as root and if you've got a NFS directory open in the workspace that has modes of something like 0700, and the NFS server has the filesystem exported WITHOUT root access, root will NOT be able to see into that directory. The effect that we've noticed here when that situation occurs is that on the initial open of the directory from the workspace all the files in that directory appear for a split second and then disappear. I reported this problem to the hot-line (problem number B3520) and was told that, yes, it was a problem and that, no, SGI wouldn't fix it. I've had to resort to telling my users that if they want to be able to access their files from the workspace, they need to make them publicly available for everyone else to access. robert -- Robert Viduya robert@shangri-la.gatech.edu Office of Computing Services Georgia Institute of Technology (404) 894-6296 Atlanta, Georgia 30332-0275   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15002; 21 Nov 89 19:31 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14828; 21 Nov 89 18:38 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa14813; 21 Nov 89 18:23 EST Received: from cypress.sgi.cs.net by SMOKE.BRL.MIL id aa03134; 21 Nov 89 17:51 EST Received: from forest.sgi.com by sgi.sgi.com (5.52/891101.SGI) for info-iris@brl.mil id AA18165; Tue, 21 Nov 89 14:48:00 PST Received: from localhost.sgi.com by forest.sgi.com (5.52/890923.SGI) for @sgi.sgi.com:info-iris@brl.mil id AA24456; Tue, 21 Nov 89 14:47:59 PST Message-Id: <8911212247.AA24456@forest.sgi.com> Cc: info-iris@BRL.MIL Subject: Re: Transfer Personal IRIS images to VCR In-Reply-To: Your message of 19 Nov 89 15:08:02 +0000. <11628@phoenix.Princeton.EDU> Date: Tue, 21 Nov 89 14:47:57 PST From: baskett%forest@sgi.com There are also some moderately priced video disk gadgets that can easily record frame by frame. We have one made by Panasonic, it was about $15K, can record about 15 minutes worth of video, but the blank disks cost about $100 each. Forest   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15799; 21 Nov 89 22:55 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15708; 21 Nov 89 22:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa15695; 21 Nov 89 22:31 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05833; 21 Nov 89 22:22 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA20413; Tue, 21 Nov 89 19:09:33 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Nov 89 03:02:36 GMT From: Steve Lamont Organization: Foo Bar Brewers Cooperative Subject: Re: Transfer Personal IRIS images to VCR Message-Id: <5783@alvin.mcnc.org> References: <1523@odin.SGI.COM>, <11628@phoenix.Princeton.EDU>, Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article jim@baroque.Stanford.EDU (unknown) writes: >ams@gauss.Princeton.EDU (Andrew Simms) writes: > > B. Abacus and others make a different type of controller. > This device sits on your ethernet and has a 1.2 Gigabyte > disk on it. You write software that FTPs your image > to the Abacus. ... > >Not completely true. I've used an Abekas (note the non-Webster >spelling) machine that took NTSC video input, digitized and stored it >on its big mama disk. It handled both realtime and frame by frame >animation. Actually, I think you're both right. There are several flavors of Abekas. The A60 is a digital disk with no NSTC input (that I know of, but I haven't completely figured the little bugger out yet). It does indeed look like a file system to your favorite file transfer protocol. The A64 and other versions are NTSC digitizers and twiddlers. The A60 comes in 25 and 50 second versions (I've heard rumors of 100 second versions, too, but they must be hellaciously expensive). The A64 will store 30 or 60 seconds (I believe) of captured video. If you're looking for a digital frame store that lives on the Ethernet, then the A60 is the beast that you want. spl (the p stands for pixels at an exhibition) -- Steve Lamont, sciViGuy EMail: spl@ncsc.org NCSC, Box 12732, Research Triangle Park, NC 27709 "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." || - Jeremy S. Anderson   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17534; 22 Nov 89 5:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17482; 22 Nov 89 5:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id ab17463; 22 Nov 89 5:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08727; 22 Nov 89 5:06 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15946; Wed, 22 Nov 89 01:59:01 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Nov 89 18:51:24 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Limit on windows? Message-Id: <1561@odin.SGI.COM> References: <21259@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <21259@uflorida.cis.ufl.EDU>, pff@beach.cis.ufl.edu (Pablo Fernicola) writes: > Is there a limit on the number of windows that can be opened using winopen()? > > Is about 100 windows okay? Should be fine except for performance issues. > > We are running a Personal Iris with 8 Megs of memory, is the number of > windows memory dependent? Yes. You can have as many windows as you can fit into your virtual memory. However performance will fall off as you start swapping. Some previous IRIX release for certain machines had bugs where more than 256 windows would break. I believe these are fixed in 3.2. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17596; 22 Nov 89 5:41 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17482; 22 Nov 89 5:20 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa17463; 22 Nov 89 5:09 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08725; 22 Nov 89 5:05 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA15861; Wed, 22 Nov 89 01:57:41 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Nov 89 19:00:03 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Message-Id: <1562@odin.SGI.COM> References: <8911201627.AA22191@jvncf.csc.org> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8911201627.AA22191@jvncf.csc.org>, shaginaw@JVNCF.CSC.ORG (Richard Shaginaw lac11205) writes: > A high-resolution scan converter from LyonLamb, Photron, YEM, or > others also permits single-frame animation, provided you also have a VCR > controller such as the LyonLamb MiniVas. The scan converter contains a The SIGGRAPH video crew tried out a variety of scan converters when they needed to show "Mike the Talking Head" live during the video show at SIGGRAPH '88 in Atlanta. They found the YEM box to be the best when working with their Eidophor projector. They had one specially flown in from Japan. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21587; 22 Nov 89 9:54 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19835; 22 Nov 89 8:45 EST Received: from smoke.brl.mil by VMB.BRL.MIL id aa19611; 22 Nov 89 8:28 EST Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01200; 22 Nov 89 8:18 EST Received: by ucbvax.Berkeley.EDU (5.61/1.39) id AA26754; Wed, 22 Nov 89 05:14:57 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Nov 89 01:54:36 GMT From: fox!portal!cup.portal.com!GEORGE_A_MANEY@apple.com Organization: The Portal System (TM) Subject: SILMA CIMSTATION DONATION AVAILABLE Message-Id: <24329@cup.portal.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL FMC corporate technology center has one seat of SILMA's CIMSTATION robot CAD package available for donation to a qualified nonprofit or charitable institution. CIMSTATION is a CAD system for designing and simulating the kinematics of robotic workcells. Both commercial workstations as well as custom robots are supported. Features include collision detection and robot programming language generation. The available license is for a SGI 3000 series workstation. It is currently running on an 3120 with 16 MB of RAM and 300 MB of disk. The workstation is not available for donation. Please contact me by telephone to discuss donation: (408) 289-2289. I do not generally read my Usenet mail. George Maneyok FMC Corporate Technology Center Santa Clara, California