------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10369; 25 Sep 87 3:09 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa09933; 25 Sep 87 1:18 EDT Date: Fri, 25 Sep 87 1:14:37 EDT From: Chuck Kennedy To: info-iris@BRL.ARPA Subject: new INFO-IRIS archive location announcement Message-ID: <8709250114.aa09930@VMB.BRL.ARPA> INFO-IRIS recently changed it's network address with the departure of John Brugge to the Artificial Intelligence field. Many thanks to John for his work in getting INFO-IRIS set up and functioning! Chuck Kennedy from the Ballistic Research Laboratory has taken over as the coordinator of INFO-IRIS. The mailing list has been functioning smoothly for several months now. The software archive has now been moved to BRL and is accessible at BRL-VGR.ARPA. For those users with FTP access to the ARPANet, these files can be retrieved from the directory info-iris on host BRL-VGR.ARPA [192.5.23.6] as user "anonymous" with any password. For those users without such access, but with electronic mail facilities with routing to the ARPANet, a request can be sent to Info-Iris-Request@BRL.ARPA to have any of these file(s) set via e-mail. Be advised that requests for files transferred via e-mail may take several days before the request is acknowledged. The preferred method for file transfer is via FTP. Archives of the mailing list up to 20 September 1987 are also available in the file info-iris.txt in the info-iris directory. The mail archives will be updated periodically. Submissions to the mailing list should be sent to: Requests to be added or deleted from the list, comments about operations, problems and administrative questions should be addressed to: INFO-IRIS, the network interest group for IRIS workstations, continues to offer users with electronic mail facilities the ability to communicate ideas, problems, questions and software. While there are large public domain software packages available for the IRIS (such as the BRL CAD package, GNU Emacs, Utah Raster Toolkit), many users have contributed several useful tools, utilities and patches worth sharing. IRIS users who have written software which they feel might be of interest to other IRIS users, and who would like to distribute it to via the INFO-IRIS group are encouraged to send their files by e-mail, along with a short description, to Info-Iris@BRL.ARPA. Software that is submitted by electronic mail to INFO-IRIS gets sent to all sites on the INFO-IRIS electronic distribution list, as well as being archived on the host that serves as the distribution point of INFO-IRIS. Below is the current listing of software kept on BRL-VGR.ARPA. A short description of the various software is included. The name and address of the person who sent in the submission is included to whom users may direct further questions about the particular software. The size of the files in eight bit bytes is included for reference as well. Directory listing of public domain software for Silicon Graphics IRIS workstations [Read: () ] 00DIR 1665(8) 24-Sep-87 05:00:00 An annotated directory listing (this file). 00README 1204(8) 24-Sep-87 05:00:00 General description of the Info-Iris network interest group drawcube.c 13806(8) 3-Nov-86 07:44:13 Backface polygon removal routines. Michael Zyda (zyda@nps-cs.arpa or ucbvax!dual!lll-crg!nps-cs!zyda) fonts 88495(8) 11-Dec-86 08:28:13 Files for creating fonts on the IRIS, as well as several font descriptions. Michael Zyda config.h 3686(8) 30-Oct-86 14:58:55 m-turbo.h 3403(8) 30-Oct-86 14:59:48 s-unipl50.h 4621(8) 30-Oct-86 14:59:35 Header files for GNU Emacs specific to the IRIS. John Brugge (brugge@sumex-aim.stanford.edu) newgnu.iris 15141(8) 1-May-87 15:51:15 Changes file for GNU Emacs to run under SGI IRIS Release 3.5 Eric Raible (raible@ames-nas.arpa) patches.c 35514(8) 11-Dec-86 08:21:23 Filled surface patches, as well as a simple lighting model. Michael Zyda qtest.c 3455(8) 23-Apr-87 21:21:51 A test of some possible bugs in the IRIS queue routines. A.L. McPherson (ssc-vax!voodoo!bhagwan@beaver.cs.washington.edu) timeserver.c 4846(8) 23-Apr-87 21:23:07 Functions for retrieving the date from another network host. Doug Kingston (dpk@brl.arpa) ttytest.c 2380(8) 23-Apr-87 21:24:19 Two test programs to demonstrate bugs with tty input in the 3.5 kernel. Steve Dempsey (sd%chem@sdcsvax.ucsd.edu) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11666; 1 Oct 87 16:54 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11535; 1 Oct 87 16:43 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa11458; 1 Oct 87 16:29 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa04859; 1 Oct 87 16:20 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Thu, 1 Oct 87 13:10:11 PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA21160; Thu, 1 Oct 87 12:56:48 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Oct 87 18:51:37 GMT From: Hugh LaMaster Organization: NASA Ames Research Center, Moffett Field, Calif. Subject: Re: Third Party Disks Message-Id: <2951@ames.arpa> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Does anyone have experience with using third party disks and controllers on Irises? Specifically, SCSI controllers and disks with 2400 Turbos and SMD disks with 2500 Turbos. People using Suns have spoken very highly of Ciprico controllers and various third party disks (Fujitsu Eagle series, CDC, etc.). Has anyone been successful at doing the same with Irises? Please post replies to the net if possible; otherwise, email also welcome. Hugh LaMaster, m/s 233-9, UUCP {topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov (Disclaimer: "All opinions solely the author's responsibility") ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13223; 6 Oct 87 22:31 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12461; 6 Oct 87 20:24 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab12437; 6 Oct 87 20:13 EDT Received: from [36.54.0.11] by SMOKE.BRL.ARPA id aa19398; 6 Oct 87 20:03 EDT Received: by lindy.stanford.edu; Tue, 6 Oct 87 16:26:04 PDT Date: Tue, 6 Oct 87 16:24:47 PDT From: PETER GRATZINGER To: info-iris@BRL.ARPA Message-ID: <8710062003.aa19398@SMOKE.BRL.ARPA> TO: INFO-IRIS@BRL.ARPA FROM: JERRY YESAVAGE, STANFORD RE: STATISTICAL PACKAGES???? We are currently doing flight simulation work on a Turbo-2400 and one of the new 3115 units. Our data analyses are labor intensive and we are looking for a UNIX based stat package which is public-domain or inexpensive. Alternatively, does anyone have experience running SAS or SPSS on an IRIS? We understand we can get a one year license for SPSS but that is prohibitive. Help? Jerry Yesavage 415-723-4270 or 493-5000 x4330 ms.jmb@forsythe.arpa P.S. We currently have the SF Bay Area on the IRIS for use with a FRASCA 141 simulator. Anyone else doing simulator work on the IRIS and interested in sharing scenery databases? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12062; 22 Oct 87 23:50 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12037; 22 Oct 87 23:48 EDT Date: Thu, 22 Oct 87 23:44:24 EDT From: Chuck Kennedy To: info-iris@BRL.ARPA Subject: [Michael Mascagni: Mailing list] Message-ID: <8710222344.aa12034@VMB.BRL.ARPA> ----- Forwarded message # 1: Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa10407; 22 Oct 87 17:26 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa16582; 22 Oct 87 17:12 EDT Received: from acf4.nyu.edu by SUMEX-AIM.STANFORD.EDU with TCP; Thu, 22 Oct 87 11:51:43 PDT Date: Thu, 22 Oct 87 14:10:54 edt From: Michael Mascagni Message-Id: <8710221810.AA23781@acf4.nyu.edu> Received: by acf4.nyu.edu; Thu, 22 Oct 87 14:10:54 edt To: Info-Iris-Request@Sumex-Aim.Stanford.EDU Subject: Mailing list Cc: mascagni@acf4.nyu.EDU Please put me on your Iris-Info mailing list. My mailing address is: elsie!ncifcrf!mascagni@mimsy.umd.edu Thanks in advance. By the way, do you or you mailing list people know of the spectral emmisivty data on the Red, Green, and Blue phosphors from the monitor to a 4D/60 workstation? I need this data in 10 nanometer increments from 380 nm to 700 nm. Thanks, Dr. Michael Mascagni National Institutes of Health (301) 496-4325 ----- End of forwarded messages ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19898; 28 Oct 87 10:22 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15854; 28 Oct 87 7:33 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15823; 28 Oct 87 7:20 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa06615; 28 Oct 87 7:07 EST Received: from lindy.stanford.edu by SUMEX-AIM.STANFORD.EDU with TCP; Wed, 28 Oct 87 04:08:36 PST Received: by lindy.stanford.edu; Tue, 27 Oct 87 23:24:48 PST Received: by Forsythe.Stanford.EDU; Tue, 27 Oct 87 23:25:42 PST Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 28 Oct 87 08:22:27 Date: Wed, 28 Oct 87 08:20:42 +0200 (Central European Summer Time) From: Knobi der Rechnerschrat Subject: Misc. Requests To: info-iris@sumex-aim.stanford.EDU X-Vms-To: X%"info-iris@SUMEX-AIM.STANFORD.EDU" Message-ID: <8710280707.aa06615@SMOKE.BRL.ARPA> Hallo everybody, I'm looking for the following PD code: 1.) A VT100 emulator for the 3100 and 4D/xx console terminal. 2.) ARPA style name and domain servers for TCP/IP. Additionaly one question: The 4D keyboard is unfortunalely emulating a PC/XT and not a VT100/220 (who (* flame *) has got that (* flame *) idea???). Is there a way to change that behaviour? Regards Martin Knoblauch TH-Darmstadt Dept. Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt West-Germany BITNET: ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10687; 29 Oct 87 23:17 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa09967; 29 Oct 87 20:40 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa09960; 29 Oct 87 20:33 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id ab00255; 29 Oct 87 20:22 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Thu, 29 Oct 87 17:15:29 PST Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA11216; Thu, 29 Oct 87 16:58:53 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 29 Oct 87 23:20:34 GMT From: Paul Connally Organization: University of Colorado, Boulder Subject: Knitting of Contours Message-Id: <2761@sigi.Colorado.EDU> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU This may not be the best place to post this but here it goes.. I am currently using an Iris 2400 (soon to be upgraded to a turbo) without Z-buffering (but may have soon) and I am looking for any information, algorithms, programs, so on and so forth on the teselation and/or knitting of contours in 3D to form solid surfaces and wire frames. The data is piped in as planes of contours (several to a plane). Any information as to acheive this in the most efficient manner (or any manner for that) would be most appreciated. If there is a better news group to post this I would also appreciate knowing that. Thanks in advance, Paul Connally "If you love something set it free, If it doesn't come back... Hunt it down and KILL IT." ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14066; 5 Nov 87 1:48 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa14006; 5 Nov 87 1:38 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa13895; 5 Nov 87 1:29 EST Received: from ames.arpa by SMOKE.BRL.ARPA id aa13677; 5 Nov 87 1:26 EST Received: Wed, 4 Nov 87 22:27:36 PST by ames.arpa (5.58/1.2) Received: from elvin.SGI.COM by sgi.sgi.com (5.52/871028.vjs) for info-iris@brl.arpa id AA05987; Wed, 4 Nov 87 21:41:05 PST Received: by elvin (5.51/871028.vjs) for info-iris@brl.arpa id AA21415; Wed, 4 Nov 87 21:43:16 PST From: Frank Dietrich Message-Id: <8711050543.AA21415@elvin> Date: 4 Nov 1987 2143-PST (Wednesday) To: info-iris@BRL.ARPA Cc: dietrich@sgi.COM Subject: fall issue of IRIS Universe COME TOGETHER (and other well known slogans by the fab four) is the motto of the fall issue of the IRIS Universe. It should be in your (physical) mail boxes within the next two weeks. If you haven't subscribed yet, send me a note. The cover shows a multi-window data-flow manager, discussed in the magazine. Other topics are: electronic publishing, a layered user interface, antique planes & starships for flight, Kyoto Common Lisp, medical imaging, user group activities, and more goodies. Announcing a new issue means the editors start preparing the next one. We have an ongoing call for your projects, pictures, and perspectives. We're keeping our eyes open. Thank you. Frank Dietrich, editor [ Change of address: I am no longer at the University of Utah. You can contact me at (415) 494-9019, ] ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14170; 5 Nov 87 1:59 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa13543; 4 Nov 87 23:40 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa13538; 4 Nov 87 23:30 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa12082; 4 Nov 87 23:26 EST Received: from lindy.stanford.edu by SUMEX-AIM.STANFORD.EDU with TCP; Wed, 4 Nov 87 20:27:18 PST Received: by lindy.stanford.edu; Wed, 4 Nov 87 20:24:43 PST Received: by Forsythe.Stanford.EDU; Wed, 4 Nov 87 20:25:40 PST Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 04 Nov 87 08:42:03 Date: Wed, 4 Nov 87 08:39:29 +0200 (Central European Summer Time) From: Knobi der Rechnerschrat Subject: NFS problems and RE:RE:VT100/Keyboard To: info-iris@sumex-aim.stanford.EDU X-Vms-To: X%"info-iris@sumex-aim.stanford.edu" Message-ID: <8711042328.aa12082@SMOKE.BRL.ARPA> Hallo, First in my posting, I have a serious problem. We are running three IRIS 31xx on an ethernet with TCP/IP and NFS. We have Rev. 3.5r1 of the software (Rev. 1.00 of NFS). On one machine we have a Fujitsu Eagle which is local (EFS) to that machine and a NFS-disk to the remaining two stations. Beside a few/lot problems we have encountered with NFS (dbx, graphics, priority, etc., all posted month ago) I yesterday traced another bug (as I assume): Some programs (e.g. good old Kermit) do wild card expansions in their code. Due to the lack of existing routines the do it by their own (see the "expand" modules in Kermit). They use (due to the lack of BSD like opendir/closedir routines) open and read statement to access the directory files (which are told to be "normal" files with the exeption that you cannot write them). Now the problem: with the EFS directories everything works fine, with the NFS directories everything I get from read seems to be junk. Result: I cannot use Kermit to do wildcard get/send's on the NFS disks. Is this a problem/bug or feature? Is this known? Will this be fixed in the next (3.6) release? (Sorry for the DEC slang) Second: I would like to thank Michael Toy for his reply to my posting from last week. I'm unfortunately unable to reply directly. Michael: I didn't know that a 24x80 wsh window is a vt100 emulator (what about the (* flame again *) keyboard?). I had that machine only for four days and couldn't discover all new features. And again: Is there a PD VT100 emulator for the 31xx console? Concerning the keyboard, I dont't complain that much about the physical layout. I can live with 17 keys on they keypad instead of the "standard" 18. But what I hate are the (* flame *) ESC sequences that are generated by that child of IBM compatibility (* general flame: Is having a three letter abrevation for the companies name not compatible enough ??? *). Is there a easy way to remap that sequences to a more handy set? If the ad's say: "Just recompile the 31xx code and enjoy" this should not only be (almost) true for the graphics, but also for the lower classes of applications. And the 4D keyboard is INCOMPATIBLE to the 31xx. Regards Martin Knoblauch TH-Darmstadt Dept. Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt West-Germany BITNET: ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa09799; 7 Nov 87 5:07 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa09343; 7 Nov 87 3:02 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa09326; 7 Nov 87 2:48 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa14489; 7 Nov 87 2:42 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Fri, 6 Nov 87 23:42:58 PST Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA13743; Fri, 6 Nov 87 23:42:35 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Nov 87 03:58:28 GMT From: Vernon Schryver Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: NFS problems Message-Id: <7773@sgi.SGI.COM> References: <8711042328.aa12082@SMOKE.BRL.ARPA> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <8711042328.aa12082@SMOKE.BRL.ARPA>, XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: - Some programs (e.g. good old Kermit) do wild card expansions in their - code. Due to the lack of existing routines the do it by their own (see - the "expand" modules in Kermit). They use (due to the lack of BSD like - opendir/closedir routines) open and read statement to access the - directory files (which are told to be "normal" files with the exeption - that you cannot write them). Now the problem: with the EFS directories - everything works fine, with the NFS directories everything I get from - read seems to be junk. Result: I cannot use Kermit to do wildcard - get/send's on the NFS disks. Is this a problem/bug or feature? Is this - known? Will this be fixed in the next (3.6) release? In summary, this is a feature, not a bug, of NFS. In detail: It might be called a bug in how Kermit was compiled for your machine. If you got it from SGI, you ought to send a bug report to the hotline. The familiar BSD opendir(3)/closedir(3) routines are available on IRIS's. Both BSD and SV flavor opendir/closedir functions are available. They work on EFS, NFS, and BFS file systems. To get BSD flavor, you must use '-lbsd' and '-I/usr/include/bsd' with ld and cc. For BSD style programing, you generally want to use '-lsun -lbsd' and '-I/usr/include/sun -I/usr/include/bsd' to get Y.P. support. Y.P. will not work unless you also have NFS, but linking with it will do no harm. In EFS, it is possible to abuse file directories with open(2) and read(2). However, it would be wise not to count on such a 'facility.' As is standard in NFS, you get EOF on the 1st read(2) of an NFS file directory. The only coming change in this area that I recall, is that we will track the change made in the SVR3.1 SVID to the magic cookie from telldir(3). This means that both flavors of cookie will have the same taste. :-) Cheers, Vernon Schryver Silicon Graphics, Mtn.View, Ca94043 vjs@sgi.com or {decwrl,sun,adobe,pyramid,research}!sgi!vjs ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00322; 11 Nov 87 11:25 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab00095; 11 Nov 87 11:14 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa06620; 9 Nov 87 20:31 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa27003; 9 Nov 87 20:29 EST Received: from ulysses.uchicago.edu ([128.135.28.5].#Internet) by SUMEX-AIM.STANFORD.EDU with TCP; Mon, 9 Nov 87 17:28:29 PST Return-Path: Received: by ulysses.uchicago.edu (5.15/1.0G) id AA06987; Sun, 8 Nov 87 15:38:35 CST Date: Sun, 8 Nov 87 15:38:35 CST From: "Stuart A. Schmukler" Full-Name: Stuart A. Schmukler Message-Id: <8711082138.AA06987@ulysses.uchicago.edu> To: info-iris@sumex-aim.stanford.EDU, sas1@ulysses.uchicago.EDU Cc: ejaz@ulysses.uchicago.EDU, ronr@sphinx, staff.dhg@chip Hello: We have an IRIS 2500T on which we are tring to bring up CAPS (Columbia AppleTalk Protocol Suite?). -Has anyone else done this? We are running into problems with CAPS need for BSD type functions namely: gettimeofday #include #include I have looked in the man pages and found references to both include files But the files themselfs don't exist. So, I checked the /usr/lib/lib* files for strings that should exist if the routines exist -- I found them. What is wrong? Did we srew-up our system? I check the distribution tape. But this is odd. SaS ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id ab00322; 11 Nov 87 11:25 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ac00095; 11 Nov 87 11:14 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa07959; 10 Nov 87 2:56 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa29544; 10 Nov 87 2:44 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Mon, 9 Nov 87 23:47:17 PST Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA16304; Mon, 9 Nov 87 23:29:54 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Nov 87 04:14:07 GMT From: Chris Ott Organization: Computer-Aided Engineering Lab (CAEL), Subject: NFS problems Message-Id: <434@amethyst.ma.arizona.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU I decided to post this article, since there is a very good possibility (I think) that many other people are having the same problem. sparks@batcomputer.tn.cornell.edu (Steve Gaarder) writes: > We, too, are having lots of trouble with NFS. We have two Iris 3020's > which are set up as clients with a Vaxstation II/GPX running Ultrix > 2.0 as the server. We have the following trouble: > > 1. "pwd" does not work in most (but not all) NFS directories. It gives > "read error in .." > > 2. C-shell scripts do not work in the same directories. The error here is > "file not found". Bourne shell scripts run fine. > > 3. Occasionally, if there are 2 or more users running ld, the server > or one of the clients will crash. > > Any and all suggestions for fixes would be greatly appreciated. Students > have managed to cope ok, but our developers now refuse to work in NFS > directories. At my lab, the IRISes have a file system mounted from a Sun, and I had the same problems, initially. Fortunately, the IRISes are on maintainence, so I called the Hotline. The engineer told me the problem: the IRIS's file system uses 16-bit I-node numbers, while the Sun's file system uses 32-bit I-node numbers. I suspect you are having the same problem with your system. This is how they told me to fix it: remake the Sun's file system (the Vax's, in your case) so that only 65535 I-nodes are reserved. This way, you can never get an I-node number that is larger than the IRIS's 16 bits can represent. Unfortunately, "mkfs" only has a parameter to set the number of bytes per I-node. This isn't a real problem, though, since you just have to take the number of bytes in the file system and divide it by 65535. For example, on my file system, there are 237200000 bytes (approximately). Divide it by 65535 and you get 3620. So, when I did the "mkfs", I told it to allocate one I-node for every 3620 bytes. Of course, the Vax may use blocks instead of bytes, in which case you will have to convert the size of the file system to blocks. If it helps any, the name of the "mkfs" parameter in the "man" pages for my system is "nbpi". It may be different for yours, but I'm not sure. I haven't had any problems since. ------------------------------------------------------------------------------- Chris Ott Computer-Aided Engr. Lab It is impossible to make anything foolproof University of Arizona because fools are so ingenious. Internet: chris@spock.ame.arizona.edu UUCP: {allegra,cmcl2,hao!noao}!arizona!amethyst!spock!chris ------------------------------------------------------------------------------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00113; 11 Nov 87 11:52 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00095; 11 Nov 87 11:14 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa05454; 9 Nov 87 17:25 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa24828; 9 Nov 87 17:18 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Mon, 9 Nov 87 14:18:07 PST Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA04607; Mon, 9 Nov 87 14:12:25 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Nov 87 19:40:27 GMT From: Steve Gaarder Organization: Computer Aided Design Instructional Facility, Cornell Univ. Subject: Re: NFS problems Message-Id: <2868@batcomputer.tn.cornell.edu> References: <8711042328.aa12082@SMOKE.BRL.ARPA> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU We, too, are having lots of trouble with NFS. We have two Iris 3020's which are set up as clients with a Vaxstation II/GPX running Ultrix 2.0 as the server. We have the following trouble: 1. "pwd" does not work in most (but not all) NFS directories. It gives "read error in .." 2. C-shell scripts do not work in the same directories. The error here is "file not found". Bourne shell scripts run fine. 3. Occasionally, if there are 2 or more users running ld, the server or one of the clients will crash. Any and all suggestions for fixes would be greatly appreciated. Students have managed to cope ok, but our developers now refuse to work in NFS directories. -- Steve Gaarder Cornell University, 171 Hollister, Ithaca NY 14853 607-255-5389 UUCP: {cmcl2,decvax,rochester,uw-beaver,ihnp4}!cornell!batcomputer!sparks BITNET: sparks@crnlthry.BITNET ARPA: sparks@tcgould.tn.cornell.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa02214; 11 Nov 87 20:33 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa02188; 11 Nov 87 20:23 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa02177; 11 Nov 87 20:09 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa05444; 11 Nov 87 20:09 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Wed, 11 Nov 87 17:11:10 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA10977; Wed, 11 Nov 87 16:29:39 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Nov 87 18:25:28 GMT From: Vernon Schryver Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: NFS problems and RE:RE:VT100/Keyboard Message-Id: <7890@sgi.SGI.COM> References: <8711042328.aa12082@SMOKE.BRL.ARPA>, <2868@batcomputer.tn.cornell.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <2868@batcomputer.tn.cornell.edu>, sparks@batcomputer.tn.cornell.edu (Steve Gaarder) writes: > We have the following trouble: > 1. "pwd" does not work in most (but not all) NFS directories. It gives > "read error in .." > 2. C-shell scripts do not work in the same directories. The error here is > "file not found". Bourne shell scripts run fine. Well, nobody's perfect... :-) The infamous "can't pwd" problem and, I think the csh problem, is a difficulty with System V file directories. Your server probably has a large file system with >64K inodes. Standard SV gives i-numbers 16 bits in many places, including stat.h. That makes things like ftw(3), pwd(1), and so on unhappy when they try to stat(2) a file descriptor, and then use readdir/getdents to find its name. (Yes, pwd(1) does something else, but the problem is the same.) In the latest version of EFS for the IRIS 4D, we changed to 32-bit i-numbers and recompiled the world. We could do that since we had control of all 4D binaries and file systems in the world. However, release 3.5 and 3.6 kernels were/will be binary compatible for application programs. This means we could not change ino_t in types.h to a long (one of things done for the new EFS on the 4D). Fortunately, there is a hack involving type punning in the user code that makes csh, pwd, and other utilities work 99.999999% of the time (Yes, that's what I calculate it to be :-). 3.6 will have the hack in all of the places that matter. Contact the hotline if you're application code messes with i-numbers and you need the hack. Try them if you need help before you receive 3.6. You might not need more than 64K inodes on your server file system. A 300MB disk should have about 70K inodes, assuming 'typical' file sizes. You might want to check 'df -i' or the ULTRIX equivalent to see if you could rebuild it with <64K inodes. > 3. Occasionally, if there are 2 or more users running ld, the server > or one of the clients will crash. If the Microvax, crashes, you should call the manufacturer. If an IRIS crashes, call the hotline. We can only fix the problems the hotline tells us about or that we find ourselves. Inside SGI we use NFS quite heavily for development. The source servers tend to be 4D's with Eagles with 80K inodes. Most of the hundreds of clients are 3000's, but there are plenty of 4D's and others. I daily use two 3030's and four 4D's as clients and servers for kernel and user-code builds and debugging--all linked with NFS. The news article to which I'm responding is NFS mounted on my personal 3030. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03451; 12 Nov 87 1:07 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa03395; 12 Nov 87 0:56 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa03387; 12 Nov 87 0:53 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa09532; 12 Nov 87 0:48 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Wed, 11 Nov 87 21:50:02 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA17257; Wed, 11 Nov 87 21:24:58 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Nov 87 03:10:15 GMT From: George Hartzell Organization: University of Colorado, Boulder Subject: Re: (none) Message-Id: <2924@sigi.Colorado.EDU> References: <8711082138.AA06987@ulysses.uchicago.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <8711082138.AA06987@ulysses.uchicago.edu> sas1@ULYSSES.UCHICAGO.EDU ("Stuart A. Schmukler") writes: >Hello: > >We are running into problems with CAPS need for BSD type functions namely: > gettimeofday > #include > #include > >I have looked in the man pages and found references to both include >files But the files themselfs don't exist. So, I checked the Have you looked in /usr/include/bsd/*... and /lib/libbsd.a for the stuff you need? g. George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{hao,nbires}!boulder!hartzell ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19958; 13 Nov 87 2:14 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa19277; 12 Nov 87 23:17 EST Received: from sem.brl.mil by VMB.BRL.ARPA id aa19242; 12 Nov 87 23:10 EST Date: Thu, 12 Nov 87 23:00:21 EST From: Mike Muuss To: Vernon Schryver cc: info-iris@BRL.ARPA Subject: Re: NFS problems and RE:RE:VT100/Keyboard Message-ID: <8711122300.aa16787@SEM.BRL.ARPA> The "stat" problem can be easily solved, while retaining binary compatability, by renaming the existing syscall numbers as "oldstat" and "oldfstat" (the only two affected syscalls), providing --special-- code in the kernel to return the old (16-bit size) STAT data, and then install two new syscall numbers that are assigned to "stat" and "fstat". Thus, old code continues to see what it expects, while any code recompiled will get the new #include files, and will link with the new sys-call interface routines in libc. If SGI ships 3.6 without a reliable fix for this problem, I will be personally very furious, because the 3030 on my desk stubs it's toes on this every few hours. I hope you will seriously consider adding the necessary 20 lines of code to the kernel (and similar amount to libc) to eliminate this problem. Best, -Mike ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa22706; 16 Nov 87 11:12 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa16074; 16 Nov 87 8:33 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15558; 16 Nov 87 8:21 EST Received: from [128.196.1.3] by SMOKE.BRL.ARPA id aa02962; 15 Nov 87 1:31 EST Date: Sat, 14 Nov 87 21:59 MST From: DOLATA@rvax.ccit.arizona.EDU Subject: PROLOG for IRIS ?? To: info-iris@BRL.ARPA X-VMS-To: IN%"info-iris@brl.arpa" Message-ID: <8711150131.aa02962@SMOKE.BRL.ARPA> I am looking for a PROLOG system that runs on the IRIS. I might accept any PROLOG system, but the ideal system would be one which: 1) was available in source so that I could also port it on my NCUBE parallel machine (for which NO PROLOG systems exist) 2) was cheap Please send a cc to me (dolata@rvax.ccit.arizona.edu) as well as to info-iris. Ta' Dan ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa24050; 16 Nov 87 12:14 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa16995; 16 Nov 87 8:56 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa16812; 16 Nov 87 8:49 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa09280; 15 Nov 87 17:02 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Sun, 15 Nov 87 14:04:22 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA01910; Sun, 15 Nov 87 13:48:13 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Nov 87 11:03:00 GMT From: Michael Mascagni Organization: New York University Subject: Help me make a video! Message-Id: <17280001@acf4.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU I have been working on a SGI 4D/60 system producing colored animation of solutions to time dependent partial differential equations solved on a Cray X/MP we have ethernetted to the graphics workstation. I really want to use the RGB outputs of the color monitor to make movies. I have experience with a straight color film recorder, where the RGB from a device are used directly to phototgraph the RGB components of the film, and the frame is advanced in the camera via a trigger from the video monitor. Film is really quite nice, but it would be nicer if I could do essentially the same thing (frame by frame triggered recording) onto VHS format video tape. Thus my question to you out there is if any of you have facilities for doing this please tell me what hardware you use, and if you can a little about the spatial and color resolution of your final products. I am really not interested in an entire video editing system, and if new video camera technologies (with triggers) do exist that give high resolution I would also be interested. Thanks a heap, Michael Mascagni mascagni@acf4.nyu.edu elsie!ncifcrf!mascagni@mimsy.umd.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa07872; 17 Nov 87 15:14 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00086; 17 Nov 87 11:56 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa13234; 17 Nov 87 11:33 EST Received: from eneevax.umd.edu by SMOKE.BRL.ARPA id aa09911; 17 Nov 87 11:21 EST Received: by eneevax.umd.edu (5.9/4.7) id AA26311; Mon, 16 Nov 87 12:33:39 EST Date: Mon, 16 Nov 87 12:33:39 EST From: Juey-Chong Ong Message-Id: <8711161733.AA26311@eneevax.umd.edu> To: DOLATA@rvax.ccit.arizona.EDU, info-iris@BRL.ARPA Subject: Re: PROLOG for IRIS ?? How about C-PROLOG from the University of Edinburgh? Source code is provided and it works on VMS and BSD Unix systems. I don't know if it'll work on the IRIS or other SysV type machines. --jc ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa27322; 19 Nov 87 6:04 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26722; 19 Nov 87 3:45 EST Received: from RELAY.CS.NET by VMB.BRL.ARPA id aa12678; 3 Nov 87 14:27 EST Received: from relay2.cs.net by RELAY.CS.NET id af04278; 3 Nov 87 13:01 EST Received: from math.waterloo.edu by RELAY.CS.NET id ad07740; 3 Nov 87 12:59 EST Received: from watcgl.uucp (watcgl) by watmath; Tue, 3 Nov 87 12:39:59 EST Received: by watcgl; Tue, 3 Nov 87 12:39:55 EST Date: Tue, 3 Nov 87 12:39:55 EST From: Rob Dickinson Message-Id: <8711031739.AA24494@watcgl.uucp> To: info-iris-request@BRL-VMB.ARPA Subject: Re: Knitting of Contours Newsgroups: uw.iris In-Reply-To: <2218@watcgl.waterloo.edu> Organization: U. of Waterloo, Ontario Cc: Resent-Date: Thu, 19 Nov 87 3:40:12 EST Resent-From: Chuck Kennedy Resent-To: info-iris@BRL In article <2218@watcgl.waterloo.edu> you write: >From: Paul Connally > > The data is piped in > as planes of contours (several to a plane). Any information > as to acheive this in the most efficient manner (or any manner > for that) would be most appreciated. K. R. Sloan, and J. Painter, "From Contours to Surfaces: testbed and initial results", Proc. CHI+GI 1987, Human Factors in Computing Systems and Graphics Interface, (Special issue of ACM-SIGCHI Bulletin), pp115-125 might be of interest. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa27438; 19 Nov 87 6:56 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26744; 19 Nov 87 3:57 EST Received: from BRAGGVAX.ARPA by VMB.BRL.ARPA id aa11708; 17 Nov 87 10:26 EST Message-Id: <8711171527.AA03046@braggvax.arpa> To: info-iris-request@brl-vmb.arpa Subject: Graphics Package For Iris 3020 Date: Tue, 17 Nov 87 10:27:38 EST From: sigcen@braggvax.arpa Resent-Date: Thu, 19 Nov 87 3:52:10 EST Resent-From: Chuck Kennedy Resent-To: info-iris@BRL IRIS Users - We have an IRIS 3020 here at Fort Gordon. We run Informix and a custom-built tactical communications network simulation on it. While the IRIS family is capable of some very complex graphics, we would like to also do some "simpler" two dimensional flow charting with custom fonts and templates. However, we would like to avoid CAD/CAM packages. Does any user know of a commercial graphics package for the IRIS with capabilities similar to the Lotus's Freelance Plus or Microsoft Chart? It can be in B/W but color is preferred. Your suggestions would be greatly appreciated. Thank You. T.K. Wood US ARMY SIGNAL CENTER Fort Gordon GA 404-791-3782 sigcen@braggvax.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01614; 19 Nov 87 12:01 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa01437; 19 Nov 87 11:51 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa01321; 19 Nov 87 11:41 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa26044; 19 Nov 87 10:54 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Thu, 19 Nov 87 00:26:33 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA14942; Wed, 18 Nov 87 23:54:25 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Nov 87 17:58:27 GMT From: _/**/Sam_Fulcomer Organization: Brown University Computer Science Dept. Subject: Re: NFS problems and RE:RE:VT100/Keyboard Message-Id: <20594@brunix.UUCP> References: <8711122300.aa16787@SEM.BRL.ARPA> Sender: info-iris-request@SUMEX-AIM.Stanford.EDU To: info-iris@SUMEX-AIM.Stanford.EDU In article <8711122300.aa16787@SEM.BRL.ARPA> mike@BRL.ARPA (Mike Muuss) writes: >If SGI ships 3.6 without a reliable fix for this problem... Well, I'll be a little unhappy if SGI doesn't cough up the promised, generally reworked, NFS. In addition to the problems I outlined in an earlier posting (mostly to do with heterogeneous networks) I've come up with an ugly little problem with links in nfs mounts. The kernel lookup code doesn't properly deal with links on the nfs filesystem under some circumstances (e.g. baby:/usr nfs 100672 83961 16711 83% /usr /usr/lib/crontab -> /private/usr/lib/crontab # vi /usr/lib/crontab :w Yields: Permission denied [Warning - /usr/lib/crontab is incomplete] It doesn't make any difference if /private/usr/lib/crontab doesn't exist ) Sam ------------------------------------------------------------------------- BITNET sgf@BROWNCS CSNET sgf@cs.brown.edu ARPANET sgf%cs.brown.edu@relay.cs.net UUCP {ihnp4,allegra,decvax,princeton}!brunix!sgf TELECOM 401-863-3618 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03355; 20 Nov 87 16:32 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa01238; 20 Nov 87 14:37 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa01118; 20 Nov 87 14:21 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa00569; 20 Nov 87 14:11 EST Date: Fri, 20 Nov 87 11:10:01 PST From: Craig Cornelius Subject: Programming question To: info-iris@SUMEX-AIM.STANFORD.EDU Message-ID: <12352172491.17.CORNELIUS@SUMEX-AIM.STANFORD.EDU> I'm writing a network interface (TCP/IP) for a program (written in C for an IRIS 3020) that also does graphics display. The idea is that the program will accept a connection over the net, check the connection for commands, and then interpret the commands and change the display appropriately. In an early version of this, Bruce Duncan of our lab had the display responding to mouse positions and other commands from a Xerox 11XX LISP workstation. The problem: SELECT is a graphics routine. There is also a SELECT routine for determining in a network message has been received. I want to use both! Does SGI have a solution to this problem? Has anyone else developed a work-around? Our initial solution was to use IOCTL to use the network connection as if it were a stream from a terminal, but this is really hacky and not at all in the spirit of network interfacing. Comments and suggestions are welcome. Craig Cornelius ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05203; 20 Nov 87 21:28 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa05160; 20 Nov 87 21:18 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa05134; 20 Nov 87 21:09 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa07804; 20 Nov 87 21:06 EST Received: from sdcsvax.UCSD.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Fri, 20 Nov 87 18:04:32 PST Received: by sdcsvax.UCSD.EDU (5.57/5.0) id AA05160 for info-iris@sumex-aim.stanford.edu; Fri, 20 Nov 87 18:03:55 PST Received: by chem.chem.ucsd.edu (5.44) id AA10532; Fri, 20 Nov 87 18:06:54 PST Received: by sdcheme.chem.ucsd.arpa (5.51) id AA22072; Fri, 20 Nov 87 18:05:33 PST Date: Fri, 20 Nov 87 18:05:33 PST From: Steve Dempsey Message-Id: <8711210205.AA22072@sdcheme.chem.ucsd.arpa> To: Cornelius@SUMEX-AIM.STANFORD.EDU, info-iris@SUMEX-AIM.STANFORD.EDU Subject: Re: Programming question SGI has changed the name of their graphics library routine 'select' to 'gselect' to take care of this problem. This change was effective with the 3.5 software release. See pages 4-39 and 4-40 of the release notes for details. The 'select' name is still in the graphics library, so in order to get the BSD call you have to make sure the BSD library precedes the graphics library in the loader command, as in: cc prog.c -lbsd -Zg ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05258; 20 Nov 87 21:40 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa04953; 20 Nov 87 20:03 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa04911; 20 Nov 87 19:51 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa07176; 20 Nov 87 19:31 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Fri, 20 Nov 87 12:42:39 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA02959; Fri, 20 Nov 87 12:03:25 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Nov 87 07:20:54 GMT From: Chris Ott Organization: Computer-Aided Engineering Lab (CAEL), University of Arizona Subject: Help me make a video! Message-Id: <482@amethyst.ma.arizona.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Michael Mascagni writes: >I have been working on a SGI 4D/60 system producing colored animation of >solutions to time dependent partial differential equations solved on a >Cray X/MP we have ethernetted to the graphics workstation. I really want >to use the RGB outputs of the color monitor to make movies. I have experience >with a straight color film recorder, where the RGB from a device are used >directly to phototgraph the RGB components of the film, and the frame is >advanced in the camera via a trigger from the video monitor. Film is really >quite nice, but it would be nicer if I could do essentially the same thing >(frame by frame triggered recording) onto VHS format video tape. Thus my >question to you out there is if any of you have facilities for doing this >please tell me what hardware you use, and if you can a little about the >spatial and color resolution of your final products. I am really not >interested in an entire video editing system, and if new video camera >technologies (with triggers) do exist that give high resolution I would >also be interested. Well, Michael, I talked to a friend of mine who works at a local television station, and knows *a lot* about video. He says there are a few problems with what you want to do. First, as far as he knows, there are no VHS machines that can do frame- by-frame recording. There are 3/4-inch machines that can do single-frame recording, but they need five seconds of pre-roll time. This means that you would have to back up the tape to five seconds before the frame you want to record, skip over those five seconds, and record the frame at the end of those five seconds. Then, for the next frame, you would have to back it up five seconds again, and repeat the process. This must be done for *every frame* you want to record. This would obviously put a lot of wear on the tape. There are a few 1-inch machines that will do frame-by-frame recording without the pre-roll time, but these are expensive ($50,000 and up). Some even come with a built-in RS-232 serial interface so that you can control the machine from your computer. Again, if there is a long time between the recording of each frame, the tapes will wear out quickly. A video tape machine is not the only thing you need. You also need a color encoder and, if you want broadcast quality video, a sync generator to convert the IRIS's RGBS signal into NTSC format video. A cheap version of each box is about $1000 apiece. Where I work, we have a 3/4-inch VCR, a color-encoder, and a sync generator. Since the VCR can't do frame-by-frame recording, we have to set up the animation so it runs in real time. Sometimes, it's not easy to cut out enough of the picture so that it runs fast enough, and looks intelligible at the same time. Anyway, that's my experience. Any corrections to the above are welcome. ------------------------------------------------------------------------------- Chris Ott Computer-Aided Engr. Lab Acid absorbs 47 times its University of Arizona weight in excess Reality. Internet: chris@spock.ame.arizona.edu UUCP: {allegra,cmcl2,hao!noao}!arizona!amethyst!spock!chris ------------------------------------------------------------------------------- ------- Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab05203; 20 Nov 87 21:29 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa05194; 20 Nov 87 21:27 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa07814; 20 Nov 87 21:12 EST Received: from lanai.cs.ucla.edu by SUMEX-AIM.STANFORD.EDU with TCP; Fri, 20 Nov 87 18:11:33 PST Return-Path: Received: from LocalHost.ARPA by lanai.cs.ucla.edu (Sendmail 5.58.2/1.13) id AA02004; Fri, 20 Nov 87 18:08:20 PST Message-Id: <8711210208.AA02004@lanai.cs.ucla.edu> To: Chris Ott Cc: info-iris@SUMEX-AIM.STANFORD.EDU Subject: Re: Help me make a video! In-Reply-To: Your message of 20 Nov 87 07:20:54 +0000. <482@amethyst.ma.arizona.edu> Date: Fri, 20 Nov 87 18:08:19 PST From: Vulture of Light > Well, Michael, I talked to a friend of mine who works at a local >television station, and knows *a lot* about video. He says there are a few >problems with what you want to do. I've always been under the impression that the ~$50K figure should really be around ~$3K, and that it isn't due purely to marketing considerations. For people with small pocketbooks that are interested in previewing animation quickly (that rules out film...), I'd suggest a cheap black-and-white single frame VCR. I used one in an animation class here at UCLA 4 years ago, and it was perfect. For the final project, beg some place with real equipment to let you use it at night... direct to video, or 35mm and then transfer to video. douglas [][] trainor@cs.ucla.edu [][] ...!{ihnp4,randvax,sch-loki,ucbvax}!ucla-cs!trainor ------- Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa07507; 21 Nov 87 6:04 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa07440; 21 Nov 87 5:58 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa12204; 21 Nov 87 5:44 EST Received: from SEM.BRL.MIL by SUMEX-AIM.STANFORD.EDU with TCP; Sat, 21 Nov 87 02:42:43 PST Date: Sat, 21 Nov 87 3:40:14 EST From: Mike Muuss To: Craig Cornelius cc: info-iris@SUMEX-AIM.STANFORD.EDU Subject: Re: Programming question Message-ID: <8711210340.aa03573@SEM.BRL.ARPA> In the case of the BRL CAD Package, we make a privage copy of /usr/lib/libdbm.a and /usr/lib/libgl2.a, delete select.o, then add libbsd.a. This, and other vendor-specific brain-damage, means that the MAKE rule for libfb.a (our device-independent framebuffer library) look like this: # On the Silicon Graphics (and in the future perhaps others), # include the vendor's library within our own, so that linking # with libfb.a is sufficient to make pictures. # ${PRODUCTS}: $(OBJS) -if test x${SYSVERS} = xSGI34 ; then \ rm -fr tmp; mkdir tmp; rm -f ${PRODUCTS}; cd tmp; \ ${AR} x /usr/lib/libsocket.a; \ ${AR} uv ../${PRODUCTS} *; \ rm -f *; \ ${AR} x /usr/lib/libgl2.a; \ ${AR} uv ../${PRODUCTS} *; \ cd ..; rm -fr tmp; \ fi -if test x${SYSVERS} = xSGI35 ; then \ rm -fr tmp; mkdir tmp; rm -f ${PRODUCTS}; cd tmp; \ ${AR} x /usr/lib/libdbm.a; \ ${AR} x /usr/lib/libgl2.a; \ rm -f select.o; \ ${AR} x /usr/lib/libbsd.a; \ ${AR} uv ../${PRODUCTS} *; \ cd ..; rm -fr tmp ; \ fi -if test x${SYSVERS} = xUNICOS20 ; then \ cp /usr/lib/libnet.${ARCH_SUF} ${PRODUCTS}; \ fi -if test x${SYSVERS} = xSUN3 ; then \ rm -fr tmp; mkdir tmp; rm -f ${PRODUCTS}; cd tmp; \ ${AR} x /usr/lib/libsuntool.a; \ ${AR} x /usr/lib/libsunwindow.a; \ ${AR} x /usr/lib/libpixrect.a; \ ${AR} uv ../${PRODUCTS} *; \ cd ..; rm -fr tmp; \ fi ${AR} uv ${PRODUCTS} ${OBJS} ${RANLIB} ${PRODUCTS} Also, note that I consider a vendor providing a library with "unqualified" named as hopelessly naive. What body of user software for doing graphics does not already have subroutines called "move", "draw", etc? I had to modify hundreds of lines of code in our CAD Package to permit linking with GL2 at all. Things should have been called gl2_select(), as a minimum. I understand that in the dim dark days of older versions of the eternally wonderful and unchanging SystemV standard, CC was unable to handle symbols that were the same in the first 8 characters. Sun scores better in this regard, typically with 4-letter prefixes, and wonderfully long and obtuse function names. Of course, ADA (boo) and C++ handle this problem in a more powerful way. Best, -Mike ------- Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa27074; 19 Nov 87 5:01 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa20880; 18 Nov 87 13:19 EST Received: from UUNET.UU.NET by SMOKE.BRL.ARPA id aa04872; 18 Nov 87 12:36 EST Received: from munnari.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA05474; Wed, 18 Nov 87 12:38:18 EST Message-Id: <8711181738.AA05474@uunet.UU.NET> Received: from cidam (via goanna) by munnari.oz with SunIII (5.5) id AA19533; Thu, 19 Nov 87 04:13:01 EST Received: by cidam.rmit.oz (4.3b/4.7) id AA29621; Thu, 19 Nov 87 00:00:01 EDT Date: Thu, 19 Nov 87 00:00:01 EDT From: "Mike A. Gigante" To: DOLATA@rvax.ccit.arizona.EDU Subject: Re: PROLOG for IRIS ?? Cc: info-iris-request@BRL.ARPA Resent-Date: Thu, 19 Nov 87 4:52:14 EST Resent-From: Chuck Kennedy Resent-To: info-iris@BRL.ARPA I've put MU-prolog on the iris without any alterations. Although these days MU-prolog has been superseded by NU prolog (which has compiler support) It comes with source (in C) and cost a few hundred dollars. I suggest you send email to jas%munnari.oz.au@uunet.uu.net for more info. Mike Gigante, RMIT, Australia ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01172; 24 Nov 87 18:07 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26466; 24 Nov 87 15:09 EST Received: from brl-tbd.arpa by VMB.BRL.ARPA id aa26322; 24 Nov 87 15:05 EST Date: Tue, 24 Nov 87 14:56:41 EST From: Glenn Randers-Pehrson (WMB) To: info-iris@BRL.ARPA Subject: backface feature Message-ID: <8711241456.aa01139@TBD.BRL.ARPA> Using FORTRAN on an IRIS 2500T running version 3.0, call backfa(.true.) causes backfacing polygons created by pclos(), spclos(), and polf() to be discarded, but not those created by poly(). This seems to be inconsistent. Is there available a version of poly() which pays attention to backfa()? Glenn Randers-Pehrson ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa27319; 1 Dec 87 18:20 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26516; 1 Dec 87 16:26 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa26451; 1 Dec 87 16:16 EST Received: from io.arc.nasa.gov by SMOKE.BRL.ARPA id aa09871; 1 Dec 87 16:07 EST Received: from RAL by IO with VMS ; Tue, 1 Dec 87 13:01:43 PST Date: Tue, 1 Dec 87 13:01:43 PST From: SERAFINI%RAL@IO.ARC.NASA.GOV Subject: IRIS's and third party hardware To: info-iris@BRL.ARPA Message-ID: <8712011607.aa09871@SMOKE.BRL.ARPA> Is anyone out there using 3rd party disks with an IRIS 2xxx or 3xxx? I'm especially interested in removable disks. Thanks. Dave Serafini Sterling Software, Federal Systems @NASA/Ames Research Center serafini%tom@ames-io.ARPA ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa02812; 2 Dec 87 9:51 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00317; 2 Dec 87 7:23 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00253; 2 Dec 87 7:14 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa19510; 2 Dec 87 7:07 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.STANFORD.EDU with TCP; Wed, 2 Dec 87 04:05:41 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA15575; Wed, 2 Dec 87 03:58:53 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Dec 87 08:35:31 GMT From: Thomas Purcell Organization: Cornell Subject: Hardware purchase advice request/any vendor Message-Id: <572@vax1.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU For those who might have opinions: This is a request for advice: I'm trying to put together a very respectable personal system for the next couple of years (till the Super-engineering workstations come down to $5k.). Its uses would include some commercial applications (that is, business type stuff) and software development. Preferred characteristics are: o Unix -- now or very soon (avail. within 1 yr.) o desktop publishing at least up to mac quality level ooo multiple operating system capability, even if this anticipates additional processor cards (methinks this is better than buying 4 different machines.?.) o speed. don't want my hair to turn grey while I'm waiting for something running on a hardware simulator, for example, to execute a single instruction o color graphics better than IBM cga, cheaper than a $50k Silicon Graphics workstation o full-page display would be pretty handy. o Big harddrive; ample memory (80 meg, 2 Meg is a nice starting point, bigger better) o Don't need (right now) state of the art CAD/CAM facilities. Can't go much over the $10k limit. Or, need to aim for near to $5k for a stripped machine if I'm to afford the bells & whistles. Multiple OS support is a goody and a biggy that I'd really like. (Seems like this would depend on architecture and vendor's economics...) Here's my reasoning: I can afford to buy ONE flexible machine, and equip it with some REALLY nice goodies: a very good display, a massive (for one user) hard drive, similarly generous RAM, a backup system, and so on.: All the goodies that make an environment more fun! But, once I've invested in all those nice things, I want to be able to work with (read/write) and write code for Unix, MS-DOS, and Mac's OS. (For starters.) I CAN'T afford to buy three or four vendor's machines and equip each one of them as nicely as the single hypothetical machine above. So, even if I have to install some extra processor boards {which had better be REAL ones that are available or will be -- hypothetical boards don't run real software }, AND suffer some slowdown, I think I'm much better off with one multifaceted machine. If YOU can recommend (or sell to me) something that will approach my Pipe-Dream as above, please let me know what it is and how much it'll cost. I welcome the suggestion of a machine which hasn't been released yet, if it fits the bill, and WILL be released within 6 mos. to a year. Or, If you'd find my reasoning faulty, I invite criticisms. Please send a copy of your response directly to me. -thomas en2j@vax1.ccs.cornell.edu en2j@crnlvax1.bitnet ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04353; 2 Dec 87 11:46 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab02464; 2 Dec 87 9:20 EST Received: from NRL-AIC.ARPA by VMB.BRL.ARPA id aa02402; 2 Dec 87 9:15 EST Return-Path: Received: Wed, 2 Dec 87 09:12:25 est by nrl-aic.ARPA id AA06839 Message-Id: <8712021412.AA06839@nrl-aic.ARPA> Date: 2 Dec 1987 09:08:58 EST (Wed) From: Russ Smith Subject: Re: Hardware purchase advice request/any vendor To: info-iris@brl-vmb.arpa [Pardon the response to this list for non-IRIS material, but that's from whence the original query came...] [To Thomas Purcell:] You may want to look into the Amiga 2000. It allows multiple (two...) cards in it for IBM *and* Amiga processors which can run in parallel. There very shortly will be a '386 card for the IBM-compatible side of the 2000. Right now I believe the IBM side is XT-compatible (with expansion slots so inexpensive IBM-compatible peripherals can be added (such as hard disks...)). The Amiga-side memory can be expanded up to at least 8 megabytes. One can install a 5.25" IBM compatible floppy disk drive which can be read/written by the Amiga-side (plus it comes with a 3.5" drive). A hard drive can be internally installed on the Amiga side. AmigaDOS is a true multi-tasking operating system somewhat similar to UNIX in that it has a heirarchical file system, etc. (it does not, however, have memory management built-in). Tasks never have to be written to KNOW about multi-tasking, for example, something that many available "task-switching" systems for other machines need. Most everything on the AMIGA (except for the system itself...) is written in C. There are extensive graphics capabilities (with hardware chips to handle them and software packages to access the chips). Commercial C compilers are available (and produce quite good code (I'd recommend Aztec C)). The most popular wordprocessor package, WordPerfect, is also available. The graphics are definitely better than IBM *BUT* can *INCLUDE* IBM (in fact, an "IBM window" can be displayed on the AMIGA screen...). Of course, you could plug an IBM vga graphics board into the IBM side for "high speed" graphics that don't use the Amiga monitor. Resolution of the Amiga 2000 can vary from 320x200x5bits to 640x400x4 bits (actually, the 320x200 can use 6 bits per pixel, but that is a special feature called Hold and Modify, allowing up to 4096 colors at once under certain restrictions). The system comes with 1 megabyte. In essence, the A2000 is two different computers that are intimately hardware connected. The Amiga side starts up the IBM side, then the two communicate through shared memory. The Amiga side allows (indeed, insists on!) multitasking. The IBM side is XT compatible. Both machines run in parallel. For the price range you quote you should be able to get a VERY fully equipped A2000 machine complete with multiple megabytes of memory, IBM compatibility, hi-res color monitor, hard disk (or two), printer, and more. The hi-res mode of the Amiga is higher (AND in 16 colors) than the Mac, but there is NO Mac compatibility currently available. Bells and Whistles: There is an Ethernet card available for the A2000, allowing the A2000 to be networked to other Ethernet machines. Russ JAYCOR Navy Center for Applied Research in Artificial Intelligence (whew!) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12409; 3 Dec 87 4:30 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11984; 3 Dec 87 2:35 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa11965; 3 Dec 87 2:29 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa19002; 3 Dec 87 2:16 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 2 Dec 87 23:03:51 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA09026; Wed, 2 Dec 87 22:41:49 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Dec 87 23:00:44 GMT From: "paul e. bloch" Organization: University of Oregon, Computer Science. Eugene OR Subject: GNU emacs 18.47 on iris 3030 release 3.4 unix Message-Id: <1184@uoregon.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU I'm trying to get GNU emacs 18.47 running on our iris 3030 running release 3.5 unix. When you try to start it, it aborts with this message: Fatal error (11).emacs-18.47.6: Segmentation violation -- Core dumped My config.h has the lines: #include "s-iris3-5.h" #include "m-irist.h" and it compiles with no errors. Any suggestions? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa22761; 4 Dec 87 0:54 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22468; 3 Dec 87 23:30 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa22455; 3 Dec 87 23:18 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa19236; 3 Dec 87 23:09 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 3 Dec 87 20:07:43 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA03452; Thu, 3 Dec 87 18:55:11 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 87 01:41:30 GMT From: Michael Cohen Organization: Boston Univ. CS Dept. Subject: SGI 3130 Yellow Pages Query Message-Id: <16933@bu-cs.BU.EDU> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Is any body running NFS with YP on a SGI, we seem to have problems binding YP to our server on a non system V BSD4.3 machine. Mike Cohen -- Boston University ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00676; 4 Dec 87 1:32 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22499; 3 Dec 87 23:41 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa22479; 3 Dec 87 23:30 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa19296; 3 Dec 87 23:21 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 3 Dec 87 20:20:43 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA03737; Thu, 3 Dec 87 19:09:29 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 87 01:53:42 GMT From: Mike Cohen Organization: Boston Univ. Center for Adaptive Systems Subject: Silicon Graphics Iris Workstation Yellow Pages Query Message-Id: <16935@bu-cs.BU.EDU> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Does anybody have the yellow pages working on an Iris 3130 Workstation. We are having trouble communicating with another system running BSD 4.3 -Mike Cohen Boston University. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13699; 5 Dec 87 9:23 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa13403; 5 Dec 87 7:49 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa13375; 5 Dec 87 7:39 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa00568; 5 Dec 87 7:36 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sat, 5 Dec 87 04:34:57 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA10628; Sat, 5 Dec 87 04:06:18 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Dec 87 21:10:27 GMT From: Root Subject: Silicon Graphics Iris Query Message-Id: <565650627.21259@bucasb.bu.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Does anybody run the Yellow Pages on the Iris. We have a problem trying to use our Iris 3130 as a YP client bind hangs in boot. Any ideas. Michael Cohen -- Center for Adaptive Systems. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00378; 6 Dec 87 7:33 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00200; 6 Dec 87 6:31 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00198; 6 Dec 87 6:24 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa09491; 6 Dec 87 6:11 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sun, 6 Dec 87 03:05:35 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA00692; Sun, 6 Dec 87 02:44:17 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Dec 87 03:07:08 GMT From: _/**/Sam_Fulcomer Organization: Brown University Computer Science Dept. Subject: Re: Silicon Graphics Iris Workstation Yellow Pages Query Message-Id: <21177@brunix.UUCP> References: <16935@bu-cs.BU.EDU> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <16935@bu-cs.BU.EDU> mac@bu-cs.UUCP (Mike Cohen) writes: >Does anybody have the yellow pages working on an Iris 3130 Workstation. I have yp running on two 3130's as a separate domain, but the 3130's do not work as slave servers or clients of Sun's (this is the yp of SGI Rel 3.5). The cause of this appears to be that the rpc implementation is a little mangled. The IRIS fails to recognize a properly registered server program on the Sun (of the same version number). This may be fixed in Rel 3.6 ------------------------------------------------------------------------- BITNET sgf@BROWNCS CSNET sgf@cs.brown.edu ARPANET sgf%cs.brown.edu@relay.cs.net UUCP {ihnp4,allegra,decvax,princeton}!brunix!sgf TELECOM 401-863-3618 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00727; 6 Dec 87 10:42 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00562; 6 Dec 87 9:19 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00552; 6 Dec 87 9:13 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa10283; 6 Dec 87 9:06 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sun, 6 Dec 87 06:05:27 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA02683; Sun, 6 Dec 87 05:45:18 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Dec 87 06:07:31 GMT From: Daniel A Haug Organization: Lockheed Austin Div. Subject: flight Message-Id: <54@grouse.AUSTIN.LOCKHEED.COM> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Sorry for posting this, but I just have to know (insatiable curiosity!). Any body out there play "flight" much? How about the heads-up display version, at least available on the new 4D machines? There are these "targets" that show up on the HSI (direction indicator), labeled "4", "8", and "A". These correspond to small brown squares on the ground. What are they, what purpose do they serve, and can I do anything with them? dan haug haug@austin.lockheed.com ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa09535; 7 Dec 87 13:43 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab09256; 7 Dec 87 13:33 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab09074; 7 Dec 87 13:19 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa04117; 7 Dec 87 13:15 EST Received: from lindy.stanford.edu by SUMEX-AIM.Stanford.EDU with TCP; Mon, 7 Dec 87 10:12:25 PST Received: by lindy.stanford.edu; Mon, 7 Dec 87 10:09:42 PST Received: by Forsythe.Stanford.EDU; Mon, 7 Dec 87 10:11:07 PST Received: (from MAILER@UCHIMVS1 for MAILER@UCHIMVS1 via NJE) (BITMAIL-4616; 50 LINES); Mon, 07 Dec 87 12:07:39 CST Date: Mon 7 Dec 87 12:05:44-CST From: Stuart Schmukler Subject: Re: (none) To: brendan@arcadia.sgi.COM, sas1@ulysses.uchicago, info-iris@sumex-aim.stanford.EDU Cc: STAFF.SAS@chip.uchicago Message-ID: <8712071315.aa04117@SMOKE.BRL.ARPA> Thank-you Brendan Eich and Steve Dempsey for your replys concerning BSD compatiability. I now have another question for the net: I have complied, linked, and ranlib'ed a new library called 'libcap' which depends on 'libbsd' for compatiability functions. All seens fine until I go to link 'libbsd' and 'libcap' with one of the example applications in the package. I get undefined symbols from one of the libraries -- 'libbsd' if it is first on the link line and 'libcap' if it is first on the link line. I think that I have created the 'libcap' wrongly, but I have not been able to figure out where I when wrong. Here is the library installation: install: $(LIBCAP) install -U BSD42 $(LIBCAP) $(LIBDIR) ranlib $(LIBDIR)/$(LIBCAP) and here is the compili/link of the sample application: cc -O -I/usr/include/sun -I/usr/include/bsd -c lwpr.c cc -lbsd -I/usr/include/sun -I/usr/include/bsd -o lwpr lwpr.o -lcap Undefined: _gettimeofday _socket _recvmsg _select _ffs _sendmsg _bind _inet_addr _gethostbyname *** Error code 1 Any help is usefull. SaS ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13528; 7 Dec 87 17:57 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12133; 7 Dec 87 16:02 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab12103; 7 Dec 87 15:58 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa10153; 7 Dec 87 15:54 EST Received: from zorac.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Mon, 7 Dec 87 12:53:30 PST Received: by zorac.ARPA (4.12/25-eef) id AA13097; Mon, 7 Dec 87 15:32:10 est Date: Mon, 7 Dec 87 15:32:10 est From: Tim Pointing Message-Id: <8712072032.AA13097@zorac.ARPA> To: STAFF.SAS%CHIP.UChicago@forsythe.stanford.EDU, brendan@arcadia.sgi.COM, info-iris@sumex-aim.stanford.EDU, sas1@ulysses.uchicago Subject: Re: (none) Cc: STAFF.SAS@chip.uchicago The solution to your problem is quite simple. The cause of the problem is that the "-l" flag on cc is the only one that is position depenant. The "-lbsd" should one of the last things on the compile line - it has to come after all of the object modules and libraries that reference things from the library. The correct line from the above compile line would be: cc -I/usr/include/sun -I/usr/include/bsd -o lwpr lwpr.o -lcap -lbsd (assuming the "cap" library referneced things in the bsd library and not vice versa.) Tim Pointing, DCIEM tim@zorac.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15540; 7 Dec 87 23:00 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ac15446; 7 Dec 87 22:50 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id ac15421; 7 Dec 87 22:44 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa16806; 7 Dec 87 22:40 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 7 Dec 87 19:38:53 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA02549; Mon, 7 Dec 87 15:29:55 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Dec 87 19:16:28 GMT From: Rasesh Trivedi Organization: Boston U., Center for Adaptive Systems Subject: Re: GNU emacs 18.47 on iris 3030 release 3.4 unix Message-Id: <565902988.11701@bucasb.bu.edu> References: <1184@uoregon.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <1184@uoregon.UUCP> paul@uoregon.UUCP (paul e. bloch) writes: > >I'm trying to get GNU emacs 18.47 running on our iris 3030 >running release 3.5 unix. When you try to start it, it aborts >with this message: >Fatal error (11).emacs-18.47.6: Segmentation violation -- Core dumped > >My config.h has the lines: > >#include "s-iris3-5.h" >#include "m-irist.h" > >and it compiles with no errors. Any suggestions? We had same problm while we installed GNU EMacs on our Iris 3130. But was that we had older version probably 18.44 or so which did not have include files made for Iris, and were trying to use home made header files. But 18.46 and then 18.47 were installed later without any problems. You can try increasing the swap space by taking some space out of your /usr which would allow to emacs loaded entirely if that was the problem, which might help. Other than that I donot see anything wrong in any files distributed with 18.47 as for us that installation was straight forward. -Rasesh Trivedi (Boston University) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15869; 8 Dec 87 0:03 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15446; 7 Dec 87 22:50 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15421; 7 Dec 87 22:44 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa16802; 7 Dec 87 22:39 EST Received: from lindy.stanford.edu by SUMEX-AIM.Stanford.EDU with TCP; Mon, 7 Dec 87 19:27:57 PST Received: by lindy.stanford.edu; Mon, 7 Dec 87 15:44:40 PST Received: by Forsythe.Stanford.EDU; Mon, 7 Dec 87 15:45:46 PST Received: (from MAILER@UCHIMVS1 for MAILER@UCHIMVS1 via NJE) (BITMAIL-5789; 20 LINES); Mon, 07 Dec 87 17:36:49 CST Date: Mon 7 Dec 87 16:21:18-CST From: Stuart Schmukler Subject: Re: (none) To: tim@zorac.arpa, info-iris@sumex-aim.stanford.EDU Cc: STAFF.SAS@chip.uchicago In-Reply-To: Message from ""Tim Pointing" " of Mon 7 Dec 87 14:52:15-CST Message-ID: <8712072239.aa16802@SMOKE.BRL.ARPA> Thank-you Tim. I now have a problem that seems to really exist. Namely the fact that the BSD function 'wait3' does not exist in the sgi 'libbsd' or anywhere else I can find. If 'wait3' really does not exist it _MAYBE_ possible to bypass it, but it will take alot of work. Does anyone have a solution? SaS ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa22668; 8 Dec 87 13:08 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa21389; 8 Dec 87 11:43 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa21192; 8 Dec 87 11:29 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa00153; 8 Dec 87 11:28 EST Received: from FORD-WDL1.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Tue, 8 Dec 87 08:27:24 PST Received: by FORD-WDL1.ARPA (5.51/5.9) id AA02286; Tue, 8 Dec 87 08:17:24 PST Date: Tue, 8 Dec 87 08:17:24 PST From: Rion Cassidy Message-Id: <8712081617.AA02286@FORD-WDL1.ARPA> To: info-iris@sumex-aim.stanford.EDU Here at Ford Aerospace we have several IRIS 3120's, and one of them has had hardware problems in the form of parity errors. The problem has reared its head several times, each time pretty much at random, and the witless maintenance people at SGI have been unable to fix it. I am posting this because, as I've mentioned the problem does continue, and in the interest of productivity, we would like to get it fixed. If you are unfamiliar with hardware errors, they generally seem to stop the computer dead in its tracks, causing untold confusion upon rebooting. One time the entire file system had to be restored (and many files were simply lost). The hardware maintenance people at SGI have replaced the memory or CPU (or both) cards each of the six times our machine has failed, each time telling us that they are now *SURE* the problem is fixed. We are tired of screwing around, obviously they are not. My questions to you as fellow IRIS users are: 1) Have you experienced similar hardware problems, and if so did you ever get a satisfactory solution? What was the answer? 2) Have you been similarly frustrated by SGI incompetence? Rion Cassidy rion@ford-wdl1.arpa ...{sgi,sun,ucbvax}!wdl1!rion ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa23373; 8 Dec 87 14:11 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22381; 8 Dec 87 12:37 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa22203; 8 Dec 87 12:27 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa01847; 8 Dec 87 12:12 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Tue, 8 Dec 87 09:12:29 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA21256; Tue, 8 Dec 87 09:00:10 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Dec 87 14:38:14 GMT From: Joel Garrett Organization: University of Delaware Subject: Re: Getting CAP to run on SGI... Message-Id: <779@louie.udel.EDU> References: , <8712072239.aa16802@SMOKE.BRL.ARPA> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU We've taken a crack at older versions of the CAP distributions and ran into the same problems you have. Which patch-level of the CAP are you running? Have you applied all patches to version 4 up to and including patch 7? Supposedly the patches in patch 6 make the program more portable (I guess that would mean eliminating calls to BSD-only routines, or at least tips on how to get around it.) Copies of the latest version of CAP and all patches to it can be found on sumex-aim.stanford.edu and cu20b.columbia.edu via anonymous login. On the sumex, the files are in the directory and on the cu20b, the files are in the us:[us.cck.cap.d4] directory. Make sure you have at least version 2 of the 'patch' program which will be needed to apply the updates in the patch files. Some of the files are shell archives, some tar, some compressed tar, just about every combination one could think of. There is probably a copy of the sources to the patch program on uunet.uu.net in the archives for comp.sources.unix. Just download some of the indexes (anonymous ftp again, of course) Hope this helps, Joel Garrett Research Associate Center for Composite Materials University of Delaware arpa: garrett@udel.edu or: garrett@udel-ccm.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa25770; 8 Dec 87 16:28 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa23773; 8 Dec 87 14:34 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa23632; 8 Dec 87 14:24 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa06506; 8 Dec 87 14:12 EST Received: from CAD.USNA.MIL (USNA.MIL) by SUMEX-AIM.Stanford.EDU with TCP; Tue, 8 Dec 87 11:08:27 PST Date: Tue, 8 Dec 87 14:02:01 EST From: "David F. Rogers" To: info-iris@sumex-aim.stanford.EDU cc: dfr@USNA.MIL Subject: Jove Editor Message-ID: <8712081402.aa01243@CAD.USNA.MIL> G'day, A number of people seem to be trying to load gnuEMACS on an Iris and having difficulty. May I suggest that unless you need the full extensibility of EMACS that you reconsider your use of it. There is an alternate editor available without charge that has nearly all the characteristics of EMACS and uses considerably less system resources. I refer, of course, to JOVE (Jonathan's Own Version of Emacs). I believe that JOVE is available on the Berkeley 4.3 distribution. It is also available from brl. I have been using JOVE on my 2400T for about 3 years with very minor problems. We also use it as our principal editor for students on our VAX 11/780 graphics support machine (under BSD 4.3), on Suns, on a Gould, and on IBM-PC's and compatibles. Makes it nice that the same editor is used across machines. Jove is very fast even on a PC. Professor David F. Rogers U. S. Naval Academy dfr@usna.mil ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26655; 8 Dec 87 18:16 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26040; 8 Dec 87 16:51 EST Date: Tue, 8 Dec 87 16:44:09 EST From: Chuck Kennedy To: info-iris@brl.arpa Subject: Re: Jove Editor Message-ID: <8712081644.aa25927@VMB.BRL.ARPA> JOVE is available via anonymous FTP from brl-vgr.arpa (192.5.23.6). A tar archive of jove is in the directory arch and is called jove.tar. It is 696320 bytes long. Note that the iris archives are in the directory info-iris. -Chuck Kennedy ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26736; 8 Dec 87 18:58 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26426; 8 Dec 87 17:24 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa26416; 8 Dec 87 17:21 EST Received: from rodan-ec.nas.nasa.gov by SMOKE.BRL.ARPA id aa12023; 8 Dec 87 17:14 EST Received: Tue, 8 Dec 87 14:17:03 PST by rodan.nas.nasa.gov (5.15/1.2) Date: Tue, 8 Dec 87 14:17:03 PST From: "Eric L. Raible" Message-Id: <8712082217.AA10796@rodan.nas.nasa.gov> To: info-iris@BRL.ARPA Subject: iris gnu emacs Just in case anyone is unclear on this: m-irist.h and s-iris3-[56].h are distributed with the latest (18.49) release of gnu emacs (as well as back to 18.41, I believe). The files in the info-iris archives are old - I put them in there before the Free Software Foundation started distributing the iris files directly. Anyone having problems with 18.49 under 3.5 or 3.6 might want to contact me directly. - Eric Raible (raible@orville.nas.nasa.gov) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10640; 9 Dec 87 23:54 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ac10545; 9 Dec 87 23:43 EST Received: from sem.brl.mil by VMB.BRL.ARPA id ac10518; 9 Dec 87 23:32 EST Received: from SUMEX-AIM.STANFORD.EDU by SEM.BRL.ARPA id aa00320; 9 Dec 87 23:28 EST Received: from zorac.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Wed, 9 Dec 87 07:19:03 PST Received: by zorac.ARPA (4.12/25-eef) id AA20022; Tue, 8 Dec 87 08:47:04 est Date: Tue, 8 Dec 87 08:47:04 est From: Tim Pointing Message-Id: <8712081347.AA20022@zorac.ARPA> To: info-iris@SUMEX-AIM.STANFORD.EDU Subject: wait3 Often, the only reason why wait3() is used instead of wait() is so that a wait can be done without delaying if there is no child process have status to report (where wait() would just sit around until one did have status to report.) The way that I have kludged around this deficiency in the past is with my own hack which sort-of simulates wait3(). Good Luck! Tim Caveats: I am typing this in off the top of my head - it may not work as typed (additional #include's may be required); it will not work when the option "WUNTRACED" is used; care must be taken if alarm's are already being used in the program. No guarantees! The fake goes something like (this at least compiles)... -------------cut-here-----------------------------------cut-here------------ #include #include #include #include #include #include typedef int (*PFI)(); /* make declarations easier to read */ wait3(status, options, rusage) union wait *status; int options; struct resource *rusage; /* not altered so declaration doesn't matter */ { extern int wait3_timeout(); PFI old_alarm, signal(); int pid; extern int errno; int err_code; unsigned time_left; /* fake the WNOHANG option by using time-out's */ if (options & WNOHANG) { old_alarm = signal(SIGALRM, wait3_timeout); time_left = alarm(1); } errno = 0; pid = wait(status); err_code = errno; if (options & WNOHANG) { (void) signal(SIGALRM, old_alarm); alarm(time_left); } /* pid == -1 means either no process to wait for or alarm */ /* interupted the wait() system call. */ if (pid == -1 && err_code == EINTR) return(0); return(pid); } static wait3_timeout() {} ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id ab10640; 9 Dec 87 23:54 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ad10545; 9 Dec 87 23:44 EST Received: from sem.brl.mil by VMB.BRL.ARPA id aa10528; 9 Dec 87 23:32 EST Received: from SUMEX-AIM.STANFORD.EDU by SEM.BRL.ARPA id aa00325; 9 Dec 87 23:28 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 9 Dec 87 11:07:26 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA22558; Wed, 9 Dec 87 10:41:26 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Dec 87 16:09:48 GMT From: Michael Cohen Organization: Boston U., Center for Adaptive Systems Subject: Ethernet Address (Hard for Iris Ethernet EXOS board) Message-Id: <566064588.23067@bucasb.bu.edu> Sender: info-iris-request@SUMEX-AIM.STANFORD.EDU To: info-iris@SUMEX-AIM.STANFORD.EDU From which command on the iris can one obtain the physical ethernet address of the EXOS board on an Iris 3130. This is not clear from the documentation and the standard ifconfig call doesn't seem to print out this address. This seems to be necessary for obtaining data for the file /etc/ethers. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10881; 10 Dec 87 0:57 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa10545; 9 Dec 87 23:43 EST Received: from sem.brl.mil by VMB.BRL.ARPA id aa10518; 9 Dec 87 23:32 EST Received: from SUMEX-AIM.STANFORD.EDU by SEM.BRL.ARPA id aa00308; 9 Dec 87 23:27 EST Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Tue, 8 Dec 87 22:40:56 PST Received: from ai.toronto.edu by RELAY.CS.NET id aa09212; 9 Dec 87 1:08 EST Received: from csri.toronto.edu by ai.toronto.edu via ETHER with SMTP id AA19429; Wed, 9 Dec 87 01:04:06 EST Received: from alias by csri.toronto.edu via phone with UUCP id AA24622; Wed, 9 Dec 87 01:03:59 EST Message-Id: <8712090603.AA24622@csri.toronto.edu> Received: by alias.uucp (4.12/celerity) id AA03559; Tue, 8 Dec 87 18:44:03 est Date: Tue, 8 Dec 87 18:44:03 est From: Kevin Tureski To: info-iris@SUMEX-AIM.STANFORD.EDU, rion@FORD-WDL1.arpa Subject: Re: Kernel Parity Errors & SGI We've got a bunch of 2400T's and 3130's in house, and were plauged by kernel parity errors this summer. Haven't seen any for a couple of months, and here's why: The KPE's are caused by some subtle timing problems between the memory boards and the processor. So subtle that only W3.5r2 detects them as KPE's. Previous releases just up and died without any indication as to why (when I was at Omnibus Toronto, we had one 3130 that did this about twice a week for months, but I don't have to worry about that machine now :-) Not all machines/boards exhibit the problems either -- at one point, I'd swapped in 3 new sets of memory boards each of which worked on other machines but wouldn't in the problem machine(s). The solution: SGI has a set of PALS, 7 for the IP2 and 1 for each memory board in the system. Replacement takes less than half an hour. I don't know how fast they are producing them now, but we had a long wait between the discovery of the likely fix and actually testing it out ... I first called in the problem May 4 and received the last set of PALS Oct 7. Kevin Tureski Alias Research Inc. 110 Richmond St E. Toronto Canada M5C 1P1 416 362-9181 UUCP: {allegra,ihnp4,watmath!utai}!utcsri!alias!ktureski ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10944; 10 Dec 87 1:07 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab10545; 9 Dec 87 23:43 EST Received: from sem.brl.mil by VMB.BRL.ARPA id ab10518; 9 Dec 87 23:32 EST Received: from SUMEX-AIM.STANFORD.EDU by SEM.BRL.ARPA id aa00314; 9 Dec 87 23:27 EST Received: from ATHENA (ATHENA.MIT.EDU) by SUMEX-AIM.Stanford.EDU with TCP; Wed, 9 Dec 87 06:17:06 PST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA02896; Wed, 9 Dec 87 09:16:47 EST From: miked@ATHENA.MIT.EDU MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Received: by M7-321-2 (5.45/4.7) id AA03897; Wed, 9 Dec 87 09:15:48 EST Message-Id: <8712091415.AA03897@M7-321-2> To: info-iris@SUMEX-AIM.STANFORD.EDU Cc: miked@ATHENA.MIT.EDU Subject: EMACS-like editors for IRIS Date: Wed, 09 Dec 87 09:15:44 EST A small emacs-like editor called micro-emacs is available from the C user group, Macpherson, Kansas. It has the essential editing elements and familiar commands of the full blown emacs without most of the powerful features (macros, language specific environments, user extensions, etc.). It is quite small, fits on an IBM PC. I have used it on an IRIS 3030. If anyone knows where the latest version of this may be obtained by ftp transfer (C user group mails disks.), please post the information to this bulletin. Mike Drooker, MIT Ocean Engineering Design Laboratory ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa20855; 10 Dec 87 18:03 EST Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19716; 10 Dec 87 15:47 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa19713; 10 Dec 87 15:45 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa10787; 10 Dec 87 15:39 EST Received: from gelac.arpa by SUMEX-AIM.Stanford.EDU with TCP; Thu, 10 Dec 87 12:39:25 PST Received: by gelac.arpa (4.12/25) id AA07447; Thu, 10 Dec 87 15:35:28 est Message-Id: <8712102035.AA07447@gelac.arpa> To: info-iris@sumex-aim.stanford.EDU Date: Thu, 10 Dec 87 15:35:24 GMT+4520891:44 From: "Mr. Barry W. Webb" Subject: Ethernet Address X-Mailer: msg [version 3.2] Michael We have several different models and each one prints out the physical ethernet address when we boot them. You can see it in parens on the line for the ex0 (TCP) or nx0 (XNS) device. It usually looks like (800.1410.9999). We've printed signs to attach to the front of each machine which displays the machine's name, enet address, and serial number. Makes it easy to identify the machine at a glance. Barry Webb Lockheed Aeronautical Systems Company bwebb@gelac.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa21354; 10 Dec 87 21:32 EST Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa21202; 10 Dec 87 20:19 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa21161; 10 Dec 87 20:13 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa15268; 10 Dec 87 20:07 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 10 Dec 87 17:07:43 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA27725; Thu, 10 Dec 87 16:42:16 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Dec 87 16:41:02 GMT From: Vernon Schryver Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: wait3 Message-Id: <8826@sgi.SGI.COM> References: <8712081347.AA20022@zorac.ARPA> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <8712081347.AA20022@zorac.ARPA>, tim@ZORAC.ARPA (Tim Pointing) writes: > Often, the only reason why wait3() is used instead of wait() is so that > a wait can be done without delaying if there is no child process have status > to report (where wait() would just sit around until one did have status to > report.) Mr. Pointing seems to be on the right track. The SGI TCP/IP/UDP code is 4.3 BSD based. As you might guess, when we did the ports for 3.5 and 1.0 we encountered uses of wait3(2). Whenever we port more 4.x compatible code, we find more uses of wait3. However, instead of using alarm(2) and SIGALRM, we use SIGCHLD. Your process can get SIGCHLD when one of its children exits. (Note: beware the surprising effect of setting SIGCHLD to SIG_IGN in SYS V.) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa21450; 10 Dec 87 21:44 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab21354; 10 Dec 87 21:34 EST Received: from sem.brl.mil by VMB.BRL.ARPA id aa21346; 10 Dec 87 21:27 EST Date: Thu, 10 Dec 87 21:13:10 EST From: Mike Muuss To: info-iris@BRL.ARPA Subject: 4D Keyboard Message-ID: <8712102113.aa02295@SEM.BRL.ARPA> Today I had my first opportunity to use an Iris-4D ("clover"). It seems very fast on some things. My objection for the day is the keyboard. The location of the CTRL and CAPS LOCK keys is *awful*. Obviously nobody at SGI uses EMACS. It's sooooo bad, I log in to the 4D from my SUN! At $4k, a Sun-3/50 isn't too expensive to use as a keyboard for a $80k workstation, but I would have expected better from the makers of $80k workstations. Sigh. Human engineering is dead. -Mike ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17588; 12 Dec 87 16:45 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa17409; 12 Dec 87 15:43 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa17403; 12 Dec 87 15:36 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa05138; 12 Dec 87 15:29 EST Received: from OTHELLO.STANFORD.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sat, 12 Dec 87 12:29:55 PST Date: Sat 12 Dec 87 12:25:30-PST From: Peter Loan Subject: XNS between VMS/Fortran and Unix/C To: info-iris@SUMEX-AIM.STANFORD.EDU Message-ID: <8712121529.aa05138@SMOKE.BRL.ARPA> Pete Loan Message-ID: <12357953400.107.S.SPEEDRACER@OTHELLO.STANFORD.EDU> Help us please... We are running dynamical simulations in Fortran on our VAX (VMS), and would like to pipe the data, as it is generated, over ethernet (XNS protocol) to our IRIS 2400T, where a C program would display it. Since there is no written doc on VMS-XNS-Fortran, we're having trouble figuring out how to do it. We've looked through the library on the VAX (and files like io.for, vmsio.for, etc.), but they're difficult to decifer. On the IRIS-C end, we've examined the DOG source code and tried things like xnsconnect and zsend, but can't get that either. There's got to be someone out there who has done this before, and if so, they could save us a week or two of trial and error. What do we do... (enquiring minds want to know) -Thanks, Peter Loan V.A. Hospital/Stanford ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa06433; 14 Dec 87 18:34 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa03012; 14 Dec 87 15:37 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa02908; 14 Dec 87 15:22 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa08408; 14 Dec 87 15:21 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 14 Dec 87 12:21:36 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA29404; Sun, 13 Dec 87 09:58:00 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Dec 87 12:16:00 GMT From: Michael Mascagni Organization: New York University Subject: Re: XNS between VMS/Fortran and Unix/C Message-Id: <17280003@acf4.UUCP> References: <8712121529.aa05138@SMOKE.BRL.ARPA> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU I have been using a Cray frontended by a VMS vax to create data that I animate on a 4D/60T that is on our ethernet. Since the files I create are too massive to sit directly on the Iris, I cat them over to the Iris from the Vax disk farm over the ethernet. If your VMS has Eunice you can issue a cat on the Vax under Eunice from a remote shell (rsh) on the Iris provided you can rlogin to the Vax. I suppose that if you can run your program under Eunice, then you can rsh the same commands and run the program on the Vax from the Iris under a remote shell., Hope you have Eunice as if you don't I don't have a clue what to do. Michael Mascagni mascagni@ncifcrf.gov National Institutes of Health Building 31, Room 4B-54 Bethesda, Maryland 20892 Tel:(301) 496-4325 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19081; 15 Dec 87 17:12 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa16771; 15 Dec 87 14:36 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa16679; 15 Dec 87 14:24 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa03251; 15 Dec 87 14:16 EST Received: from ATHENA (ATHENA.MIT.EDU) by SUMEX-AIM.Stanford.EDU with TCP; Tue, 15 Dec 87 11:16:54 PST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA10599; Tue, 15 Dec 87 14:16:24 EST From: miked@ATHENA.MIT.EDU MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Received: by M7-321-5 (5.45/4.7) id AA24804; Tue, 15 Dec 87 14:16:08 EST Message-Id: <8712151916.AA24804@M7-321-5> To: info-iris@sumex-aim.stanford.EDU Subject: Re: XNS between VMS/Fortran and Unix/C In-Reply-To: Your message of Sat, 12 Dec 87 12:25:30 -0800. <8712121529.aa05138@SMOKE.BRL.ARPA> Date: Tue, 15 Dec 87 14:16:04 EST Peter, As an alternative, you might investigate installing the IRIS Remote Graphic Library (available from your friendly purveyor of IRISes) on your VAX. This will permit you to write your graphic display code using familiar IRIS graphic calls in FORTRAN or C on the VAX, link this to your application code, and run it on the VAX. As you generate graphics information, it is sent to the IRIS which is running a terminal emulation program (thus becoming a fancy terminal to the VAX). We have linked a MicroVaxII running ULTRIX to our IRIS this way on a TCP/IP LAN. It has the advantage of eliminating the need to build a graphic data output file, the data transfer step, and the need for a separate graphics display program to be written on the IRIS. A disadvantage is that your graphics display speed will be paced by the VAX, which may or not be a problem in your application. I know the RGL is available for VMS systems, but am not sure about XNS network support, though this is easily checked by a call to your friendly supplier. Mike Drooker Design Laboratory Ocean Engineering Department MIT ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00446; 16 Dec 87 4:52 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00207; 16 Dec 87 3:59 EST Received: from sem.brl.mil by VMB.BRL.ARPA id ac00155; 16 Dec 87 3:47 EST Received: from SUMEX-AIM.STANFORD.EDU by SEM.BRL.ARPA id aa01288; 16 Dec 87 0:19 EST Received: from rodan.nas.nasa.gov (rodan-ec.nas.nasa.gov) by SUMEX-AIM.Stanford.EDU with TCP; Tue, 15 Dec 87 21:19:35 PST Received: Tue, 15 Dec 87 21:23:27 PST by rodan.nas.nasa.gov (5.15/1.2) Date: Tue, 15 Dec 87 21:23:27 PST From: "Eric L. Raible" Message-Id: <8712160523.AA01412@rodan.nas.nasa.gov> To: info-iris@SUMEX-AIM.STANFORD.EDU Subject: gnu on iris 4d Has anyone gotten gnu emacs to dump on the iris 4d. I've gotten asynchoronous subprocess, psuedo ttys, etc to work. I'd like to get it to dump before sending off the m-iris4d.h file out to the world. By the way, in case anyone is interested and doesn't already know, the standard gnu emacs distribution supports the 2500 and 2500 turbos (and 3030, etc) running release 3.5 or 3.6. - Eric ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00574; 16 Dec 87 5:02 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab00207; 16 Dec 87 4:00 EST Received: from sem.brl.mil by VMB.BRL.ARPA id ae00155; 16 Dec 87 3:47 EST Received: from SUMEX-AIM.STANFORD.EDU by SEM.BRL.ARPA id aa01733; 16 Dec 87 2:01 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Tue, 15 Dec 87 23:02:24 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA29644; Tue, 15 Dec 87 22:45:21 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Dec 87 03:19:02 GMT From: Joel Garrett Organization: University of Delaware Subject: IRIS RGL (Was Re: XNS between VMS/Fortran and Unix/C) Message-Id: <825@louie.udel.EDU> References: <8712121529.aa05138@SMOKE.BRL.ARPA>, <8712151916.AA24804@M7-321-5> Sender: info-iris-request@SUMEX-AIM.STANFORD.EDU To: info-iris@SUMEX-AIM.STANFORD.EDU In article <8712151916.AA24804@M7-321-5> miked@ATHENA.MIT.EDU writes: >Peter, > >As an alternative, you might investigate installing the IRIS Remote Graphic >Library (available from your friendly purveyor of IRISes) on your VAX. ... >Mike Drooker >Design Laboratory >Ocean Engineering Department >MIT We've been trying to get the RGL for our 3030s to use with Precision Visuals' GK-2000 and DI-3000 and have been getting no end of run-around from our local SGI rep. First they said it wouldn't run under the newer kernels, but now they say it does, but we still don't have it and have been BEGGING them for it for what seems to be AGES now. Anyone have any ideas? Joel J. Garrett Research Associate Center for Composite Materials University of Delaware Newark, DE 19716 arpa: garrett@udel.edu or: garrett@udel-ccm.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa06539; 16 Dec 87 12:22 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa04755; 16 Dec 87 9:56 EST Received: from sem.brl.mil by VMB.BRL.ARPA id aa04674; 16 Dec 87 9:47 EST Received: from SUMEX-AIM.STANFORD.EDU by SEM.BRL.ARPA id aa00274; 16 Dec 87 9:36 EST Received: from aplpy.jhuapl.edu by SUMEX-AIM.Stanford.EDU with TCP; Wed, 16 Dec 87 06:23:16 PST Received: by aplpy.jhuapl.edu (4.12/4.7) id AA03785; Wed, 16 Dec 87 09:20:01 est Date: Wed, 16 Dec 87 09:20:01 est From: "Marcus H. Gates" Message-Id: <8712161420.AA03785@aplpy.jhuapl.edu> To: garrett@louie.udel.EDU, info-iris@sumex-aim.stanford.EDU Subject: Re: IRIS RGL (Was Re: XNS between VMS/Fortran and Unix/C) There is another option (maybe). We are a running applications on a Vax and doing remote graphics to 6 2400's connected on an ethernet. Initially we were using the RGL from Silicon Graphics but people at NASA Ames developed a sockets based RGL for use with their Cray and many irises. We were able (with permission from SGI) to get a copy of their package and easily adapted it to work on our Vax. We are very happy with it. In case anyone doesn't already know it, the original SGI Remote Graphics was basically a modified 'cu' command. The sockets-based version is much faster. I believe the person to contact at Ames is Diana Choi. If I can be of further help please feel free to contact me. marc gates johns hopkins applied physics lab laurel, md marc@aplvax.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11669; 16 Dec 87 22:50 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11308; 16 Dec 87 21:06 EST Received: from sem.brl.mil by VMB.BRL.ARPA id aa11290; 16 Dec 87 21:01 EST Received: from SUMEX-AIM.STANFORD.EDU by SEM.BRL.ARPA id aa05628; 16 Dec 87 20:40 EST Received: from FORD-WDL1.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Wed, 16 Dec 87 17:39:07 PST Received: from ford-wdl53.ARPA by FORD-WDL1.ARPA (5.51/5.9) id AA02869; Wed, 16 Dec 87 11:52:41 PST Received: by ford-wdl53.wdl.com (3.2/SMI-3.2) id AA00853; Wed, 16 Dec 87 11:51:41 PST Date: Wed, 16 Dec 87 11:51:41 PST From: Rion Cassidy Message-Id: <8712161951.AA00853@ford-wdl53.wdl.com> To: info-iris@sumex-aim.stanford.EDU Earlier last week I posted a complaint regarding SGI hardware maintenance on one of our IRIS's here at Ford Aerospace. Because of the reaction to that posting, I want to clarify my intent and apologize for my tone. The reason for this is that several people who have seen the letter have felt "shocked" and "disturbed" at the language I used, and while I consider that over reaction, I want to make amends. First, as is virtually always the case with people posting to the net, my opinions were mine, not my company's. In case you don't remember my original letter, we have had our machine stop with a kernel parity error on six different occasions in the last couple months. Each time we called SGI in to fix it. My intent was to solicit experiences others have had with SGI hardware problems and the repair thereof, and also to alert SGI that "unsuccessful" customer service can hurt their reputation. I believe that I accomplished my goals, however I was probably a bit heavy-handed in implying that SGI personnel are witless and incompetent. I honestly don't believe that they are, and only used those terms to get their attention. I apologize. Apparently my letter is now being circulated at SGI, as I have been called by our local sales rep and the head of hardware maintenance, both of whom suggested that I contact them rather than posting angry letters. Here are a couple of the responses that I have recieved: From an individual at scubed: "Backplane problems are difficult to diagnose because hardware tests usually pass (my experience). The machine simply crashes for various reasons. You end up chasing the problem until every board is swapped out without fixing it." From Toronto: "The solution: SGI has a set of PALS, 7 for the IP2 and 1 for each memory board in the system. Replacement takes less than half an hour. I don't know how fast they are producing them now, but we had a long wait between the discovery of the likely fix and actually testing it out ... I first called in the problem May 4 and received the last set of PALS Oct 7." Rion Cassidy rion@ford-wdl1.arpa ...{sgi,sun,ucbvax}!wdl1!rion ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19253; 21 Dec 87 6:30 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa18958; 21 Dec 87 5:27 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa18936; 21 Dec 87 5:14 EST Received: from CUNYVM.CUNY.EDU by SMOKE.BRL.ARPA id aa14850; 21 Dec 87 5:03 EST Received: from NEUVM1.BITNET by CUNYVM.CUNY.EDU ; Mon, 21 Dec 87 05:05:13 EST Received: from vms2.uni-c.dk by NEUVM1.BITNET (Mailer X1.25) with BSMTP id 6871; Mon, 21 Dec 87 10:58:20 DNT Date: Mon, 21 Dec 87 10:57 CET From: "Morten Kjeldgaard " Subject: vt100 emulation for the IRIS?? To: info-iris@BRL.ARPA X-VMS-To: RECAU::IN%"info-iris@brl.arpa" Message-ID: <8712210503.aa14850@SMOKE.BRL.ARPA> [I'm posting this a second time; I'm not sure I posted it correctly the first time.] Unfortunately, Silicon Graphics has chosen the out-dated vt52 emulation for the Iris keyboard (at least on the 3020 and 2400) -- and it doesn't even work properly. When I telnet to our local microVAX, and invoke EDT the forward scrolling is not working. Only the last line is 'scrolling'. Of course you can do a ^w screen refresh once in a while, but it becomes a nuissance in the long run :-{. Sooo, until SGI comes up with a decent ANSI keyboard driver routine (SGI, are you there??) we are in desperate need of a vt100/vt200 emulation program. Something that would enable one to run a VAX session in a separate window. If anyone has any information I would be very happy. -- Morten Kjeldgaard, Aarhus University Denmark phone: +45 6 12 46 33 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa07548; 22 Dec 87 14:00 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa06498; 22 Dec 87 12:37 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa06466; 22 Dec 87 12:28 EST Received: from [36.10.0.13] by SMOKE.BRL.ARPA id aa19897; 22 Dec 87 12:19 EST Date: Tue 22 Dec 87 09:20:13-PST From: Lloyd La Comb Subject: Apple laserwriter and Iris To: info-iris@BRL.ARPA cc: lacomb@Sierra.Stanford.EDU Message-ID: <12360541109.18.LACOMB@Sierra.Stanford.EDU> I'm interested in hooking up my Apple laserwriter to my Iris and I'm trying to see if anyone out there has had an experience with a similar setup. My first question is about hooking the Iris up to a laserwriter that already hooked to an Appletalk network. SGI says that it works fine and that all I need is a smart switch which I thought would switch between either Appletalk or the Iris, but on the back of my laserwriter is a switch that selects either Appletalk or serial with some baud rate so I'm not too sure even a smart switch will help that problem. I'm also wondering what I'll get for the ~2K or so for the software from SGI. I know that the output will be in black and white and thats fine for graphs and text but can I print grayscale images with any degree of defination? Thanks, Lloyd La Comb lacomb@sierra.stanford.edu ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12383; 4 Jan 88 14:05 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa10158; 4 Jan 88 12:10 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa09724; 4 Jan 88 11:59 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa12667; 4 Jan 88 11:51 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 4 Jan 88 08:46:11 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA28072; Mon, 4 Jan 88 08:44:56 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Jan 88 14:43:00 GMT From: Michael Mascagni Organization: New York University Subject: 4D/60T Monitor Info Needed Message-Id: <17280004@acf4.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU I need the Spectral Emissivity Function for the Red, Green, and Blue phosphors of the color monitor on the Iris (Sgi) 4D/60T. I have been doing colorimetric computations with a "best guess/generic" mapping from XYZ -> RGB, and I would like to recompute the linear transform with the real data for the monitor I use. I have not been able to get a straight answer from the Sgi people, but I really think the that's because colorimetric computations are not widely done. Thanks in advance, send me e-mail to: mascagni@nyu.edu or mascagni@nyu.arpa or mascagni@ncifcrf.gov Thanks a heap (in technicolor), Michael Mascagni ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05161; 8 Jan 88 1:11 EST Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04715; 7 Jan 88 23:16 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa04670; 7 Jan 88 23:11 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa00640; 7 Jan 88 23:04 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 7 Jan 88 18:32:59 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA26266; Thu, 7 Jan 88 15:55:37 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Jan 88 16:44:00 GMT From: Michael Mascagni Organization: New York University Subject: 4D/60T monitor info found! Message-Id: <17280005@acf4.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU I have gotten the RGB <-> XYZ transformation information for the Iris 4D/60T monitor. It is: R G B X 0.6100 0.2980 0.1510 Y 0.3420 0.5880 0.0640 Z 0.0480 0.1240 0.7850 X Y Z R 2.2708 -1.0772 -0.3490 multiply the XYZ values of the color you want G -1.3285 2.3607 0.0631 by this matrix for the RGB (not normalized) B 0.0710 -0.3070 1.2853 values for the 4D/60T monitor. Have a colorful experience today, Michael Mascagni mascagni@nyu.edu mascagni@ncifcrf.gov ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11174; 12 Jan 88 21:38 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa10736; 12 Jan 88 19:43 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa10728; 12 Jan 88 19:36 EST Received: from CUNYVM.CUNY.EDU by SMOKE.BRL.ARPA id aa11824; 12 Jan 88 19:29 EST Received: from DKARH02.BITNET by CUNYVM.CUNY.EDU ; Tue, 12 Jan 88 19:32:25 EST Date: Tue, 12 Jan 88 23:31 A From: KEMBIOS%DKARH02.BITNET@CUNYVM.CUNY.EDU MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Subject: vt100 emulator badly needed... To: info-iris@BRL.ARPA X-Original-To: info-iris@brl.arpa, KEMBIOS Message-ID: <8801121929.aa11824@SMOKE.BRL.ARPA> [If you've seen this before, I apologize. I've posted parts of it before, but I haven't seen it appear on the net, and I haven't seen any replies.] Unfortunately, Silicon Graphics has chosen the out-dated vt52 emulation for the Iris keyboard (at least on the 3020 and 2400) -- and it doesn't even work properly. When I telnet to our local microVAX, and invoke EDT the forward scrolling is not working. Only the last line is 'scrolling'. Of course you can do a ^w screen refresh once in a while, but it becomes a nuissance in the long run :-{. Sooo, until SGI comes up with a decent ANSI keyboard driver routine (SGI, are you there?? Is it happening??) we are in *desperate* need of a vt100/vt200 emulation program. Something that would enable one to run a VAX session in a separate window. The vt52 emulation scheme is a *disaster* when running gnu emacs, since the arrow keys don't have the usual meaning (cursor movement...). It isn't possible to change this without changing some of the standard gnu emacs key bindings (M-A, M-B, etc). Talking of terminal emulation, there seems to be the problem with mex, that it doesn't keep track of the size of your textports. This means that vi and emacs *has* to run in a full sized window. Are there any fixes for this on the way?? Last, but not least: the world seems to be going X-windows. This is at least true for the European Macromolecular Crystallographers, who is currently deciding on X (and PHIGS) as the future standard for software (molecular graphics) development. Does anyone know of a fullblown IRIS mouse-driven X implementation, with the option of doing 3D graphics?? -- Morten Kjeldgaard, Aarhus University Denmark phone: +45 6 12 46 33 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26021; 13 Jan 88 18:48 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa25038; 13 Jan 88 16:43 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa24925; 13 Jan 88 16:36 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa00331; 13 Jan 88 16:28 EST Received: from bnl.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Wed, 13 Jan 88 13:17:03 PST Received: by bnl.ARPA; Wed, 13 Jan 88 16:09:04 EST Date: Wed, 13 Jan 88 16:09:04 EST From: Ed Thieberger Message-Id: <8801132109.AA07293@bnl.ARPA> To: Info-Iris@sumex-aim.stanford.EDU Has anyone tried compiling and using the timeserver program (available from sumex-aim)? Is it supposed to run under GL2? How does one go about compiling it (what libraries need to be loaded, etc.)? I'm using an IRIS 2400 Turbo w/ TCP/IP (Berkeley). I'd appreciate any help I can get. Thanks. Ed ---------------------------------------- Ed Thieberger thieb@bnl.ARPA Applied Math Dept. Brookhaven National Laboratory To iterate is human, to recurse, divine. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26473; 13 Jan 88 21:05 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26090; 13 Jan 88 19:21 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa26069; 13 Jan 88 19:13 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa02686; 13 Jan 88 18:56 EST Received: from NMFECC.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Wed, 13 Jan 88 15:57:07 PST Received: from fsu.mfenet by ccc.mfenet with Tell via MfeNet ; Tue, 12 Jan 88 10:50:00 PST Date: Tue, 12 Jan 88 10:50:00 PST From: MINUIT%FSU.MFENET@NMFECC.arpa Message-Id: <880112105000.2100022d@NMFECC.ARPA> Subject: disk space usage To: INFO-IRIS@SUMEX-AIM.STANFORD.EDU Comment: From MINUIT@FSU.MFENET on 12-JAN-1988 13:50:31.64 EST We just got an upgrade from 72 Meg to 170 Meg on our two 3130 machines. We were very surprised to find only 110 Meg of usable disk space on our new disks. After a little checking, I found that the 72 Meg drives have 59 Meg of usable space. So, the 72 Meg drives had 82% usable space while the 170 Meg drives only have 65%. What gives? Is there an alternate way to format the drive so as to be able to get more usable disk space? Any comments will be appreciated, David LaSalle SCRI Fla State Univ minuit%fsu@nmfecc.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01563; 14 Jan 88 7:49 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00454; 14 Jan 88 6:26 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id an00339; 14 Jan 88 6:22 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa06259; 14 Jan 88 1:43 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 13 Jan 88 22:45:13 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA12343; Wed, 13 Jan 88 22:20:54 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Jan 88 01:48:44 GMT From: "Renu Raman, Sun Microsystems" Organization: Sun Microsystems, Mountain View Subject: Re: (none) Message-Id: <38804@sun.uucp> References: <8801131909.AA00656@nps-cs.arpa> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <8801131909.AA00656@nps-cs.arpa> barrow@NPS-CS.ARPA (theodore barrow x2174) writes: >Please send me information on registration. We use IRIS 2000 and 3000 series >workstations and I am involved in porting some of the code to our new 4D. In other buy AAPL in the morning(friday) and sell it soon. --------------------- Renukanthan Raman ARPA:ram@sun.com Sun Microsystems UUCP:{ucbvax,seismo,hplabs}!sun!ram M/S 5-40, 2500 Garcia Avenue, Mt. View, CA 94043 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26160; 15 Jan 88 16:58 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa23932; 15 Jan 88 14:42 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa23920; 15 Jan 88 14:38 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa04747; 15 Jan 88 14:34 EST Date: Fri, 15 Jan 88 11:32:26 PST From: Craig Cornelius Subject: CommonLISP experience? To: info-iris@SUMEX-AIM.Stanford.EDU Message-ID: <12366856635.17.CORNELIUS@SUMEX-AIM.Stanford.EDU> I'm very interested in hearing about experiences with CommonLisp of any flavor on the IRIS series machines. In particular, I'd like to know about memory and disk requirements, debugging environments, speed, editing, and interactions with C programs. Also, does anyone know of a LISP to C translator of any sort? All pointers are appreciated. Craig ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa16385; 22 Jan 88 20:16 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15763; 22 Jan 88 18:01 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15743; 22 Jan 88 17:55 EST Received: from NPS-CS.ARPA by SMOKE.BRL.ARPA id aa00690; 22 Jan 88 17:50 EST Received: by nps-cs.arpa (5.51/1.26) id AA00409; Fri, 22 Jan 88 14:46:27 PST Date: Fri, 22 Jan 88 14:46:27 PST From: michael zyda Message-Id: <8801222246.AA00409@nps-cs.arpa> To: info-iris@BRL.ARPA Subject: IRIS 4D... At the Naval Postgraduate School, we now have an IRIS-4D/70G. We are busily porting our software from the 3120 and Turbo 2400 machines that we have. We find a few things missing from the machine. There is no /usr/people/gifts directory, as in the past. This is not a big problem as most everything is porting over OK. We did want to see a sample program that utilized the "Lighting Models" of Chapter 14 of the Graphics Library User's Guide. Does anyone out there, including SGI people, have any short demonstration programs that utilize this facility that they would be willing to forward over the net? One avenue I tried that did NOT pan out. I requested the source to the /usr/demos code that comes with the IRIS-4D. I had hoped that the code there would show me samples of the Lighting Model software. None of the demos there uses those routines! (Also, many of the programs there are written in a style that leaves a lot to be desired...) Thank you in advance! Michael Zyda Naval Postgraduate School, Code 52, Dept. of Computer Science Monterey, California 93943-5100 (408) 646-2305 (work) (408) 624-3546 (home) zyda@nps-cs.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa23411; 24 Jan 88 17:07 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22636; 24 Jan 88 15:43 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa22549; 24 Jan 88 15:35 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa21048; 24 Jan 88 15:35 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sun, 24 Jan 88 12:33:54 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA24599; Sun, 24 Jan 88 12:16:41 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Jan 88 05:55:20 GMT From: Charles L Ditzel Organization: Boeing Aerospace Corp., Seattle WA Subject: NeWS or X on sgi 3000 series Message-Id: <1627@ssc-vax.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU A friend of mine is trying to figure out the status of NeWS or X on his sgi 3000 series workstations. Apparently, SGI announced a NeWS based product for their new RISC machine, but has failed to mention anything about that product for their older workstations. 1) Does anyone know if sgi plans on releasing the NeWS product for the 3000 series? 2) Has anyone ported X to the SGI 3000 series? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04845; 25 Jan 88 13:53 EST Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04533; 25 Jan 88 13:43 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa04293; 25 Jan 88 13:31 EST Received: from CS.UTAH.EDU by SMOKE.BRL.ARPA id aa16133; 25 Jan 88 13:23 EST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA15585; Mon, 25 Jan 88 11:22:03 MST Received: by gr.utah.edu (5.54/utah-1.0-gr) id AA11656; Mon, 25 Jan 88 11:21:57 MST Date: Mon, 25 Jan 88 11:21:57 MST From: Russ Fish Message-Id: <8801251821.AA11656@gr.utah.edu> Subject: 4D ranlib Newsgroups: fa.iris,comp.sys.sgi Distribution: fa To: info-iris@brl.MIL Your makefiles, like ours, might want to `ranlib' your .a libraries. As has been mentioned, the 4D doesn't have a `ranlib', but does support the same function as a command to `ar'. Here's a little `ranlib' script to make life a little easier while porting. -Russ ================ Cut Here ================================ #! /bin/csh -f # There is no ranlib on the MIPS. Use `ar ts' instead. # Have to specify the "t", but throw the listing away. # Error messages come out on std err, so they will still be seen. ar ts $1 > /dev/null ================ End ================================ ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa25473; 28 Jan 88 12:39 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ac24948; 28 Jan 88 12:29 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab24734; 28 Jan 88 12:19 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa11266; 28 Jan 88 7:33 EST Received: from NMFECC.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Tue, 26 Jan 88 12:10:49 PST Received: from fsu.mfenet by ccc.mfenet with Tell via MfeNet ; Tue, 26 Jan 88 12:09:56 PST Date: Tue, 26 Jan 88 12:09:56 PST From: PEPKE%FSU.MFENET@NMFECC.arpa Message-Id: <880126120956.2120021c@NMFECC.ARPA> Subject: RE: Overhead Projector Mac Displays To: INFO-IRIS@sumex-aim.stanford.edu.arpa Comment: From PEPKE@FSU.MFENET on 26-JAN-1988 15:10:14.34 EST X-ST-Return-Receipt-Requested: In response to A. E. Siegman's posting about the quality of overhead Mac displays: I, too, was at the MacWorld show, and I looked at all the displays. Kodak was indeed there. In my opinion, the Kodak display was the best at the show. The contrast was high, it was sharp and fast, and I could perceive no row or column artifacts. It is not surprising that their display was so good, considering that the first company to my knowledge which came out with a good display for the PC was mostly owned by Kodak. Kodak, unlike many of the other vendors at the show, made sure that the display conditions were as good as possible, which may have exaggerated the difference in quality. The Kodak display was, however specifically for the small Macs, and the salesman there refused to comment at all about their plans for a Mac II version. The use of the term "high-powered" to describe the overhead projector is dangerous. Everyone who has left an LCD watch on a car dashboard knows that heat and LCD's are natural enemies. The original Sayett system, the Kodak precursor, was said to fail after about an hour on cheap projectors. So, if you get one of these, make sure that the projector has the magic piece of glass that stops infrared. I have no connection with any of the vendors except as a potential customer. Eric Pepke pepke%fsu.mfenet@nmfecc.arpa Supercomputer Computations pepke%scri.hepnet@lbl-csa2.arpa Research Institute pepke%fsu.bitnet@wiscvm.wisc.edu Florida State University Disclaimer: My employers seldom even LISTEN to my opinions, let alone endorse them. Meta-disclaimer: Any society that needs disclaimers has too many lawyers. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id ab25473; 28 Jan 88 12:39 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ad24948; 28 Jan 88 12:29 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id ac24734; 28 Jan 88 12:20 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa11287; 28 Jan 88 7:36 EST Received: from megaron.arizona.edu by SUMEX-AIM.Stanford.EDU with TCP; Tue, 26 Jan 88 18:05:14 PST Received: by megaron.arizona.edu; Tue, 26 Jan 88 17:01:38 MST Received: by uazchem.SGI (5.15/5.6) id AA03739; Tue, 26 Jan 88 16:54:42 PST Date: Tue, 26 Jan 88 16:54:42 PST From: Dolata Message-Id: <8801270054.AA03739@uazchem.SGI> To: arizona!info-iris%sumex-aim.stanford.edu@arizona.EDU, dolata@arizona.EDU Subject: Who's fault is it???? I realize that the following is not stricitly an IRIS question, but it often impacts my ability to interact with this list; The following is a far too typical example of what happens to many of my info-iris (and other) messages. I have complained bitterly to our system manager, but he claims that sumex, brl, rutgers, riacs, nd others all have 'funny' mailers which cause the problem... (Sounds like a little child saying that the whole world is wrong...). What I would like to know is: How many subscribers are there on info-iris, and how many other people have had problems like this? Would the info-iris manager please send me the number of total users, and would any individual who has seen a similar problem please send me a message? (or try to...) thank you for your help uazchem!dolata%arizona.edu ------- Resent-From: arizona!info-iris-request@brl-vmb.arpa Return-Path: info-iris-request@brl-vmb.arpa Date: 24 Jan 88 05:55:20 GMT From: Charles L Ditzel Subject: NeWS or X on sgi 3000 series Sender: arizona!info-iris-request@sumex-aim.stanford.edu To: info-iris@sumex-aim.stanford.edu X-Vms-To: info-iris@sumex-aim.stanford.edu Resent-Date: Tue, 26 Jan 88 16:07 MST Resent-To: uazchem!dolata Organization: Boeing Aerospace Corp., Seattle WA A friend of mine is trying to figure out the status *** Timeout on net connection: VMS or TCP error: %x22c *** === Network Mail from host BRL-VMB.ARPA on Tue Jan 26 16:03:32 === ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26812; 28 Jan 88 13:13 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26374; 28 Jan 88 13:03 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa26180; 28 Jan 88 12:55 EST Received: from [36.10.0.13] by SMOKE.BRL.ARPA id aa19990; 28 Jan 88 12:28 EST Date: Wed 27 Jan 88 08:30:47-PST From: Lloyd La Comb Subject: dog under tcp/ip To: info-iris@BRL.ARPA cc: lacomb@Sierra.Stanford.EDU Message-ID: <12369969294.17.LACOMB@Sierra.Stanford.EDU> I recently got the source code from SGI for the flight/dog demos. I have only the TCP/IP operating system, so at first even the filght program will not compile because I didn't have some include files. The folks at SGI told me what was in those include files so I how have the new version of flight, but unfortunately dog still does not run even if all I want to do is use the dog -i airshow option to fly with the demonstration program. There are some libs. that it need that they send only if you have the XNS options. My question is does someone have dog running under TCP/IP and if possible could they illucidated the changes that are needed. Thanks. Lloyd La Comb. lacomb@sierra.stanford.edu ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa28575; 28 Jan 88 14:26 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab24948; 28 Jan 88 12:29 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab24662; 28 Jan 88 12:17 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa11145; 28 Jan 88 7:26 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 28 Jan 88 02:08:48 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA14956; Thu, 28 Jan 88 01:29:42 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Jan 88 02:07:49 GMT From: Tony To Lam SLB Organization: NASA Ames Research Center, Moffett Field, CA. Subject: Can mapw() be used in Mex? Message-Id: <4092@ames.arpa> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Hello: I have a question about the mapw() function in the iris gl library. Can this function be used in the mex window environment? If yes, how can one save and pass the viewport transformation matrix when calling mapw? I tried the following, but it did not work. winopen(); getmatrix(matrix); . . . makeobj(1); loadmatrix(matrix); << other transformations >> closeobj(); mapw(1,..........); Anyone have any ideas? Thanks! . . ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa28822; 28 Jan 88 14:47 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa24948; 28 Jan 88 12:29 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id ac24605; 28 Jan 88 12:16 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa10190; 28 Jan 88 6:11 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 27 Jan 88 21:44:44 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA10344; Wed, 27 Jan 88 21:22:25 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Jan 88 18:56:40 GMT From: Kris Iskandar Organization: UF CIS Department Subject: Hidden surface removal algorithm on IRIS 2400 Message-Id: <10400@uflorida.cis.ufl.EDU> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Hi, netlander: I am working on a project building a 3D modeling system on an IRIS 2400. The machine has only 8 bitplanes which means I have to create my own hidden surface removal routines. I am sure other people have done this before. I appreciate anybody that can share his/her code, it will save some of my time from creating my own. Please e-mail the code to the following address: kis@beach.cis.ufl.edu Thank you very much for your help. -- -------------------------------------------------------------------------- Kris Iskandar University of Florida Computer kis@beach.cis.ufl.edu Graphics Research Laboratory .!ihnp4!codas!uflorida!beach.cis.ufl.edu!kis Gainesville, FL 32611 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa21098; 4 Feb 88 13:57 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa19451; 4 Feb 88 12:12 EST Received: from brl-spark.arpa by VMB.BRL.ARPA id aa19226; 4 Feb 88 11:57 EST Received: from SUMEX-AIM.STANFORD.EDU by SPARK.BRL.ARPA id aa03532; 4 Feb 88 11:43 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 4 Feb 88 08:24:11 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA16832; Thu, 4 Feb 88 08:01:55 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Feb 88 15:53:00 GMT From: Marcus Gates Organization: The Johns Hopkins University Applied Physics Laboratory Subject: Color Printers Message-Id: <23@aplcomm.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU We have 6 Silicon Graphics 2400T workstations on an ethernet with a Vax running Ultrix and are in the process of evaluating color printers to improve our hardcopy capability. We currently are able to output plots to flat-bed plotters using 4.XBSD line-printer spooling, which allows access to the plotter from any workstation, and also doesn't force the workstation to be tied-up waiting for the plotter to become available. We would prefer to use lineprinter-type spooling to share whatever color printer we buy, among the workstations. We are looking at the Tektronix 4693D color printer. Any experience regarding this printer or spooling of print files would be greatly appreciated. Any suggestions or description of how others have solved this problem would also be very useful greatly appreciated. Also, not long ago someone posted a request for information concerning use of the X-window system on irises, I haven't seen any replies yet. Could the original poster please send me a summary of replies (if any) he received. Thanks, marc gates johns hopkins applied physics lab laurel, md marc@aplpy.jhuapl.edu marc gates johns hopkins applied physics lab laurel, md marc@aplvax.jhuapl.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa02255; 5 Feb 88 9:38 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00863; 5 Feb 88 8:14 EST Received: from brl-spark.arpa by VMB.BRL.ARPA id aa00832; 5 Feb 88 8:08 EST Received: from SUMEX-AIM.STANFORD.EDU by SPARK.BRL.ARPA id aa05472; 5 Feb 88 8:07 EST Received: from gelac.arpa by SUMEX-AIM.Stanford.EDU with TCP; Fri, 5 Feb 88 05:10:40 PST Received: by gelac.arpa (4.12/25) id AA20347; Fri, 5 Feb 88 08:12:13 est Message-Id: <8802051312.AA20347@gelac.arpa> To: info-iris@sumex-aim.stanford.EDU Date: Fri, 5 Feb 88 8:12:11 GMT+4520891:44 From: "Mr. Barry W. Webb" Subject: Re: Color Printers X-Mailer: msg [version 3.2] We have eight IRISes that are on the same XNS ethernet. We don't use a color printer but we do use a single line printer for all the machines. The configuration and software is as follows: The printer is attached to a serial port on one IRIS. I have used the 'lpadmin' command to define the line printer spooler to the system. On that IRIS I have written a program that is started in /etc/rc.local and waits for connections from the other machines on a particular socket. Once the connection is established, the program reads the data, creates a temporary file and issues an 'lp' command to submit the file to the line printer spooling system. Upon completion it again waits for another connection. On the other machines I wrote a program that accepts a file's name as the command line argument, establishes the connection to the line printer machine, and sends the file. The arrangement seems to work quite well. I have even extended the second program to PCs that are also on the network so they have access to the remote printer. Our plans are to switch to TCP/IP in the near future so we can expand the network to include a VAX, 4 SELs and 7 Symbolics. Once this is accomplished and the IRIS programs rewritten (does anyone have such programs they would like to share, I'd be glad to share mine if anyone is interested) I hope to have access to all line and laser printers that are in the configuration. Barry Webb Lockheed Aeronautical Systems Company bwebb@gelac.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa06907; 6 Feb 88 9:36 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa06706; 6 Feb 88 8:23 EST Received: from brl-spark.arpa by VMB.BRL.ARPA id aa06701; 6 Feb 88 8:19 EST Received: from SUMEX-AIM.STANFORD.EDU by SPARK.BRL.ARPA id aa12542; 6 Feb 88 8:18 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sat, 6 Feb 88 05:21:14 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA14226; Sat, 6 Feb 88 04:56:19 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Feb 88 08:29:22 GMT From: Gavin Bell Organization: Dept. of Computer Science, Princeton University Subject: Silicon Graphics 4d caps lock/cntrl keys Message-Id: <8725@princeton.Princeton.EDU> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU [I once heard a rumor that the lineater really exists...] I'm going crazy trying to switch back and forth between 'normal' keyboards and the 4d's backwards keymapping of the control and caps-lock keys. Is there anything at all that can be done about this short of rlogging in from the sun sitting next to it and using it as a smart frame-buffer? Trying to use Emacs nearly breaks my little finger. There must be an alternate keymapping, keyboard, or something, right? Please? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14221; 7 Feb 88 16:19 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12831; 7 Feb 88 14:35 EST Received: from brl-spark.arpa by VMB.BRL.ARPA id aa12667; 7 Feb 88 14:26 EST Received: from SUMEX-AIM.STANFORD.EDU by SPARK.BRL.ARPA id aa18776; 7 Feb 88 12:52 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sun, 7 Feb 88 09:48:49 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA10469; Sun, 7 Feb 88 09:48:12 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Feb 88 17:13:14 GMT From: Michael Cohen Organization: Boston U., Center for Adaptive Systems Subject: Silicon Graphics Synchronization Message-Id: <571252394.3609@bucasb.bu.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Could you please tell me what are is the function call/signal so once can wait/interrupt on screen refresh. This is so screen activities can be synchronized with programming commands. -thanks mike ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19568; 8 Feb 88 8:53 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa19314; 8 Feb 88 8:42 EST Received: from brl-spark.arpa by VMB.BRL.ARPA id aa19226; 8 Feb 88 8:34 EST Received: from SUMEX-AIM.STANFORD.EDU by SPARK.BRL.ARPA id aa21373; 8 Feb 88 8:30 EST Received: from zorac.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Mon, 8 Feb 88 05:27:32 PST Received: by zorac.ARPA (4.12/25-eef) id AA11874; Mon, 8 Feb 88 08:31:15 est Date: Mon, 8 Feb 88 08:31:15 est From: Tim Pointing Message-Id: <8802081331.AA11874@zorac.ARPA> To: info-iris@sumex-aim.stanford.EDU Subject: Re: Silicon Graphics Synchronization I think that "gsync" (described in the Graphics Programming Reference Manual and probably on-line too) is the subroutine-call you are looking for. Tim Pointing, DCIEM tim@zorac.arpa, uunet!mnetor!dciem!tim ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01100; 8 Feb 88 23:51 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00729; 8 Feb 88 22:17 EST Received: from brl-spark.arpa by VMB.BRL.ARPA id aa00721; 8 Feb 88 22:12 EST Received: from SUMEX-AIM.STANFORD.EDU by SPARK.BRL.ARPA id aa02038; 8 Feb 88 22:03 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 8 Feb 88 18:59:41 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA11303; Mon, 8 Feb 88 18:28:32 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Feb 88 00:50:10 GMT From: Michael Cohen Organization: Boston U., Center for Adaptive Systems Subject: Silicon Graphics ftp Bug Message-Id: <571366210.10744@bucasb.bu.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In communicating with a BSD 4.3 machine SGI ftp doesn't seem to be able to do mputs or mgets. This is true if I either attmpt to mget from a remote machine or mput locally. I get different error messages in each case. ftp using put or get works fine. Has anybody seen bugs like this before. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13737; 9 Feb 88 16:17 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa10552; 9 Feb 88 13:51 EST Received: from brl-spark.arpa by VMB.BRL.ARPA id aa10385; 9 Feb 88 13:36 EST Received: from SUMEX-AIM.STANFORD.EDU by SPARK.BRL.ARPA id aa04325; 9 Feb 88 13:31 EST Received: from cu-arpa.cs.cornell.edu by SUMEX-AIM.Stanford.EDU with TCP; Tue, 9 Feb 88 10:19:02 PST Message-Id: <8802091819.AA12438@cu-arpa.cs.cornell.edu> Received: from cheme.tn.cornell.edu by cu-arpa.cs.cornell.edu (5.54/4.30) id AA12438; Tue, 9 Feb 88 13:19:47 EST Date: 9 Feb 88 07:52:00 EST From: "CHEME::OLIN" Subject: IRIS ftp bug To: "info-iris%sumex-aim.stanford.edu" Cc: olin@cu-arpa.cs.cornell.EDU Michael Cohen writes: > In communicating with a BSD 4.3 machine SGI ftp doesn't seem to be > able to do mputs or mgets. This is true if I either attmpt to mget > from a remote machine or mput locally. I get different error messages > in each case. ftp using put or get works fine. Has anybody seen bugs > like this before. I look after an IRIS 3020 and an IRIS 3030 (V3.5 software) which talk to a VAX 8250 running Woolongong's WIN/TCP on top of VMS. We can't do mput's or mget's either. Again put and get works fine. Looks like we have the same bug. It's very inconvenient! Steve Thompson, System Mangler School of Chemical Engineering Cornell University Ithaca NY 14853 (607) 255 4616 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15018; 9 Feb 88 19:07 EST Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14130; 9 Feb 88 16:42 EST Received: from brl-spark.arpa by VMB.BRL.ARPA id aa14117; 9 Feb 88 16:36 EST Received: from SUMEX-AIM.STANFORD.EDU by SPARK.BRL.ARPA id aa04747; 9 Feb 88 16:28 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Tue, 9 Feb 88 13:23:50 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA05328; Tue, 9 Feb 88 12:57:45 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Feb 88 16:40:58 GMT From: Joel Garrett Organization: University of Delaware Subject: Re: Silicon Graphics ftp Bug Message-Id: <1123@louie.udel.EDU> References: <571366210.10744@bucasb.bu.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <571366210.10744@bucasb.bu.edu> mike@bucasb.UUCP (Michael Cohen) writes: >In communicating with a BSD 4.3 machine SGI ftp doesn't seem >to be able to do mputs or mgets. This is true if I either attmpt >to mget from a remote machine or mput locally. I get different error >messages in each case. ftp using put or get works fine. Has anybody >seen bugs like this before. Yeah, we've been having that same problem ever since we upgraded to the latest release of the kernel. Does anyone know if SGI knows about the problem already and maybe has a fix for it? Joel Garrett Research Associate Center for Composite Materials University of Delaware Newark, DE 19716 arpa: garrett@udel.edu ------- Received: from [128.95.1.1] by VMB.BRL.ARPA id aa00251; 16 Dec 87 4:02 EST Received: by beaver.cs.washington.edu (5.52.1/6.12) id AA08387; Wed, 16 Dec 87 00:22:26 PST Return-Path: Received: by ssc-vax (4.12/4.7) id AA09067; Tue, 15 Dec 87 19:05:29 pst Received: by voodoo.UUCP (1.2/smail2.5/10-14-87) id AA03403; Sat, 12 Dec 87 10:09:22 pst From: ssc-vax!voodoo!zombie@beaver.cs.washington.edu (Mike York) Message-Id: <8712121809.AA03403@voodoo.UUCP> To: ssc-vax!uw-beaver!BRL-VMB.arpa!info-iris-request@beaver.cs.washington.edu (Mike Muuss) Date: Sat, 12 Dec 87 10:09:19 PDT Subject: Re: 4D Keyboard In-Reply-To: Message from "Mike Muuss" of Dec 10, 87 at 9:13 pm X-Mailer: Elm [version 1.5b] I felt the same way about the keyboard when our 4D/60's were delivered in mid August. I got used to it after a month and am quite comfortable with it now. In fact, whenever I use one our 2400T's, I complain loudly about its keyboard (which used to be one of my favorite keyboards). ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19952; 10 Feb 88 9:04 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa18561; 10 Feb 88 7:41 EST Date: Wed, 10 Feb 88 7:36:50 EST From: Chuck Kennedy To: info-iris@BRL.ARPA Subject: Greetings! Message-ID: <8802100736.aa18526@VMB.BRL.ARPA> Folks, sorry for the long delay for those that have had requests into info-iris-request. There was a death in the family piled on top of Xmas, piled on top of a lot of waiting work when I returned. I have finished up most of the backlog for additions and deletions to the mailing list. Best, -Chuck Kennedy ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15816; 11 Feb 88 19:59 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15501; 11 Feb 88 18:25 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15482; 11 Feb 88 18:20 EST Received: from [36.10.0.13] by SMOKE.BRL.ARPA id aa11674; 11 Feb 88 18:13 EST Date: Thu 11 Feb 88 15:06:31-PST From: Lloyd La Comb Subject: stereo on iris To: info-iris@BRL.ARPA cc: lacomb@Sierra.Stanford.EDU Message-ID: <12373973495.14.LACOMB@Sierra.Stanford.EDU> I'm having some trouble creating stereo pairs on the Iris. It seems that all I should have to do is to change the eye position with polarview() or lookat() and I should have stereo pairs but that doesn't seem to be happening. The following is a short algol-like desription of what I'm doing can anyone out there see anything that's wrong I imagine it's something obvious. ginit() viewport() perspective() pushmatrix() polarview(dist,0,0-offset,twist) nose sitting on z axis, left eye to the left drawobj() popmatrix() polarview(dist,0,0+offset,twist) right eye to the right drawobj() I ran the program with several different offsets from 1 to 12 degrees and took slides for each eye and looked at them in a stereo viewer and threr's is no 3d effect to speak of. Any suggestions? Thanks. Lloyd La Comb lacomb@sierra.stanford.edu ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa20564; 12 Feb 88 9:26 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa19077; 12 Feb 88 8:23 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa19004; 12 Feb 88 8:12 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa19942; 12 Feb 88 8:03 EST Received: Fri, 12 Feb 88 08:01:48 EST by aero4.larc.nasa.gov (5.15/5.6) Date: Fri, 12 Feb 88 08:01:48 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8802121301.AA11106@aero4.larc.nasa.gov> To: LACOMB@Sierra.Stanford.EDU Subject: Re: stereo on iris Cc: info-iris@BRL.ARPA Interesting that you should pose that question now, I was just experimenting with that last week. Personally, I think lookat() is the best way to do it. I've got a program that I use to look at 3D grids, it rotates, magnifies, translates, and changes the perspective. I modified it slightly so that, in one buffer the object was drawn in RED with lookat() offset to the right about 1.0 and in the other buffer I draw in BLUE with lookat() offset to the left about 1.0. Then I swap buffers back & forth, and look at the screen with MAGENTA & CYAN filters. One thing I notice was that depending on how deep the object was I needed to adjust the field of view. With very deep objects, I needed a narrow view, with shallow objects, I could use a larger view. Usually, my field of view was less than 20 degrees. In FORTRAN: call getsiz(xlength,ylength) . . . totext=max(abs(xmax-xmin),abs(ymax-ymin),abs(zmax-zmin))*1.25 . . far=totext*1.5-viewpnt if(far.le.0) then far=totext*1.0e-4 endif near=-viewpnt if(near.ge.far.or.near.le.far*1.0e-3.or.near.le.0) then near=far*1.0e-2 endif call perspe(fovy,real(xlength)/real(ylength),near,far) if(red) then call lookat(viewpnt-totext,xpos-1.0,ypos,viewpnt,xpos,ypos,-900) else call lookat(viewpnt-totext,xpos+1.0,ypos,viewpnt,xpos,ypos,-900) endif I adjust xpos & ypos for translations and viewpnt for magnifications. If you are doing zbuffering near can't be 0.0 or < far*1.0e-3. The near to far ratio is not carved in stone, but the 0.0 is. I hope this is of some help, if you have any questions just ask. The RED and BLUE works ok, but I the stereo viewer would be better. You might try my way to test how things look and then get hard copy in the correct colors for the stereo viewer. Good luck. Brent L. Bates ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26011; 17 Feb 88 1:46 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa25505; 16 Feb 88 23:51 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa25490; 16 Feb 88 23:43 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa10994; 16 Feb 88 23:31 EST Received: from megaron.arizona.edu by SUMEX-AIM.Stanford.EDU with TCP; Tue, 16 Feb 88 20:30:11 PST Received: by megaron.arizona.edu; Tue, 16 Feb 88 21:32:13 MST Received: by uazchem.SGI (5.15/5.6) id AA00650; Tue, 16 Feb 88 21:29:17 PST Date: Tue, 16 Feb 88 21:29:17 PST From: Dolata Message-Id: <8802170529.AA00650@uazchem.SGI> To: arizona!info-iris%sumex-aim.stanford.edu@arizona.EDU Subject: Knob and dial box Sometimes the switch on the back of the button box gets turned off. When it is turned back on the button and dial boxes don't interact with programs anymore. Can someone tell me how to reset them, short of my current technique of rebooting the system while the switch is turned on? Also, sometimes the port which is attached to my dial out modem gets hung. I can "kill -9 nnnn" the processes which are using the port (typically cu has two hanging on it), but often when I try to "cu" after that I am told either that the dev is out of resources, or unavailable. Any hints on how to fix that? Thanks for the help. Dan ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa28955; 17 Feb 88 8:56 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa27309; 17 Feb 88 7:53 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa27227; 17 Feb 88 7:44 EST Received: from [128.155.20.81] by SMOKE.BRL.ARPA id aa14534; 17 Feb 88 7:40 EST Received: Wed, 17 Feb 88 07:41:51 EST by aero4.larc.nasa.gov (5.15/5.6) Date: Wed, 17 Feb 88 07:41:51 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8802171241.AA03516@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: Silicon Graphics ftp Bug In referece to Michael Cohen's message: YES. ftp, along with just about everything else on the IRIS's, doesn't work properly. People at NASA Ames have supposedly come up with a fix, however, it works only marginally better. Silicon Graphics makes great hardware, but, the software stinks! and their documentation is worse. I have used BETA test site software that works better. I don't know who you should talk to at Ames to see if you can get their ftp. I think they are suppose to have an improved telnet too. Good luck. Brent L. Bates ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00177; 17 Feb 88 10:02 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab28955; 17 Feb 88 8:58 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa28847; 17 Feb 88 8:51 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa16316; 17 Feb 88 8:38 EST Received: from masig1.ocean.fsu.edu by SUMEX-AIM.Stanford.EDU with TCP; Wed, 17 Feb 88 05:37:17 PST Received: by masig1.ocean.fsu.edu (5.15/25-eef) id AA10239; Tue, 16 Feb 88 17:42:32 EST Date: Tue, 16 Feb 88 17:42:32 EST From: "John D. McCalpin" Message-Id: <8802162242.AA10239@masig1.ocean.fsu.edu> To: info-iris@sumex-aim.stanford.EDU Subject: Tek 4010/4014 emulator ??? Cc: mccalpin@masig1.ocean.fsu.EDU, simmy@ocean Does anyone have a Tektronix 4010/4014 emulator for the IRIS 3000 series machines ? I know it is rather silly to use a $50,000 workstation to emulate a Tek 4010, but it is also rather silly that I can NOT do it :-). It is also much faster and nicer looking to print Tek 4010/4014 plots (using ps4014), than to wait the 30 minutes for a screen dump to our LaserWriter.... Please reply directly (especially if everybody knows about this already) John D. McCalpin mcalpin@fsu.BITNET mccalpin@fsu.MFENET mccalpin@masig1.ocean.fsu.edu (128.186.3.1) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01210; 17 Feb 88 11:36 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa29886; 17 Feb 88 9:51 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa29773; 17 Feb 88 9:43 EST Received: from USNA.MIL by SMOKE.BRL.ARPA id aa17712; 17 Feb 88 9:34 EST Date: Wed, 17 Feb 88 9:26:04 EST From: "David F. Rogers" To: info-iris@BRL.ARPA Subject: Iris Message-ID: <8802170926.aa04918@CAD.USNA.MIL> Brent L. Bates's comments re the quality of the Silicon Graphics software and documentation are at best immature. Especially on a public net. I have worked with Iris's since the 2400 (i.e. a 68010 box) thru a 2400T i.e. a 3000 series machine and now on to the 4D. In some nearly 20 years of experience in both computers and computer graphics I find that not only is the hardware outstanding, but also the actual user (i.e. application programmer) software and especially documentation is superior to anyone elses in the market place. That is not to say that room for improvement does not exist. The TCP/IP problem is one of long standing. It definitely needs fixing. SGI should definitely devote some real resources to correcting this problem. However, one has to realize that networking is an ancilliary problem and concern as far as the basic machine function is concerned. I for one would rather have the really great graphics machine and struggle with the network than vice versa. There are also other known problems. These are especially annoying if you are a BSD 4.2/3 person and have to cope with some of the System V differences. But then that is the Unix world. In comparison, I find trying to cope with a Sun and the Sun documentation quite annoying. AND I don't even get good graphics. Because any workstation of the sophistication of an Iris or a Sun or a Raster Tech, etc. is a complex engineering and manufacturing system, difficulties will always exist. Ranting and raving about them does not really help. Good constructive rational criticisms made to appropriate company representatives will achieve more lasting and useful results. Come on people let's remember that this is a public net. Comments in poor taste are not appropriate. Professor David F. Rogers Aerospace Engineering Department U.S. Naval Academy Annapolis, MD 21402 USA ARPANET: dfr@usna.mil UUCP: ~uunet!usna!dfr ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa07674; 17 Feb 88 20:51 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa07338; 17 Feb 88 19:38 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa07292; 17 Feb 88 19:29 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa10385; 17 Feb 88 19:24 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 17 Feb 88 16:23:47 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA03263; Wed, 17 Feb 88 15:49:41 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Feb 88 20:16:50 GMT From: Michael Piplani Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: Re: Iris Message-Id: <3759@batcomputer.tn.cornell.edu> References: <8802170926.aa04918@CAD.USNA.MIL> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Does anybody out there know who makes monitors that will work on a 3000 system - 60HZ using the IRIS RGB and Synch cables? I know BARCO makes a fantastic projection viewer but the screen size is a little larger then I had in mind (it also costs $10K+) thanks mike piplani darpa: piplani@tcgould.tn.cornell.edu bitnet: piplani@crnlimap ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15108; 18 Feb 88 11:29 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa13973; 18 Feb 88 10:16 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa13817; 18 Feb 88 10:07 EST Date: Thu, 18 Feb 88 9:55:15 EST From: "Mr. Tracy Wood" (USASIGCEN | mort) To: info-iris@brl-vmb.arpa cc: sigcen@BRL.ARPA Subject: TCP/IP Hardware Upgrade Required? Message-ID: <8802180955.aa02591@SMOKE.BRL.ARPA> Iris Users - Here at Fort Gordon we have an Iris 3020 (Unix System 5) with XNS installed for use with an Ethernet. We want to convert to TCP/IP. We know there is a software upgrade involved. Is there any hardware upgrade required (e.g. new ROMS, complete swapping of I/O boards)? We look forward to a response. Thank You (Mr.) Tracy Wood Operations Research Analyst U.S. Army Signal Center Directorate of Combat Developments C&S, Studies Branch (ATZH-CDC) Fort Gordon, GA 30905-5090 Phone 404-791-3782 (AV 780-3782) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11977; 19 Feb 88 9:59 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa09581; 19 Feb 88 8:12 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa09544; 19 Feb 88 8:03 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa05593; 19 Feb 88 7:48 EST Received: from lindy.stanford.edu by SUMEX-AIM.Stanford.EDU with TCP; Fri, 19 Feb 88 04:48:32 PST Received: by lindy.stanford.edu; Fri, 19 Feb 88 04:49:51 PST Received: by Forsythe.Stanford.EDU; Fri, 19 Feb 88 04:47:54 PST Received: by PUCC (Mailer X1.25) id 8826; Fri, 19 Feb 88 07:20:34 EST Date: Fri, 19 Feb 1988 07:12:38 EST From: "Amit S. Joshi" To: info-iris@sumex-aim.stanford.EDU Message-ID: <8802190748.aa05593@SMOKE.BRL.ARPA> I don't know how to get get the local editor (XEDIT) to include mail files so I shall just have to paraphrase the original query: " Are there any other monitors (RGB) that connect to the IRIS" Yes (and possibly no). I had managed to connect with Zero difficulty a NEC Multisynch (yes bought originallly for our IBM PC AT ) while the 19" was down. No problems at all. Just configure the switches at the back for a secondary monitor. The 'no' part - well the Multisynch is 14" and I can't seem to get the IRIS to understand that. It still acts as if it were a 19". The good news may be that I think there is a newer NEC which is 19" and costs about $1K (just check with your local IBM (;m)) supplies dealer !!). Hope this helps. Amit Joshi | BITNET | Q3696@PUCC.BITNET | USENET | {seismo, rutgers}\!princeton\!phoenix\!asjoshi " There's a pleasure in being mad... which none but madmen know!" - St. Dryden ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13722; 19 Feb 88 11:12 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11302; 19 Feb 88 9:17 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa10976; 19 Feb 88 9:06 EST Date: Fri, 19 Feb 88 8:54:07 EST From: "Mr. Tracy Wood" (USASIGCEN | mort) To: info-iris@brl-vmb.arpa cc: sigcen@BRL.ARPA Subject: Answer to TCP/IP Hardware Upgrade Question Message-ID: <8802190854.aa08168@SMOKE.BRL.ARPA> IRIS Users - I received the necessary information on the TCP/IP upgrade. M. Zyda, Naval Postgraduate School, informs me that it's just a software issue on the IRIS 3020. (You just "PROM" boot up using the TCP/IP kernal instead on the XNS kernal). Both kernals are already installed on the IRIS. Further investigation shows that any potential hardware upgrades are for the mainframe computer which will interface with the IRIS. Tracy Wood OR Analyst US Army Signal Center (404) 791-3782 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa21121; 20 Feb 88 4:15 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa20702; 20 Feb 88 2:31 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa20688; 20 Feb 88 2:24 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa03926; 20 Feb 88 2:14 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Fri, 19 Feb 88 23:15:06 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA08282; Fri, 19 Feb 88 23:02:42 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Feb 88 20:40:47 GMT From: Ian Clements Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: Answer to TCP/IP Hardware Upgrade Question Message-Id: <11199@sgi.SGI.COM> References: <8802190854.aa08168@SMOKE.BRL.ARPA> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <8802190854.aa08168@SMOKE.BRL.ARPA>, sigcen@BRL.ARPA ("Mr. Tracy Wood", USASIGCEN | mort) writes: > ... (You just "PROM" boot up using the TCP/IP kernal instead > on the XNS kernal). Both kernals are already installed on the IRIS. Actually, when you install TCP the default kernel is set to 3000.tcp. You can change this by using the command "kernel xns" or for that matter "kernel tcp" if you're runnign XNS. Ian ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa24222; 23 Feb 88 15:44 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa23783; 23 Feb 88 15:34 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa23686; 23 Feb 88 15:25 EST Received: from HAWAII-EMH.ARPA by SMOKE.BRL.ARPA id aa01379; 23 Feb 88 15:13 EST Date: 23 Feb 88 20:04 GMT From: dkb-amos@Hawaii-EMH.arpa Subject: KCL and GNU Emacs Graphics Interface To: Info-IRIS@BRL.ARPA Message-ID: <8802231513.aa01379@SMOKE.BRL.ARPA> Does anyone have any pointers to IRIS graphics interfaces for Kyoto Common Lisp or GNU Emacs? Thanks in advance, Dennis ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa24415; 23 Feb 88 16:05 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa21826; 23 Feb 88 13:59 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa21686; 23 Feb 88 13:49 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa26375; 23 Feb 88 13:40 EST Received: from NMFECC.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Tue, 23 Feb 88 10:24:24 PST Received: from fsu.mfenet by ccc.mfenet with Tell via MfeNet ; Tue, 23 Feb 88 10:23:17 PST Date: Tue, 23 Feb 88 10:23:17 PST From: PEPKE%FSU.MFENET@NMFECC.arpa Message-Id: <880223102317.2040021c@NMFECC.ARPA> Subject: Color Printers for the IRIS To: INFO-IRIS@SUMEX-AIM.STANFORD.EDU Comment: From PEPKE@FSU.MFENET on 23-FEB-1988 13:26:02.50 EST X-ST-Return-Receipt-Requested: We are considering buying a color printer for our IRIS 3030. Does anyone have experience and words o' wisdom about the SGI thermal transfer offerings, either the Tektronix or the Seiko? How many colors do you effectively get, what dithering options do you get, etc.? Do you have experience hooking up other printers? If you send responses directly to me, I will summarize and post. Eric Pepke pepke%fsu.mfenet@nmfecc.arpa Supercomputer Computations pepke%scri.hepnet@lbl-csa2.arpa Research Institute pepke%fsu.bitnet@wiscvm.wisc.edu Florida State University Tallahassee, FL 32306-4052 Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26802; 23 Feb 88 21:30 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26436; 23 Feb 88 19:56 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa26404; 23 Feb 88 19:51 EST Received: from [128.102.22.45] by SMOKE.BRL.ARPA id aa08387; 23 Feb 88 19:38 EST Received: Tue, 23 Feb 88 14:51:03 PST by rodan.nas.nasa.gov (5.15/1.2) Date: Tue, 23 Feb 88 14:51:03 PST From: "Eric L. Raible" Message-Id: <8802232251.AA00609@rodan.nas.nasa.gov> To: info-iris@BRL.ARPA Cc: dkb-amos@hawaii-emh.arpa In-Reply-To: dkb-amos@Hawaii-EMH.arpa's message of 23 Feb 88 20:04 GMT <8802231513.aa01379@SMOKE.BRL.ARPA> Subject: KCL and GNU Emacs Graphics Interface Date: 23 Feb 88 20:04 GMT From: dkb-amos@Hawaii-EMH.arpa Does anyone have any pointers to IRIS graphics interfaces for Kyoto Common Lisp or GNU Emacs? Thanks in advance, Dennis I wrote an interface that includes most of the Iris gl2 calls. Just drop me a note if you want it. It includes some (very) simple demos. All users of KCL should be interested in the work that Bill Schelter (wfs@rascal.ics.utexas.edu) has done to enhance kcl. A partial list of his changes include fast fasling (doesn't fork an ld), better debugging, faster function calls, profiling, etc. A compressed tar is available on rascal as akcl.tar.Z. In addition to the enhancements mentioned above, it also includes my port of KCL to the iris. Have fun - Eric ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14282; 26 Feb 88 11:34 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11194; 26 Feb 88 9:29 EST Received: from brl-tbd.arpa by VMB.BRL.ARPA id aa11054; 26 Feb 88 9:14 EST Date: Fri, 26 Feb 88 9:07:18 EST From: Glenn Randers-Pehrson (WMB) To: info-iris@BRL.ARPA Subject: IRIS floating point read error Message-ID: <8802260907.aa27838@TBD.BRL.ARPA> caution: The FORTRAN READ statement can produce erroneous results when using the IRIS floating point board, viz: Script started on Fri Feb 26 08:37:42 1988 taurus.brl.mil> cat bug75.f program bug75 character*4 temp temp=' 75' read(temp,'(f4.0)')value ivalue=ifix(value) write(*,*)' value=',value,', ivalue=',ivalue end taurus.brl.mil> f77 bug75.f # not using the floating point board taurus.brl.mil> a.out # answer is correct value=+7.500000E+01, ivalue=75 taurus.brl.mil> f77 -Zf bug75.f # using the floating point board taurus.brl.mil> a.out # answer is wrong value=+7.499999E+01, ivalue=74 taurus.brl.mil> f77 -Zf -ZF+F bug75.f # using fp board and accurate divide taurus.brl.mil> a.out # answer is still wrong value=+7.499999E+01, ivalue=74 taurus.brl.mil> script done on Fri Feb 26 08:38:57 1988 Please don't send flames about the program. I know and you know that ivalue=nint(value) or ivalue=ifix(value+.5) will work properly in all cases. But sometime you might inherit a program containing coding as above, as I did, and be baffled for a while. The example above was run on an IRIS 2500 Turbo, with Rev C FP1 board, running release GL2-W3.5rl. I got the same results on a 3130 and a 3030.. Glenn Randers-Pehrson ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01899; 26 Feb 88 14:55 EST Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id ab14282; 26 Feb 88 11:36 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa14271; 26 Feb 88 11:33 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa04050; 26 Feb 88 11:27 EST Received: Fri, 26 Feb 88 11:26:36 EST by aero4.larc.nasa.gov (5.15/5.6) Date: Fri, 26 Feb 88 11:26:36 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8802261626.AA03615@aero4.larc.nasa.gov> To: glennrp@BRL.ARPA Subject: Re: IRIS floating point read error Cc: info-iris@BRL.ARPA You shouldn't have to add the .5 to your sample case, it should work as is. I have had similar problems with programs. A set of subroutines work fine everyplace, but on our IRIS. I avoid doing ANY calculations on our IRIS that require any accuracy. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05752; 26 Feb 88 19:44 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa05038; 26 Feb 88 17:49 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa04934; 26 Feb 88 17:34 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa09506; 26 Feb 88 17:12 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Fri, 26 Feb 88 14:07:40 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA03222; Fri, 26 Feb 88 14:00:34 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 88 14:15:46 GMT From: Rich Rosenthal Organization: USAETL, Fort Belvoir, Virginia Subject: Mail Internet Style on 4D - How To? Message-Id: <25@etl.ARPA> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU How do I change/modify/configure the software on SGI 4D so that I can receive mail over the net. Facts: 4D is on local net connected to VAX 4.3 BSD that is on ARPANET. At momment, I cannot send mail locally between 4D and VAX. Any comments would be appreciated. -- Rich Rosenthal richr@etl.arpa US Army Engineer Topographic Laboratories Fort Belvoir, Virginia 22060-5546 (202) 355-2830 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa08522; 27 Feb 88 9:31 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa08300; 27 Feb 88 8:29 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa08286; 27 Feb 88 8:22 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa23421; 27 Feb 88 8:10 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sat, 27 Feb 88 05:09:00 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA20741; Sat, 27 Feb 88 04:51:44 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Feb 88 22:50:39 GMT From: Lief Sorensen Organization: Hewlett-Packard - Fort Collins, CO Subject: IRIS 3010/3110 cost Message-Id: <13570001@hpfclm.HP.COM> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Help! I need to know the current cost of IRIS 3010s and 3110s in their standard configuration. The DATAQUEST information I have is 1 year old and also in error. For some reason, SGI does not like to give us this information directly. So if you have purchased one lately, could you please give me a call. Lief Sorensen Hewlett Packard Co. Fort Collins, COLO. (303) 229-4116 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01388; 1 Mar 88 6:42 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa23570; 29 Feb 88 15:07 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa23521; 29 Feb 88 14:56 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa16795; 29 Feb 88 14:45 EST Received: Mon, 29 Feb 88 13:44:19 EST by aero4.larc.nasa.gov (5.15/5.6) Date: Mon, 29 Feb 88 13:44:19 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8802291844.AA14566@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: Tek 4x14 emulation In reference to mccalpin@masig1.ocean.fsu.EDU request for information. Have you gotten any replies? If so I am also interested in it. I have been asked that question before. If I have the time I may try to write one, hopefully someone else has already done it. So does anyone have one? (I tried to mail to mccalpin directly, however my mail was returned.) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa02970; 1 Mar 88 8:15 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab01388; 1 Mar 88 6:47 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00812; 1 Mar 88 5:05 EST Received: from [128.228.1.2] by SMOKE.BRL.ARPA id aa29421; 1 Mar 88 4:44 EST Received: from DKAUNI11.BITNET by CUNYVM.CUNY.EDU ; Mon, 29 Feb 88 10:17:05 EST Received: from DKAUNI46.BITNET (CD05) by DKAUNI11.BITNET (Mailer X1.25) with BSMTP id 2522; Mon, 29 Feb 88 15:51:48 MEZ Date: 02/29/88 15:53:24 CET From: CD05%DKAUNI46.BITNET@CUNYVM.CUNY.EDU To: INFO-IRIS@BRL.ARPA Message-ID: <8803010444.aa29421@SMOKE.BRL.ARPA> concerning the dials and button box and problems of Dan Dolata. we've got dials and buttons recently for our IRIS-4D/60T. The same problem Dan had, occured to me. On the 4D there is a way to restart the box without rebooting: 1. change diald-entry in /etc/inittab form diald:234:..... to diald:234a:...... (234 are our run-levels, may be other on yours) a is a very special run-level 2. if your box was turned off, turn it on, kill the running diald- process and type telinit a That restarts only the processes marked with a, but does not change the actual run level and therefore does not interfer with running processes. I don't know who to do that on an IRIS-3D, but I think there must be a similar way. Stefan Brode ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04429; 3 Mar 88 9:13 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa02561; 3 Mar 88 6:55 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa02549; 3 Mar 88 6:44 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa21662; 3 Mar 88 6:35 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 3 Mar 88 03:33:55 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA00742; Thu, 3 Mar 88 02:58:46 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Mar 88 17:12:42 GMT From: Jim Barton Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: Parallel Processing Graphics Engine Message-Id: <11994@sgi.SGI.COM> References: <2067@ncr-sd.SanDiego.NCR.COM> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <2067@ncr-sd.SanDiego.NCR.COM>, dennisr@ncr-sd.SanDiego.NCR.COM (Dennis Russell) writes: > I would like to receive information on the multiple MIPS based > parallel-processing graphics engine from Silicon Graphics that was > presented in a paper delivered at Uniforum a few weeks ago. A copy of the > paper would also be appreciated. > > > -- > Dennis Russell | NCR Corp., M/S 4720 > phone: 619-485-3214 | 16550 W. Bernardo Dr. > UUCP: ...{ihnp4|pyramid}!ncr-sd!dennisr | San Diego, CA 92128 Several presentations have been made on various things by SGI personnel recently, though none of them have been about this. At USENIX (NOT, mind you, the same as Uniforum), we presented two papers: "Beyond Threads: Resource Sharing in UNIX" (Barton and Wagner), which discussed our modifications to 5.3.1 for advanced support of "threads" "Translation Lookaside Buffer Management in a Multiprocessor System", (Thompson, Barton, Wagner, Jermoluk), discussing just what it says. Also on the systems side, Forrest Baskett presented a paper at CompCon last week on some of our work (sorry, don't know the title offhand). The pipelined graphics architecture used in our newest models (4D70GT) is described in the technical brief on the product, and was also described in a paper presented recently by Kurt Akely. If you can't find a copy of the USENIX proceedings, I'd be happy to send you electronic versions of the USENIX papers (you'll need nroff, the ms macros, and 'pic'). For information on the 4D70GT, contact our marketing and sales organization. The above papers obviously refer to multiprocessor systems, but no product has yet been announced. You'll just have to wait and see how well we've done - I think you may be pleasantly surprised... -- Jim Barton From the UNIX asylum at SiliconGraphics, Inc. jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00076; 3 Mar 88 16:30 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa04041; 3 Mar 88 8:52 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa03830; 3 Mar 88 8:45 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa23915; 3 Mar 88 8:28 EST Received: from masig1.ocean.fsu.edu by SUMEX-AIM.Stanford.EDU with TCP; Thu, 3 Mar 88 05:26:48 PST Received: by masig1.ocean.fsu.edu (5.15/25-eef) id AA05287; Thu, 3 Mar 88 08:24:44 EST Date: Thu, 3 Mar 88 08:24:44 EST From: "John D. McCalpin" Message-Id: <8803031324.AA05287@masig1.ocean.fsu.edu> To: info-iris@sumex-aim.stanford.EDU Subject: (1) C++ ? (2) Array processors Cc: mccalpin@masig1.ocean.fsu.EDU (1) Has anyone ported C++ to the IRIS 3000 series ? If so, who ? (2) Has anyone integrated any of the new vector-pipelined floating-point boards into an IRIS 3000 ? I am thinking of the products of SKY, which produces a 10-MFLOP board based on the Weitek chips; and more recently, Weitek has announced a set of boards in the 20-25 MFLOP range. Thanks for any replies.... john d mccalpin mccalpin@masig1.ocean.fsu.edu (128.186.3.1) mcalpin@fsu.BITNET mccalpin@fsu.MFENET ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa07050; 4 Mar 88 13:21 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa03695; 4 Mar 88 10:55 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa03563; 4 Mar 88 10:38 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa13004; 4 Mar 88 10:29 EST Received: from NMFECC.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Fri, 4 Mar 88 07:28:03 PST Received: from fsu.mfenet by ccc.mfenet with Tell via MfeNet ; Fri, 4 Mar 88 07:26:39 PST Date: Fri, 4 Mar 88 07:26:39 PST From: PEPKE%FSU.MFENET@NMFECC.arpa Message-Id: <880304072639.2100021c@NMFECC.ARPA> Subject: RE: Color IRIS Printers To: INFO-IRIS@SUMEX-AIM.STANFORD.EDU Comment: From PEPKE@FSU.MFENET on 4-MAR-1988 10:30:30.52 EST My recent request for personal experience with color printers for the IRIS elicited 5 responses. A summary follows, but first, some disclaimers: This was not a scientifically performed survey. Five responses is not large enough to draw statistical conclusions. All the information herein is second hand or worse. I have no connection with anyone except as a customer or potential customer. Mongo only little cog in big machine of Institute. We don't really know what reality is exists except through our senses. Blah blah blah. There were three recommendations of the Seiko printer, which boiled down to it works well, it does reasonable shading, and it is easy to install, as it connects to the RGB output of the IRIS. There was one recommendation for a printer manufactured by Shinko and distributed by Mitsubishi, which I guess was either the CHC-635 or the CHC-335. Mitsubishi also distributes a box which allows the printer to connect to the RGB output. Their printer seems to do good shading as well. As far as I can tell, both printers would be good choices. 16 of one, 10 hex of another. There were two caveats about the Tektronix ink jet printer. One told of a demo unit that never worked properly in spite of claims from Tektronix and Silicon Graphics that their individual pieces worked perfectly. The other told of a Textronix printer that another department obtained that was cumbersome to use and install. The Tektronix printer, apparently, requires a board to be installed in the IRIS. Maybe the problems have been fixed. Maybe Tektronix has come out with a wonderful new printer that works perfectly. Maybe a Democrat will be elected President. I don't know. You get to determine what you believe. There was one recommendation of the Dunn Instruments camera, which is somewhat beyond the scope of this discussion. Hope this helps anybody in a similar bind... Eric Pepke pepke%fsu.mfenet@nmfecc.arpa Supercomputer Computations pepke%scri.hepnet@lbl-csa2.arpa Research Institute pepke%fsu.bitnet@wiscvm.wisc.edu Florida State University "The black paper between a mirror Tallahassee, FL 32306-4052 breaks my heart that I can't go." Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17026; 5 Mar 88 23:46 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa16806; 5 Mar 88 22:13 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab16784; 5 Mar 88 22:00 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa24348; 5 Mar 88 21:52 EST Received: from uunet.UU.NET by SUMEX-AIM.Stanford.EDU with TCP; Sat, 5 Mar 88 18:36:18 PST Received: from munnari.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA04698; Sat, 5 Mar 88 21:37:14 EST Message-Id: <8803060237.AA04698@uunet.UU.NET> Received: from cidam (via goanna) by munnari.oz with SunIII (5.5) id AA01583; Sun, 6 Mar 88 12:45:06 EST Received: by cidam.rmit.oz (4.3b/4.7) id AA00632; Sat, 5 Mar 88 21:27:31 EDT Date: Sat, 5 Mar 88 21:27:31 EDT From: "Mike A. Gigante" To: info-iris@sumex-aim.stanford.EDU Subject: X windows on 3130 has anyone done a reasonable server for X11R1 on the 3130? If so, I'd like to hear from you. Does anyone know when SGI will be releasing the combined windowing environmennt on the 3000 class machines? thanks, Mike ------- Mike Gigante, Applied Computer Graphics Lab, RMIT, Australia mg%cidam.oz.au@uunet.uu.net ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17317; 6 Mar 88 1:22 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab17026; 5 Mar 88 23:48 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa17003; 5 Mar 88 23:38 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa24801; 5 Mar 88 23:33 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sat, 5 Mar 88 20:28:33 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA21371; Sat, 5 Mar 88 20:10:57 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Mar 88 23:36:25 GMT From: Stuart Cracraft Organization: USC-Information Sciences Institute Subject: GNU Emacs on Silicon Graphics IRIS Message-Id: <4954@venera.isi.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Here is the stack trace of GNU Emacs which intends to run on an IRIS 3130. Header files used were: s-iris3-5.h and m-irist.h as defined in config.h. Stuart # adb ./xemacs a.out file = ./xemacs core file = core ready $c _sighnd+0x9C: (a0@) (0xB) .L715+0x1A: (a0@) (0x305662C, 0x4056698, 0x5) .L611+0x3E: _Feval (0x5056624) .L484+0x24: _Fcondition_case(0x50844B8) .L715+0x1A: (a0@) (0x305650C, 0x4056790, 0x13) .L450+0xE: _Feval (0x5056504) .L20111+0x2E: _Fprogn (0x5056838) .L796+0x3C: _funcall_lambda (0x5056840, 0x0, 0x1FFFDBBC) .L440+0x22: _Ffuncall (0x1, 0x1FFFDBB8) .L715+0x1A: (a0@) (0x3056410, 0x40564B4, 0x3) .L450+0xE: _Feval (0x5056408) .L20111+0x2E: _Fprogn (0x50564EC) .L809+0x1A: _funcall_lambda (0x50564F4, 0x0, 0x1FFFDD1C) .L723+0x18: _apply_lambda (0x50564F4, 0x1074808, 0x1) _top_level_2+0xA: _Feval (0x507CBA8) .L615+0x3E: (a0@) () _top_level_1+0x24: _internal_condition_case(0xD05E, 0x10748F8, 0xCD62) _internal_catch+0x6C: (a0@) (0x1074808) .L560+0x12: _internal_catch (0x10748E4, 0xD074, 0x1074808) .L10003+0x10: _command_loop () ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa04267; 7 Mar 88 13:23 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa27930; 7 Mar 88 11:29 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa27725; 7 Mar 88 11:16 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa16929; 7 Mar 88 10:41 EST Received: from masig1.ocean.fsu.edu by SUMEX-AIM.Stanford.EDU with TCP; Mon, 7 Mar 88 07:39:43 PST Received: by masig1.ocean.fsu.edu (5.15/25-eef) id AA14084; Mon, 7 Mar 88 10:38:44 EST Date: Mon, 7 Mar 88 10:38:44 EST From: "John D. McCalpin" Message-Id: <8803071538.AA14084@masig1.ocean.fsu.edu> To: info-iris@sumex-aim.stanford.EDU Subject: f77 on iris 3000's Cc: mccalpin@masig1.ocean.fsu.EDU Has anyone produced a real fortran compiler for the IRIS 3000 series ??? I am getting tired of the multitudinous bugs in the SVS compiler, the almost total lack of SGI support for the compiler, and the pathetic optimization that it performs.... Has Silicon Valley Software produced any revisions of f77 since version 2.4, dated 30-Oct-85 ??? john d. mccalpin mccalpin@masig1.ocean.fsu.edu (128.186.3.1) mcalpin@fsu.BITNET mccalpin@fsu.MFENET ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa24649; 8 Mar 88 19:21 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa23695; 8 Mar 88 16:45 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa23500; 8 Mar 88 16:31 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa06376; 8 Mar 88 16:20 EST Received: from masig1.ocean.fsu.edu by SUMEX-AIM.Stanford.EDU with TCP; Tue, 8 Mar 88 11:00:21 PST Received: by masig1.ocean.fsu.edu (5.15/25-eef) id AA00459; Tue, 8 Mar 88 13:59:21 EST Date: Tue, 8 Mar 88 13:59:21 EST From: "John D. McCalpin" Message-Id: <8803081859.AA00459@masig1.ocean.fsu.edu> To: info-iris@sumex-aim.stanford.EDU Subject: GNU Emacs Does anyone have the `m-' and `s-' header files for gnu-emacs for an IRIS 3000 series machine ??? john d. mccalpin mcalpin@fsu.BITNET mccalpin@masig1.ocean.fsu.edu (128.186.3.1) mccalpin@fsu.MFENET ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa08517; 10 Mar 88 6:21 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa07422; 9 Mar 88 23:45 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab07387; 9 Mar 88 23:31 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa12505; 9 Mar 88 23:26 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 9 Mar 88 20:25:28 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA25673; Wed, 9 Mar 88 11:32:20 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Mar 88 20:12:54 GMT From: Jim Barton Organization: Silicon Graphics Inc, Mountain View, CA Subject: USENIX Paper on SGI's Threads Message-Id: <12192@sgi.SGI.COM> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU As I have had quite a few request for these papers, I'll post them here for all to see. This paper concerns our work extending the UNIX process model to accomodate parallel programming. -- Jim Barton From the UNIX asylum at SiliconGraphics, Inc. jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb ---------- cut here ---------------- .\" .\" Converted to the 'ms' macros (blehhhh...). .\" Run it through 'pic' first ... .\" .TL Beyond Threads: Resource Sharing in UNIX .AU J. M. Barton J. C. Wagner .AI Silicon Graphics, Incorporated 2011 Stirlin Road Mountain View, California 94039 jmb@sgi.com, jwag@sgi.com .AB UNIX provides a programming model for the user which gives an illusion of multiprocessing. On uniprocessors, this illusion works well, providing communication paths, firewalls between processes and a simple programming environment. Unfortunately, the normal UNIX model does not provide the capabilities to take full advantage of modern multiprocessor hardware. This results from a design which uses data queueing and preemption to provide the multiprocessing illusion, which are unnecessary on a true multiprocessor. .LP The recent proposed addition of .I threads to CMU's MACH kernel shows that there are other effective programming models that may be supported in UNIX as well. This model provides for sharing the virtual address space of a process by breaking the process into several lightweight contexts that may be manipulated more quickly than a normal process. Unfortunately, this model raises questions about support for normal UNIX semantics, as well as thread scheduling performance and kernel overhead. .LP This paper describes a programming model which goes beyond the simple concept of threads, providing a much broader range of resource sharing while retaining the key parts of the UNIX process model. Instead of .I threads, the concept of a process is retained along with most of it's semantics. As usual, the fundamental resource shared is the virtual address space. In addition, open file descriptors, user and group ID's, the current directory, and certain other elements of the process environment may be shared also. This makes for easy construction of useful servers and simple concurrent applications, while still providing high-performance support for more computationally intensive applications. .LP This implementation, labelled .I process share groups, .R allows normal process actions to take place easily, such as system calls, page faulting, signalling, pausing, and other actions which are ill-defined within the .I threads model. The paper describes the philosophy which drove the design, as well as details of the implementation, which is based on, and upwardly compatible with, AT&T 5.3 UNIX. Performance of normal UNIX processes is maintained while providing high-performance share group support. .AE .NH 1 Introduction .LP The success of the UNIX\** kernel is owed in part to the .FS Standard Declaration: "UNIX is a trademark of AT&T Bell Laboratories". .FE effective way in which it hides the resource sharing necessary in a multiprogrammed environment. A UNIX process is a highly independent entity, having it's own address space and environment. Communication paths are restricted to low-bandwidth mechanisms, such as pipes, sockets and messages. .LP When moved to a multiprocessor, this model is overly restrictive. We would like to allow several processors to work on a problem in parallel using high-bandwidth communications (shared memory, for instance). Even though this explicit sharing of data is thought of most often when working with parallel programing, there are other resources that can be shared usefully. For instance, the file descriptors associated with a process could be shared among several processes. .LP In order to provide a conceptual framework for resource sharing among concurrent processes, we have introduced an additional level of functionality into the normal UNIX process model. A process may gain access to this additional level of functionality through an interface called .I process share groups. .R Members of a .I share group .R can potentially share many resources previously thought of as private to a single process. .LP This interface is first demonstrated in an AT&T System V.3 kernel, and relies on modified region handling abilities to share a virtual address space. New file opens can be propagated to all processes, as well as modifications to the environment of a process (such as the .I ulimit(2) values). By extending the semantics of the UNIX process in an upwardly compatible way, a powerful new programming model has been developed. .NH 2 The Road to Resource Sharing .LP In order to provide a simple model for multi-programming, the designers of UNIX chose a model of independent processes, shared access to a file-system, and limited communications using low-bandwidth paths, such as signals or pipes (Figure 1). Such a decision was appropriate, since the inherent queueing of data implied at many levels of the UNIX interface simplifies multi-programming support. .KS .DS B .PS # # Some globals # addrht = 1.5 addrwid = .75 elht = addrht / 8 ellipsewid = addrwid * (2/3) ellipseht = (addrht/4) * (2/3) # # Address space # A1: box wid addrwid ht addrht box wid addrwid ht elht with .nw at A1.nw "\s-2stack\s0" B1: box wid addrwid ht elht with .sw at A1.sw "\s-2text\s0" box wid addrwid ht elht with .sw at B1.nw "\s-2data/bss\s0" # # Environment # B2: box wid addrwid * 2 ht elht with .c at B1.s - (0.0, 0.25) " File I/O" at B2.e ljust move to B2.sw + (addrwid/2, -0.25) L1: line -> up .25 "pipes" at L1.start below move to B2.se - (addrwid/2, 0.25) L2: line -> up .25 "files" at L2.start below move to A1.w - (0.35, 0.0) L3: line -> right .25 "signals " at L3.start above rjust # # State # move to A1.e + (0.1, 0.0) E1: ellipse with .w "\s-2state\s0" line -> left .25 from E1.w .PE .DE .DS C \fBFigure 1.\fP Version 7 Process Environment .DE .KE To meet the growing need for high-performance and concurrent programming support, some new mechanisms were introduced. Berkeley UNIX introduced the .I socket interface, while System V introduced a local inter-process communication interface providing shared memory support (Figure 2). No new interfaces for managing files were proposed, nor were changes to improve concurrent programming abilities put forward. .KS .DS B .PS # # Draw the address space again. # A1: box wid addrwid ht addrht box wid addrwid ht elht with .nw at A1.nw "\s-2stack\s0" B1: box wid addrwid ht elht with .sw at A1.sw "\s-2text\s0" B2: box wid addrwid ht elht with .sw at B1.nw "\s-2data/bss\s0" B3: box wid addrwid ht elht with .sw at B2.nw + (0.0, 0.4) \ "\s-2shared memory\s0" # # Draw the environment again. # B4: box wid addrwid * 2 ht elht with .c at B1.s - (0.0, 0.25) " File I/O" at B4.e ljust move to B4.sw + (addrwid/2, -0.25) L1: line -> up .25 "pipes" at L1.start below move to B4.se - (addrwid/2, 0.25) L2: line -> up .25 "files" at L2.start below move to A1.w - (0.35, 0.0) L3: line -> right .25 "signals " at L3.start rjust move to A1.w - (0.35, -0.2) L4: line -> right .25 "messages " at L4.start rjust move to A1.w - (0.35, 0.2) L5: line -> right .25 "semaphores " at L5.start rjust # # Some state # move to A1.e + (0.1, 0.0) E1: ellipse with .w "\s-2state\s0" line -> left .25 from E1.w # # Add the legend # "\fBSystem V Environment\fP" at A1.n + (0.0, 0.1) # # Now draw the BSD layout. # right move to A1.e + (2.5, 0.0) A2: box wid addrwid ht addrht box wid addrwid ht elht with .nw at A2.nw "\s-2stack\s0" BB1: box wid addrwid ht elht with .sw at A2.sw "\s-2text\s0" box wid addrwid ht elht with .sw at BB1.nw "\s-2data/bss\s0" # # Draw it's environment # BB2: box wid addrwid * 2 ht elht with .c at BB1.s - (0.0, 0.25) " File I/O" at BB2.e ljust move to BB2.sw + (addrwid/4, -0.25) LL1: line -> up .25 "pipes" at LL1.start below move to BB2.se - (addrwid/4, 0.25) LL2: line -> up .25 "files" at LL2.start below move to BB2.s + (0.0, -0.25) LL4: line -> up .25 "sockets" at LL4.start below move to A2.w - (0.35, 0.0) LL3: line -> right .25 "signals " at LL3.start rjust # # Some state # move to A2.e + (0.1, 0.0) E2: ellipse with .w "\s-2state\s0" line -> left .25 from E2.w # # Add the legend # "\fBBSD 4.2 Environment\fP" at A2.n + (0.0, 0.1) .PE .DE .DS C \fBFigure 2.\fP System V and BSD Process Environments .DE .KE Most recently, the Mach[Acce86] kernel introduced an implementation of tasking labeled \fIthreads\fP[Teva87]. This model allows an address space to be shared among several processes. Each process can execute independently in both kernel and user mode. Although independent execution adds additional cost for a threaded process, such as kernel context (the user area) and a kernel stack for each thread, a useful concurrent programming environment is provided (Figure 3). .KS .DS B .PS # # Now draw the Mach layout. # right A2: box wid addrwid ht addrht BB0: box wid addrwid ht elht with .nw at A2.nw "\s-2stack\s0" BB1: box wid addrwid ht elht with .sw at A2.sw "\s-2text\s0" BB9: box wid addrwid ht elht with .sw at BB1.nw "\s-2data/bss\s0" B3: box wid addrwid ht elht with .sw at BB9.nw + (0.0, 0.2) \ "\s-2shared memory\s0" box wid addrwid ht elht with .nw at BB0.sw - (0.0, 0.2) \ "\s-2mapped file\s0" # # Draw it's environment # BB2: box wid addrwid * 2 ht elht with .c at BB1.s - (0.0, 0.25) " File I/O" at BB2.e ljust "\s-2BSD 4.3 kernel\s0" at BB2.c move to BB2.sw + (addrwid/4, -0.25) LL1: line -> up .25 "pipes" at LL1.start below move to BB2.se - (addrwid/4, 0.25) LL2: line -> up .25 "files" at LL2.start below move to BB2.s + (0.0, -0.25) LL4: line -> up .25 "sockets" at LL4.start below move to A2.w - (0.35, 0.1) LL3: line -> right .25 "signals " at LL3.start rjust move to A2.w - (0.35, -0.1) LL5: line -> right .25 "messages " at LL5.start rjust # # Draw the Mach performance killer. # mht = (addrht * 0.75) move to A2.e + (0.15, 0.0) BB4: box wid elht ht mht with .w "\s-2Mach kernel\s0" at BB4.n above # # Some state # eoff = 0.1 move to BB4.e + (eoff, 0.0) move by (0.0, mht/4) E1: ellipse with .w "\s-2state 0\s0" line -> left .25 from E1.w right move to BB4.e + (eoff, 0.0) E2: ellipse with .w "\s-2state 1\s0" line -> left .25 from E2.w right move to BB4.e + (eoff, 0.0) move by (0.0, -mht/4) E3: ellipse with .w "\s-2state 2\s0" line -> left .25 from E3.w # # The message line # line <-> down .35 from BB4.s "\s-2 messages\s0" ljust .PE .DE .DS C \fBFigure 3.\fP Mach Process Environment .DE .KE .LP As part of the research for share groups, a true threaded process implementation on System V.3 was constructed[Wagn87]. This implementation of threaded execution went beyond that used in the Mach kernel. A thread was realized as an actual entity within a process, and truly manifested itself only as the minimum machine context which could be scheduled. This version of threads provided a good environment for numerical or other computationaly intensive algorithms, but it suffered from limited applications. Finally realizing the limitations of this approach, we looked for a more powerful model. .NH 1 Parallel Programming .LP To take maximum advantage of multi-processors, it must be possible to create and execute parallel algorithms, and to get truly parallel execution of application code. Because of the data-sharing bandwidth necessary for applications to gain performance from parallelism, shared memory is usually the main data path. Sharing memory isn't enough, however. The sharing mechanism and other aspects of the environment must all work together to provide a useful programming model[Bart87]. .LP Shared memory is not useful without a mechanism for synchronizing access to it. For instance, pipes, System V messages or semaphores, sockets or signals can be used to synchronize memory access between processes, but are all much lower bandwidth mechanisms than the memory itself, which can be a liability. With hardware supported locking, synchronization speeds can approach memory access speeds. .LP Two equally important aspects of the environment are scheduling and context switching. Even if a multi-process application limits itself to the number of processors available, the best performance will occur only if all the processes are actually running in parallel. The kernel needs to take steps to insure that these processes run in parallel whenever possible. Since this isn't always possible in UNIX, fast context switching is also important. For high-performance semaphores, it is necessary that blocking or unblocking a process be extremely quick. Fast context switching is one element of this; the kernel must provide facilities for the actual blocking operations to be executed quickly as well. .LP Dynamic creation and destruction of processes must be possible, and getting an existing process started on a new task must have little overhead. In a threaded model, creation of a new thread is often an order of magnitude faster than creation of a process, however this seems unimportant. If a process model is used instead (such as Sequent's[Beck87]), then the speed penalties of process creation are eliminated by creating a pool of processes before entering parallel sections of code, each of which then waits to be dispatched quickly as needed. If enough processes are not available, a new one can be dynamically created, but this problem can be tuned out of the application. .LP If we add to this model by introducing sharing of other process resources, we approach a useful superset of normal UNIX process semantics. Signals, system calls, traps and other process events happen in an expected way, since they deal with actual processes. By sharing other resources, such as file descriptors, user ID's, and the like, we can develop a powerful model that gives the performance of threads with greater functionality (Figure 4). .KS .DS B .PS addrht = 2.0 addrwid = .75 ellipsewid = addrwid * (2/3) ellipseht = (addrht/4) * (2/3) elht = addrht / 16 # # Draw the address space one more time # A1: box wid addrwid ht addrht C1: box wid addrwid ht elht with .nw at A1.nw "\s-2stack\s0" C2: box wid addrwid ht elht with .nw at C1.sw - (0.0, elht/2) "\s-2stack\s0" box wid addrwid ht elht with .nw at C2.sw - (0.0, elht/2) "\s-2stack\s0" B1: box wid addrwid ht elht with .sw at A1.sw "\s-2text\s0" C3: box wid addrwid ht elht with .sw at B1.nw + (0.0, elht/2) \ "\s-2shared lib text\s0" C4: box wid addrwid ht elht with .sw at C3.nw + (0.0, elht/2) \ "\s-2shared lib data\s0" C5: box wid addrwid ht elht with .sw at C4.nw "\s-2data/bss\s0" C6: box wid addrwid ht elht with .sw at C5.nw + (0.0, elht) \ "\s-2mapped file\s0" C7: box wid addrwid ht elht with .sw at C6.nw + (0.0, elht) \ "\s-2shared memory\s0" # # Draw the environment again. # B4: box wid addrwid * 2 ht elht with .c at B1.s - (0.0, 0.25) " File I/O" at B4.e ljust move to B4.sw + (addrwid/4, -0.25) L1: line -> up .25 "pipes" at L1.start below move to B4.se - (addrwid/4, 0.25) L2: line -> up .25 "files" at L2.start below move to B4.s + (0.0, -0.25) LL4: line -> up .25 "sockets" at LL4.start below move to A1.w - (0.35, 0.0) L3: line -> right .25 "signals " at L3.start rjust move to A1.w - (0.35, -0.2) L4: line -> right .25 "messages " at L4.start rjust move to A1.w - (0.35, 0.2) L5: line -> right .25 "semaphores " at L5.start rjust # # Draw some processes using the address space # eoff = 0.1 move to A1.e + (eoff, 0.0) move by (0.0, addrht/4) E1: ellipse with .w "\s-2state 0\s0" line -> left .25 from E1.w right move to A1.e + (eoff, 0.0) E2: ellipse with .w "\s-2state 1\s0" line -> left .25 from E2.w right move to A1.e + (eoff, 0.0) move by (0.0, -addrht/4) E3: ellipse with .w "\s-2state 2\s0" line -> left .25 from E3.w .PE .DE .DS C \fBFigure 4.\fP New SGI 4D Series Environment .DE .KE .NH 1 Share Groups .LP To address the failures and limitations of resource sharing when applied to multiprocessors, we developed the concept of the .I share group. .R Such a group is a collection of processes which share a common ancestor and have not executed the .I exec(2) system call since being created. The parent-child relationship between processes is maintained, and forms the basis for a hierarchial resource sharing facility, where a parent can indicate what shared resources each child should share. .LP In general, the main resource shared is the virtual address space associated with the share group, although it need not be. Processes in the share group are free to pass pointers to data, and to use high-performance synchronization and data passing techniques (mainly shared memory and spinlocks). .LP A small number of other resources may be shared in the initial implementation. Chief among these are file descriptors. When one of the processes in a group opens a file, the others will see the file as immediately available to them. The descriptor number\** may be passed between processes or simply assumed as part of the algorithm. .FS The descriptor number is an index into the file table for a process, which holds pointers to open file table entries. For example, .I standard input .R is by convention descriptor number 0, while .I standard output .R indicates descriptor number 1. .FE Other resources that may be shared are the .I ulimit values, the .I umask value, the current directory and the root directory .NH 1 System Call Interface .LP The share group interface is defined through two new system calls, .I sproc() and .I prctl(). The .I sproc() call is used to create a new process within the share group, and controls the resources which will be shared with the new process. The .I prctl() call is used to obtain information about the share group and to control certain features of the group and new processes. .NH 2 The \fIsproc\fP System Call .LP The syntax of this call is: .DS \fC int sproc(entry, shmask, arg) void (*entry)(); unsigned long shmask; long arg; returns - -1 - OS error in call >0 - new process ID \fP .DE This call is similar to the .I fork(2) system call, in that a new process is created. The .I shmask parameter specifies which resources the child will share with the share group, each particular resource being identified with a bit in the parameter. A new stack is automatically created for the child process, and the new process is entered at the address given by .I entry. This new stack is visible to all other processes in the share group, and will automatically grow. The single argument .I arg is passed to newly created process as the only parameter to the entry point, and can be used to pass a pointer to a data block or perhaps an index into a table. .LP The first use of the .I sproc() call creates a .I share group. .R Whenever a process in the share group issues the .I sproc () call the new process is made part of the parent's share group. A new process may be created outside the share group through the .I fork(2) system call, and use of the .I exec(2) system call also removes the process from the share group before overlaying the new process image. .LP All resource sharing is controlled through the .I shmask ( .B "share mask" ) .R parameter. Currently, the following elements can be shared: .DS \fC PR_SADDR - share virtual address space PR_SULIMIT - ulimit values PR_SUMASK - umask values PR_SDIR - current/root directory PR_FDS - open file descriptors PR_SID - uid/gid PR_SALL - all of the above and any future resources \fP .DE When the child is created, the share mask is masked against the share mask used when creating the parent. This means that a process can only cause a child to share those resources that the parent can share as well, thus forming a hierarchy. The original process in a share group is given a mask indicating that all resources are shared. .LP Whenever a process modifies one of the shared resources, and it's share mask indicates that it is sharing the resource, all other processes in the share group which are also sharing the resource will be updated. .LP When the virtual address(VM) space is shared, a process may modify the VM space and all other processes will see that same change. If new regions are added to the VM space, the kernel will check to insure that no address range overlaps any other. If the virtual address space is not shared, the new process (child) gets a .I copy-on-write image of the share group's (parent's) virtual address space. In this case, the child's stack is not visible in the parent's virtual address space. .LP Certain small parts of a process's VM space are not shared. The most critical of these is the process data area, or PRDA. This is a small amount of memory (less than a page in size) which records data which must remain private to the process, and is always at the same fixed virtual location in every process. As an example, consider the .I errno variable provided by the C library. Since the data space is shared, if this variable were only in the data space it would be difficult for independent processes to make reliable system calls. Thus, the C library locates a copy of .I errno in the PRDA for a process. The format and use of the PRDA is totally within the scope of the user program, and can be managed in any way appropriate. Libraries (such as the C library) which need some private data may use a portion of the PRDA, leaving a portion for direct use by the programmer. .NH 2 The \fIprctl\fP System Call .LP The second system call is the .I prctl() call, which allows certain aspects of a share group to be controlled. Its syntax is: .DS \fC int prctl(option [, value [, value2 ]]) unsigned option; char *value; char *value2; returns - -1 - error in OS call <>0 - request result \fP .DE The following .I option values may be used: .DS \fC PR_MAXPROCS - return limit on processes per user PR_MAXPPROCS - return number of processes that the system can run in parallel. PR_SETSTACKSIZE - sets the maximum stack size for the current process. PR_GETSTACKSIZE - retrieves the maximum stack size for the current process. \fP .DE The PR_SETSTACKSIZE option allows the program to set the maximum stack size which it may have. This value is inherited across .I sproc() and .I fork() system calls, and indirectly controls the layout of the shared VM image. .NH 1 Implementation .LP The implementation of share groups centered on four goals: .RS .IP 1. The implementation must work correctly in both multi-processor and uni-processor environments. .IP 2. Synchronization between share group processes must be able to proceed even though one member is not available for execution. .IP 3. The overall structure of the kernel must not be modified. .IP 4. The performance for non-share group processes must not be reduced. .RE .LP The multiprocessor requirement proved to be the major difficulty in the design, since there are no formal interfaces for synchronization between processes executing in the kernel. This is not usually a problem on uni-processor systems since a process executing in the kernel cannot be preempted. Thus it may examine and modify the state of any other process, and know that the state will not change (unless the executing process goes to sleep). This isn't true in a multi-processor environment. The process being examined may be running on another processor, sleeping on a semaphore waiting for a resource (it could even be waiting for a resource that the examining process controls), or it may be waiting for a slow operation (i.e. read on a pty, performing the .I wait(2) system call, etc.). .NH 2 Data Structures .LP For each share group, there is a single data structure (the shared address block) that is referenced by all members of the group: .DS \fC typedef struct shaddr_s { /* the following are all to handle pregions */ preg_t *s_region; /* processes' shared pregions */ lock_t s_acclck; /* lock on access to shared block */ sema_t s_updwait; /* wait for update lock */ short s_acccnt; /* count of readers */ ushort s_waitcnt; /* count of waiting processes */ /* generic fields for handling shared processes */ struct proc s_plink; /* link to shared processes */ ushort s_refcnt; /* # process in list */ ushort s_flag; /* flags */ lock_t s_listlock; /* protects s_plink */ /* semaphore for single threading open file updating */ sema_t s_fupdsema; /* wait for opening file */ struct file **s_ofile; /* copy of open file descriptors */ char *s_pofile; /* copy of open file flags */ struct inode *s_cdir; /* current directory */ struct inode *s_rdir; /* root directory */ /* lock for updating misc things that don't need a semaphore */ lock_t s_rupdlock; /* update lock */ /* hold values for other sharing options */ short s_cmask; /* mask for file creation */ daddr_t s_limit; /* maximum write address */ ushort s_uid; /* effective user id */ ushort s_gid; /* effective group id */ } shaddr_t; \fP .DE 1 This structure is dynamically allocated the first time that a process invokes the .I sproc(2) system call. A pointer in the .I proc structure points to this, and the .I s_plink field links all processes via a link field in the .I proc structure. To protect the linked list during searching, the lock .I s_listlock is used. A reference count is kept in .I s_refcnt, and the structure is thrown away once the last member exits (Figure 5). The rest of the fields are used to implement the resource sharing between group members and are explained in the following sections. .KS .DS B .PS linewid = .25 lineht = .25 # # Draw a process slot box # define procent X box ht .55 wid .4 "\s-2proc\s0" $1 X # # Draw a pregion box # define pregion X box ht .25 wid .5 "\s-2pregion\s0" X define pregionmove X box ht .25 wid .5 invisible X # # Build three example entries # right move by (.75, 0.0) move by (linewid, 0.0) R1: pregion() line <- from R1.e P1: procent("\s-20\s0") line down -> from P1.s P2: procent("\s-21\s0") line down -> P3: procent("\s-22\s0") left L1: line -> from P3.w B0: box ht .25 wid .5 with .e at L1.end "\s-2pregion\s0" L2: line -> from B0.w box ht .25 wid .5 with .e at L2.end "\s-2pregion\s0" right # # Draw share block # move to P2.e B1: line -> right .5 B2: box ht .75 wid .5 with .sw at B1.end "\s-2File\s0" "\s-2Sync\s0" B3: box ht .375 wid .5 with .nw at B2.sw "\s-2Other\s0" B4: box ht .375 wid .5 with .nw at B3.sw "\s-2Address\s0" \ "\s-2Space\s0" # # Connect up the lines # line <-> from P1.e to B2.w line -> from P3.e to B4.nw # # Add the global pregions # line -> down from B4.s down R3: pregion() right line -> from R3.e R2: pregion() line ->; pregion() # # Add additional Legends # move to B2.n "Share Block" above move to R1.nw + (0.0, 0.05) "Private Pregions" above move to R2.n + (0.1, 0.05) "Shared Pregions" above .PE .DE .DS C \fBFigure 5.\fP Share Block Data Structure .DE .KE .NH 2 Virtual Space Sharing .LP The kernel in which this was implemented is based on System V.3, and therefore uses the \fBregion\fP[Bach86] model of virtual memory. This model consists of 2 main data structures - .I regions, which describe contiguous virtual spaces (and contain all the page table information etc.) and .I pregions, which are linked per-process and describe the virtual address at which a region is attached to the process, and certain other per-process information about the region of memory. This model is designed to allow for full orthogonality between regions that grow (up or down), and those that can be shared. .LP The most interesting (and difficult) part of resource sharing to implement is sharing of the VM image, although the job is simplified by using .I regions as the basis for managing the VM. The .I sproc system call shares code with the standard .I fork call, the only difference being the handling of regions. If address space sharing is not indicated when the .I sproc() call is made, than the standard .I fork() operations are performed, generating an image that provides .I copy-on-write access to the VM image. If sharing of the VM image is specified, the private regions of the parent process are marked as .I copy-on-write in the child, while all other regions are shared. A point to remember is that a .I fork() or non-VM sharing .I sproc() call leaves any visible stack or other regions from the share group as .I copy-on-write elements of the new process. .LP Algorithmically, the private regions for a process are examined when demand paging or loading a new process before examining the shared regions. This provides the .I copy-on-write abilities of a non-VM sharing share group member. It also provides a basis for future enhancements to the manner in which the VM is shared. For instance, it could be possible to share part of the VM image and have .I copy-on-write access to other parts of the image. .LP .I Sproc() allocates a new stack segment in a non-overlapping region of the parent's virtual address space. The new process starts on this stack and therefore does not inherit the stack context of the parent (though the child can reference the parent's stack). The child process starts executing at the address given in the .I sproc() call. .LP Unfortunately, the stock (V.3) region implementation does not support growing or shrinking shared regions (e.g., the data and BSS portion of a process). The main problem is that although regions have a well defined locking protocol, a basic assumption is made that only the process owning a private region (one that has only a single reference) will ever change it. Using this assumption, various parts of the kernel hold implicit pointers into the region (i.e. pointers to pages) even though they no longer hold a lock on the region. If a process comes in and shrinks such a region, then any implicit pointers are left dangling. .\" Lack of adequate region locking also comes into play when scanning a pregion list attempting to match a virtual address reference with a region of actual memory (during a page fault, for example). This list is not usually protected via a lock since only the calling process can change it. With growable sharable regions, information that is used during the scan could change. The former problem is inherent in uni-processor as well as multi-processor systems, and the later is only a problem for multi-processor systems. .LP The obvious soution to this is to use a lock on the pregion list. Since all share group processes must obtain this lock each time they page fault, the lock was made a shared read lock - any number of processes can scan the list, but if a process needs to update or change the list or what it points to, it must wait until all others are done scanning. Unfortunately, to guard against the 'implicit' references mentioned above, the lock could not be hidden in the existing region lock routines, but had to be placed around the entire sections of code that reference the virtual address. .LP The shared read lock consists of a spin lock .I s_acclck which guards the counters: .I s_acccnt and .I s_waitcnt. .I s_acccnt is the number of processes reading the list (or -1 if someone is updating the list); .I s_waitcnt counts the number of processes waiting for the shared lock. .I s_updwait is a semaphore on which waiting processes sleep. Since operations that require the update lock are relatively rare (fork, exec, mmap, sbrk, etc) compared to the operations that scan (page fault, pager) the shared lock is almost always available and multiple processes do not collide. .LP When a process first creates a share group (by calling .I sproc(2)) all of its sharable pregions are moved to the list of pregions in the shared address block. Some types of regions are not currently shareable. For instance, private text regions may be created for debugging - that way breakpoints may (but are not required to) be set in an individual share group member. The shared pregion list is protected via the shared lock in all places that the pregion list is accessed. In most cases the only code change was to put calls to the shared lock routines around the large sections of code that reference the pregion or region. Since there is only one list, if one process adds a pregion (say through a mmap(2) call) all other share group members will immediately see that new virtual region. .LP An interesting problem occurs when a process wishes to delete some section of its virtual space either by removing or shrinking a region. In this case it is important that the actual physical pages not be freed until .B all share group members have agreed to not reference those pages. Also important is that the initiating process not have to wait for each group member to run before completing its system call (some members may not run for a long time). To solve this problem, we use the fact that the TLB (translation lookaside buffer) is managed by software for the target processor (a MIPS R2000[MIPS86]). Thus before shrinking or detaching a region, we synchronously flush the TLBs for ALL processors, while holding the update lock for the share group's pregions. Thus if any group members are running, they will immediately trap on a TLB miss exception, come into the kernel and attempt to grab the shared read lock and block. Since the lock is held for update, the process will sleep until the lock is released. The invoking process may then continue to remove the region, free the lock and leave the kernel. .NH 2 Other Attribute Sharing .LP \" something about making pools and why we want to share other things Unlike virtual space, other process resources are not visible outside of the kernel, thus it is only important that they be synchronized whenever a group member enters the kernel. As with virtual space synchronization, we don't want to force the calling process to wait until all other group members have synchronized. To implement this, we keep a copy of each resource in the shared address block: current directory inode pointer, open file descriptors, user ids, etc. This also allows immediate access to this data, as most of it is kept in the user area and therfore inaccessible to other than the owning process. .LP Those resources which have reference counts (file descriptors and inodes) have the count bumped one for the shared address block. This avoids any races whereby the process that changed the resource exits before all other group members have had a chance to synchronize. Since there always exists a reliable available copy of the data, all that remains is to synchronize the data on each member's entry to the kernel. To make this efficient, multiple bits in the proc structure .I p_flag word are used. When a group member changes a sharable resource, it first checks its .I p_shmask mask (the kernel version of the share mask) to see if it is sharing this particular resource. If so, .I s_fupdsema or .I s_fupdlock is locked to avoid any races between multiple updaters. The resource is then modified (open the file, set user id, etc), a copy is made in the shared address block, each sharing group member's .I p_flag word is updated, and the locks are released. When a shared process enters the system via a system call, the collection of bits in .I p_flag is checked in a single test; if any are set then a routine to handle the synchronization is called. Other events that must be checked on entry to the system were also changed to this scheme, thus lowering the system call overhead for most system calls. .LP The above scheme works well except if two processes attempt to update a resource at the same time. The lock will stop the second process, but it is important that the second process be synchronized prior to being allowed update the resource. This is handled by also checking the synchronization bits after acquiring the lock. .NH 1 Analysis .LP The resource sharing mechanism described above was implemented and tested on a multi-processor MIPS R2300 testbed. As expected, the time for a .I sproc() system call is slightly less than a regular .I fork(). The overhead for synchronizing the virtual spaces is negligible except when detaching or shrinking regions. In practice this only happens if a process shrinks its data space (fairly rare) or if a process does considerable VM management activity (e.g. mapping or unmapping files). A possible system performance gain could be to only selectively flush the TLBs of the other processors. .NH 1 Future Directions .LP Although the set of features included in the first release is adequate for many tasks, there are many other interesting capabilities that could be added. .LP For example, the ability to selectively share regions when calling .I sproc() could be a useful facility, somewhat along the lines of Mach shared memory, thus allowing some parts of the address space to be accessed .I copy-on-write while others are simply shared. This ability is a simple extension to the current scheme, as it only requires proper management of the private pregion list and the shared pregion list. .LP There are also other resources that could be usefully shared. For instance, the scheduling parameters of a process could be shared among the members of the share group. Since the shared address block is always resident, it provides a convienent handle for making scheduling decisions about the process group as a whole. In a multi-processor example, the programmer could specify that at least two of the processes in the share group must run in parallel, or the group should not be allowed to execute at all. The priority of the whole group could be raised or lowered, or a whole process group could be convienently blocked or unblocked. .LP Currently, calling .I exec(2) breaks the association with the share group. By modifying the concept of pregion sharing to handle a unique address space, it could be possible to have a group of unrelated programs managed as a whole for file sharing or scheduling purposes. .NH 1 Conclusion .LP This paper has presented a new and unique interface for the System V kernel, .I share groups, .R that allows an extremely high level of resource sharing between UNIX processes. The programmer has control of what is being shared. Normal UNIX semantics are maintained for all processes within a share group, thus maintaining compatability and expected behaviour. .LP This interface has been implemented within a production kernel, and meets the promise of its design. Processes not associated with a share group experience no penalty for the inclusion of share group support, while processes within a share group may take advantage of a common address space and automatic sharing of certain fundamental resources. .LP This interface also allows for a large degree of future extensions, and shows how an additional layer of process management may be added to the UNIX kernel without penalizing standard programs. .bp .SH References .XP Accetta, Mike, et.al., "Mach: A New Kernel Foundation For UNIX Development", in .I USENIX Association Proceedings, Summer, 1986. .R .XP Tevanian, Avadis, et.al., "Mach Threads and the UNIX Kernel: The Battle for Control", in .I USENIX Conference Proceedings, .R Summer 1987. .XP Wagner, J. C., and Barton, J. M., "Threads in System V: Letting UNIX Parallel Process", a work-in-progress paper presented in .I ;login:, .R USENIX Association, Vol. 12, No. 5, September/October 1987. .XP Barton, J. M., "Multiprocessors: Can UNIX Take the Plunge?", in .I UNIX Review, .R October, 1987. .XP Beck, Bob, and Olien, Dave, "A Parallel Programming Process Model", in .I USENIX Conference Proceedings, .R Winter, 1987. .XP Bach, Maurice J., .I The Design of the UNIX Operating System, .R Prentice Hall, New Jersey, 1986. .XP .I MIPS R2000 Processor Architecture, .R Mips Computer Systems, Inc., Mountain View, CA., 1986. ---------- cut here ---------------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17868; 10 Mar 88 16:25 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15632; 10 Mar 88 14:51 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15191; 10 Mar 88 14:32 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa02916; 10 Mar 88 14:17 EST Received: from FORD-WDL1.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Thu, 10 Mar 88 11:14:43 PST Received: by FORD-WDL1.ARPA (5.51/5.9) id AA18419; Thu, 10 Mar 88 10:31:27 PST Date: Thu, 10 Mar 88 10:31:27 PST From: Rion Cassidy Message-Id: <8803101831.AA18419@FORD-WDL1.ARPA> To: info-iris@sumex-aim.stanford.EDU Subject: kermit on IRIS After our disk crashed here recently, we were required to upgrade to SGI's release 3.6 of the operating system; otherwise the new disk they installed would not work. This of course required that the complete distribution tape be loaded onto our system (the tech's tape -- we haven't gotten ours yet). We restored all our user files and everything seems to work fine. Except kermit. Our 3120 is pretty much stand-alone; there's no ethernet connection to other machines. Our only means of transfering files to/from the IRIS is through the company phone system using kermit. Without kermit we have problems, and for some odd reason it crashes (segmentation violation) whenever we try to send a file. It recieves files OK and is apparently able to connect to other systems just fine. My hunch is that we were given a corrupted source code file for kermit or our kernel has somehow been damaged. It worked fine before!! Yes, I've tried remakeing kermit and rebooting the IRIS. No luck. No, I can't reinstall the system; we don't have the distribution tapes yet. Yes, I've called the hotline; every day for the last week, and, well, you know what kind of people they typically put on hotline duty. Any suggestions would be appreciated. Responses from anyone using kermit under release 3.6 would be particularly nice. Rion Cassidy Ford Aerospace rion@ford-wdl1.arpa ...{sgi,sun,ucbvax}!wdl1!rion Disk Claimer: My employer forced me to write this at gun-point. I assume no responsibility whatsoever for what I've said here. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19754; 10 Mar 88 21:51 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa19217; 10 Mar 88 19:36 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa19207; 10 Mar 88 19:28 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa11665; 10 Mar 88 19:17 EST Date: Thu, 10 Mar 88 16:17:11 PST From: Russ Altman Subject: mouse driven rotations To: info-iris@SUMEX-AIM.Stanford.EDU Message-ID: <12381326391.70.ALTMAN@SUMEX-AIM.Stanford.EDU> Does anyone have a reference to code, article or book which discusses good ways to map mouse motion to smooth rotation and translation of objects on a graphics screen? I could imagine playing around a long time finding the most natural interface. However, I have played with some programs that have very good algorithms. For instance, the mouse mapping in the molecular graphics program MMS is quite good. Any help? Thanks, Russ ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa23696; 11 Mar 88 9:24 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22119; 11 Mar 88 8:01 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa22113; 11 Mar 88 7:53 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa18636; 11 Mar 88 7:41 EST Received: Fri, 11 Mar 88 07:44:05 EST by aero4.larc.nasa.gov (5.15/5.6) Date: Fri, 11 Mar 88 07:44:05 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8803111244.AA24175@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: ref. Rion Cassidy & kermit If you want any action from SGI you have to keep at them constantly, more than once a day, until they get tired of hearing from you. That seems to be the ONLY way to get ANY positive action out of them. They get tired of hearing from you and they will do anything to stop hearing your complaining. Voice of experience. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01499; 11 Mar 88 21:19 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00798; 11 Mar 88 19:14 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aq00530; 11 Mar 88 19:05 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa05320; 11 Mar 88 18:39 EST Received: from lindy.stanford.edu by SUMEX-AIM.Stanford.EDU with TCP; Fri, 11 Mar 88 15:35:04 PST Received: by lindy.stanford.edu; Fri, 11 Mar 88 11:54:32 PST Received: by Forsythe.Stanford.EDU; Fri, 11 Mar 88 15:34:41 PST Received: (from ACPPROD@UCHIMVS1 for UCHIMVS1 via NJE) (M-ACPPROD-3167; 19 LINES); Fri, 11 Mar 88 17:15:26 CST Received: from CHIP.UCHICAGO by UCHIMVS1.UCHICAGO.EDU with TCP; Fri, 11 Mar 88 17:15:25 CST Date: Fri 11 Mar 88 17:14:07-CST From: Stuart Schmukler Subject: Re: mouse driven rotations To: ALTMAN@sumex-aim.stanford.EDU, info-iris@sumex-aim.stanford.EDU Cc: STAFF.SAS@chip.uchicago.EDU In-Reply-To: Message from "Russ Altman " of Thu 10 Mar 88 19:26:59-CST Message-ID: <8803111839.aa05320@SMOKE.BRL.ARPA> I recall a note in the ACM journal TOG (Transactions On Graphics) about that subject. It may have been a year or so ago. SaS ------- ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05058; 12 Mar 88 15:37 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa04832; 12 Mar 88 14:24 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa04830; 12 Mar 88 14:20 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa16359; 12 Mar 88 14:07 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sat, 12 Mar 88 11:06:37 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA11903; Sat, 12 Mar 88 10:47:00 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Mar 88 14:54:32 GMT From: Michael Piplani Organization: Cornell Theory Center, Cornell University, Ithaca NY Subject: optical disk for iris Message-Id: <4001@batcomputer.tn.cornell.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU I know that there are write once read many times optical disks out there for vaxes, but I'm interested in one for the iris (3000 series). Does anyone our there know of such a product? I'ld like to store librarys of digital images, and streaming tapes just aren't the way to go. thanks mike piplani piplani@crnlimap (bitnet) (607)255-9101 (nynex) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa01013; 13 Mar 88 2:46 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00673; 13 Mar 88 1:33 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00658; 13 Mar 88 1:26 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa23880; 13 Mar 88 1:13 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sat, 12 Mar 88 22:12:12 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA23354; Sat, 12 Mar 88 22:02:03 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Mar 88 20:44:16 GMT From: "Michael L. Johnson" Organization: School of Medicine, University of Va. Subject: Exabyte EXB-8200 tape drives Message-Id: <228@dale.acc.virginia.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Has anyone tried to install an Exabyte EXB-8200 vcr tape drive on a Silicon Graphics 4D/70? I would like any information that I can get. i.e. How to configure? Did it work? O.E.M.'s? etc. Thanks. Michael Johnson mlj8e@virginia.edu -- Michael L. Johnson Pharmacology Dept.; Box 448; Univ. of Va.; Charlottesville, Va. 22908 mlj8e@acc.virginia.edu || uunet!virginia!mlj8e || mlj8e@virginia.BITNET ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa20991; 14 Mar 88 20:03 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa18884; 14 Mar 88 15:43 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa18788; 14 Mar 88 15:34 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa00706; 14 Mar 88 15:11 EST Received: Mon, 14 Mar 88 07:29:43 EST by aero4.larc.nasa.gov (5.15/5.6) Date: Mon, 14 Mar 88 07:29:43 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8803141229.AA04686@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: Mouse driven rotations Did I miss a message? Did some one have a question about mouse driven rotations? I have used a progam called PLOT3D that does that, and I have writen several programs and subroutines that do that. What was the exact question? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa23113; 15 Mar 88 1:58 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22433; 14 Mar 88 23:51 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa22379; 14 Mar 88 23:33 EST Received: from ucsd.edu by SMOKE.BRL.ARPA id aa00720; 14 Mar 88 23:22 EST Received: from chem.ucsd.edu by ucsd.edu (5.58/UCSD-1.0) id AA14990 for info-iris@brl.arpa; Mon, 14 Mar 88 11:14:07 PST Received: by chem.chem.ucsd.edu (5.44) id AA17269; Mon, 14 Mar 88 11:12:56 PST Received: by chem.chem.ucsd.arpa (5.51) id AA23679; Mon, 14 Mar 88 11:12:50 PST Date: Mon, 14 Mar 88 11:12:50 PST From: Steve Dempsey Message-Id: <8803141912.AA23679@chem.chem.ucsd.arpa> To: info-iris@BRL.ARPA Subject: cron and rwhod dump core in 3.6 Ever since I installed the 3.6 upgrade on my 2400 Turbo I've had problems with /etc/cron and /usr/etc/rwhod crashing and dumping core. Adb reports (as best it can without a namelist) that the reason for termination in both cases is signal 0????? I haven't been able to associate any particular activity with the crashes. Sometimes they stay up for a week, sometimes only a few minutes. Has anybody else witnessed similar behavior? Steve Dempsey Dept. of Chemistry Computer Facility, B-014 Univ. of Calif., San Diego La Jolla, CA 92093 BITNET: sdempsey@ucsd INTERNET: sdempsey@ucsd.edu UUCP: ...!ucbvax!ucsd!sdempsey ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa23665; 15 Mar 88 3:21 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22756; 15 Mar 88 0:45 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa22727; 15 Mar 88 0:35 EST Received: from ucsd.edu by SMOKE.BRL.ARPA id aa01642; 15 Mar 88 0:21 EST Received: from chem.ucsd.edu by ucsd.edu (5.58/UCSD-1.0) id AA07177 for info-iris@brl.arpa; Mon, 14 Mar 88 21:22:40 PST Received: by chem.chem.ucsd.edu (5.51) id AA00961; Mon, 14 Mar 88 21:21:24 PST Received: by chem.chem.ucsd.edu (5.44) id AA00261; Mon, 14 Mar 88 12:34:08 PST Received: by chem.chem.ucsd.arpa (5.51) id AA24172; Mon, 14 Mar 88 12:11:53 PST Date: Mon, 14 Mar 88 12:11:53 PST From: Steve Dempsey Message-Id: <8803142011.AA24172@chem.chem.ucsd.arpa> To: info-iris@BRL.ARPA Subject: IRID 4D/70g zbuffer bugs When Z buffering is enabled, depthcueing and clipping of line segments is not always done properly. When a depthcued line is zbuffered, all of the pixels of the line are drawn at the same intensity, which appears the be the intensity of the closest pixel. It appears that only the first pixel is depthcued, and then all of the remaining pixels are given whatever color was determined for the first pixel. This bug is most noticable when long lines are drawn from the hither to yon plane. Note that if the line is drawn as a series of short segments then each segment will be drawn at a different intensity and you might not notice the problem. In addition, some depthcued and zbuffered lines are not clipped properly. As the hither plane moves behind one endpoint of the line segment, the entire segment disappears. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa26262; 15 Mar 88 8:27 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id ab26073; 15 Mar 88 8:17 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa26065; 15 Mar 88 8:14 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa05104; 15 Mar 88 7:57 EST Received: Tue, 15 Mar 88 07:59:57 EST by aero4.larc.nasa.gov (5.15/5.6) Date: Tue, 15 Mar 88 07:59:57 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8803151259.AA08770@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: Mouse rotations source program solidshade character file*80,reverse*1,type*1 integer*2 bx,by,numdev,numlights,sleep,val integer*4 ax,ay,curentdev(0:3),dev,fovy,g,i,inorm(162,66,4),lamps integer*4 nullwin,oldwin,rankleft,rankmid,rankright,shadesolid integer*4 xwinlen,xwinorg,ywinlen,ywinorg integer*4 j,k,nx(4),ny(4),nz(4) logical bflag,btogl,cflag,ctogl,extflag,currentwin,front logical ltemp,mflag,pflag,sflag,stogl logical xflag,xtogl,yflag,ytogl,zflag,ztogl real data(3,162,66,4),far,lightlen,mag,magrate real near,nmag1,nmag2,nmag3,nmag4 real norm(3,162,66,4),normlength real nx1,nx2,nx3,nx4,ny1,ny2,ny3,ny4,nz1,nz2,nz3,nz4 real rprate,rxrate,ryrate,rzrate,scale,tempdircos real totdircos,totext,txrate,tyrate real viewpnt,vx1,vx2,vx3,vx4,vy1,vy2,vy3,vy4,vz1,vz2,vz3,vz4 real xangle,xdiff,xdircos(3),xmax,xmid,xmin,xpos real yangle,ydiff,ydircos(3),ymax,ymid,ymin,ypos real zangle,zdircos(3),zmax,zmid,zmin $ include /usr/include/fgl.h $ include /usr/include/fdevice.h call getarg(2,file) call getarg(3,type) call getarg(4,reverse) if(type.eq.'b') then open(79,file=file,form='binary') read(79) ngrid read(79) (nx(i),ny(i),nz(i),i=1,ngrid) do 20 g=1,ngrid write(*,1000) g,nx(g),g,ny(g),g,nz(g) if(reverse.eq.'r') then read(79)(((data(1,i,j,g),i=1,nx(g)),j=ny(g),1,-1),k=1,nz(g)), . (((data(2,i,j,g),i=1,nx(g)),j=ny(g),1,-1),k=1,nz(g)), . (((data(3,i,j,g),i=1,nx(g)),j=ny(g),1,-1),k=1,nz(g)) else read(79)(((data(1,i,j,g),i=1,nx(g)),j=1,ny(g)),k=1,nz(g)), . (((data(2,i,j,g),i=1,nx(g)),j=1,ny(g)),k=1,nz(g)), . (((data(3,i,j,g),i=1,nx(g)),j=1,ny(g)),k=1,nz(g)) endif if(nz(g).gt.1) then open(80,file='out.bin',form='binary') write(80) ngrid write(*,1000) g,nx(g),g,ny(g),g,1 write(80) (nx(i),ny(i),1,i=1,ngrid) write(80)((data(1,i,j,g),i=1,nx(g)),j=1,ny(g)), . ((data(2,i,j,g),i=1,nx(g)),j=1,ny(g)), . ((data(3,i,j,g),i=1,nx(g)),j=1,ny(g)) endif 20 continue else open(79,file=file,form='formatted') read(79,*) ngrid read(79,*) (nx(i),ny(i),nz(i),i=1,ngrid) do 30 g=1,ngrid write(*,1000) g,nx(g),g,ny(g),g,nz(g) if(reverse.eq.'r') then read(79,*)(((data(1,i,j,g),i=1,nx(g)),j=ny(g),1,-1),k=1,nz(g)), . (((data(2,i,j,g),i=1,nx(g)),j=ny(g),1,-1),k=1,nz(g)), . (((data(3,i,j,g),i=1,nx(g)),j=ny(g),1,-1),k=1,nz(g)) else read(79,*)(((data(1,i,j,g),i=1,nx(g)),j=1,ny(g)),k=1,nz(g)), . (((data(2,i,j,g),i=1,nx(g)),j=1,ny(g)),k=1,nz(g)), . (((data(3,i,j,g),i=1,nx(g)),j=1,ny(g)),k=1,nz(g)) endif nz(g)=1 30 continue open(80,file='out.bin',form='binary') write(80) ngrid write(80) (nx(i),ny(i),nz(i),i=1,ngrid) do 40 g=1,ngrid write(*,1000) g,nx(g),g,ny(g),g,nz(g) c if(g.ne.3) then write(80)(((data(1,i,j,g),i=1,nx(g)),j=1,ny(g)),k=1,nz(g)), . (((data(2,i,j,g),i=1,nx(g)),j=1,ny(g)),k=1,nz(g)), . (((data(3,i,j,g),i=1,nx(g)),j=1,ny(g)),k=1,nz(g)) c else c write(80)(((data(1,i,j,g),i=1,nx(g)),j=ny(g),1,-1),k=1,nz(g)), c . (((data(2,i,j,g),i=1,nx(g)),j=ny(g),1,-1),k=1,nz(g)), c . (((data(3,i,j,g),i=1,nx(g)),j=ny(g),1,-1),k=1,nz(g)) c endif 40 continue endif close(79) close(80) extflag=.true. do 220 g=1,ngrid do 220 i=1,nx(g) do 220 j=1,ny(g) x1=data(1,i,j,g) y1=data(2,i,j,g) z1=data(3,i,j,g) if(i.gt.1.and.i.lt.nx(g).and.j.gt.1.and.j.lt.ny(g)) then vx1=data(1,i+1,j,g)-x1 vy1=data(2,i+1,j,g)-y1 vz1=data(3,i+1,j,g)-z1 vx2=data(1,i,j+1,g)-x1 vy2=data(2,i,j+1,g)-y1 vz2=data(3,i,j+1,g)-z1 vx3=data(1,i-1,j,g)-x1 vy3=data(2,i-1,j,g)-y1 vz3=data(3,i-1,j,g)-z1 vx4=data(1,i,j-1,g)-x1 vy4=data(2,i,j-1,g)-y1 vz4=data(3,i,j-1,g)-z1 nx1=vy1*vz2-vz1*vy2 ny1=vz1*vx2-vx1*vz2 nz1=vx1*vy2-vy1*vx2 nmag1=sqrt(nx1*nx1+ny1*ny1+nz1*nz1) if(nmag1.gt.0) then nx1=nx1/nmag1 ny1=ny1/nmag1 nz1=nz1/nmag1 endif nx2=vy2*vz3-vz2*vy3 ny2=vz2*vx3-vx2*vz3 nz2=vx2*vy3-vy2*vx3 nmag2=sqrt(nx2*nx2+ny2*ny2+nz2*nz2) if(nmag2.gt.0) then nx2=nx2/nmag2 ny2=ny2/nmag2 nz2=nz2/nmag2 endif nx3=vy3*vz4-vz3*vy4 ny3=vz3*vx4-vx3*vz4 nz3=vx3*vy4-vy3*vx4 nmag3=sqrt(nx3*nx3+ny3*ny3+nz3*nz3) if(nmag3.gt.0) then nx3=nx3/nmag3 ny3=ny3/nmag3 nz3=nz3/nmag3 endif nx4=vy4*vz1-vz4*vy1 ny4=vz4*vx1-vx4*vz1 nz4=vx4*vy1-vy4*vx1 nmag4=sqrt(nx4*nx4+ny4*ny4+nz4*nz4) if(nmag4.gt.0) then nx4=nx4/nmag4 ny4=ny4/nmag4 nz4=nz4/nmag4 endif norm(1,i,j,g)=nx1+nx2+nx3+nx4 norm(2,i,j,g)=ny1+ny2+ny3+ny4 norm(3,i,j,g)=nz1+nz2+nz3+nz4 else if(i.eq.1.and.j.eq.ny(g)) then vx1=data(1,i+1,j,g)-x1 vy1=data(2,i+1,j,g)-y1 vz1=data(3,i+1,j,g)-z1 vx4=data(1,i,j-1,g)-x1 vy4=data(2,i,j-1,g)-y1 vz4=data(3,i,j-1,g)-z1 nx4=vy4*vz1-vz4*vy1 ny4=vz4*vx1-vx4*vz1 nz4=vx4*vy1-vy4*vx1 nmag4=sqrt(nx4*nx4+ny4*ny4+nz4*nz4) if(nmag4.gt.0) then nx4=nx4/nmag4 ny4=ny4/nmag4 nz4=nz4/nmag4 endif norm(1,i,j,g)=nx4 norm(2,i,j,g)=ny4 norm(3,i,j,g)=nz4 else if(i.eq.1.and.j.eq.1) then vx1=data(1,i+1,j,g)-x1 vy1=data(2,i+1,j,g)-y1 vz1=data(3,i+1,j,g)-z1 vx2=data(1,i,j+1,g)-x1 vy2=data(2,i,j+1,g)-y1 vz2=data(3,i,j+1,g)-z1 nx1=vy1*vz2-vz1*vy2 ny1=vz1*vx2-vx1*vz2 nz1=vx1*vy2-vy1*vx2 nmag1=sqrt(nx1*nx1+ny1*ny1+nz1*nz1) if(nmag1.gt.0) then nx1=nx1/nmag1 ny1=ny1/nmag1 nz1=nz1/nmag1 endif norm(1,i,j,g)=nx1 norm(2,i,j,g)=ny1 norm(3,i,j,g)=nz1 else if(i.eq.nx(g).and.j.eq.ny(g)) then vx3=data(1,i-1,j,g)-x1 vy3=data(2,i-1,j,g)-y1 vz3=data(3,i-1,j,g)-z1 vx4=data(1,i,j-1,g)-x1 vy4=data(2,i,j-1,g)-y1 vz4=data(3,i,j-1,g)-z1 nx3=vy3*vz4-vz3*vy4 ny3=vz3*vx4-vx3*vz4 nz3=vx3*vy4-vy3*vx4 nmag3=sqrt(nx3*nx3+ny3*ny3+nz3*nz3) if(nmag3.gt.0) then nx3=nx3/nmag3 ny3=ny3/nmag3 nz3=nz3/nmag3 endif norm(1,i,j,g)=nx3 norm(2,i,j,g)=ny3 norm(3,i,j,g)=nz3 else if(i.eq.nx(g).and.j.eq.1) then vx2=data(1,i,j+1,g)-x1 vy2=data(2,i,j+1,g)-y1 vz2=data(3,i,j+1,g)-z1 vx3=data(1,i-1,j,g)-x1 vy3=data(2,i-1,j,g)-y1 vz3=data(3,i-1,j,g)-z1 nx2=vy2*vz3-vz2*vy3 ny2=vz2*vx3-vx2*vz3 nz2=vx2*vy3-vy2*vx3 nmag2=sqrt(nx2*nx2+ny2*ny2+nz2*nz2) if(nmag2.gt.0) then nx2=nx2/nmag2 ny2=ny2/nmag2 nz2=nz2/nmag2 endif norm(1,i,j,g)=nx2 norm(2,i,j,g)=ny2 norm(3,i,j,g)=nz2 else if(i.eq.1.and.j.gt.1.and.j.lt.ny(g)) then vx1=data(1,i+1,j,g)-x1 vy1=data(2,i+1,j,g)-y1 vz1=data(3,i+1,j,g)-z1 vx2=data(1,i,j+1,g)-x1 vy2=data(2,i,j+1,g)-y1 vz2=data(3,i,j+1,g)-z1 vx4=data(1,i,j-1,g)-x1 vy4=data(2,i,j-1,g)-y1 vz4=data(3,i,j-1,g)-z1 nx1=vy1*vz2-vz1*vy2 ny1=vz1*vx2-vx1*vz2 nz1=vx1*vy2-vy1*vx2 nmag1=sqrt(nx1*nx1+ny1*ny1+nz1*nz1) if(nmag1.gt.0) then nx1=nx1/nmag1 ny1=ny1/nmag1 nz1=nz1/nmag1 endif nx4=vy4*vz1-vz4*vy1 ny4=vz4*vx1-vx4*vz1 nz4=vx4*vy1-vy4*vx1 nmag4=sqrt(nx4*nx4+ny4*ny4+nz4*nz4) if(nmag4.gt.0) then nx4=nx4/nmag4 ny4=ny4/nmag4 nz4=nz4/nmag4 endif norm(1,i,j,g)=nx1+nx4 norm(2,i,j,g)=ny1+ny4 norm(3,i,j,g)=nz1+nz4 else if(i.eq.nx(g).and.j.gt.1.and.j.lt.ny(g)) then vx2=data(1,i,j+1,g)-x1 vy2=data(2,i,j+1,g)-y1 vz2=data(3,i,j+1,g)-z1 vx3=data(1,i-1,j,g)-x1 vy3=data(2,i-1,j,g)-y1 vz3=data(3,i-1,j,g)-z1 vx4=data(1,i,j-1,g)-x1 vy4=data(2,i,j-1,g)-y1 vz4=data(3,i,j-1,g)-z1 nx2=vy2*vz3-vz2*vy3 ny2=vz2*vx3-vx2*vz3 nz2=vx2*vy3-vy2*vx3 nmag2=sqrt(nx2*nx2+ny2*ny2+nz2*nz2) if(nmag2.gt.0) then nx2=nx2/nmag2 ny2=ny2/nmag2 nz2=nz2/nmag2 endif nx3=vy3*vz4-vz3*vy4 ny3=vz3*vx4-vx3*vz4 nz3=vx3*vy4-vy3*vx4 nmag3=sqrt(nx3*nx3+ny3*ny3+nz3*nz3) if(nmag3.gt.0) then nx3=nx3/nmag3 ny3=ny3/nmag3 nz3=nz3/nmag3 endif norm(1,i,j,g)=nx2+nx3 norm(2,i,j,g)=ny2+ny3 norm(3,i,j,g)=nz2+nz3 else if(i.gt.1.and.i.lt.nx(g).and.j.eq.ny(g)) then vx1=data(1,i+1,j,g)-x1 vy1=data(2,i+1,j,g)-y1 vz1=data(3,i+1,j,g)-z1 vx3=data(1,i-1,j,g)-x1 vy3=data(2,i-1,j,g)-y1 vz3=data(3,i-1,j,g)-z1 vx4=data(1,i,j-1,g)-x1 vy4=data(2,i,j-1,g)-y1 vz4=data(3,i,j-1,g)-z1 nx3=vy3*vz4-vz3*vy4 ny3=vz3*vx4-vx3*vz4 nz3=vx3*vy4-vy3*vx4 nmag3=sqrt(nx3*nx3+ny3*ny3+nz3*nz3) if(nmag3.gt.0) then nx3=nx3/nmag3 ny3=ny3/nmag3 nz3=nz3/nmag3 endif nx4=vy4*vz1-vz4*vy1 ny4=vz4*vx1-vx4*vz1 nz4=vx4*vy1-vy4*vx1 nmag4=sqrt(nx4*nx4+ny4*ny4+nz4*nz4) if(nmag4.gt.0) then nx4=nx4/nmag4 ny4=ny4/nmag4 nz4=nz4/nmag4 endif norm(1,i,j,g)=nx3+nx4 norm(2,i,j,g)=ny3+ny4 norm(3,i,j,g)=nz3+nz4 else if(i.gt.1.and.i.lt.nx(g).and.j.eq.1) then vx1=data(1,i+1,j,g)-x1 vy1=data(2,i+1,j,g)-y1 vz1=data(3,i+1,j,g)-z1 vx2=data(1,i,j+1,g)-x1 vy2=data(2,i,j+1,g)-y1 vz2=data(3,i,j+1,g)-z1 vx3=data(1,i-1,j,g)-x1 vy3=data(2,i-1,j,g)-y1 vz3=data(3,i-1,j,g)-z1 nx1=vy1*vz2-vz1*vy2 ny1=vz1*vx2-vx1*vz2 nz1=vx1*vy2-vy1*vx2 nmag1=sqrt(nx1*nx1+ny1*ny1+nz1*nz1) if(nmag1.gt.0) then nx1=nx1/nmag1 ny1=ny1/nmag1 nz1=nz1/nmag1 endif nx2=vy2*vz3-vz2*vy3 ny2=vz2*vx3-vx2*vz3 nz2=vx2*vy3-vy2*vx3 nmag2=sqrt(nx2*nx2+ny2*ny2+nz2*nz2) if(nmag2.gt.0) then nx2=nx2/nmag2 ny2=ny2/nmag2 nz2=nz2/nmag2 endif norm(1,i,j,g)=nx1+nx2 norm(2,i,j,g)=ny1+ny2 norm(3,i,j,g)=nz1+nz2 endif c if(y1.eq.0) norm(2,i,j,g)=0.0 normlength=sqrt(norm(1,i,j,g)*norm(1,i,j,g)+ . norm(2,i,j,g)*norm(2,i,j,g)+ . norm(3,i,j,g)*norm(3,i,j,g)) norm(1,i,j,g)=norm(1,i,j,g)/normlength norm(2,i,j,g)=norm(2,i,j,g)/normlength norm(3,i,j,g)=norm(3,i,j,g)/normlength if(extflag) then xmax=x1 xmin=x1 ymax=y1 ymin=y1 zmax=z1 zmin=z1 extflag=.false. else if(x1.gt.xmax) then xmax=x1 else if(x1.lt.xmin) then xmin=x1 endif if(y1.gt.ymax) then ymax=y1 else if(y1.lt.ymin) then ymin=y1 endif if(z1.gt.zmax) then zmax=z1 else if(z1.lt.zmin) then zmin=z1 endif endif 220 continue write(*,'(''Enter number of light sources:'',$)') read(*,*) numlights do 225 k=1,numlights write(*,1010) k,k,k read(*,*) xdircos(k),ydircos(k),zdircos(k) 225 continue xmid=(xmax+xmin)/2.0 ymid=(ymax+ymin)/2.0 zmid=(zmax+zmin)/2.0 totext=max(abs(xmax-xmin),abs(ymax-ymin),abs(zmax-zmin))*1.25 scale=totext/875.0 curentdev(0)=0 curentdev(1)=0 curentdev(2)=0 curentdev(3)=0 fovy=200 mag=0.10 magrate=0.0 numdev=0 rankleft=0 rankmid=0 rankright=0 rxrate=0.0 ryrate=0.0 rzrate=0.0 txrate=0.0 tyrate=0.0 xangle=0.0 xpos=0.0 yangle=0.0 ypos=0.0 viewpnt=0.0 zangle=0.0 bflag=.false. btogl=.true. cflag=.false. ctogl=.true. mflag=.true. pflag=.false. sflag=.false. stogl=.true. xflag=.false. xtogl=.true. yflag=.true. ytogl=.false. zflag=.true. ztogl=.false. lamps=14 call lampon(lamps) call foregr shadesolid=winope('solidshade',5) oldwin=winatt() currentwin=.true. call double call gconfi call qdevic(redraw) call qdevic(bkey) call qdevic(ckey) call qdevic(ekey) call qdevic(lkey) call qdevic(mkey) call qdevic(pkey) call qdevic(skey) call qdevic(xkey) call qdevic(ykey) call qdevic(zkey) call qdevic(uparro) call qdevic(downar) call qdevic(leftmo) call qdevic(middle) call qdevic(rightm) call tie(leftmo,mousex,mousey) call tie(middle,mousex,mousey) call tie(rightm,mousex,mousey) call noise(mousex,2) call noise(mousey,2) call backfa(.true.) print *,'Making color map' do 230 i=768,1023 c call mapcol(i,i-768,i-768,i-768) call mapcol(i-256,0,0,i-768) call mapcol(i,i-768,i-768,255) C call mapcol(i-512,0,0,i-768) C call mapcol(i-256,0,i-768,255) C call mapcol(i,i-768,255,255) 230 continue call getori(xwinorg,ywinorg) call getsiz(xwinlen,ywinlen) 240 print *,'Calculating surface shading colors' do 245 k=1,numlights lightlen=sqrt(xdircos(k)*xdircos(k)+ydircos(k)*ydircos(k)+ . zdircos(k)*zdircos(k)) xdircos(k)=xdircos(k)/lightlen ydircos(k)=ydircos(k)/lightlen zdircos(k)=zdircos(k)/lightlen 245 continue do 250 g=1,ngrid do 250 i=1,nx(g) do 250 j=1,ny(g) totdircos=0.0 do 255 k=1,numlights tempdircos=norm(1,i,j,g)*xdircos(k)+ . norm(2,i,j,g)*ydircos(k)+ . norm(3,i,j,g)*zdircos(k) if(tempdircos.gt.0) then totdircos=totdircos+tempdircos endif 255 continue c inorm(i,j,g)=768+nint(255*totdircos) c if(inorm(i,j,g).gt.1023) then c inorm(i,j,g)=1023 c else if(inorm(i,j,g).lt.768) then c inorm(i,j,g)=768 c endif inorm(i,j,g)=512+nint(511*totdircos) if(inorm(i,j,g).gt.1023) then inorm(i,j,g)=1023 else if(inorm(i,j,g).lt.511) then inorm(i,j,g)=511 endif C inorm(i,j,g)=256+nint(767*totdircos) C if(inorm(i,j,g).gt.1023) then C inorm(i,j,g)=1023 C else if(inorm(i,j,g).lt.256) then C inorm(i,j,g)=256 C endif 250 continue call qreset 260 call frontb(.true.) front=.true. sleep=0 270 continue if(bflag) call zclear call color(black) call clear call pushma viewpnt=viewpnt-magrate xpos=xpos+txrate ypos=ypos+tyrate fovy=fovy+rprate if(fovy.lt.2) then fovy=2 else if(fovy.gt.1800) then fovy=1800 endif far=totext*1.5-viewpnt if(far.le.0) then far=totext*1.0e-4 endif near=-viewpnt if(near.ge.far.or.near.le.far*1.0e-3.or.near.le.0) then near=far*1.0e-2 endif if(bflag) then call perspe(fovy,real(xwinlen)/real(ywinlen),near,far) else call perspe(fovy,real(xwinlen)/real(ywinlen),0.0,far) endif call lookat(viewpnt-totext,xpos,ypos,viewpnt,xpos,ypos,-900) xangle=xangle+rxrate yangle=yangle+ryrate zangle=zangle+rzrate call rot(zangle,'z') call rot(yangle,'y') call rot(xangle,'x') call color(green) call move(0.0,0.0,0.0) call draw(10.0*scale,0.0,0.0) call move(10.0*scale,0.0,-0.5*scale) call draw(10.5*scale,0.0,0.5*scale) call move(10.0*scale,0.0,0.5*scale) call draw(10.5*scale,0.0,-0.5*scale) call color(cyan) call move(0.0,0.0,0.0) call draw(0.0,10.0*scale,0.0) call move(0.0,10.0*scale,0.5*scale) call draw(0.0,10.25*scale,0.0) call draw(0.0,10.25*scale,-0.5*scale) call move(0.0,10.5*scale,0.5*scale) call draw(0.0,10.25*scale,0.0) call color(magent) call move(0.0,0.0,0.0) call draw(0.0,0.0,10.0*scale) call move(0.25*scale,0.0,11.25*scale) call draw(-0.25*scale,0.0,11.25*scale) call draw(0.25*scale,0.0,10.25*scale) call draw(-0.25*scale,0.0,10.25*scale) call transl(-xmid,0.0,-zmid) call color(white) if(sflag) then if(cflag) then do 280 g=1,ngrid do 280 j=1,ny(g)-1 do 280 i=1,nx(g)-1 call setsha(inorm(i,j,g)) call pmv(data(1,i,j,g), . -data(2,i,j,g),data(3,i,j,g)) call setsha(inorm(i,j+1,g)) call pdr(data(1,i,j+1,g), . -data(2,i,j+1,g),data(3,i,j+1,g)) call setsha(inorm(i+1,j+1,g)) call pdr(data(1,i+1,j+1,g), . -data(2,i+1,j+1,g),data(3,i+1,j+1,g)) call setsha(inorm(i+1,j,g)) call pdr(data(1,i+1,j,g), . -data(2,i+1,j,g),data(3,i+1,j,g)) call spclos 280 continue endif do 290 g=1,ngrid do 290 j=1,ny(g)-1 do 290 i=1,nx(g)-1 call setsha(inorm(i,j,g)) call pmv(data(1,i,j,g), . data(2,i,j,g),data(3,i,j,g)) call setsha(inorm(i+1,j,g)) call pdr(data(1,i+1,j,g), . data(2,i+1,j,g),data(3,i+1,j,g)) call setsha(inorm(i+1,j+1,g)) call pdr(data(1,i+1,j+1,g), . data(2,i+1,j+1,g),data(3,i+1,j+1,g)) call setsha(inorm(i,j+1,g)) call pdr(data(1,i,j+1,g), . data(2,i,j+1,g),data(3,i,j+1,g)) call spclos 290 continue else if(cflag) then do 300 g=1,ngrid do 310 j=1,ny(g) call move(data(1,1,j,g), . -data(2,1,j,g),data(3,1,j,g)) do 310 i=2,nx(g) call draw(data(1,i,j,g), . -data(2,i,j,g),data(3,i,j,g)) 310 continue do 320 i=1,nx(g) call move(data(1,i,1,g), . -data(2,i,1,g),data(3,i,1,g)) do 320 j=2,ny(g) call draw(data(1,i,j,g), . -data(2,i,j,g),data(3,i,j,g)) 320 continue 300 continue endif do 330 g=1,ngrid do 340 j=1,ny(g) call move(data(1,1,j,g),data(2,1,j,g),data(3,1,j,g)) do 340 i=2,nx(g) call draw(data(1,i,j,g),data(2,i,j,g),data(3,i,j,g)) 340 continue do 350 i=1,nx(g) call move(data(1,i,1,g),data(2,i,1,g),data(3,i,1,g)) do 350 j=2,ny(g) call draw(data(1,i,j,g),data(2,i,j,g),data(3,i,j,g)) 350 continue 330 continue endif call popmat if(front.and.btogl) then call frontb(.false.) front=.false. endif 370 if(qtest().eq.0) then if(btogl) call swapbu else sleep=0 dev=qread(val) if(dev.eq.redraw.and.val.eq.shadesolid) then call reshap call getori(xwinorg,ywinorg) call getsiz(xwinlen,ywinlen) curentdev(0)=0 curentdev(1)=0 curentdev(2)=0 curentdev(3)=0 numdev=0 rankleft=0 rankmid=0 rankright=0 magrate=0.0 rprate=0.0 rxrate=0.0 ryrate=0.0 rzrate=0.0 txrate=0.0 tyrate=0.0 call qreset goto 260 else if(dev.eq.inptch) then if(val.eq.shadesolid) then curentdev(0)=0 curentdev(1)=0 curentdev(2)=0 curentdev(3)=0 numdev=0 rankleft=0 rankmid=0 rankright=0 magrate=0.0 rprate=0.0 rxrate=0.0 ryrate=0.0 rzrate=0.0 txrate=0.0 tyrate=0.0 currentwin=.true. call qreset goto 260 else currentwin=.false. endif else if(dev.eq.uparro) then if(val.gt.0) then mag=mag*1.5 txrate=txrate*1.5 tyrate=tyrate*1.5 rprate=rprate*1.5 rxrate=rxrate*1.5 ryrate=ryrate*1.5 rzrate=rzrate*1.5 magrate=magrate*1.5 endif else if(dev.eq.downar) then if(val.gt.0) then mag=mag/1.5 txrate=txrate/1.5 tyrate=tyrate/1.5 rprate=rprate/1.5 rxrate=rxrate/1.5 ryrate=ryrate/1.5 rzrate=rzrate/1.5 magrate=magrate/1.5 endif else if(dev.eq.middle) then if(val.gt.0) then dev=qread(bx) dev=qread(by) if(numdev.lt.3.and.rankmid.eq.0) then numdev=numdev+1 rankmid=numdev curentdev(numdev)=middle endif else dev=qread(bx) dev=qread(by) magrate=0.0 rprate=0.0 rxrate=0.0 if(numdev.gt.0) then do 380 i=rankmid,numdev-1 curentdev(i)=curentdev(i+1) 380 continue curentdev(numdev)=0 numdev=numdev-1 rankmid=0 endif endif else if(dev.eq.leftmo) then if(val.gt.0) then dev=qread(bx) dev=qread(by) if(numdev.lt.3.and.rankleft.eq.0) then numdev=numdev+1 rankleft=numdev curentdev(numdev)=leftmo endif else dev=qread(bx) dev=qread(by) rzrate=0.0 ryrate=0.0 if(numdev.gt.0) then do 390 i=rankleft,numdev-1 curentdev(i)=curentdev(i+1) 390 continue curentdev(numdev)=0 numdev=numdev-1 rankleft=0 endif endif else if(dev.eq.rightm) then if(val.gt.0) then dev=qread(bx) dev=qread(by) if(numdev.lt.3.and.rankright.eq.0) then numdev=numdev+1 rankright=numdev curentdev(numdev)=rightm endif else dev=qread(bx) dev=qread(by) txrate=0.0 tyrate=0.0 if(numdev.gt.0) then do 400 i=rankright,numdev-1 curentdev(i)=curentdev(i+1) 400 continue curentdev(numdev)=0 numdev=numdev-1 rankright=0 endif endif else if(dev.eq.mkey) then if(val.gt.0) then call lampof(15) if(mflag) then mflag=.false. lamps=iand(lamps,7) call lampon(lamps) else mflag=.true. pflag=.false. xflag=.false. lamps=iand(lamps,14) lamps=ior(lamps,8) call lampon(lamps) endif endif else if(dev.eq.pkey) then if(val.gt.0) then if(pflag) then pflag=.false. else call lampof(15) pflag=.true. mflag=.false. xflag=.false. lamps=iand(lamps,6) call lampon(lamps) endif endif else if(dev.eq.bkey) then if(val.gt.0) then ltemp=bflag bflag=btogl btogl=ltemp if(bflag) then call single call gconfi call setdep($0000,$7fff) call zbuffe(bflag) call zclear sleep=sleep+3 else call zbuffe(bflag) call double call gconfi endif call backfa(.true.) front=.true. call qreset goto 270 else if(bflag) then sleep=sleep+3 call qreset endif else if(dev.eq.ckey) then if(val.gt.0) then ltemp=cflag cflag=ctogl ctogl=ltemp goto 270 endif else if(dev.eq.lkey) then if(val.gt.0) then call noport nullwin=winope('null',4) oldwin=winatt() call winclo(nullwin) print *,'' do 410 k=1,numlights read(*,*) xdircos(k),ydircos(k),zdircos(k) 410 continue call winset(shadesolid) oldwin=winatt() call qreset goto 240 endif else if(dev.eq.skey) then if(val.gt.0) then ltemp=sflag sflag=stogl stogl=ltemp goto 270 endif else if(dev.eq.zkey) then if(val.gt.0) then call lampof(15) ltemp=zflag zflag=ztogl ztogl=ltemp lamps=ieor(lamps,4) call lampon(lamps) endif else if(dev.eq.ykey) then if(val.gt.0) then call lampof(15) ltemp=yflag yflag=ytogl ytogl=ltemp lamps=ieor(lamps,2) call lampon(lamps) endif else if(dev.eq.xkey) then if(val.gt.0) then call lampof(15) if(xflag) then xflag=.false. lamps=iand(lamps,14) call lampon(lamps) else xflag=.true. mflag=.false. pflag=.false. lamps=iand(lamps,7) lamps=ior(lamps,1) call lampon(lamps) endif endif else if(dev.eq.ekey) then call curson call lampof(15) stop endif endif if(curentdev(numdev).ne.0) then if(currentwin) then ax=getval(mousex) ay=getval(mousey) if(ax.ne.bx.and.ay.ne.by) then xdiff=ax-bx ydiff=ay-by if(ax.ge.1023) then ax=1 call setval(mousex,ax,0,1023) else if(ax.le.0) then ax=1022 call setval(mousex,ax,0,1023) endif if(ay.ge.767) then ay=1 call setval(mousey,ay,0,767) else if(ay.le.0) then ay=766 call setval(mousey,ay,0,767) endif bx=ax by=ay if(curentdev(numdev).eq.leftmo) then if(zflag) rzrate=rzrate+xdiff*mag/50.0 if(yflag) ryrate=ryrate+ydiff*mag/50.0 else if(curentdev(numdev).eq.middle) then if(mflag) then magrate=magrate+ydiff*mag/10.0*scale else if(pflag) then rprate=rprate+xdiff*mag/40.0 else if(xflag) then rxrate=rxrate+xdiff*mag/40.0 endif else if(curentdev(numdev).eq.rightm) then txrate=txrate+xdiff*mag/40.0*scale tyrate=tyrate-ydiff*mag/40.0*scale endif endif else goto 270 endif else sleep=sleep+1 if(bflag) sleep=sleep+2 if(sleep.ge.3) then sleep=3 goto 370 endif endif goto 270 stop 1000 format(' nx(',i1,')=',i3,' ny(',i1,')=',i3,' nz(',i1,')=',i3) 1010 format('Enter xdircos(',i1,'),ydircos(',i1,'),zdircos(',i1,'):',$) end ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa27051; 15 Mar 88 9:09 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa25222; 15 Mar 88 7:33 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa25129; 15 Mar 88 7:23 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa04341; 15 Mar 88 7:14 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Tue, 15 Mar 88 04:13:43 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA16940; Tue, 15 Mar 88 03:53:20 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Mar 88 21:12:51 GMT From: "Michael L. Johnson" Organization: School of Medicine, University of Va. Subject: Exabyte tape drives Message-Id: <230@dale.acc.virginia.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Does anyone know how to install an Exabyte tape drive on a Silicon Graphics 4D/70? Thanks. Michael Johnson mlj8e@virginia.edu -- Michael L. Johnson Pharmacology Dept.; Box 448; Univ. of Va.; Charlottesville, Va. 22908 mlj8e@virginia.edu || uunet!virginia!mlj8e || mlj8e@virginia.BITNET ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa28256; 15 Mar 88 10:12 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa26073; 15 Mar 88 8:17 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa26051; 15 Mar 88 8:13 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa04968; 15 Mar 88 7:54 EST Received: Tue, 15 Mar 88 07:57:55 EST by aero4.larc.nasa.gov (5.15/5.6) Date: Tue, 15 Mar 88 07:57:55 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8803151257.AA08764@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: Mouse driven rotations Personally, I prefere driving rotations based on the change in mouse position. I have used programs that use the absolute position, but most of the time I don't like it. However, there have been a few cases where absolute positioning has been better. If you want to return to a specific orientation or if you want to limit the amount of movement. I have a sample FORTRAN source I can send you that reads in x,y,z coordinates and allows you to rotate them about all 3-axes of rotation, translate, zoom, change perspective, Gouraud shade sufaces with and with out Z-buffering. It is constantly in flux, as I try new and different things, but it will give you a good start. I will send it in my next message (almost 1000 lines). If you have any questions or suggestions for improvement let me know. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa21787; 16 Mar 88 16:08 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa20819; 16 Mar 88 15:16 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa20774; 16 Mar 88 15:02 EST Received: from NPS-CS.ARPA by SMOKE.BRL.ARPA id aa13620; 16 Mar 88 14:43 EST Received: by nps-cs.arpa (5.51/1.26) id AA21566; Wed, 16 Mar 88 11:42:56 PST Date: Wed, 16 Mar 88 11:42:56 PST From: michael zyda Message-Id: <8803161942.AA21566@nps-cs.arpa> To: info-iris@BRL.ARPA Subject: font memory on the 4D Does anyone know how much font memory is on the 4D/70G? Michael Zyda Naval Postgraduate School ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa22529; 16 Mar 88 17:01 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa21867; 16 Mar 88 16:30 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa21857; 16 Mar 88 16:14 EST Received: from NPS-CS.ARPA by SMOKE.BRL.ARPA id aa17248; 16 Mar 88 16:05 EST Received: by nps-cs.arpa (5.51/1.26) id AA22867; Wed, 16 Mar 88 13:05:13 PST Date: Wed, 16 Mar 88 13:05:13 PST From: michael zyda Message-Id: <8803162105.AA22867@nps-cs.arpa> To: info-iris@BRL.ARPA Subject: Lighting and Shading Hints for the 4D... Chapter 14 of the IRIS User's Guide on the IRIS 4D describes the lighting and shading software available on that system. It is a pretty terse but not bad description of that software and the only thing missing is a working sample program. I requested over the net if anyone had a sample they could send me and got no replies. I called a few friends at SGI and eventually got some sample programs. There is one subtlety that is easily missed. The lighting software runs in RGB mode. On the IRIS 4D/70G, one can run this mode in a double-buffered, z-buffered fashion. If you do this, the software splits the available bit planes so that you only have 12 bits for color specification. This is important to remember when you turn on the lighting and shading software. If you put in a local viewer or a local light source and use double-buffered RGB, you get a serious banding effect on the filled polygons. It looks like you are doing something wrong with the lighting software. The fix to this came to me upon examination of the IRIS 4D samples sent me by people at SGI. All of the samples had a menu option to freeze the picture, i.e. put the system into singlebuffer mode and then redraw the picture with the lighting routines on. The pictures generated this way lose their banding. Another hint is that you may need to set the normal vector for every square of your underlying checkerboard and not just once at the top of your checkerboard generation loop. If you have an infinite light source and an infinite viewer and only set the normal once, you get a single colored checkerboard. Michael Zyda Naval Postgraduate School ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa24127; 16 Mar 88 18:13 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa23606; 16 Mar 88 17:52 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa23565; 16 Mar 88 17:43 EST Received: from ucsd.edu by SMOKE.BRL.ARPA id aa21107; 16 Mar 88 17:31 EST Received: from chem.ucsd.edu by ucsd.edu (5.58/UCSD-1.0) id AA28710 for info-iris@brl.arpa; Wed, 16 Mar 88 12:45:42 PST Received: by chem.chem.ucsd.edu (5.51) id AA13998; Wed, 16 Mar 88 12:44:27 PST Date: Wed, 16 Mar 88 12:44:27 PST From: Steve Dempsey Message-Id: <8803162044.AA13998@chem.chem.ucsd.edu> To: info-iris@BRL.ARPA Subject: 4D 1/4" Tape drive bug Machine: 4D/70g with SCSI cartridge tape drive Problem: Tar times out too quickly while waiting for tape drive to rewind Repeat by: Write enough data on the tape so that it takes ~45 seconds to rewind, then issue the command: tar c data; tar t As soon as the first tar command finishes, the tape begins rewinding, and the second tar starts running. The second tar has to wait for the tape to finish rewinding, but it seems to give up after ~30 seconds with the message: tar: cannot open /dev/tape ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa27776; 17 Mar 88 2:57 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa27738; 17 Mar 88 2:47 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa27681; 17 Mar 88 2:39 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa09251; 17 Mar 88 2:30 EST Received: from FORD-WDL1.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Wed, 16 Mar 88 16:23:34 PST Received: by FORD-WDL1.ARPA (5.51/5.9) id AA12751; Wed, 16 Mar 88 16:25:32 PST Date: Wed, 16 Mar 88 16:25:32 PST From: Rion Cassidy Message-Id: <8803170025.AA12751@FORD-WDL1.ARPA> To: info-iris@sumex-aim.stanford.EDU Subject: reliability questions I want to get some feedback from those of you have had significant experience with SGI equipment. From our experiences either SGI hardware is very low quality or we have a lemon. It is important for us to know which because we have to make a decision regarding the purchase of a new machine soon. I will explain; you judge for yourself. I am not trying to run down SGI, just explain the facts. Our IRIS 3120 was originally purchased in November 1986. In July 1987 we started having intermittent RAM parity problems. This is the sort of problem that stops the IRIS dead in its tracks and frequently can ruin files. The SGI tech came out six different times, each time saying, "we're pretty sure it's fixed *this* time." Finally, after some angry phone calls, the sixth visit (in October) seemed to do the trick. Perhaps we had an elusive, unusual problem that no one else could've solved any faster. In January we started getting error messages about track errors on the disk. These seemed pretty innocous at first since no real harm was being done. First the tech came out and made some disk configuration changes and rebooted the system. That seemed to work for a couple of weeks until the same error message started popping up again. The decision then was to reformat the disk, eliminating the spurious bad sector messages. Trouble here was that my backup of the system apparently was not successful; tar got conflicting file sizes on many files. We didn't realize this until the disk had been reformatted and we were trying to restore everything. The backup tape was trash, a month's work was lost. The IRIS only worked for a while after that. In February we were getting occasional error messages about the fbc and font ram (I never did figure out what that meant!). We reported this but before they had a chance to attempt a fix, the disk went completely south. There were continous I/O error messages and it wouldn't reboot. So now they had to give us a new disk. This problem cost a week of access time and lost work. The gotcha on the repair was that the new disk would only run under SGI's system release 3.6 (new model, not previously supported I imagine). Our backup was an entire dump of the disk. The new disk had just release 3.6, no user files, and doing a complete restoration would wipe out the new operating system without which we couldn't use the disk. So we had to do a file by file restore in some cases (we were foolish enough to have used SGI's 'backup' program which splits directories between tape cartridges). It seems to be OK now. Occasionally when I put a tape in the drive and attempt a tar command the system locks up. Drive light off, no response on the console. Should I call in on this too? We've got Sun workstations all over the place and they don't seem to have anywhere near as many hardware problems. In our estimation, the total of system down time and lost work comes to about 10%. When it comes in large chunks during critical development periods it seems a lot worse. My question: have other SGI users had problems with this frequency? Or do we just have a lemon? Are repeated visits for the same problem normal in the world of hardware maintenance? Any feedback would be appreciated. If there is sufficient and interesting responses, I will post a summary. P.S. I solved the problem with kermit crashing (discussed in a previous posting). It has to be installed in /bin *and* /usr/bin or else it will crash when a send is attempted. Rion Cassidy Ford Aerospace rion@ford-wdl1.arpa ...{sgi,sun,ucbvax}!wdl1!rion Disclaimer: The above is solely the opinion of the author. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa27956; 17 Mar 88 3:19 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa27843; 17 Mar 88 3:09 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa27835; 17 Mar 88 3:07 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa09500; 17 Mar 88 2:33 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 16 Mar 88 19:07:08 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA03857; Wed, 16 Mar 88 17:36:33 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Mar 88 16:06:32 GMT From: "William C. Anderson" Organization: The University of Texas at Austin, Austin, Texas Subject: Re: Mouse driven rotations Message-Id: <1227@ut-emx.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Interestingly, almost all workstation manufacturers have settled on the optical mouse design originated by Mouse Systems, Inc. This mouse is interesting in that it has *two* LED/phototransistor "eyes" in its bottom. Although usually only one eye is turned on (this is sufficient to report relative position), both eyes can be enabled and will report on their respective relative positions. This is sufficient information to generate (small) rotations. I wrote just such a driver for a Sun 1 workstation (serial number 91 - my age is showing) and a simple program to test the human factors related to the idea that by rotating and translating the *mouse*, an object on the screen would likewise rotate and translate. It was a very intuitive interface, in my humble opinion. Those readers schooled in geometrical matters will realize the limitations of the mouse in reporting the rotation. Whereas the information which you need to generate accurate rotations is sin(theta) or cosine(theta), the two eyes in fact generated information related to tangent(theta). Therefore the rotation information became difficult to deal with as theta -> pi/2, or tangent(theta) -> +infinity. Still, with a "reset rotation" command/switch and by rotating in small increments, the user interface seemed to me to be unusually transparent. I have never seen this implemented elsewhere. William Anderson - University of Texas Computation Center - wca@emx.utexas.edu Disclaimer: No connection with Mouse Systems Inc. or Sun Microsystems Inc., except as a satisfied user of their equipment. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa29392; 17 Mar 88 8:02 EST Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa29226; 17 Mar 88 7:51 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa29167; 17 Mar 88 7:46 EST Received: from cunyvm.cuny.edu by SMOKE.BRL.ARPA id aa18685; 17 Mar 88 7:35 EST Received: from DKAUNI11.BITNET by CUNYVM.CUNY.EDU ; Thu, 17 Mar 88 07:34:21 EST Received: from DKAUNI46.BITNET (CD05) by DKAUNI11.BITNET (Mailer X1.25) with BSMTP id 1570; Thu, 17 Mar 88 13:26:14 MEZ Date: 03/17/88 13:28:10 CET From: CD05%DKAUNI46.BITNET@CUNYVM.CUNY.EDU To: INFO-IRIS@BRL.ARPA Subject: SGI Message-ID: <8803170736.aa18685@SMOKE.BRL.ARPA> Reliability of SGI and MIPS hardware and software: We have purchased an IRIS-4D/60 (the one with the single-board) in November, 1987. In fact there were some hardware-problems: - one (of three) 4-Mbyte memory-bank on the main-board, - one (of two) 380-Mbyte disk-drive and - the buttons-and-dials-box did not work properly in the beginning. The memory problem was fixed by the tech in the second attempt one week after the first installation. With the disk and the buttons we had to wait until replacement arrived from USA, and the machine was working with it's desired hardware configuration in January, 1988. I know that similar problems occured in other IRIS-4D-installations in Germany. However, I cannot complain about local service here. There were no problems to get reactions from SGI. They always invested much personal power to solve our problems, e.g. they came along with a spare machine and tried to replace parts of the hardware-equipment to locate our bugs. Concerning the software there are some (minor?) problems too: - MIPS-FORTRAN does not work properly with the optimization features. - AT&T UNIX (V.3) seems to have some problems on the IRIS-4D (cron crashes sometimes). - the UNIX-kernel (probably by SGI?) locks on interactive requests some- times, while background-processes continue operating. The system has to be rebooted, to wake up the machine. - SGI-graphics sometimes dies and the graphics-console cannot be used, while interactive usage on the attached ascci-terminals (three) is still possible. The system has to be rebooted, to allow usage of graphics again. - in the documentation there are references to tools which are not available. We were told from our local-dealer, that most of these bugs are fixed in the next software update (announced for March or April). None the less the IRIS is an excellent and powerful machine and we like to work with it. Stefan (from Theoretical Chemistry, University of Karlsruhe, Germany) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa29555; 17 Mar 88 8:13 EST Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id ab29226; 17 Mar 88 7:51 EST Received: from GELAC.ARPA by VMB.BRL.ARPA id aa29212; 17 Mar 88 7:49 EST Received: by gelac.arpa (4.12/25) id AA20716; Thu, 17 Mar 88 07:47:57 est Message-Id: <8803171247.AA20716@gelac.arpa> To: info-iris@BRL-VMB.arpa Date: Thu, 17 Mar 88 7:47:55 GMT+4520891:44 From: gelac!bwebb@gelac.arpa (Mr. Barry W. Webb) Subject: Re: reliablility questions X-Mailer: msg [version 3.2] In response to Rion Cassidy's problems: We have 8 IRISes (a mixture of 2400, 2400T, 3020, 3120, 3130) and have experienced very little down time due to the type problems he is experiencing. Only once have we had disk drive problems (also on a 3120) where we continually reformatted and rebuilt the system in an attempt to solve the problem. The final solution was a new disk controller, not a new drive. About 8 months ago we did experience a rash of problems across several machines. When the smoke cleared, we decided to leave the machines running all the time instead of powering them down each night. This seems to help MTBF significantly. Other than that, we haven't experienced the problems with the hardware he has. Barry Webb Lockheed Aeronautical Systems Company - Georgia bwebb@gelac.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03064; 17 Mar 88 14:05 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa02664; 17 Mar 88 13:54 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa02619; 17 Mar 88 13:48 EST Received: from NPS-CS.ARPA by SMOKE.BRL.ARPA id aa13238; 17 Mar 88 13:34 EST Received: by nps-cs.arpa (5.51/1.26) id AA12115; Thu, 17 Mar 88 10:34:22 PST Date: Thu, 17 Mar 88 10:34:22 PST From: michael zyda Message-Id: <8803171834.AA12115@nps-cs.arpa> To: info-iris@BRL.ARPA Subject: iris reliability... I have had IRISes continuously since Oct 1984. I have also had a lot of other manufacturers' graphics systems. Hardware-wise, the IRIS has been about as reliable as the other systems. We did find that the IRIS-2400, IRIS-2400 Turbo and IRIS-3120 systems do require air conditioning and a clean room. We used to run them in an office environment and had a down on 1 system per month (with 3 systems in the room). We moved them to the air conditioned room and they have been up with only one down in the year since. Our 4D/70G was turned on at New Years and has had no hardware problems (knock on wood). We put our old buttons and dials on the system after making the right cable and table entries. Most everything works fine. There are obvious software problems that will probably be fixed in the next release. Such problems are typical of leading edge graphics hardware. The IRIS-3120 is relatively mature compared to the 4D and most problems have been worked out. People with "work to get done" will be very impatient with the 4D. People with leading edge things to try out will have fun with the 4D. A year from now, you can expect the 4D to be "better/more reliable". But at that time, there will be a newer, faster, better piece of graphics hardware. It will also require patience. Our mode of operation: air conditioned and clean room for the IRISes and full maintenance. Volumes of patience and lots of fun. Michael Zyda ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa11802; 18 Mar 88 9:20 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11683; 18 Mar 88 9:09 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa11570; 18 Mar 88 8:58 EST Received: from NPS-CS.ARPA by SMOKE.BRL.ARPA id aa01550; 18 Mar 88 8:29 EST Received: by nps-cs.arpa (5.51/1.26) id AA19800; Thu, 17 Mar 88 22:04:50 PST Date: Thu, 17 Mar 88 22:04:50 PST From: michael zyda Message-Id: <8803180604.AA19800@nps-cs.arpa> To: info-iris@BRL.ARPA Subject: experience with real-time RGB to NTSC converters... We are looking for a converter that takes RGB from the IRIS and turns it into NTSC in real-time. We are particularly interested in systems that take the full resolution of the IRIS and perform an averaging of some sort down to the smaller NTSC size. We had a demo here of the Folsom Research Imaging system (around $16K) and its not bad. The Lyon & Lamb system takes 1/10th of a second and doesn't work in real-time (I then need a single step videotape capability). What other systems are people out there using? Michael Zyda Naval Postgraduate School (408) 646-2305 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12627; 18 Mar 88 10:25 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa12538; 18 Mar 88 10:14 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa12408; 18 Mar 88 10:05 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa05374; 18 Mar 88 9:27 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Fri, 18 Mar 88 06:27:14 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA13274; Fri, 18 Mar 88 03:03:56 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 17 Mar 88 22:27:12 GMT From: Thomas Palmer Organization: NCI Supercomputer Center, Frederick, MD Subject: Video output reconfiguration on an Iris 4D/60T? Message-Id: <361@ncifcrf.ncifcrf.gov> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Is there any way to reconfigure (in software) the video output timing signals from an Iris 4D/60T? In particular, I'd like to be able to produce a 640 by 484 interlaced timed (not encoded) signal (RS-170-A). Thanks. -Tom Thomas C. Palmer NCI Supercomputer Facility c/o PRI, Inc. Phone: (301) 698-5797 PO Box B, Bldg. 430 Uucp: ...!uunet!ncifcrf.gov!palmer Frederick, MD 21701 Arpanet: palmer@ncifcrf.gov ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13038; 18 Mar 88 10:56 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11279; 18 Mar 88 8:36 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa11202; 18 Mar 88 8:24 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa00193; 18 Mar 88 8:14 EST Received: Fri, 18 Mar 88 07:56:53 EST by aero4.larc.nasa.gov (5.15/5.6) Date: Fri, 18 Mar 88 07:56:53 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8803181256.AA21559@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: Mouse driven rotations Our IRIS 3030 uses both LED's, one for left/right (x) translation and the second for up/down (y) translation. In the software I wrote I used the mouse buttons to determine whether the mouse was being used for translation, rotation, or something else. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15683; 18 Mar 88 13:56 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15344; 18 Mar 88 13:46 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15189; 18 Mar 88 13:35 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa17078; 18 Mar 88 13:08 EST Received: from FORD-WDL1.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Fri, 18 Mar 88 10:07:37 PST Received: by FORD-WDL1.ARPA (5.51/5.9) id AA23996; Fri, 18 Mar 88 08:41:09 PST Date: Fri, 18 Mar 88 08:41:09 PST From: Rion Cassidy Message-Id: <8803181641.AA23996@FORD-WDL1.ARPA> To: info-iris@sumex-aim.stanford.EDU Subject: repeated info-iris stuff A while back someone posted the question of whether others were getting duplicate mailings from info-iris. At the time I wasn't, so I wrote to him saying "it seems to be working fine for me!" Not so anymore. This morning I got two messages from info-iris that I got yesterday, plus a second copy of the article that I posted myself; I *know* I only posted it once! Last week I sent someone a minor flame because I'd seen their posting three different times. I assumed that the guy kept forgetting that he'd already posted it. I feel a little foolish now becuase I believe that it was the info-iris mailer that did it, not him. Will someone please look into this? I really didn't intend for all the ino-iris subscribers to see this, but I don't know how else to communicate with the info-iris administrator. Rion Cassidy Ford Aerospace rion@ford-wdl1.arpa ...{sgi,sun,ucbvax}!wdl1!rion Disk Claimer: My employer forced me to write this at gun-point. I assume no responsibility whatsoever for what I've said here. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03102; 21 Mar 88 8:20 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa01995; 21 Mar 88 6:23 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa01948; 21 Mar 88 6:14 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa05984; 21 Mar 88 5:53 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sun, 20 Mar 88 08:50:38 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA28335; Sat, 19 Mar 88 20:18:45 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Mar 88 16:45:13 GMT From: Mike York Organization: Voodoo Graphics Project Subject: Re: ref. Rion Cassidy & kermit Message-Id: <452@voodoo.UUCP> References: <8803111244.AA24175@aero4.larc.nasa.gov> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <8803111244.AA24175@aero4.larc.nasa.gov> blbates@AERO4.LARC.NASA.GOV (Bates TAD/HRNAB ms294 x2601) writes: > > If you want any action from SGI you have to keep at them constantly, more >than once a day, until they get tired of hearing from you. That seems to >be the ONLY way to get ANY positive action out of them. They get tired of >hearing from you and they will do anything to stop hearing your complaining. >Voice of experience. I have to disagree with this. While we have encountered a few problems with the Hotline support, we have, in general, found the Hotline people to be very competent and very responsive to our needs. In fact, the only problem that we've had that hasn't been resolved is a problem with the C compiler on our 4D/60's. This is supposed to fixed in the next release, due RSN (we do have a work around). From our point of view, the Hotline people are doing a great job. -- Mike York Boeing Computer Services, Renton, Washington (206) 656-7724 uw-beaver!ssc-vax!voodoo!zombie ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15486; 21 Mar 88 21:34 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15322; 21 Mar 88 21:23 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15276; 21 Mar 88 21:15 EST Received: from [128.228.1.2] by SMOKE.BRL.ARPA id aa02678; 21 Mar 88 21:12 EST Received: from DKAUNI11.BITNET by CUNYVM.CUNY.EDU ; Mon, 21 Mar 88 10:37:49 EST Received: from DKAUNI46.BITNET (CD05) by DKAUNI11.BITNET (Mailer X1.25) with BSMTP id 0073; Mon, 21 Mar 88 12:41:16 MEZ Date: 03/21/88 10:40:48 CET From: CD05%DKAUNI46.BITNET@CUNYVM.CUNY.EDU To: INFO-IRIS@BRL.ARPA Subject: MOLECULAR Message-ID: <8803212113.aa02678@SMOKE.BRL.ARPA> Is there anybody using MM2 or MMP2 ? I am seeking for additional atom- parameters, which are not in the standard package. If you have any more parameters please reply directly. Stefan Brode ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa07736; 23 Mar 88 14:46 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa05089; 23 Mar 88 12:18 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa04861; 23 Mar 88 12:00 EST Date: Wed, 23 Mar 88 11:45:41 EST From: "Mr. T.K. Wood, ATZH-CDC, USA Sigcen" To: info-iris@BRL.ARPA cc: sigcen@BRL.ARPA Subject: Soft PC MS-DOS Emulation Software Message-ID: <8803231145.aa11932@SMOKE.BRL.ARPA> Iris Users - I noticed in Federal Computer Week (March 21, p. 36) that SGI will sell SoftPC as an option with the 4-D series. SoftPC is an MS-DOS emulation package that is sold as an OEM item to workstation producers. (SoftPC versions are under development for MacIntosh II - both A/UX and Multifinder environments). I would like to know if Silicon Graphics plans to release a version of SoftPC for its other computers, e.g. IRIS 3020. Any answers would be appreciated. Thanks. (Mr.) Tracy Wood Operations Research Analyst U.S. Army Signal Center ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa12727; 23 Mar 88 17:22 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa05535; 23 Mar 88 13:01 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa05442; 23 Mar 88 12:51 EST Received: from [128.218.1.1] by SMOKE.BRL.ARPA id aa13007; 23 Mar 88 12:37 EST Received: by cgl.ucsf.edu (5.54/GSC4.5) id AA06780; Wed, 23 Mar 88 09:33:30 PST Date: Wed, 23 Mar 88 09:33:30 PST From: David Spellmeyer Message-Id: <8803231733.AA06780@cgl.ucsf.edu> To: info-iris@BRL.ARPA Subject: mm2 info Sir, I am not presently using MM2, but have had extensive experience with it as a graduate student at UCLA. What sort of parameters are you specifically looking for? I might be able to guide you in the correct direction. David Spellmeyer (415)476-5326 spell@cgl.ucsf.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05473; 25 Mar 88 1:32 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa04851; 24 Mar 88 22:30 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa04827; 24 Mar 88 22:20 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa23167; 24 Mar 88 22:15 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 24 Mar 88 19:16:35 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA15336; Thu, 24 Mar 88 15:10:21 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Mar 88 13:32:53 GMT From: Mark Bartelt Organization: Hospital for Sick Children, Toronto Subject: Status of CASPAR and/or Molecular Architects Corporation Message-Id: <96@sickkids.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU SGI's 1987 Geometry Partners Directory lists a company in Sausalito named Molecular Architects Corporation. It sold a product called CASPAR, a set of programs that could be used to predict protein structural features from primary sequence information. This company seems to have gone out of business. A few questions ... First, has it in fact disappeared, or have they simply moved? Does anyone know for certain one way or the other? Second, if the company is defunct, has any other company acquired rights to the software? I.e. who, if anyone, is selling and/or supporting it? Third, does anybody have any experience with the package, good/bad/etc.? If the software isn't any good, the first two questions are, of course, irrelevant. Thanks in advance for any help. Mark Bartelt Hospital for Sick Children, Toronto 416/598-6442 UUCP: {utzoo,decvax,ihnp4}!sickkids!mark BITNET: mark@sickkids.utoronto ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05664; 25 Mar 88 2:24 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa05270; 25 Mar 88 0:50 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa05243; 25 Mar 88 0:38 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa24797; 25 Mar 88 0:33 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 24 Mar 88 21:35:00 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA19950; Thu, 24 Mar 88 19:55:12 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Mar 88 15:24:52 GMT From: Rasesh Trivedi Organization: Boston U., Center for Adaptive Systems Subject: GNU Emacs on Iris 3130(GL-W 3.5) Message-Id: <575220292.26702@bucasb.bu.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU I have strange problem with puttign up GNU Emacs version 18.50 on Iris 3130(GL-W 3.5 version). While compiling emacs with "-g" option for debugging purpose, created executable "emacs" works fine. But trying to compile with "-O" option does compile and give "emacs" executable file, which dumps the core. Did any one have any problem like this? I tried this with older version of GNU Emacs 18.47 and gave the same results as above. Comments are welcome. Thanks. -Rasesh Trivedi Center for Adaptive Systems Boston University "rasesh@bucasb.bu.edu" ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa03247; 25 Mar 88 16:02 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa01477; 25 Mar 88 14:18 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa01383; 25 Mar 88 14:02 EST Received: from SGI.COM by SMOKE.BRL.ARPA id aa09682; 25 Mar 88 13:53 EST Received: from elvin.SGI.COM by sgi.sgi.com (5.52/880301.vjs) (for info-iris@brl.arpa) id AA05948; Fri, 18 Mar 88 13:42:45 PST Received: by elvin (5.51/880301.vjs) (for dietrich@sgi.SGI.COM) id AA23791; Fri, 18 Mar 88 13:42:16 PST From: Frank Dietrich Message-Id: <8803182142.AA23791@elvin> Date: 18 Mar 1988 1342-PST (Friday) To: info-iris@BRL.ARPA Cc: dietrich@SGI.COM Subject: New Iris Universe out Fresh from the press we got a new issue of the Iris Universe Magazine. This issue contains: Recipe to create random fractals On CG education A method to shade single-sided polygons A visual supercomputing environment Info on thermal color copies, Mac-Iris connection, and more. Several programs are discussed that will be available in the "Software Exchange": Slidemaker ICARE-interactive color editor OPER-job control In a separate mailing I will ask for your suggestions on how to organize the Software Exchange within the Iris community. Thank you for your contributions to the Iris Universe. You are invited to participate in the SIGGRAPH edition. Frank (415) 392-3348 ------- End of Forwarded Message ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa00588; 26 Mar 88 1:23 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00432; 26 Mar 88 1:12 EST Received: from brl-spark.arpa by VMB.BRL.ARPA id aa00178; 26 Mar 88 1:00 EST Date: Fri, 25 Mar 88 17:03:45 EST From: Phil Dykstra To: info-iris@BRL.ARPA Subject: X Window System Message-ID: <8803251703.aa07160@SPARK.BRL.ARPA> Does anyone have an X Window System server for either the 3d (oops, 3030) or 4d? Does SGI plan to provide one at some point? - Phil ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05721; 27 Mar 88 19:05 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa05553; 27 Mar 88 18:13 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id ab05536; 27 Mar 88 18:07 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa07592; 27 Mar 88 17:56 EST Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sun, 27 Mar 88 14:58:02 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA13345; Sun, 27 Mar 88 03:25:03 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Mar 88 02:53:00 GMT From: Rodian Paul Organization: The Big Electric Cat, NYC, NY Subject: mail help Message-Id: <3571@dasys1.UUCP> Sender: info-iris-request@SUMEX-AIM.Stanford.EDU To: info-iris@SUMEX-AIM.Stanford.EDU Machine: 4D/70 Version: 2.0 Can anyone explain to a systems novice, why there is both a /bin/mail and a /usr/sbin/mail? I've allready just set up a symbolic link: ln -s /usr/sbin/Mail /usr/sbin/mail what gives with /bin/mail? Also when I try to run 'calendar' with args I get a message somewhat like: /usr/bin/calendar cannot execute /usr/lib/calnames ? I cannot find any reference to /usr/lib/calnames in either the on-line manual or the printed. The documentation also makes reference to calendar using mail. How is this done? Cheers. -- Rodian Paul Big Electric Cat Public UNIX ..!cmcl2!phri!dasys1!rpaul ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa06319; 27 Mar 88 22:45 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa06162; 27 Mar 88 21:32 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa06120; 27 Mar 88 21:23 EST Received: from orville.nas.nasa.gov by SMOKE.BRL.ARPA id aa09183; 27 Mar 88 21:16 EST Received: Sun, 27 Mar 88 18:15:06 PST by orville.nas.nasa.gov (5.54/1.2) Message-Id: <8803280215.AA27018@orville.nas.nasa.gov> To: Phil Dykstra Cc: info-iris@BRL.ARPA Subject: Re: X Window System In-Reply-To: Your message of Fri, 25 Mar 88 17:03:45 EST. <8803251703.aa07160@SPARK.BRL.ARPA> Date: 27 Mar 88 18:15:03 PST (Sun) From: creon@orville.nas.nasa.GOV Silicon graphics new window system (called 4sight, I believe) is being shipped now with its beta-test 4DGT machines. It is based on news and works pretty well, even in pre-release. It supports regular news. It also supports mex windows (more correctly "GL windows") and they work, though there are a few minor incompatibilities. (we have a 4DGT running 4sight). 4sight also supports X version 11, though I have not used it. All the X and news routines are in the new 4DGT graphics manual, so I presume they exist. I have only been porting mex based applications so far, and hence have not used them. 4sight is being released for the whole 4D family, in release 3 (I believe) of the SGI operating system for the 4D60 and 4D70, so they should also have news and X any day now. As for the 3000s, I know that some version of 4sight has been runnning in house at SGI on the 3000 family for some time now, and they told us, at a meeting with all their big shots present (Clark, McCracken, Chesson, Baskett) that they would release it. I hope they meant it. The alpha releases we have been using are buggy, of course, but the bugs have been cleaned up at rapid rate even in these (pre-) releases. The official (beta) release looks like it should be quite usable, given the rate of cleanup of bugs in the alpha versions. I should point out that it is quite a job that they have done (NeWs + X + GL windows), making available the full power of the hardware (through GL windows at least). The performance is, naturally, much higer performance than I have seen on any SUN, even on the bitmap-oriented stuff (at least on ther GT). Also, I have heard, many of the bugs in 4sight are bugs in the (licensed) SUN code, and just like NFS, sgi is realizing that they must rewrite most of what they licensed. I believe they showed the product at NCGA, though I was not there. Creon Levit MS 258-5 NASA Ames Research Center Moffett Field, California 94035 (415)-694-4403 creon@orville.nas.nasa.gov (internet) ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa08578; 28 Mar 88 8:55 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa07796; 28 Mar 88 8:03 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa07769; 28 Mar 88 7:52 EST Received: from aero4.larc.nasa.gov by SMOKE.BRL.ARPA id aa12780; 28 Mar 88 7:44 EST Received: Mon, 28 Mar 88 07:36:18 EST by aero4.larc.nasa.gov (5.15/5.6) Date: Mon, 28 Mar 88 07:36:18 EST From: Bates TAD/HRNAB ms294 x2601 Message-Id: <8803281236.AA14896@aero4.larc.nasa.gov> To: info-iris@BRL.ARPA Subject: Iris Universe How does one get a copy of Iris Universe? ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13186; 28 Mar 88 14:35 EST Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id ab12623; 28 Mar 88 14:24 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa12520; 28 Mar 88 14:19 EST Received: from SGI.COM by SMOKE.BRL.ARPA id aa24373; 28 Mar 88 14:09 EST Received: from elvin.SGI.COM by sgi.sgi.com (5.52/880301.vjs) (for info-iris@brl.arpa) id AA00992; Mon, 28 Mar 88 11:09:29 PST Received: by elvin (5.51/880301.vjs) (for info-iris@BRL.ARPA) id AA11439; Mon, 28 Mar 88 11:08:19 PST From: Frank Dietrich Message-Id: <8803281908.AA11439@elvin> Date: 28 Mar 1988 1108-PST (Monday) To: Bates TAD/HRNAB ms294 x2601 Cc: info-iris@BRL.ARPA Subject: Re: Iris Universe In-Reply-To: Your message of Mon, 28 Mar 88 07:36:18 EST. <8803281236.AA14896@aero4.larc.nasa.gov> Subscription to the Iris Universe is free for users of SGI workstations. You need to provide us with your address. Deadline for the Siggraph issue is: June 1, 1988. Please share your information and images with us. Frank Dietrich, editor Silicon Graphics, Inc. 2011 Shoreline Blvd. Mountain View, CA 94043 (415) 962-3348 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15394; 28 Mar 88 18:48 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15371; 28 Mar 88 18:37 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15357; 28 Mar 88 18:31 EST Received: from ucsd.edu by SMOKE.BRL.ARPA id aa01218; 28 Mar 88 18:24 EST Received: from chem.ucsd.edu by ucsd.edu (5.58/UCSD-1.0) id AA09554 for info-iris@BRL.ARPA; Mon, 28 Mar 88 15:25:47 PST Received: by chem.chem.ucsd.edu (5.51) id AA24696; Mon, 28 Mar 88 15:24:27 PST Date: Mon, 28 Mar 88 15:24:27 PST From: Steve Dempsey Message-Id: <8803282324.AA24696@chem.chem.ucsd.edu> To: info-iris@BRL.ARPA Subject: Z buffering on the 4D I have just discovered that the "zclear()" function only affects the portion of the z-buffer defined by the current viewport. Thus it behaves analogously to "clear()". The manual entry is ambiguous on this point. It states: zclear loads the z-buffer with the largest possible positive integer. I originally made the assumption that zclear affected the entire z-buffer, resulting in some entertaining, but frustrating images. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15942; 28 Mar 88 20:45 EST Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15803; 28 Mar 88 20:34 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15770; 28 Mar 88 20:28 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa01971; 28 Mar 88 20:20 EST Received: from FORD-WDL1.ARPA by SUMEX-AIM.Stanford.EDU with TCP; Mon, 28 Mar 88 17:19:36 PST Received: by FORD-WDL1.ARPA (5.51/5.9) id AA11992; Mon, 28 Mar 88 14:28:16 PST Date: Mon, 28 Mar 88 14:28:16 PST From: Rion Cassidy Message-Id: <8803282228.AA11992@FORD-WDL1.ARPA> To: info-iris@sumex-aim.stanford.EDU Subject: reliability ques responses After waiting about two weeks for people to respond, I have now summarized the responses to my 'reliability questions' posting. Out of all the (who knows how many?) Iris users there are on the info-iris system, I recieved 12 responses, one of which was from a SGI technician. I've categorized and tallied the responses as follows: "you've got a lemon -- our Iris(s) has had excellent 2 reliability" "your story sounds familiar -- we've had similar problems" 4 "SGI is putting out leading-edge high-performance workstations 1 and you can't expect the best in reliability" "we've had hardware problems, but not as bad as yours, and 4 would like to take this opportunity to complain about software bugs and poor documentation" "I'm an SGI tech and would like to make a few comments" 1 My favorite quote: "We have two Iris workstations here, a 3020 and a 3030. In my opinion, the worst decision we every made was to buy one of these things. The best decision we ever made was to buy two of them, as we now have enough parts to keep one of them running." Comments from the SGI tech: "Switching the system off without executing reboot could have caused damage to the disk and subsequent problems with getting that disk to work again. ...in every case in which a customer complained to me about frequent problems with his disk drive, I have discovered that he (or she) was NOT using the reboot command (they just hit the power switch)." "It seems that the tape drive on many 3000 series products is not properly grounded. We have devised a method of grounding a tape when it is inserted. You should ask your FE for the grounding clip for your tape drive. Electrostatic discharge from a tape inserted in the tape drive is almost always the cause of the type of system lockups you describe. (By the way, until the clip is installed, touch your tape to the cabinet before inserting it.)" "I hope you will keep in mind that the nature of humans is to speak up when things are wrong and to keep quiet when things are going well - so your survey may be a little skewed to those with problems with their IRIS'." I have to agree with this last comment. I will refrain from making *any* conclusions; the number of responses is very small, and, I'm afraid, not indicative of anything. Another problem is that some people obviously have a single machine, some have dozens, while others did not specify. This makes it hard to do any meaningful statistics. I have also purposely avoided naming the respondents. Rion Cassidy Ford Aerospace rion@ford-wdl1.arpa ...{sgi,sun,ucbvax}!wdl1!rion Disclaimer: My employer forced me to write this at gun-point. I assume no responsibility whatsoever for what I've said here. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17720; 29 Mar 88 5:55 EST Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa17351; 29 Mar 88 3:39 EST Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa17339; 29 Mar 88 3:29 EST Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa05310; 29 Mar 88 3:24 EST Received: from ucbvax.berkeley.edu by SUMEX-AIM.Stanford.EDU with TCP; Tue, 29 Mar 88 00:25:25 PST Received: by ucbvax.berkeley.edu (5.59/1.26) id AA12326; Mon, 28 Mar 88 14:56:52 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Mar 88 20:31:21 GMT From: Ralph Hyre Organization: Carnegie-Mellon University, CS/RI Subject: Re: X Window System Message-Id: <1244@PT.CS.CMU.EDU> References: <8803251703.aa07160@SPARK.BRL.ARPA>, <8803280215.AA27018@orville.nas.nasa.gov> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU What about for the 'older' machines, like a 2400T. Any chance of an X11 for them? -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19894; 4 Apr 88 3:30 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa19667; 4 Apr 88 2:28 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa19659; 4 Apr 88 2:16 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa03679; 4 Apr 88 2:11 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Sun, 3 Apr 88 23:11:56 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.26) id AA16812; Thu, 31 Mar 88 15:49:44 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 31 Mar 88 13:52:13 GMT From: "Michael L. Johnson" Organization: School of Medicine, University of Va. Subject: BASIC? on 4D/70 Message-Id: <243@dale.acc.virginia.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU These are going to sound like very silly questions but we are new in the SG world so I figured I would ask. Does anyone know how to get a BASIC compiler/interpreter for a 4D/70. We have one user with a lot of BASIC code which he wants to run. How about a BASIC translater to C, FORTRAN or ?? Has anyone installed an Exabyte tape drive on a 4D/70? If so, could you tell us how, did it work correctly, etc. Thank for the info. -- (804)-924-2496 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa29503; 4 Apr 88 20:28 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa29172; 4 Apr 88 19:25 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa29152; 4 Apr 88 19:18 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa27020; 4 Apr 88 19:08 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 4 Apr 88 16:09:02 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.26) id AA18414; Sun, 3 Apr 88 23:17:46 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Apr 88 20:18:51 GMT From: Mike Nemeth Organization: HCR Corporation, Toronto Subject: command line options for "cc" Message-Id: <3196@hcr.UUCP> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU can anyone out there give me the command line option for the "cc" command to make the driver "think" it should use another assembler instead of /bin/asm68k (or whatever)? does this make sense? no? okay, from the top... a friend of mine has an IRIS (lucky dog), a "baby" one (ie. 68010, 1 engine), and would like to know what the command sequence to "cc" is to 0) make the compiler generate 68020 code instead of 68010 code 1) use the 68020 assembler instead of the 68010 that's about as much i could glean from his demented ravings. i don't own an iris, but i do have access to the net, so does anyone out there have the answer? -- Mike Nemeth "etch out a future of your own design, ...utzoo!hcr!miken well tailored to your needs" - T. Dolby ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05557; 5 Apr 88 2:41 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa04794; 5 Apr 88 1:28 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa04787; 5 Apr 88 1:14 EDT Received: from SGI.COM by SMOKE.BRL.ARPA id aa00388; 5 Apr 88 1:04 EDT Received: from elvin.SGI.COM by sgi.sgi.com (5.52/880301.vjs) (for info-iris@brl.arpa) id AA10660; Mon, 4 Apr 88 21:04:57 PST Received: by elvin (5.51/880301.vjs) (for user@sgi.SGI.COM) id AA16297; Mon, 4 Apr 88 21:03:36 PST From: Frank Dietrich Message-Id: <8804050503.AA16297@elvin> Date: 4 Apr 1988 2103-PST (Monday) To: info-iris@BRL.ARPA Cc: user@SGI.COM Subject: Software Exchange IRIS Software Exchange: a proposal The IRIS Software Exchange is designed to make user developed software accessible within the IRIS User Community on a non-commercial basis. The entire spectrum of applications, including UNIX System V programs, special graphics algorithms, file conversion programs, editors, drivers, languages and experimental software is covered in the Software Exchange. Silicon Graphics will continue to make selected demo programs available as part of the Software Exchange. Silicon Graphics also provides assistance in distributing suitable software across a variety of channels. We are suggesting the following guidelines and welcome any feedback/input you may have. We encourage you to participate in the Software Exchange to increase the productivity of everyone in the IRIS User Community. a) Software submitted to the Software Exchange is generally copyrighted by the author and not in the public domain; software will be accepted only from the author, or from another party with the written permission of the author. b) No warranty of any kind is made in regard to the software, nor is any support provided for the software. c) The authors and SGI will cooperate to ensure that each program submitted contains the following: * source code * makefile * man page * one paragraph description * configuration specs d) SGI will publish and update a catalogue of software available in the Exchange. e) Several channels for distribution will be available: * the authors distribute directly (NASA, BRL,etc) * software in info-IRIS-Archives via FTP over the net * cartridge distribution by SGI at nominal fee * SGI established server accessable via modem f) A representative will be appointed by IRIS users to help organize the Software Exchange. Again, your feedback and help on this proposal are crucial. We are also interested in hearing from you about any software that you feel may be appropriate for inclusion in the IRIS Software Exchange. Best regards, Frank Dietrich Monica Schulze IRIS User Services Silicon Graphics Inc. 2011 Shoreline Blvd. Mountain View, CA 94043 (415) 962-3320 user@sgi.com ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa13170; 5 Apr 88 15:03 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa11166; 5 Apr 88 12:27 EDT Received: from GELAC.ARPA by VMB.BRL.ARPA id aa11164; 5 Apr 88 12:24 EDT Received: by gelac.arpa (4.12/25) id AA02104; Tue, 5 Apr 88 12:26:34 est Message-Id: <8804051726.AA02104@gelac.arpa> To: info-iris@brl-vmb.arpa Date: Tue, 5 Apr 88 12:26:32 GMT+4520891:44 From: gelac!bwebb@gelac.arpa (Mr. Barry W. Webb) Subject: Re: XDOS X-Mailer: msg [version 3.2] I just read a short blurb on XDOS in the latest UNIX REVIEW. It comes from Hunter Systems, Mountain View, CA (415)965-2400. I have no experience with it but the blurb says the executable binaries for the Intel 8086 are compiled by the XDOS compiler into non-8086 executable binaries for the target system. This compilation is performed only once on a PC program, then is installed on the target system, and run as if it were a UNIX program. Hunter Systems' offering is licensed to computer OEMs on a royalty basis, and has a suggested end-user price ranging from $425 to $2000. Barry Webb Lockheed Aeronautical Systems Company bwebb@gelac.arpa ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa14730; 5 Apr 88 18:02 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa13920; 5 Apr 88 16:07 EDT Received: from brl-tbd.arpa by VMB.BRL.ARPA id ab13781; 5 Apr 88 15:57 EDT Date: Tue, 5 Apr 88 15:54:51 EDT From: Glenn Randers-Pehrson (WMB) To: info-iris@BRL.ARPA Subject: 3.6 font Message-ID: <8804051554.aa03768@TBD.BRL.ARPA> I have just installed 3.6, and find that I prefer the font used by the 3.5 operating system. Can anyone tell me how to restore the old font (other than by going back to 3.5)? Also I found no improvement in floating point accuracy. READ(5,5)F 5 FORMAT(4.0) still yields 74.99999 when the input is " 75". But if the input is "75.0" then you get 75.00000. Both should yield the latter, in my opinion. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10443; 7 Apr 88 2:11 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa10083; 7 Apr 88 0:47 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa10050; 7 Apr 88 0:37 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa19729; 7 Apr 88 0:32 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 6 Apr 88 21:32:03 PDT Received: by ucbvax.berkeley.edu (5.59/1.26) id AA10545; Wed, 6 Apr 88 10:18:24 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 1 Apr 88 22:39:43 GMT From: Joe Szep Organization: Boston U. Comp. Sci. Subject: DISCOVER Visual Computing Message-Id: <21154@bu-cs.BU.EDU> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU Join Silicon Graphics and DISCOVER the power of visual computing. Visual computing shortens the distance between concept and reality. IRIS Superworkstations allow you to simulate real world phenomenon on a computer screen and interact with it in real time. Our mini trade shows will give you the opportunity to explore the possibilities of 3D graphics. Come and see the new high end Superworkstation from Silicon Graphics, the "IRIS GT". Experience the future of computer graphics technology - visual computing. The IRIS 4D/70 GT is a balance of computing power and graphics performance that supports real world applications: VLSI design, animation, manufacturing simulation, visual simulation, and general scientific. With RISC as their computing platform, third party experts will demonstrate what makes the IRIS unique. DATE LOCATION THEME(S) ---- -------- -------- April 18 Holiday Inn Industrial/Conceptual 300 Plaza Drive Design and Animation Secaucus, NJ (201) 348-2000 To Register: (201) 599-2172 April 20 Royce Carlin Visual Simulation 598 Broad Hollow and MCAE Melville, NY (516) 845-1000 To Register: (516) 424-9445 April 22 Philadelphia Airport Marriot Industrial/Conceptual 4509 Island Avenue Design and Animation Philadelphia, PA (215) 365-4150 To Register: (201) 599-2172 April 25 Holiday Inn - Rochester South Molecular Modeling, 1111 Jefferson Road MCAE, and Visual Rochester, NY Simulation (716) 475-1510 To Register: (617) 891-8100 April 27 Park Plaza Molecular Modeling, 155 Temple Street MCAE, and Visual New Haven, CT Simulation (203) 772-1700 To Register: (617) 891-8100 April 29 Days Inn, Burlington Molecular Modeling, Wheelen Road MCAE, and Visual Burlington, MA Simulation (617) 272-8800 To Register: (617) 891-8100 Please note: Please direct all inquires to the "To Register" phone numbers, not this account. Thank you. ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa19383; 8 Apr 88 15:19 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa18494; 8 Apr 88 14:06 EDT Received: from [128.196.6.1] by VMB.BRL.ARPA id aa18458; 8 Apr 88 13:54 EDT Received: by megaron.arizona.edu; Fri, 8 Apr 88 10:54:44 MST Received: by uazchem.SGI (5.15/5.6) id AA03668; Fri, 8 Apr 88 11:07:58 PST Date: Fri, 8 Apr 88 11:07:58 PST From: uazchem!dolata@arizona.edu (Dolata) Message-Id: <8804081907.AA03668@uazchem.SGI> To: arizona!info-iris%brl-vmb.arpa@arizona.edu Subject: FTP to VMS systems I have a 3130, 2400T, and a mVAX II running ULTRIX, and a mVAX II running VMS. (And a headache!) All of these machines are hanging on an ethernet, and all have FTP and TELNET. I can telnet between all of the machines. But I cannot FTP between all of them. The possible connections are; ULTRIX <-> IRIS (both) ULTRIX <-> VMS VMS -----> IRIS IRIS -//-> VMS When I try to 'open vms' on the IRIS's ftp, it gives me a "segmentation violation, core dumped" message. However, if I run ftp on the VMS system, and 'open iris1' or 'open iris2' it works well. Any hints, anecdotes, fixes ??? Dan ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa10670; 11 Apr 88 21:33 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa10358; 11 Apr 88 20:10 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa10333; 11 Apr 88 20:02 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa00510; 11 Apr 88 19:50 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 11 Apr 88 16:51:04 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA04652; Mon, 11 Apr 88 14:53:03 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Apr 88 19:48:37 GMT From: Rasesh Trivedi Organization: Center for Adaptive Systems, Boston U. Subject: Re: FTP to VMS systems Message-Id: <576791317.8201@bucasb.bu.edu> References: <8804081907.AA03668@uazchem.SGI> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <8804081907.AA03668@uazchem.SGI> dolata@uazchem.UUCP (Dolata) writes: > >I have a 3130, 2400T, and a mVAX II running ULTRIX, and a mVAX II running VMS. >(And a headache!) All of these machines are hanging on an ethernet, and all >have FTP and TELNET. I can telnet between all of the machines. But I >cannot FTP between all of them. The possible connections are; > > ULTRIX <-> IRIS (both) > ULTRIX <-> VMS > VMS -----> IRIS > IRIS -//-> VMS > >When I try to 'open vms' on the IRIS's ftp, it gives me a "segmentation >violation, core dumped" message. However, if I run ftp on the VMS >system, and 'open iris1' or 'open iris2' it works well. > >Any hints, anecdotes, fixes ??? >Dan Problem on Iris end implies something wrong on set up of your 3130 kernel. Make sure it has the proper protocol i.e. possibly TCP/IP. If it is XNS it has to be changed using "kernel xns" command. Other than this your "ifconfig" command line set up seems to be ok as you can telnet from vms. -rasesh ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa23140; 12 Apr 88 23:20 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa22823; 12 Apr 88 21:46 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa22806; 12 Apr 88 21:36 EDT Received: from RELAY.CS.NET by SMOKE.BRL.ARPA id aa12314; 12 Apr 88 21:24 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa27241; 12 Apr 88 20:17 EDT Received: from waterloo.edu by RELAY.CS.NET id ag01164; 12 Apr 88 20:04 EDT Received: by watmath; Tue, 12 Apr 88 16:57:07 EDT Date: Tue, 12 Apr 88 16:57:07 EDT From: Steve Hayman To: info-iris@BRL.ARPA Subject: Porting 4.3BSD dump/restor Message-ID: <8804122124.aa12314@SMOKE.BRL.ARPA> Hello list. We have just acquired some 3030's here at Waterloo, and "uname -k" tells me our version is "5.0+5.3+ (GL2-W3.5)", whatever that is. (Forgive me if I misuse some terminology, we're still new to these machines.) We already have a large number of Vaxen and Suns running 4.3BSD here and use scripts based on 4.3's "dump" and "restor" to back them up, and would like to back up our Irises in the same way if possible for simplicity. If anyone has ever ported over the 4.3 dump (and rdump), I'd like to hear from you before I start trying to do this myself. Thanks in advance. Steve Hayman Math Faculty Computing Facility University of Waterloo watmath!sahayman sahayman@math.waterloo.edu sahayman@water.bitnet ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa02264; 13 Apr 88 17:22 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa00566; 13 Apr 88 15:58 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa00547; 13 Apr 88 15:51 EDT Received: from megaron.arizona.edu by SMOKE.BRL.ARPA id aa05386; 13 Apr 88 15:40 EDT Received: by megaron.arizona.edu; Wed, 13 Apr 88 12:41:45 MST Received: by uazchem.SGI (5.15/5.6) id AA00980; Wed, 13 Apr 88 10:49:17 PST Date: Wed, 13 Apr 88 10:49:17 PST From: Dolata Message-Id: <8804131849.AA00980@uazchem.SGI> To: arizona!info-iris%brl.arpa@arizona.EDU Subject: I tried to send this direct, but our mailer ****ed up. In-Reply-To: Ian Clements's message of Tue, 12 Apr 88 10:46:29 PDT <8804121746.AA26476@lassen.sgi.com> Subject: FTP to VMS systems The VMS machine is using an Excelan EXOS 203 board, running the EXOS 8044-01 Rev B TCP/IP software. The 3130 IRIS is running GL2-W3.5r1, with bug fixes 004-0134-663 and 673. The TCP/IP kernel is running. Thanks a lot if you can give me some help!!!!! Dan ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa05915; 14 Apr 88 6:24 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa05893; 14 Apr 88 6:24 EDT Date: Thu, 14 Apr 88 6:21:16 EDT From: Chuck Kennedy To: info-iris@BRL.ARPA Subject: info-iris administrivia Message-ID: <8804140621.aa05776@VMB.BRL.ARPA> Folks, I've noticed that some folks are still using the old address of Info-Iris: info-iris@sumex-aim.stanford.edu Instead, please use the current address: info-iris@brl.arpa If you have requests to be added or deleted from the mailing list or other questions with which the entire mailing list does not need to be bothered, use the address: info-iris-request@brl.arpa I have sent information so that the list-of-lists kept by Rich Zellich at the NIC will be updated. In addition, I just completed a backlog of updates to the mailing list brought on by a spate traveling about the country, including a visit to SGI. One other comment, I see that info-iris is now being distributed via the USENET newsgroup: comp.sys.sgi Could whoever is relaying the messages from the ARPA side please send me a note. This may be the source of possible duplications that have been rumored but not seen here. There is a scheme for avoiding duplication of messages caused by USENET messages being fed back to the ARPA mailing list then being relayed back into USENET. Best, -Chuck Kennedy ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa15995; 15 Apr 88 5:05 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa15596; 15 Apr 88 3:21 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa15567; 15 Apr 88 3:07 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa14604; 15 Apr 88 3:03 EDT Received: from ucbvax.Berkeley.EDU by SUMEX-AIM.Stanford.EDU with TCP; Fri, 15 Apr 88 00:02:15 PDT Received: by ucbvax.Berkeley.EDU (5.59/1.28) id AA05177; Thu, 14 Apr 88 04:53:55 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@sumex-aim.stanford.edu (info-iris@sumex-aim.stanford.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 88 15:15:13 GMT From: Root Organization: Brown University Computer Science Dept. Subject: Re: FTP to VMS systems Message-Id: <24953@brunix.UUCP> References: <8804081907.AA03668@uazchem.SGI>, <576791317.8201@bucasb.bu.edu> Sender: info-iris-request@sumex-aim.stanford.EDU To: info-iris@sumex-aim.stanford.EDU In article <576791317.8201@bucasb.bu.edu> rasesh@bucasb.bu.edu (Rasesh Trivedi) writes: >In article <8804081907.AA03668@uazchem.SGI> dolata@uazchem.UUCP (Dolata) writes: >>I have a 3130, 2400T, and a mVAX II running ULTRIX, and a mVAX II running VMS.>>(And a headache!) All of these machines are hanging on an ethernet, and all >>... >>When I try to 'open vms' on the IRIS's ftp, it gives me a "segmentation > >Problem on Iris end implies something wrong on set up of your 3130 kernel. No, not at all. It was mentioned that telnet works just fine in both directions from all machines. That means that the kernel should be perfectly happy chewing on tcp. The problem is more likely in /etc/hosts or tcp configuration files on the irises, or in the VMS tcp implementation (whose is it?). From: sgf@nancy (Sam Fulcomer) Path: nancy!sgf I didn't see the original posting and don't have enough info to tell what the problem might be. Feel free to send mail to one of the following addresses if the headache persists. Sam ------------------------------------------------------------------------- BITNET sgf@BROWNCS CSNET sgf@cs.brown.edu ARPANET sgf%lfm.brown.edu@relay.cs.net UUCP {ihnp4,allegra,decvax,princeton}!brunix!sgf TELECOM 401-863-3618 ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa18912; 15 Apr 88 9:58 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa18007; 15 Apr 88 8:45 EDT Received: from brl-smoke.arpa by VMB.BRL.ARPA id aa17977; 15 Apr 88 8:42 EDT Received: from SUMEX-AIM.STANFORD.EDU by SMOKE.BRL.ARPA id aa19827; 15 Apr 88 8:39 EDT Received: from masig1.ocean.fsu.edu by SUMEX-AIM.Stanford.EDU with TCP; Fri, 15 Apr 88 05:38:32 PDT Received: by masig1.ocean.fsu.edu (5.15/25-eef) id AA07080; Fri, 15 Apr 88 08:39:08 EST Date: Fri, 15 Apr 88 08:39:08 EST From: "John D. McCalpin" Message-Id: <8804151339.AA07080@masig1.ocean.fsu.edu> To: info-iris@sumex-aim.stanford.EDU Subject: nntp Does anyone have 'news with the nntp daemon' working on a iris 3120. If so send the Makefile, and defs.h, or localize.iris. simmy@nu.cs.fsu.edu simmy@ocean.ocean.fsu.edu ------- Received: from BRL-VMB.ARPA by VMB.BRL.ARPA id aa21983; 15 Apr 88 14:23 EDT Received: from BRL-VMB.ARPA by VMB.brl.ARPA id aa21898; 15 Apr 88 14:12 EDT Received: from megaron.arizona.edu by VMB.BRL.ARPA id aa21836; 15 Apr 88 14:06 EDT Received: by megaron.arizona.edu; Fri, 15 Apr 88 11:06:53 MST Received: by uazchem.SGI (5.15/5.6) id AA02417; Fri, 15 Apr 88 11:12:02 PST Date: Fri, 15 Apr 88 11:12:02 PST From: uazchem!dolata@arizona.edu (Dolata) Message-Id: <8804151912.AA02417@uazchem.SGI> To: arizona!info-iris%brl-vmb.arpa@arizona.edu Subject: Third Party Disk Drives I have a Hitachi 600 MByte disk that is currently underused. I would like to connect it to my IRIS 3130. Does anyone know about this? Is it possible? Dan