From apollo-request@umix.cc.umich.edu Sun Oct 1 07:43:38 1989 Date: 30 Sep 89 21:46:37 GMT From: kts%quintro%tiamat.uucp@uunet.uu.net (Kenneth T. Smelcer) Organization: none Subject: Re: Why is /etc/reboot so unreliable? Message-Id: <1989Sep30.214637.7921@quintro.uucp> References: <8909291722.AA00609@civilgate.ce.uiuc.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8909291722.AA00609@civilgate.ce.uiuc.edu> lray@CIVILGATE.CE.UIUC.EDU (Ray) writes: > >I've been having considerable problems with /etc/reboot. Over 50% of the >time, the node being rebooted fails to come up with one of the >following symptoms: > > 1. The node says the clock is off and waits forever for a y/n. > 2. The node freezes prior to going into self tests. > 3. The node fails to shut down at all. > [ explanations of above conditions ] >--------------------------------------------------------------------- > >Does anyone know how /etc/reboot works, enough to give me some insight >as to whats going on here? > Have you tried /etc/reboot with different types of nodes? I've noticed on our system that 'reboot' works fine with our DN3000s, but fails 90% of the time on our DN3500 nodes. Note: all our nodes had SR10.1 loaded from one AA on a 3500, so I don't think it's a garbled/out-dated version problem. Just for the record, I really enjoy having the /etc/reboot option available. It makes my life much easier, especially when I can dial in from home and reset things, instead of always having to be on the scene. > Leland Ray > UIUC - CE Dept. > (217) 333-3821 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet From apollo-request@umix.cc.umich.edu Sun Oct 1 19:22:59 1989 Date: 1 Oct 89 17:21:07 GMT From: phcalamai%water%maytag%watmath%utgpu%attcan.uucp@uunet.uu.net (Paul H. Calamai) Organization: U of Waterloo, Ontario Subject: Mathematica on SR10 nodes - info needed Message-Id: <2680@water.waterloo.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Could anyone tell me about the price and availability of Mathematica for Apollo Workstations running SR10.x. Info on pricing and licensing details would be useful as well as any info on Educational Discounting policies. Thanks -Paul From apollo-request@umix.cc.umich.edu Mon Oct 2 07:24:36 1989 Date: 2 Oct 89 09:43:19 GMT From: laba-1aj%web-4e.berkeley.edu%agate.uucp@ucbvax.Berkeley.EDU Organization: Berzerkley Institute Subject: looking for Folded Message-Id: <1989Oct2.094319.15186@agate.berkeley.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I need some pointers to the editor Folded by Todd Burkey. I tried to get mail through to him but could not. Does anyone know where an Apollo 4.3 BSD version can be gotten? thanx & John Kawakami & laba-1aj@web.berkeley.edu & Live each day as if it were your first From apollo-request@umix.cc.umich.edu Mon Oct 2 09:54:27 1989 From: tpfabian@nasamail.nasa.gov (THEODORE FABIAN) Date: Sun, 1 Oct 89 20:49 PDT Message-Id: Cc: Subject: dn3000 vs. dn3500 X-Lines: 36 regarding the recent set of messages in which someone asked about /etc/reboot, I'd like to submit that while we've not tried the reboot function you're talking about, we have noticed some differences in the way things act on DN3500s as compared to DN3000s... most notably, the color map seems more phinicky on the DN3500.. but there are some other subtle things... one of the folks who responded stated that he had not had a problem using the reboot on a DN3000... given this, I wanted to call to your attention the subtle oddities that don't always manifest themselves.... be aware... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Thanks, * * * * Ted Fabian * * * * NASA Lewis Research Center * * Cleveland, Ohio * * * * phone: 216-433-6307 * * FTS: 297-6307 * * * * email: tpfabian@nasamail.nasa.gov * * tfabian@earth.lerc.nasa.gov * * tfabian@csd.lerc.nasa.gov * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From apollo-request@umix.cc.umich.edu Mon Oct 2 11:38:34 1989 Date: Mon, 2 Oct 89 10:17:29 EDT From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8910021417.AA15995@richter.mit.edu> To: phcalamai%water%maytag%watmath%utgpu%attcan.uucp@uunet.uu.net Subject: Re: Mathematica on SR10 nodes - info needed Cc: apollo@umix.cc.umich.edu Call Gail Mann at Apollo's Educational Business Office in Chelmsford (508-256-6600). She was working on a special educational price the last time I talked with her. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Mon Oct 2 17:17:10 1989 Date: 2 Oct 89 15:35:09 GMT From: sahayman@iuvax.cs.indiana.edu (Steve Hayman) Organization: Computer Science Department, Indiana University Subject: Apollo won't release rbak/wbak format. grrr. Message-Id: <26979@iuvax.cs.indiana.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We do all of our nightly dumps to an Exabyte tape drive on a Sun and use a variety of formats in the process - dump, tar, cpio and wbak. I wanted to find out some details of the wbak format so that I could run some simple tools on the Sun to give me a table of contents of the tape. So I called Apollo, and their response is that "the rbak/wbak format is unpublished and we don't want to give it out." Thanks a lot. If anyone important at Apollo happens to read this, I hope this policy can be changed. I hate doing something as important as backups without being sure of what I'm writing to the tape. I don't want all the source to wbak, I just want something like "man 5 tar" to tell me about the wbak format. Mind you I suspect that "man 5 tar" doesn't tell you the true story of Apollo's tar format, since it doesn't mention anything about whatever extensions they've added to support Apollo specific information. (see "man 1 tar", description of the "A" option) When can we get HP-UX for these things ? :-) Steve -- Steve Hayman Workstation Manager Computer Science Department Indiana U. sahayman@iuvax.cs.indiana.edu (812) 855-6984 From apollo-request@umix.cc.umich.edu Mon Oct 2 21:40:01 1989 Date: 29 Sep 89 11:05:42 GMT From: achille%cernvax%mcsun.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Using Exabyte for data exchange Message-Id: <1101@cernvax.UUCP> References: <1989Sep28.205528.6220@hellgate.utah.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi there, we are trying here to use exabytes as a way to ship user written data to other sites. These data come from HEP experiments where all code is in Fortran. The ideal situation would be for us to not change any program and simply tell users to use "/dev/..." as output file. That's what I tried with the /dev/rmts* devices installed by Omniback. (These are the device special files for tape units on SCSI). Now comes the funny thing: ftn programs can write sequential formatted data on the exabyte (and you can even read it back !), but ... ftn programs canNOT write sequential unformatted data, the error messages says something like: "illegal parameter combination for this type manager" Is ther anybody out there who has tried that, who wants to do the same thing, who's been hit by this problem ? Any Apollo guru who knows why I can't write raw data on a tape ? If you want I can summarize to the net the answers (if I get any :-) Thanks in advance, Achille Petrilli Cray & PWS Operations P.s.: I forgot to mention that all that happens under sr10.1.p (dn10000), Omniback 1.0 From apollo-request@umix.cc.umich.edu Mon Oct 2 21:46:57 1989 Message-Id: <8910022135.AA12864@umix.cc.umich.edu> From: eal@sol.engin.umich.edu To: naugle%dover.uucp@sol.engin.umich.edu Cc: apollo@umix.cc.umich.edu, paul@speedmetal.engin.umich.edu Date: 2 Oct 1989 21:24 GMT Subject: Re: SR10.1 / TCP / UUCP ------- Forwarded Message Date: 15 Sep 89 00:22:33 +0000 From: naugle%dover%oakhill%cs.utexas.edu%mailrus.uucp@tut.cis.ohio-state.edu (Ray Naugle) To: apollo@umix.cc.umich.edu Subject: SR10.1 / TCP / UUCP Has anyone successfully gotten the UUCP distributed with Apollo's SR10.1 to work over a TCP connection? The documentation looks very poor. The UUCP distributed is the HoneyDanBer version (BNU) which looks like it should, but there is *no* explicit mention of doing this. The manual supplied (Managing BSD System Software) with the release goes into vague detail and has no living examples. (there is one mention of an old file - /usr/lib/uucp/uucico.real - which doesn't exist and I believe it is a hold over from sr9.5 Unix) Any help would be greatly appreciated. Thanks Ray Naugle ------- End of Forwarded Message Sure, here's what's I use in our Systems, Devices, and Permissions files: #excerpt from Systems: umich Any TCP uucp umich.engin.umich.edu login: Ucaen ssword: fill-in-passwd #excerpt from Devices: TCP,t TCP - Any TCP #excerpt from Permissions: #Permissions for when we call site umich (umich.engin.umich.edu) MACHINE=umich MYNAME=caen\ COMMANDS=rmail\ READ=/usr/spool/uucppublic WRITE=/usr/spool/uucppublic #umich never calls us Hope this helps! Lisa Leutheuser ip: eal@sol.engin.umich.edu Computer Aided Engineering Network uucp: {backbone}!sol.engin.umich.edu!eal University of Michigan "Hacking's a dirty habit. Mail is science." From apollo-request@umix.cc.umich.edu Tue Oct 3 05:55:36 1989 Date: 2 Oct 89 20:42:29 GMT From: craig%edstip%edsews.uucp@uunet.uu.net (Craig Doebler) Organization: EDS - Tech Pubs, Bloomfield Hills, MI Subject: Using tar commands Message-Id: <801@edstip.EDS.COM> References: <8908231355.AA09223@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have been trying to send files to a quarter inch cartarige tape using tar cvf /dev/rct0 filename. The results I get are a message on the screen which signifies the file name and its block size and nothing has been transfered to the tape. If I do a ls -las (list and show attributes), the rct0 file has all my data in it whats going on??? I am running a DN3500, BSD 4.2 -- Craig Doebler, EDS UUCP: ...!uunet!edsews!edstip!craig 1400 N. Woodward Ave craig@edstip.EDS.COM Bloomfield Hills, Voice: (313)645-4720 Fax:645-4824 MI 48013 * The above are my views only!! From apollo-request@umix.cc.umich.edu Tue Oct 3 05:58:51 1989 Date: 2 Oct 89 13:16:18 GMT From: solomon%mdcbbs.uucp@uunet.uu.net Organization: McDonnell Douglas M&E, Cypress CA Subject: Re: SR10 GotchaDOWN Message-Id: <519.25275fa3@mdcbbs.com> References: <8909291500.AA06515@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > - the one major problem (and > one which we still have not totally resolved) is that the > radical changes in how virtual memory is implemented > cause major consternation for some of our applications > (Pre-empting the obvious question, by radical changes > I am refering to the fact that at SR10 address space > is mapped to disk at time of creation, rather than > at use. If you have data structures designed > for the former paradigm, you're not sitting too > well for the change). You're not the only one!! Yeh, for some applications this memory enforcer may be ok, but if you have a monster of a program with many many modules that are not in use at the same time, this is a real pain! ANSI standards are fine, but I say give us an option as to whether or not we want memory locked in or as in the good ol' days. Apollo, you've got a good idea in place. Please give us the option. Barry Solomon From apollo-request@umix.cc.umich.edu Tue Oct 3 14:49:28 1989 Date: 3 Oct 89 13:47:00 GMT From: weber_w%apollo%hp-sdd.uucp@hplabs.hp.com (Walt Weber) Organization: Apollo Systems Division , Hewlett Packard Subject: Re: SR10.1 / TCP / UUCP Message-Id: <4601b7d1.10b48@apollo.HP.COM> References: <8910022135.AA12864@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In <8910022135.AA12864@umix.cc.umich.edu> eal@SOL.ENGIN.UMICH.EDU writes some instructions for setting up HDB over the TCP transport, but only included the entries for Systems, Devices, and Permissions files. The following is "submitted for your approval" (with a brief nod to The Twilight Zone :-) 1. Verify that the /etc/services file has a uucp entry that resembles: uucp 540/tcp uucpd # uucp daemon 2. Verify that tcpd is running (correctly). 3. Edit the /etc/inetd.conf file adding a line that resembles: uucp stream tcp nowait root /usr/lib/uucp/uucpd uucpd and restart inetd. 4. The /usr/lib/uucp/Systems file entry should look like: hiway61 Any TCP 540 hiway61 login: uucp assword: uucpwd 5. The /usr/lib/uucp/Devices file entry should look like: TCP,t TCP - Any TCP 6. Initiate the connection as normal. ...walt... -- Walt Weber Apollo Systems Division, Hewlett Packard (508) 256-6600 x8315 People's Republic of Massachusetts -The views expressed herein are personal, and not binding on ANYONE- From apollo-request@umix.cc.umich.edu Tue Oct 3 21:33:13 1989 Date: Tue, 3 Oct 89 14:38:02 CDT From: lray@civilgate.ce.uiuc.edu (Ray) Message-Id: <8910031938.AA01386@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: bug alert - /lib/ftnlib If you have PATRAN on your system, do not use any ftnlib other than the 10.1 FCS ftnlib. Otherwise, you will break Patran. The problem occurs when trying to read formatted results files. The traceback is: Process 1354 (parent 1256, group 1256) Time 89/10/03.11:14(CDT) Program //node_194e9/patran/patran23/com/patran2.m68k Status 03080004: requested too large an area from baf (process manager/basic heap storage manager) In routine "pfm_$error_trap" line 160 Called from "rws_$alloc_heap_pool" line 498 Called from "pas_$new" line 772 Called from "fio_$getrec" line 613 Called from "fio_$real_ioinit" line 4071 Called from "fio_$real_ioinit" line 29 Called from "BINFIL" line 72 (miscellaneous patran routines deleted) The problem is a DN10k bug that crept into the 68000 stuff somehow. The execution error occurs because Patran is trying to determine if the input file is ascii or binary. It performs a series of tests on the file, and apparently one of the causes this error. I have not yet run into another program which has this problem, but if anyone else does, do open an 800-number call on it -- the more customers who complain, the better the change of this one getting squished for good. I've also got a call in to PDA about this, and am going to scream loudly until it is fixed. Leland Ray UIUC - CE Dept. (217) 333 - 3821 From apollo-request@umix.cc.umich.edu Tue Oct 3 23:25:42 1989 Date: 3 Oct 89 17:01:40 GMT From: achille%cernvax%mcsun%sunic%luth%eru.uucp@bloom-beacon.mit.edu (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: DN10000 salvol + disk problems Message-Id: <1108@cernvax.UUCP> References: <8909291500.AA06515@umix.cc.umich.edu>, <519.25275fa3@mdcbbs.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, we are having a few problems (well, more than a few :-) with some third party disks we've installed on our DN10000s. The disks are just Maxtor's 700MB, the same shipped by Apollo, ESDI i/f. Here are the problems: 1) on one system we get constantly errors on head 0x0E, sector 0x0C, any cylinder. We swapped out the disk and introduced a new one, and it did exactly the same. 2) after introducing a bad spot, it happens quite often that salvol crashes during the 2nd pass with the following message: Internal Error: n_free (12F88) is < 0 in mark_blk in use, looks bad! (zone = 36 zone.n_free = FFFFFFFF) Does anybody know if problem 1) could be due to cables/controllers problems ? I don't know enough of ESDI to understand what's going on. Problem 2 seems pretty bad, if salvol gives up, who's going to fix your disk ? Any idea about it ? There is another thing that really makes me wonder: Maxtor disks shipped by Apollo are some 659MB, 3rd party Maxtor disks come out after an invol to be 683MB. What's going on here ? Thanks a lot, Achille Petrilli Cray & PWS operations From apollo-request@umix.cc.umich.edu Wed Oct 4 01:28:21 1989 Date: 4 Oct 89 04:23:27 GMT From: ianh%merlin%bruce%munnari.oz.au.uucp@uunet.uu.net (Ian Hoyle) Organization: none Subject: SLIP on 3500 workstation Message-Id: <1302@merlin.bhpmrl.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is SLIP available on the 68030 workstations, specifically a 3500 ??? If so, a) has anyone used it b) where is it documented ???? (is it part of SR10.1 ??) ian -- Ian Hoyle /\/\ Computer Systems Superintendent / / /\ BHP Melbourne Research Laboratories / / / \ 245 Wellington Rd, Mulgrave, 3170 / / / /\ \ AUSTRALIA \ \/ / / / \ / / / Phone : +61-3-560-7066 \/\/\/ ACSnet : ianh@merlin.bhpmrl.oz.au Internet: ianh%merlin.bhpmrl.oz.au@uunet.uu.net From apollo-request@umix.cc.umich.edu Wed Oct 4 11:35:55 1989 Date: 4 Oct 89 11:06:11 GMT From: cees%maestro%hp4nl%mcsun.uucp@uunet.uu.net (Cees Keyer) Organization: AHA-TMF (Technical Institute), Amsterdam, The Netherlands Subject: Bug in man????? Message-Id: <1093@maestro.htsa.aha.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello, I've encountered a strange bug?? in man. When I invoke the man command it returns the following message: Unable to create a read window for catx/command name not found (os/naming server) With catx some directory in /usr/man/ When I reboot the node, the man command works just fine but after a day, or less, it will produce the error again. First I thougt it was a protection problem of the manual pages but I checked that and there is no problem at all. The pages are mode 666 and the mode of the command is 4755. So there shouldn't be a problem in that. We are running SR10.1 BSD4.3 only. Could it be that the DM causes this error, or is it a error in man itself. The message "Unable to create a read window for ...." is a message produced by the man command it self (see also strings man). So if someone outhere in netland could give some pointers to the solution of the problem. Tnx in advance Cees Keyer. -- DISCLAIMER: I am not insane, I am a plane. pjew! Cees Keyer, Algemene Hogeschool Amsterdam. department of electrical engineering. Email: cees@tamtam.htsa.aha.nl cees@maestro.htsa.aha.nl Snail: AHA-TMF, Europaboulevard 23, 1079 PC Amsterdam, The Netherlands. From apollo-request@umix.cc.umich.edu Wed Oct 4 11:41:11 1989 Date: Wed, 4 Oct 89 09:57:43 CDT From: Andrew M. Wescott Message-Id: <8910041457.AA02679@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu, ianh%merlin%bruce%munnari.oz.au.uucp@uunet.uu.net Subject: Re: SLIP on 3500 workstation I think SLIP is supported at SR 10.1 . I'd start with a "man" on "ifconfig" . Beyond that I have little information. Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Wed Oct 4 17:50:40 1989 Date: 4 Oct 89 18:57:37 GMT From: laba-1aj%WEB.berkeley.edu%agate.uucp@ucbvax.Berkeley.EDU (John Kawakami) Organization: Berzerkley Institute Subject: STILL looking for FOLDED Message-Id: <1989Oct4.185737.5099@agate.berkeley.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm still looking for the apollo version of FOLDED by Todd Burkey (trb@stag). I have not been able to get mail thru to him, so I'm asking YOU. If you know where I can get the APOLLO version of FOLDED, please tell me. Are you out there trb?!? & John Kawakami & laba-1aj@web.berkeley.edu & Live each day as if it were your first From apollo-request@umix.cc.umich.edu Wed Oct 4 17:53:26 1989 Date: 4 Oct 89 14:05:51 GMT From: gene%images%ncrwat%ncrlnk.uucp@uunet.uu.net (Gene Franklin) Organization: NCR Canada Ltd, Waterloo, Ontario, Canada. Subject: Kermit under SR10.1 Message-Id: <237@images.Waterloo.NCR.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have apollos, which used to run under SR9.7. We also had C-Kermit running on these apollos. Now we have upgraded to SR10.1, and now the old Kermit doesn't work ( the symptoms are when you try to go SERVER you get the message "Unable to open line: Not a typewriter"). Anybody got kermy going under 10.1 ? Anybody got any ideas ? Thanks for all your help (in advance) - email responses if you like From apollo-request@umix.cc.umich.edu Wed Oct 4 17:55:19 1989 Date: 4 Oct 89 14:08:10 GMT From: gene%images%ncrwat%ncrlnk.uucp@uunet.uu.net (Gene Franklin) Organization: NCR Canada Ltd, Waterloo, Ontario, Canada. Subject: Re: Kermit under SR10.1 Message-Id: <238@images.Waterloo.NCR.COM> References: <237@images.Waterloo.NCR.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I seemed to have forgotten my address in the previous posting so .... ---- Gene ---- [usenet] G.Franklin@Waterloo.NCR.COM [cems] WAT-ENG-ASET@CEMS Forward-Path: G.Franklin@Waterloo.NCR.COM NCR Canada LTD., E&M Waterloo, Waterloo Ontario Canada, (519)-884-1710 x590 From apollo-request@umix.cc.umich.edu Wed Oct 4 21:52:18 1989 Date: 4 Oct 89 15:10:10 GMT From: leonh%hhb%pyrnj.uucp@rutgers.edu (leon howorth) Organization: HHB Systems, Mawah, NJ Subject: Root login over TCP/IP network Message-Id: <282@hhb.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This may have been covered before, but I missed the information. My question is: What entries do I need to make to an SR10.1 apollo systems /etc/ttys file in order to permit root login over the TCP/IP network. My existing /etc/ttys file on the apollo node is as follows: ********************************************************************** # # ttys - terminal initialization data # #device getty/program term on/off other flags comment console "/etc/dm_or_spm" apollo on secure # use mkcon to redirect console output display none apollo off secure # DM pad devices tty01 none dumb off secure tty02 none dumb off secure tty03 none dumb off secure ********************************************************************** -- Leon A. Howorth | UUCP: ....princeton!hhb!leonh Computer Operations Manager | ARPA: leonh%hhb@princeton.edu HHB Systems | VOICE: 201-848-8000 ext. 243 Mahwah, New Jersey 07430 | FAX: 201-848-8189 From apollo-request@umix.cc.umich.edu Thu Oct 5 01:38:45 1989 Message-Id: <8910050346.AA27264@umix.cc.umich.edu> Date: Thu, 5 Oct 89 11:40 H From: Subject: Server Process Manager (SPM) To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK Re: Server Process Manager (SPM) We've a DSP90 to which a vt100-compatible is connected. We can log into the server node by typing SH to get a 'login' prompt and enter the user-id and passwd. The strange thing is that the login process seems different from the normal one, eg /etc/profile is not executed at all. I wonder any body knows why? Another strange thing is that some of our accounts can log in but some just get kicked out after the welcome message appears on the screen. After a few experiments, I found out that those accounts with /bin/sh or /com/sh as the startup shell will be accepted, and those with /bin/ksh just get rejected by SPM. Any body who knows how to solve the problem? Is there any other documentation about SPM besides the one found in the sysadmin manuals? (We're running SR10.1 with default SYSTYPE=BSD4.3) --AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Thu Oct 5 05:33:51 1989 Date: 4 Oct 89 19:56:00 GMT From: conliffe%caen.engin.umich.edu%netnews.engin.umich.edu%shadooby%mailrus.uucp@tut.cis.ohio-state. (Darryl C. Conliffe) Organization: U of M Engineering, Ann Arbor, Mich. Subject: Re: Apollo won't release rbak/wbak format. grrr. Message-Id: <46080999.14df5@ulsoy.engin.umich.edu> References: <26979@iuvax.cs.indiana.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <26979@iuvax.cs.indiana.edu>, sahayman@iuvax.cs.indiana.edu (Steve Hayman) writes: > > We do all of our nightly dumps to an Exabyte tape drive on a Sun and > use a variety of formats in the process - dump, tar, cpio and wbak. > I wanted to find out some details of the wbak format so that I could > run some simple tools on the Sun to give me a table of contents > of the tape. So I called Apollo, and their response is that > "the rbak/wbak format is unpublished and we don't want to give it out." > Is knowledge of the internal format necessary? Why not index the tape for a TOC? How do you gen the tape in the first place? -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 ------------------- From apollo-request@umix.cc.umich.edu Thu Oct 5 06:12:33 1989 Date: 5 Oct 89 03:00:05 GMT From: chen%digital.sps.mot.com%digital%dover%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Jinfu Chen) Organization: Motorola, Inc. Logic IC Div, Mesa, AZ Subject: Sendmail hole (?) Message-Id: <46098421.81da@digital.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu People at comp.virus are getting quite excited about the coming "Friday the 13th" (Oct 13th). This reminds me the infamous ARPANET-worm last November, so I just tried the following to our SMTP gateway node (running SR10.1.0.4), and to my surprise: [ first look for 'debug' string in sendmail ] > $ strings /usr/lib/sendmail | grep -i debug > debug > Debug set [ then, connected to digital.sps.mot.com on SMTP port ] > 220 digital.sps.mot.com Sendmail 5.51.2/SMI-3.2 ready at Wed, 4 Oct 89 20:21:41 MDT > DEBUG > 200 Debug set > quit > 221 digital.sps.mot.com closing connection > > ====finis: stat 0 e_flags 1 > dropenvelope 1cdb8 id="AA14672" flags=1 > Connection closed by foreign host. Should I get panic?! I don't know if the "DEBUG" command in this version of SMTP from Apollo is immune to the ARPANET worm. Could someone from Apollo verify this? One of the recent Apollo patch is related to `fingerd' and the document says it's been inoculated against the virus publicized on USENET. Does this apply to sendmail? -- Jinfu Chen (602)898-5338 | Disclaimer: Motorola, Inc. Logic IC Div., Mesa, AZ | ...{somewhere}!uunet!dover!digital!chen | My employer doesn't pay chen@digital.sps.mot.com | me to express opinions. ---------- From apollo-request@umix.cc.umich.edu Thu Oct 5 11:28:44 1989 Date: 5 Oct 89 12:21:58 GMT From: ebersman%software.org.uucp@uunet.uu.net (ebersman) Organization: Software Productivity Consortium, Inc., Herndon, Virginia Subject: DPSS to Berkeley Mail Message-Id: <381@sunny.software.org> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Before I spend a half-day or day reinventing the wheel, has anyone written a filter to convert DPSS style mail (either the "unfetched" or "fetched" flavor) to Berkeley/RFC 822 style headers? Thanks. -- Paul A. Ebersman @ Software Productivity Consortium uunet!sunny!ebersman or ebersman@software.org ( The difference between practice and theory in practice is always greater than the difference between practice and theory in theory. ) -- Paul A. Ebersman @ Software Productivity Consortium uunet!sunny!ebersman or ebersman@software.org ( The difference between practice and theory in practice is always greater than the difference between practice and theory in theory. ) From apollo-request@umix.cc.umich.edu Thu Oct 5 11:38:37 1989 Date: Thu, 5 Oct 89 09:33:54 CDT From: Andrew M. Wescott Message-Id: <8910051433.AA03873@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: netlib servers Does anyone know of any netlib based servers for computational software besides netlib@mcs.anl.gov ? Thanks, Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Thu Oct 5 13:29:43 1989 Date: Thu, 5 Oct 89 10:32:46 CDT From: Andrew M. Wescott Message-Id: <8910051532.AA00387@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: Password protection on dialups Can someone tell me a simple way to restrict login access on a couple of our dialup lines? Right now we use ttys/getty . I know you can add password protection with Aegis siologin/siomonit, but what if I'm a UNIX only installation ? Thanks in advance for any help. Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Thu Oct 5 13:38:26 1989 Date: Thu, 5 Oct 89 10:11:24 CDT From: Andrew M. Wescott Message-Id: <8910051511.AA00345@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: T1 links What can someone tell me about the current state of T1 links to Apollo nodes ? In "Planning Domain Networks and Internets" (page 7-3) it says T1 links can only be used between ATR networks. Another limitation is the Domain/BridgeA controller which is a MULTIBUS device. Well let's say we have (3) 3500s and (1) dn10000 on a local 802.3 network, and a couple of 3500 orphans at least a mile away. It is not possible to connect the orphans into the campus LAN due to distance/property restrictions. I would like to connect the orphans point-to-point with 802.3 and let one of them be a gateway to our campus Apollo nodes via T1. This seems reasonable to me, but does the hardware exist yet ? Thanks in advance for any help. Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Thu Oct 5 13:39:14 1989 Date: Thu, 5 Oct 1989 17:06:08 MET From: Harald Hanche-Olsen To: apollo@umix.cc.umich.edu Cc: Gene Franklin Subject: Re: Kermit under SR10.1 In-Reply-To: Your message of 4 Oct 89 14:08:10 GMT Message-Id: Gene Franklin was having problems with C-kermit under SR10.1. So did I, and I am pleased to report that the problem was easily fixed, as I also reported to Info-Kermit Digest half a year ago. I don't remember which issue it ended up in, but anyway I include below the message I sent at the time. One warning though: I got a letter from one user who had included the flag -Uapollo among the CFLAGS in the makefile. Unfortunately, there is code in stdio.h that breaks down if apollo is undefined. So please, do it my way. And make sure to #undef apollo *after* the #include's in ckcmai.c... Frank da Cruz has been in communication with me about getting this fixed properly in the official release of C-kermit, but haven't had the time to look at it yet (working my butt off this term). Enough said. Here is the promised article: Date: Tue, 4 Apr 89 20:05:28 EST From: hanche To: Info-Kermit@cunixc.cc.columbia.edu CC: fdc@cunixc.cc.columbia.edu In-reply-to: hanche@imf.unit.no's message of Wed, 25 Jan 89 09:46:21 EST Subject: C-kermit on apollo under SR10! I asked earlier about making C-Kermit work under SR10 on an Apollo. I now have the answer, thanks to our local Apollo representative. Although the silence following my query was deafening---suggesting that no one on this list uses Apollos---I will now report the fix. The problem is basically this: The C-kermit code is full of special code to handle Apollos. All this code turns out to be unnecessary (and indeed harmful) when running under SR10, since the operating system is now much more Unixlike. Unfortunately, even the C compiler provided with the 4.3BSD environment of SR10 defines the preprocessor symbol aegis, thereby activating the unwanted code. I fixed this by inserting a new item in the makefile, looking like this: #Apollos running SR10.0 or later: sr10-bsd: make wermit "CFLAGS= -DBSD4 -DDEBUG -DTLOG -Uaegis" I also needed to add one line to ckcmai.c (anywhere near the beginning): #undef apollo and then the program compiled like a charm. I also discovered that you must use /dev/tty??, not /dev/sio? as the latter access the serial lines at a lower level than is standard on Unix systems. - Harald Hanche-Olsen Division of Mathematical Sciences hanche@imf.unit.no The Norwegian Institute of Technology From apollo-request@umix.cc.umich.edu Thu Oct 5 17:21:41 1989 Date: 5 Oct 89 17:33:27 GMT From: sridhar%usceast%ncrcae%ncrlnk.uucp@uunet.uu.net (M. A. Sridhar) Organization: University of South Carolina, Columbia Subject: Re: Kermit under SR10.1 Message-Id: <2948@usceast.UUCP> References: <237@images.Waterloo.NCR.COM>, <238@images.Waterloo.NCR.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <238@images.Waterloo.NCR.COM> gene@images.Waterloo.NCR.COM (Gene Franklin) writes: > > (Asking about Kermit under SR10.1) > I got a copy of an Apollo-specific C-Kermit from labrea.stanford.edu (anonymous ftp), and implemented it under SR10.1. I haven't had any problems so far. Please e-mail me if you need a copy. Sridhar -- M. A. Sridhar | Department of Computer Science | ncr-sd!ncrcae ! usceast!sridhar (USENET) University of South Carolina | sridhar@cs.scarolina.edu (CSNET) Columbia, SC 29208 | (803) 777-2427 (Ma Bell) From apollo-request@umix.cc.umich.edu Thu Oct 5 17:38:50 1989 Date: 5 Oct 89 11:03:34 GMT From: achille%cernvax%mcsun.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Re: Root login over TCP/IP network Message-Id: <1109@cernvax.UUCP> References: <282@hhb.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <282@hhb.UUCP> leonh@hhb.UUCP (leon howorth) writes: >This may have been covered before, but I missed the information. > >My question is: What entries do I need to make to an SR10.1 apollo >systems /etc/ttys file in order to permit root login over the TCP/IP >network. My existing /etc/ttys file on the apollo node is as follows: > ... >-- >Leon A. Howorth | UUCP: ....princeton!hhb!leonh >Computer Operations Manager | ARPA: leonh%hhb@princeton.edu >HHB Systems | VOICE: 201-848-8000 ext. 243 >Mahwah, New Jersey 07430 | FAX: 201-848-8189 I changed /etc/ttys to prevent anybody (root included and me excluded) from logging in via telnet/rlogin to my node. Here it is my /etc/ttys, you just have to change "off" to "on" to tell the system that each port is secure. # # ttys - terminal initialization data # #device getty/program term on/off other flags comment console "/etc/dm_or_spm" apollo on # use mkcon to redirect console output ttyp0 none dialup off ttyp1 none dialup off ttyp2 none dialup off ... ttypf none dialup off For those of you who don't know how to turn off all other user accounts from my node, I created a /etc/d_users file containing just my user name. Hope this helps, Achille Petrilli Cray & PWS Operations From apollo-request@umix.cc.umich.edu Thu Oct 5 19:24:46 1989 Date: 5 Oct 89 20:20:00 GMT From: pcc%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Peter Craine) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Password protection on dialups Message-Id: <460d2633.20b6d@apollo.HP.COM> References: <8910051532.AA00387@lnic1.hprc.uh.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910051532.AA00387@lnic1.hprc.uh.edu> wescott@LNIC1.HPRC.UH.EDU (Andrew M. Wescott) writes: > >Can someone tell me a simple way to restrict login access on a couple >of our dialup lines? Right now we use ttys/getty . I know you can >add password protection with Aegis siologin/siomonit, but what if >I'm a UNIX only installation ? > >Thanks in advance for any help. > Check out the man page for login. You'll see a section on "Dial-Up Security". This will discuss /etc/d_users and /etc/d_passwd. These files allow only certain users (d_users) who know the dialin password (d_passwd) to use lines that are tagged as "dialin" in /etc/ttys. You can use both, either, or neither of these files. Peter Craine, NACS *I* don't wany my own opinions. Why would HPOLLO want them? From apollo-request@umix.cc.umich.edu Thu Oct 5 21:24:13 1989 Date: 5 Oct 89 04:00:00 GMT From: conliffe%caen.engin.umich.edu%netnews.engin.umich.edu%shadooby%mailrus.uucp@tut.cis.ohio-state. (Darryl C. Conliffe) Organization: U of M Engineering, Ann Arbor, Mich. Subject: Re: Apollo won't release rbak/wbak format. grrr. Message-Id: <460bf837.14df5@ulsoy.engin.umich.edu> References: <26979@iuvax.cs.indiana.edu>, <46080999.14df5@ulsoy.engin.umich.edu>, <27200@iuvax.cs.indiana.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <27200@iuvax.cs.indiana.edu>, sahayman@iuvax.cs.indiana.edu (Steve Hayman) writes: > >Is knowledge of the internal format necessary? Why > >not index the tape for a TOC? How do you gen > >the tape in the first place? > > Our Exabyte tape drive is attached to a Sun. > Right now I'm doing > > wbak -stdout ... | rsh sun-with-exabyte-drive dd of=/the/tape > > You can't do > > wbak -l -stdout ... | rsh sun ... > > because the list-of-files-saved is written to stdout, > and vanishes down the pipe getting mixed in with the wbak stuff. > Try this approach: wbak -to -l > Then copy the to be tar'ed, and you also have the artifact of the index in From apollo-request@umix.cc.umich.edu Fri Oct 6 01:23:36 1989 Date: 5 Oct 89 21:31:13 GMT From: chen%digital%dover%oakhill%cs.utexas.edu%execu%sequoia%texbell.uucp@rutgers.edu (Jinfu Chen) Organization: Motorola, Inc. Subject: Re: Password protection on dialups Message-Id: <460d658b.81da@digital.sps.mot.com> References: <8910051532.AA00387@lnic1.hprc.uh.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910051532.AA00387@lnic1.hprc.uh.edu> wescott@LNIC1.HPRC.UH.EDU (Andrew M. Wescott) writes: > >Can someone tell me a simple way to restrict login access on a couple >of our dialup lines? Right now we use ttys/getty . I know you can >add password protection with Aegis siologin/siomonit, but what if >I'm a UNIX only installation ? > >From /bsd4.3/usr/man/cat1/login.1 page: SECURITY Sites wishing additional security protection on dial-up lines may want to use these security features, /etc/d_users and /etc/d_passwd. /etc/d_users is simply a file containing a list of users authorized to log in on this node. /etc/d_passwd is a file containing lines of the following format: /bin/sh:encrypted-password where encrypted-password is the dial-in password for the specified shell as returned by crypt(3). If an entry for the user's log-in shell is not found in this file, the password for /bin/sh is used. -- Jinfu Chen (602)898-5338 | Disclaimer: Motorola, Inc. Logic IC Div., Mesa, AZ | ...{somewhere}!uunet!dover!digital!chen | My employer doesn't pay chen@digital.sps.mot.com | me to express opinions. ---------- From apollo-request@umix.cc.umich.edu Fri Oct 6 04:47:39 1989 Date: 6 Oct 89 05:43:51 GMT From: sahayman@iuvax.cs.indiana.edu (Steve Hayman) Organization: Computer Science Department, Indiana University Subject: Re: Apollo won't release rbak/wbak format. grrr. Message-Id: <27264@iuvax.cs.indiana.edu> References: <46080999.14df5@ulsoy.engin.umich.edu>, <27200@iuvax.cs.indiana.edu>, <460bf837.14df5@ulsoy.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >Try this approach: >wbak -to -l > > >Then copy the to be tar'ed, and you also >have the artifact of the index in Hmmm ... That'd work, except that we usually don't have enough disk space to do our backups to disk and then copy them to tape. Thanks anyway. I think I'm going to switch to tar. wbak is just too inconvenient in a mixed-OS environment. Steve From lubkin@apollo.com Fri Oct 6 09:32:44 1989 Message-Id: <8910061310.AA25036@xuucp.ch.apollo.com> From: lubkin@apollo.com Date: Fri, 6 Oct 89 09:00:28 EDT Subject: INFO-DSEE mail To: dsee_list:@apollo.com Date: sun, 1 oct 89 20:04:00 From: derstad@cim-vax.honeywell.com ("DAVE ERSTAD") Subject: Re: DSEE Model Problem In my previous posting, I made a parenthetical comment that I wasn't sure why a block_id could appear as a source dependency (as opposed to a results dependency). Of course, the reason is for the MACRO and PROMOTE_DEPENDS cases. The real question remains unanswered, however. Dave Erstad Principal Design Automation Engineer Honeywell SSED DERSTAD@cim-vax.honeywell.com ====================================================================== Post to info-dsee@apollo.com Administrative mail to info-dsee-request@apollo.com ====================================================================== ------- From lubkin@apollo.com Fri Oct 6 09:38:21 1989 Message-Id: <8910061311.AA25051@xuucp.ch.apollo.com> From: lubkin@apollo.com Date: Fri, 6 Oct 89 08:59:53 EDT Subject: INFO-DSEE mail To: dsee_list:@apollo.com Date: sun, 1 oct 89 19:55:00 From: derstad@cim-vax.honeywell.com ("DAVE ERSTAD") Subject: DSEE Model Problem Here's one we'll try on this list. The hotline to date has not been too helpful: I've got a file which I wish to be a source dependency in some blocks, and will also be built in an element block. Something likd ELEMENT foo @ foo_lib; ELEMENT foobar @ foo_lib = DEPENDS_SOURCE foo @ foo_lib; END OF foobar; ELEMENT footoo @ foo_lib = DEPENDS_SOURCE foo @ foo_lib; END OF foobar; ELEMENT foo2 @ foo_lib = DEPENDS_RESULT foo; END OF foo2; When I try this, I get an error citing the ELEMENT declaration of foo, and each place it is used as a SOURCE dependency, indicating that the foo block lacks a PROMOTE_DEPENDS or MACRO declaration. Removing the ELEMENT foo block removes this error. I do not want to use a PROMOTE_DEPENDS, and MACRO provides the wrong functionality. The question is, is there any valid reason for this behaviour? I can't find any justification in the documentation. My guess is that since a block_id can be used in a DEPENDS_SOURCE declarations (I've never totally figured out why that was) that the model compiler is having problems with the scope of foo. It seems to me, however, that since the DEPENDS_SOURCE indicates that the use of foo in that context comes from "@ foo_lib" that the scope is unambiguous - the source dependency msut refer to the element and the results dependency to the \ block-id. Any help on how to work around this problem? As I noted, I do not want to use a PROMOTE_DEPENDS; also, hiding one of the uses of foo using hierarchy is not an option in this case. Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com ====================================================================== Post to info-dsee@apollo.com Administrative mail to info-dsee-request@apollo.com ====================================================================== ------- From apollo-request@umix.cc.umich.edu Fri Oct 6 17:23:10 1989 Date: 6 Oct 89 15:57:00 GMT From: pcc%apollo%hp-sdd%ncr-sd%ncrcae%hubcap.uucp@gatech.edu (Peter Craine) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Sendmail hole (?) Message-Id: <461142ab.20b6d@apollo.HP.COM> References: <46098421.81da@digital.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <46098421.81da@digital.sps.mot.com> chen@digital.sps.mot.com (Jinfu Chen) writes: >People at comp.virus are getting quite excited about the coming "Friday the 13th" >(Oct 13th). This reminds me the infamous ARPANET-worm last November, so I just >tried the following to our SMTP gateway node (running SR10.1.0.4), and to my >surprise: > [sendmail DEBUG stuff deleted] > >Should I get panic?! I don't know if the "DEBUG" command in this version of >SMTP from Apollo is immune to the ARPANET worm. Could someone from Apollo >verify this? > >One of the recent Apollo patch is related to `fingerd' and the document says >it's been inoculated against the virus publicized on USENET. Does this apply >to sendmail? > >-- You don't have to panic. Sendmail is inoculated at SR10.2 so that THAT virus attack won't work (unless you use the undocument, unsupported option that I'm not going to talk about). Theoretically, if somebody did enough work, they could find a way to get the old internet virus to work against SR10.0 and SR10.1 systems. But the attack would be very difficult to engineer (I'm reasonably sure). I'm not going to go into a dissertation about how that virus (worm, actually) worked, but it's a tad more difficult than it would be on a "real UNIX" system. I'm not going to say anything stupid like "Gee, our system is impervious to attack" (I'll wait while you finish laughing), but that particular attack isn't as easy as some people believe. BTW, the hole in fingerd that we fixed was that fingerd never checked how long the data was that was being passed to it. There is now an (enforced) limit. [flame suit on] Peter Craine, NACS *I* don't wany my own opinions. Why would HPOLLO want them? From apollo-request@umix.cc.umich.edu Fri Oct 6 17:28:29 1989 Date: 5 Oct 89 22:41:48 GMT From: news%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%gryphon%hacgate%usc.uucp@BLOOM-BEACON.MIT.EDU (Dave Hayes) Organization: Jet Propulsion Laboratory Subject: Re: the deafening silence Message-Id: <1989Oct5.224148.19484@elroy.jpl.nasa.gov> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In the past few weeks I have noticed a marked discrepancy between the amount of questions asked on this newsgroup and the amount of answers received. I have recently posted an article to which I have gotten no response. This leads me to ask "Is this newsgroup alive?" "Does APOLLO listen?" "Does APOLLO care?" I can see that there may be some questions which have no real answers. But fully half of the queries posted here are met with the kind of silence that makes one think that one's post did not get through to everybody. Certainly if none of us users know the answer, someone from APOLLO (and some of these people have posted in the past) would be in a position to provide needed answers. Or at least a "Well, hey, got your message and we're working on it/looking at it/thinking about it/etc." But, alas, maybe I have too much faith in the good side of human nature. For certainly no one has to respond to anything. Maybe I expect too much. -Dave Hayes dave%jplopto@jpl-mil.jpl.nasa.gov From apollo-request@umix.cc.umich.edu Fri Oct 6 21:17:55 1989 Date: 6 Oct 89 23:39:15 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: Apollo won't release rbak/wbak format. grrr. Message-Id: References: <26979@iuvax.cs.indiana.edu>, <46080999.14df5@ulsoy.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have been following this discussion and seem to remember that one of the problems had to do with the index and wbak data being mixed on the stdout. Well I just finished some monthly backups from our Apollos to Sun 8mm tape. Remebering this problem I checked the tapes and they are fine. Now I need to qualify what I did. The latest version of SR10 states in the release notes that you can use the '-remote node:device' option to write to a remote tape device. Well on our DN4000, SR10.1.1.2, it accepts this option, but fails the login. I gave up after several ideas, need to call Apollo. Our DN10000, SR10.1, does not even recognize this option. So I used a PD rmt package to write two cat-like routines to go from stdin -> remote tape and remote tape -> stdout. So on the 10000 I made the monthly backups as follows. 1. In a script I do a little book keeping and then invoke wbak: wbak //node_id -ld -pdtu -nhi -full -stdout | rmtwrt sun:/dev/rst0 2. The script is run manualy :( as follows: backup-script |& tee month-log >From this setup, I get the wbak data written on the Sun 8mm drive and the wbak index in the month-log file. To check that this worked, I reversed the process like so: rmtrd sun:/dev/rst0 | rbak -index -all -stdin Which gave me a nice index as would be expected. Now the catch! When I try this from the DN4000, it fails badly. The tape seems to end up with either the index or bad data, which may be what the previous complaint was about. Apparently the wbak option -stdout does not work, again I need to call Apollo. To confirm this, I just tried running wbak -stdout with no piping, which I would expect to dump bits all over my lap, but it just said it was dumping the files. I have no idea where the binary data was going. On the 10000 this did what I expected, bits in my lap. Now you may start wondering why the tape is not messed up, so was I. However, I think what happens is that wbak writes its messages to stderr and the data to stdout if the -stdout option is used. If anyone from Apollo would like to help enlighten us further, please do so. I'll probably give them a call next week anyway. Alan Bair SPS CAD Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Sat Oct 7 09:22:53 1989 Date: 5 Oct 89 23:12:00 GMT From: alan%procase%tolerant.uucp@ucbvax.Berkeley.EDU (Alan M. Steinberg) Organization: proCASE Corporation, Santa Clara, CA Subject: Re: SR10.1 / TCP / UUCP Message-Id: <460dc00e.10297@scheme> References: <8910022135.AA12864@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > From: naugle%dover%oakhill%cs.utexas.edu%mailrus.uucp@tut.cis.ohio-state.edu > Has anyone successfully gotten the UUCP distributed with Apollo's > SR10.1 to work over a TCP connection? The documentation looks very > poor. The UUCP distributed is the HoneyDanBer version (BNU) which > looks like it should, but there is *no* explicit mention of doing > this. The manual supplied (Managing BSD System Software) with the > release goes into vague detail and has no living examples. (there > is one mention of an old file - /usr/lib/uucp/uucico.real - which > doesn't exist and I believe it is a hold over from sr9.5 Unix) Today I discovered that the Managing BSD manual says to use uucico.real for the uucp login shell, BUT the man page for uucico says that in SR10 uucico.real is not used. Someone must have done a poor job of editing. I will presume that the man page is correct. -- Alan Steinberg tolerant!procase!alan Helllllp, Mr. Wizarrrrrrd!!! I don't wanna be a system administratorrrrrr..." From apollo-request@umix.cc.umich.edu Sat Oct 7 19:35:41 1989 Message-Id: <8910072136.AA02071@umix.cc.umich.edu> Date: 7 Oct 89 16:20:00 CST From: "DAVE ERSTAD" Subject: Re: The deafening silence To: "apollo" > > In the past few weeks I have noticed a marked discrepancy between > the amount of questions asked on this newsgroup and the amount of > answers received. > > I have recently posted an article to which I have gotten no response. > > This leads me to ask "Is this newsgroup alive?" "Does APOLLO listen?" > "Does APOLLO care?" > > I can see that there may be some questions which have no real answers. > But fully half of the queries posted here are met with the kind of > silence that makes one think that one's post did not get through to > everybody. > > Certainly if none of us users know the answer, someone from APOLLO (and > some of these people have posted in the past) would be in a position > to provide needed answers. Or at least a "Well, hey, got your message > and we're working on it/looking at it/thinking about it/etc." > > But, alas, maybe I have too much faith in the good side of human nature. > For certainly no one has to respond to anything. Maybe I expect too much. > > -Dave Hayes > dave%jplopto@jpl-mil.jpl.nasa.gov I would not necessarily bash those people from Apollo who have responded in the past. As far as I'm aware, those folks are all interacting with this news group in an unofficial capacity. Thus, when I get a response from a system programmer at Apollo, I regard that as a privilege, not a right. I appreciate the fact they spend time to help us out, and don't expect them to solve all of our problems. One might argue that Apollo should have someone officially monitor the group, but that's not necessarily better than sending E-Mail APRs directly to Apollo since probably the same group of people would handle it (although it sure wouldn't hurt). I'd rather see Apollo spend effort and money improving the customer service group on hotline. I realize the volume of calls they get require some form of "triage," but In the last three months, I've had the following experiences: o Had a support person admit he doesn't know the answer, run down the hall to ask someone else, return with another question, have me provide the answer, run down the hall again, return with another followup question, etc., without allowing me to talk directly to the second person involved. (I'm pretty sure I know who he was talking to; I've talked to her before and in a small fraction of the time it actually took we could have resolved the issue) o Had a support person answer a question with a fairly definite response ("I'm almost positive that...") and, after a half hour of followup discussion, I finally realized that he didn't understand the question, didn't actually have the foggiest idea what the answer was, and should have known he was speaking out of his depth. o Had difficult times getting in touch with a number of different support people on different occasions, leading me to suspect that they're understaffed, at least in the areas of most interest to me (DSEE, Domain/Dialog, Compilers, and OS) I don't expect every support person to know everything, but it would be nice if the recognized the cases where the customer knows the product area better than they do, and pass the call promptly to someone who can help. In summary: o I personally consider this newsgroup more of a user forum, rather than a vehicle for communication with Apollo o The fact that there are questions unanswered should reflect on Apollo's customer service, rather than this newsgroup. What experiences do other have? Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Sun Oct 8 07:23:03 1989 Date: 8 Oct 89 09:52:32 GMT From: news%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc.uucp@ucsd.edu (Dave Hayes) Organization: Jet Propulsion Laboratory Subject: Re: The deafening silence Message-Id: <1989Oct8.095232.29536@elroy.jpl.nasa.gov> References: <8910072136.AA02071@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910072136.AA02071@umix.cc.umich.edu> derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") writes: >As far as I'm aware, those folks are all interacting with this >news group in an unofficial capacity. Thus, when I get a response from >a system programmer at Apollo, I regard that as a privilege, not a right. That's very good. I can respect that viewpoint, even though it differs from mine. Keep in mind it is really difficult to remember that when you are up to your whatever in system regeneration of other undocumented behavior and you are behind schedule. But...point well taken, for surely no one is forced to be on the net. Even looking at that particular point with more scrutiny, I would also tend to think that being able to communicate directly with users via a forum like this is a privilege of another sort. However, mutual respect is still a voluntary thing. The *real* meat of my gripe is that we are CUSTOMERS, yet we are not really treated like customers ought to be treated. The "right" we have (if any can be so forcibly imposed) is to be able to use the tools and systems that we purchase. In my opinion that also means we have the right to timely and informative answers to any questions or problems that interfere with our ability to use our systems. Perhaps my misconception is that I do not make any distinction between different vehicles of communication...besides, what better place to alleviate some of the pressure on their customer service then the net? >I appreciate the fact they spend time to help us out, and don't expect them >to solve all of our problems. I appreciate that too, damned good of those brave souls who monitor the net and help us poor folk out from time to time. Alas, unlike you, I am hoplessly idealistic about responses being able to solve problems. >One might argue that Apollo should have someone officially monitor the group, >but that's not necessarily better than sending E-Mail APRs directly to >Apollo since probably the same group of people would handle it (although >it sure wouldn't hurt). Really? How does one send E-MAIL APR's? Is that kind of mechanism set up? >I'd rather see Apollo spend effort and money improving the customer service >group on hotline. Actually, there is better bandwidth for that here on the net or through E-MAIL. Phone calls take up much more "real-time" than sending an E-MAIL message, wouldn't you agree? >In summary: Ok..I can do that too...good idea! > o I personally consider this newsgroup more of a user forum, rather > than a vehicle for communication with Apollo What better place to communicate to Apollo than a user forum? > o The fact that there are questions unanswered should reflect on > Apollo's customer service, rather than this newsgroup. What > experiences do other have? It should reflect upon Apollo's communication skills as a company. I'd say that a lot of the blame goes to Customer Service, but with proper use of available resources...a lot of good could happen! >Dave Erstad Dave Hayes From apollo-request@umix.cc.umich.edu Sun Oct 8 13:21:40 1989 Date: 8 Oct 89 17:55:41 GMT From: ix%cosmo2%unido%mcsun%cosmo.UUCP@uunet.uu.net (Redaktion ix) Organization: CosmoNet, D-3000 Hannover 1, FRG Subject: Character I/O &Starbase(HP) Message-Id: <4050@cosmo2.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Re Character Processing with HpWindows & Starbase Hi, everyone interrested... working with HPWindows and Starbase can be rather strange, especially when I tried to have I/O in a graphical window. The reason is that according to my experience the BACKSPACE and the DOT have got the same code (the same applies to RETURN/CR and the "9". I'd be very grateful, if anyone knew a more or less efficient solution for this. Thanks galore (in advance...) Henning Behme ix@cosmo.uucp From apollo-request@umix.cc.umich.edu Sun Oct 8 19:19:50 1989 Date: 8 Oct 89 20:58:46 GMT From: patw%leadsv%excelan.uucp@ames.arc.nasa.gov (Patrick L. Wigen) Organization: LMSC-LEADS, Sunnyvale, Ca. Subject: X Without DM Message-Id: <8136@leadsv.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am running X11R3 on a DN3000 under sr10 with only bsd4.3 loaded. Can someone tell me how to start X on the console with out first running dm then starting X? Thanks in advance for any help. Patrick L. Wigen Voice: (408) 756-9748 Lockheed Missiles & Space Co. ( patw@leadsv.UUCP ) Sunnyvale, Ca. ..{cae7780,sun!sunncal,savax}!leadsv!patw ********************************************************************* Disclaimer: My opinions are my own(mostly). Certainly not those of LMSC's. ********************************************************************* From apollo-request@umix.cc.umich.edu Sun Oct 8 22:35:57 1989 Date: 5 Oct 89 07:05:01 GMT From: sahayman@iuvax.cs.indiana.edu (Steve Hayman) Organization: Computer Science Department, Indiana University Subject: Re: Apollo won't release rbak/wbak format. grrr. Message-Id: <27200@iuvax.cs.indiana.edu> References: <26979@iuvax.cs.indiana.edu>, <46080999.14df5@ulsoy.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >Is knowledge of the internal format necessary? Why >not index the tape for a TOC? How do you gen >the tape in the first place? Our Exabyte tape drive is attached to a Sun. Right now I'm doing wbak -stdout ... | rsh sun-with-exabyte-drive dd of=/the/tape You can't do wbak -l -stdout ... | rsh sun ... because the list-of-files-saved is written to stdout, and vanishes down the pipe getting mixed in with the wbak stuff. Also I don't want to create the tape over the network and then do rsh sun dd if=/the/tape | rbak -stdin -index even though it would produce the index I want, because I don't want to send all the backed-up data over the network twice (once from Apollo to Sun to write the tape, once from Sun to Apollo to read it again and make the index.) This process is slow enough as it is ... I want to run a program on the sun that will read the tape and produce a TOC. Basically I want to do the equivalent of "rbak -stdin -index" on the Sun itself. Is there some obvious way to do this that I'm missing? Anyway, I don't see why the rbak format should be a big secret. Steve P.S. Thank you to Brian Holt for describing how "tar -A" works. From apollo-request@umix.cc.umich.edu Sun Oct 8 23:15:56 1989 Date: 9 Oct 89 00:23:10 GMT From: trb%stag%pwcs%nis.uucp@UMN-CS.CS.UMN.EDU ( Todd Burkey ) Organization: Mindtools ST Access Group, Plymouth, MN Subject: Re: STILL looking for FOLDED Message-Id: <1989Oct9.002310.16741@stag.UUCP> References: <1989Oct4.185737.5099@agate.berkeley.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1989Oct4.185737.5099@agate.berkeley.edu> laba-1aj@WEB.berkeley.edu (John Kawakami) writes: > >I'm still looking for the apollo version of FOLDED by Todd Burkey (trb@stag). >I have not been able to get mail thru to him, so I'm asking YOU. > >If you know where I can get the APOLLO version of FOLDED, please tell me. > >Are you out there trb?!? Yes, I am out here...I still haven't gotten around to sending folded off to the source and binary archives yet. Too many tie-ups at work lately. I'll try to get everything moved over to my Unix system and 'shar'ed together for release in the next week or two. The version that I will be sending out is 0.9e and is the version I have been using on Unix and the IBM PC for the last three months without any glitches. I haven't powered on my Atari ST for several months now, but I imagine that the ST version is fairly bug free as well. Sorry for the delay... -Todd Burkey pwcs!stag!trb From apollo-request@umix.cc.umich.edu Mon Oct 9 09:20:41 1989 From: tpfabian@nasamail.nasa.gov (THEODORE FABIAN) Date: Sat, 7 Oct 89 23:06 PDT Message-Id: Cc: Subject: RE: Re: the deafening silence X-Lines: 72 Regarding the following message.... ------------------------------------------------- In the past few weeks I have noticed a marked discrepancy between the amount of questions asked on this newsgroup and the amount of answers received. I have recently posted an article to which I have gotten no response. This leads me to ask "Is this newsgroup alive?" "Does APOLLO listen?" "Does APOLLO care?" I can see that there may be some questions which have no real answers. But fully half of the queries posted here are met with the kind of silence that makes one think that one's post did not get through to everybody. Certainly if none of us users know the answer, someone from APOLLO (and some of these people have posted in the past) would be in a position to provide needed answers. Or at least a "Well, hey, got your message and we're working on it/looking at it/thinking about it/etc." But, alas, maybe I have too much faith in the good side of human nature. For certainly no one has to respond to anything. Maybe I expect too much. -Dave Hayes dave%jplopto@jpl-mil.jpl.nasa.gov ------------------------------------------------- I think you've hit on a good point... Apollo is not listening.. it seems with the buyout by HP of Apollo, things have changed drastically... I was at the ADUS Conference in New Orleans a couple of weeks ago, and sadly, I think that the outcomes of the conference pretty much sealed the fate of ADUS.. it seems that the HP group, whose name escapes me at this time, want to swallow ADUS up.. Also, the wish list from last years ADUS Conference got only a meager set of cursory answers at this past conference... one only needs to imagine what this years wish list will yield in the way of answers next year.. if ADUS is around next year... btw... I'm interested in hearing about your thoughts on ADUS.. are you a member?? what did you think of the recent conference?? do you think the group will survive?? etc. etc. etc. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Thanks, * * * * Ted Fabian * * * * NASA Lewis Research Center * * Cleveland, Ohio * * * * phone: 216-433-6307 * * FTS: 297-6307 * * * * email: tpfabian@nasamail.nasa.gov * * tfabian@earth.lerc.nasa.gov * * tfabian@csd.lerc.nasa.gov * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From apollo-request@umix.cc.umich.edu Mon Oct 9 11:18:26 1989 Message-Id: <8910091405.AA12946@umix.cc.umich.edu> Date: Mon, 9 Oct 89 17:31 H From: Subject: rsh To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK Re: rsh We've a DSP90 sitting on both Domain Ring and Ethernet. I'm unable to get rsh to work from DSP90 to other nodes on the Ethernet side such as our Sun and HP9000. The error messages are "Login Incorrect" or "Permission Denied" if "-l" is specified. What puzzled me is that I can rsh from Sun and HP9000 (remsh) to DSP90, even between Sun and HP9000, but not from DSP90 to the rest. I've check the contents and access rights of /etc/hosts.equiv and .rhosts in the respective home dirs. They all appear ok to me. Is there anyone can help me please? We are running SR10.1 with default SYSTYPE=bsd4.3. --AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Mon Oct 9 11:24:03 1989 Date: Mon, 9 Oct 89 08:41:35 CDT From: Andrew M. Wescott Message-Id: <8910091341.AA01143@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: Exabyte Tape Drives for Domain Workstations Some of the talk about Apollo/Sun Wbak/Tar with Exabyte drives leads me to ask a question. This discussion concerned an Exabyte drive attached to a Sun Workstation, not an Apollo. I thought Apollo was one of the first workstation vendors to announce the Exabyte drives, but now it seems like they are very tardy in delivery. We now have Exabyte drives attached to everything from Mac IIs to VAX 8650s EXCEPT Apollos. I've had one on order for over 2 months, and they're telling me its on Engineering Hold and won't ship until November. What is the holdup ? I should have bought one from Workstation Solutions ! An exasperated cartridge tape user, Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Mon Oct 9 13:23:14 1989 Date: 9 Oct 89 15:35:27 GMT From: ebersman%software.org.uucp@uunet.uu.net (ebersman) Organization: Software Productivity Consortium, Inc., Herndon, Virginia Subject: GCC on Apollo SR9.7 Message-Id: <400@sunny.software.org> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Will GCC (V1.35) compile correctly on Apollo SR9.7? If so, what config should I use? Thanks. -- Paul A. Ebersman @ Software Productivity Consortium uunet!sunny!ebersman or ebersman@software.org ( The difference between practice and theory in practice is always greater than the difference between practice and theory in theory. ) From apollo-request@umix.cc.umich.edu Mon Oct 9 13:57:08 1989 Date: 9 Oct 89 15:35:27 GMT From: ebersman%software.org.uucp@uunet.uu.net (ebersman) Organization: Software Productivity Consortium, Inc., Herndon, Virginia Subject: GCC on Apollo SR9.7 Message-Id: <400@sunny.software.org> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Will GCC (V1.35) compile correctly on Apollo SR9.7? If so, what config should I use? Thanks. -- Paul A. Ebersman @ Software Productivity Consortium uunet!sunny!ebersman or ebersman@software.org ( The difference between practice and theory in practice is always greater than the difference between practice and theory in theory. ) From apollo-request@umix.cc.umich.edu Mon Oct 9 15:54:38 1989 Message-Id: <8910091759.AA00799@speedmetal.engin.umich.edu> To: dave%jplopto@jpl-mil.jpl.nasa.gov Cc: apollo@umix.cc.umich.edu Subject: Re: the deafening silence (And administrivia) In-Reply-To: Your message of 05 Oct 89 22:41:48 +0000. <1989Oct5.224148.19484@elroy.jpl.nasa.gov> Date: Mon, 09 Oct 89 13:59:19 -0400 From: paul killey This leads me to ask "Is this newsgroup alive?" "Does APOLLO listen?" "Does APOLLO care?" I'm afraid that recent uucp changes on umix may be to blame for some problems. I should have been more on the ball, etc. Maybe people could ax their questions again. But, alas, maybe I have too much faith in the good side of human nature. For certainly no one has to respond to anything. Maybe I expect too much. Dave, I'm afraid that your faith in accurately shuffling news and mail around has been misplaced! Let's give apollo another chance. Pretty soon, the apollo mailing list will be moving from umix.cc.umich.edu to caen.engin.umich.edu. the umix address will still work (the yale address still works!). I used to be at the comp center, which is where umix is. Now I am at CAEN, right across the street. I actually have been here since April. The apollo list will be run on an apollo machine (umix is a Vax 750). I think I am almost caught up on mailing list additions/deletions. Bark if you think I am not. --paul From apollo-request@umix.cc.umich.edu Mon Oct 9 16:04:19 1989 Date: 9 Oct 89 14:46:00 GMT From: marc%apollo%hp-sdd%ncr-sd%ncrcae%hubcap.uucp@gatech.edu (Marc Gibian) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: the deafening silence Message-Id: <4620194b.20b6d@apollo.HP.COM> References: <1989Oct5.224148.19484@elroy.jpl.nasa.gov> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu As the Project Engineer responsible for Apollo email software, I can say that I attempt to respond as quickly as possible to postings in this news group, or any other for that matter, when it seems appropriate. There are times when a private email response is more appropriate, and those too are sent as quickly as I can. There are times, though, that I am unable to do this a promptly as I would like... I am out of town for a week, I get assigned to something for a few weeks that prevents me from reading ANY news, even the most important groups, or I have to research a problem. In these cases, I will get a response out, it just takes longer than most of you would like, and in fact longer than I would like. I know there are many other Project Engineers that give this the same level of effort... but, as you could probably guess, we are rather busy right now. So we continue to do our best to keep up with news that needs responses... Marc S. Gibian Project Engineer, email project: Apollo Systems Division of HP Internet: marc@apollo.hp.COM NETel: Apollo: 508-256-6600 x2077 (Copyright 1989 by author. All rights reserved. Free redistribution allowed.) From apollo-request@umix.cc.umich.edu Mon Oct 9 16:07:26 1989 Message-Id: <8910091730.AA00689@speedmetal.engin.umich.edu> To: bgo%pbhya%pacbell%amdahl.uucp@ames.arc.nasa.gov Cc: apollo@umix.cc.umich.edu Subject: Re: Unix mail problem In-Reply-To: Your message of 20 Sep 89 23:06:02 +0000. <30030@pbhya.PacBell.COM> Date: Mon, 09 Oct 89 13:30:35 -0400 From: paul killey We have about 460 users on 86 nodes. All of the Unix mail is located on one node (//s5/sys5/usr/mail). % wc -l /etc/passwd 6684 /etc/passwd % % ls -l /usr/spool/mail lrwxrwxrwx 1 root 28 Sep 29 23:43 /usr/spool/mail -> //mail/bsd4.3/usr/spool/mail % ls -lL /usr/spool/mail | wc 4067 32530 214157 % We run sendmail.5.59 plus some changes on the apollos. 5.61 with the same kind of changes applied will be installed pretty soon, I hope. The nature of the changes are for concurrency control when doing file i/o and in dealing with temporary failures when verifying addresses (rgy down, alias file not available, etc.). I changed sendmail, binmail, /usr/ucb/mail, and MH to co-operate in this endeavor. I also made a couple changes to dbm, and have sendmail not using dbminit(), but dbm_open() instead. My colleague and unindicted mail co-conspirator, Mark Giuffrida, has made every effort to get our code sprung out, but I have turned out to be quite an immovable object in this regard. But a current project is to get sendmail on all our platforms (Sun, Dec, apollo) to compile and run from the same set of source, and I will make that available. I'm *really* almost done! Thanks to some work at Berkeley, other source code has been declared to be free of AT&T license restrictions (like binmail, I believe) and I assume that will make it easier for people to deal with things. I understand a freely distributable version of dbm routines is coming down the pike as well (not from Berkeley). --paul From apollo-request@umix.cc.umich.edu Mon Oct 9 16:14:08 1989 Date: 9 Oct 89 17:53:00 GMT From: oj%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: bug alert - /lib/ftnlib Message-Id: <4620c106.20b6d@apollo.HP.COM> References: <8910031938.AA01386@civilgate.ce.uiuc.edu>, <462073b7.208ba@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910031938.AA01386@civilgate.ce.uiuc.edu> lray@CIVILGATE.CE.UIUC.EDU (Ray) writes: >>If you have PATRAN on your system, do not use any ftnlib other >>than the 10.1 FCS ftnlib. Otherwise, you will break Patran. >>The problem is a DN10k bug that crept into the 68000 stuff somehow. The offending ftnlib is the one shipped with the new compiler version. It seems you don't have to install the ftnlib when you install the new compilers. If you're a PATRAN user, don't install the new ftnlib. I logged an internal bug on this. It's OK for someone else to file an APR. The SR10.2 ftnlib (I know, most of you don't care yet) is OK. Do you mind doublechecking that, Ray? /Ollie Jones (speaking for myself, not necssarily for HP Apollo Systems Div.) From apollo-request@umix.cc.umich.edu Mon Oct 9 16:20:42 1989 Date: 9 Oct 89 16:27:00 GMT From: oj%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: bug alert - /lib/ftnlib Message-Id: <462073b7.208ba@apollo.HP.COM> References: <8910031938.AA01386@civilgate.ce.uiuc.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910031938.AA01386@civilgate.ce.uiuc.edu> lray@CIVILGATE.CE.UIUC.EDU (Ray) writes: > >If you have PATRAN on your system, do not use any ftnlib other >than the 10.1 FCS ftnlib. Otherwise, you will break Patran. >The problem is a DN10k bug that crept into the 68000 stuff somehow. The DN10000 ftnlib problem was fixed last July. The application (PDA's PATRAN in this case) reads an unknown-format file with unformatted IO, hoping to take the ERR=9999 escape from the READ statement to find out that the file is in fact formatted. Something somebody did to /lib/ftnlib for sr10.1.p broke this, and we had to scramble to fix it. If (and only if) you have this problem with your DN10000, please call your friendly customer service person and mutter the incancation "performing a read of a formatted file with unformatted I/O caused a fault." The implication in the news article is that the problem has cropped up on M68K machines. Please please please call in a bug on this if it has in fact happened. I will test it now on a local sr10.2 node to see if SR10.2's ftnlib has the problem. >I've also got a call in to PDA about this, and am going to scream >loudly until it is fixed. Don't wear out your voice unnecessarily. We also respond to gentle requests, you know. :-) /Ollie Jones From apollo-request@umix.cc.umich.edu Mon Oct 9 18:05:35 1989 Date: Mon 9 Oct 89 13:12:43-PST From: Steve Albrecht Subject: Re: The deafening silence To: news%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc.uucp@ucsd.edu Cc: apollo@umix.cc.umich.edu Message-Id: <623967163.560000.ALBRECHT@CALIPH> In-Reply-To: <1989Oct8.095232.29536@elroy.jpl.nasa.gov> Mail-System-Version: Submitting APRs vua UUCP is documented with MKAPR (Make APR) on page 2-277 of AEGIS COMMAND REFERENCE, Order # 002547-A00 for those of you with SR10 manuals. I have used addresses to particular support people in the past, which was quite convenient. (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ) Steve Albrecht - IntelliCorp, Inc. - Knowledge Systems Product Development ) ( "Opinions expressed here are my own, if anyone's, and not my employer's." ( ) DDS albrecht@intellicorp.com : COMPUSERVE 73657,1342 ( ( UUCP ...!sun!intellicorp.com!albrecht : public bbs (415)969-5643 ) ) or ...!sun!icmv!albrecht : "c"omment to sysop ( (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ------- From apollo-request@umix.cc.umich.edu Mon Oct 9 18:08:38 1989 Date: 9 Oct 89 20:24:22 GMT From: jozwiak%cpsvax%cps3xx%eecae%tank.uucp@speedy.wisc.edu (Susan J Jozwiak) Organization: Michigan State University, Computer Science Department Subject: Apollo Network Computing System Message-Id: <4916@cps3xx.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, I was wondering if anyone out there has knowledge/experience using Apollo's Network Computing System. It is a way of distributing the work load for programs, etc. across various machines (i.e. utilizing the cpu's to the max to get a job done). Some questions in my mind are 1) how well does it perform in actuality, 2) how hard is it to get up and running on (say for example) a network of suns? I am looking to answers to these and many other questions. Any input on this subject would be greatly appreciated. Please e-mail me at jozwiak@cpsvax.cps.msu.edu. Thanks. Sue Jozwiak From apollo-request@umix.cc.umich.edu Mon Oct 9 18:13:47 1989 Date: Mon 9 Oct 89 12:52:00-PST From: Steve Albrecht Subject: Re: The deafening silence To: derstad@cim-vax.honeywell.com Cc: apollo@umix.cc.umich.edu Message-Id: <623965920.490000.ALBRECHT@CALIPH> In-Reply-To: <8910072136.AA02071@umix.cc.umich.edu> Mail-System-Version: In reply to... >Date: 7 Oct 89 16:20:00 CST >From: "DAVE ERSTAD" >> >> In the past few weeks I have noticed a marked discrepancy between >> the amount of questions asked on this newsgroup and the amount of >> answers received. >> >> I have recently posted an article to which I have gotten no response. >> >> This leads me to ask "Is this newsgroup alive?" "Does APOLLO listen?" >> "Does APOLLO care?" >> >> I can see that there may be some questions which have no real answers. >> But fully half of the queries posted here are met with the kind of >> silence that makes one think that one's post did not get through to >> everybody. >> >> Certainly if none of us users know the answer, someone from APOLLO (and >> some of these people have posted in the past) would be in a position >> to provide needed answers. Or at least a "Well, hey, got your message >> and we're working on it/looking at it/thinking about it/etc." >> >> But, alas, maybe I have too much faith in the good side of human nature. >> For certainly no one has to respond to anything. Maybe I expect too much. >> >> -Dave Hayes >> dave%jplopto@jpl-mil.jpl.nasa.gov > >I would not necessarily bash those people from Apollo who have responded in >the past. As far as I'm aware, those folks are all interacting with this >news group in an unofficial capacity. Thus, when I get a response from >a system programmer at Apollo, I regard that as a privilege, not a right. >I appreciate the fact they spend time to help us out, and don't expect them >to solve all of our problems. I agree completely with Dave Erstad on this. >One might argue that Apollo should have someone officially monitor the group, >but that's not necessarily better than sending E-Mail APRs directly to >Apollo since probably the same group of people would handle it (although >it sure wouldn't hurt). I disagree. It is illegal to conduct business over the InterNet. This is a common offense, for which I rarely grieve. You can't expect Apollo to sanction illegal activity. >I'd rather see Apollo spend effort and money improving the customer service >group on hotline. I realize the volume of calls they get require some >form of "triage," but > >In the last three months, I've had the following experiences: > > o Had a support person admit he doesn't know the answer, run down the > hall to ask someone else, return with another question, have me > provide the answer, run down the hall again, return with another > followup question, etc., without allowing me to talk directly to > the second person involved. (I'm pretty sure I know who he was > talking to; I've talked to her before and in a small fraction > of the time it actually took we could have resolved the issue) Having "graduated" from a customer support position where I spent two years answering customer questions regarding their use of our company's software products, I have a somewhat different perspective. The breadth and complexity of the products is such that it took me 4-6 months to achieve a level of competence where I could produce answers to 80% of customer question within one hour and without appealing for help from the software engineers. If I had deferred all "hard" questions directly to software engineers, I would have remained incompetent much longer and their for would have disappointed many more customers. Customer support is only learned by doing. I might add that making the engineers do customer support directly causes a hit on their productivity. This translates into slower patch availability and late(r) releases of new products and upgrades. For the last year I've been doing software engineering for the same company. I thank my lucky stars that the support staff takes the initiative to learn to answer the hard questions; thus allowing me to do my job. > o Had a support person answer a question with a fairly definite > response ("I'm almost positive that...") and, after a half hour > of followup discussion, I finally realized that he didn't > understand the question, didn't actually have the foggiest > idea what the answer was, and should have known he was > speaking out of his depth. I hope that this person was on the early end of the learning curve, and will learn from this mistake. Of course, I was never guilty of that. ;-) > o Had difficult times getting in touch with a number of different > support people on different occasions, leading me to suspect > that they're understaffed, at least in the areas of most > interest to me (DSEE, Domain/Dialog, Compilers, and OS) Customer support positions are great learning opportunities, but are not the highest paying. You can't expect a person with a Master's in C.S. to remain in this role very long. It is a fairly high pressure job, as well, so those who can't move up generally move out within two years. (I don't know the specifics regarding turnover at Apollo, but feel that my experience is typical.) >I don't expect every support person to know everything, but it would be >nice if the recognized the cases where the customer knows the >product area better than they do, and pass the call promptly to >someone who can help. I have not had to communicate any problems to Apollo (yet) in which I needed the solution urgently and immediately. I would hope that truly urgent requests of the form "my demo is this afternoon, and I absolutely rely on does not work as expected in " get sent up the ladder within minutes. Here we rely on our highly skilled staff to be available in times of dire need. In return, we avoid crying "wolf" when urgency is not required. I expect to have my calls returned with meaningful assistance within 24 hours, and a solution within two or three days. In the three years of work on Apollo machines, I can't remember receiving less service than this. As long as I get the help I need in a reasonably timely fashion, I don't care if the support person had to seek out assistance, or worked it out for [him/her]self on an abacus. (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ) Steve Albrecht - IntelliCorp, Inc. - Knowledge Systems Product Development ) ( "Opinions expressed here are my own, if anyone's, and not my employer's." ( ) DDS albrecht@intellicorp.com : COMPUSERVE 73657,1342 ( ( UUCP ...!sun!intellicorp.com!albrecht : public bbs (415)969-5643 ) ) or ...!sun!icmv!albrecht : "c"omment to sysop ( (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ------- From apollo-request@umix.cc.umich.edu Tue Oct 10 01:58:51 1989 Message-Id: <8910100530.AA20356@umix.cc.umich.edu> Date: Tue, 10 Oct 89 13:24 H From: Subject: RE: Server Process Manager (SPM) To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK The subject of my previous posting was wrong. It should have been "Printer Driver (prsvr)". Apologize for the mistake. --AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Tue Oct 10 03:57:08 1989 Message-Id: <8910100624.AA21119@umix.cc.umich.edu> Date: Tue, 10 Oct 89 14:18 H From: Subject: RE: INPROT & ACl To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK Re: INPROT & ACLs There was a posting about INPROT & ACL not long ago. I wonder whether there is a ACL template available now? The default ACLs provided by SR10.1 seems to be very loose. Many dirs can be accessed by the world with 'w' right. I'm afraid the system would crash in no time if I try to paste them. A ACL template will be very handy. --AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Tue Oct 10 03:59:01 1989 Message-Id: <8910100313.AA17547@umix.cc.umich.edu> Date: Tue, 10 Oct 89 11:07 H From: Subject: Server Process Manager (SPM) To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK After having read the recent postings on "the deafeaning silence", I repost my mail here. Hope that someone would help. BTW, this is my first posting ever. I'd got a response for my second posting on SPM thru' private mail. Thanks. Here you go.... 1) We've a Seikosha dot-matrix printer connected to a SR10.1 node running BSD4.3. We used 'genicom' device driver in our prsvr configuration file. After having setup prsvr & prmgr, our text files can be printed on the Seikosha printer using prf, but almost every printed line is prefixed with 120e0m. (I presume it's genicom printer control code.) Right now we use 'prf -trans' to print our text files, that means we lost all the good features of prf such as -head, -banner & etc. Q: Is there a way to substitute the genicom control codes by other dot-matrix printer control codes? How? Q: Is there a generic device driver available for printing text file on a dot-matrix or line printer which has a serial/RS232 port? 2) I've tried to build a simple device driver by following the example shown in 5.1.2 of "Printing in the Aegis Environment". I encountered the following problem during bind: Unresolved globals: add_db_range_c First referenced in driver_ex.bin add_db_value_c "" get_db_value_c "" inq_entry_c "" Q: Where is the lib for there routines? 3) What is TML as mentioned in "Printing in the Aegis Environment"? 4) We've managed to set up lpd in a separate testing. We're able to get lpr to work w/o prsvr & prmgr. The problem is that the output is in double spacing. Any body knows how to fix it? Thanks for your helps in advance. --AnnKian Yeo Email: YEOAK@NUSDISCS.BITNET or YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Tue Oct 10 05:16:40 1989 Date: 10 Oct 89 04:02:23 GMT From: robert%aragorn.cm.deakin.oz.au%charlie%murtoa.cs.mu.oz.au%munnari.oz.au.uucp@uunet.uu.net (Robert Ruge) Organization: Department of Computing & Mathematics - Deakin University Subject: Apollo NFS V2.0 Message-Id: <7847@charlie.OZ> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am hoping that somebody can help me with an NFS installation problem that I am having. I am running SR10.1 on a 3010 and have had troubles getting NFS running. I can mount the apollo root directory and access all its files from another unix system but I cannot get a unix filesystem mounted onto the apollo. I need to mount some user filesystems onto the apollo because it only has an 80Mb disk and it is becoming desperately short on space. The message I get from a 'mount -o soft aragorn:/u /u' is 'nfsmount returned in error', and when I run nfsmount itself or even showmount I get an 'IOT Trap' message. Does anybody have any idea what could be causing the problem or how to fix it? Any pointers would be greatly appreciated. Why is it that every time I work on our (only) apollo I experience extreme depression?? Is it the contorted installation procedures, the pathetic installation manuals, or just me?? Anyway you don't have to answer that, but any tips on my other problem would be appreciated. Thanks. Robert Ruge | UUCP: {uunet,mcvax,ukc,ubc-cs Computing/Maths | nttlab}!munnari!aragorn.oz!robert Deakin University | ARPA: robert@aragorn.OZ.AU Victoria, 3217 | CSNET: robert@aragorn.OZ.AU Australia | ACSNET: robert@aragorn.oz PHONE: +61 52 471319 Robert Ruge robert@aragorn From apollo-request@umix.cc.umich.edu Tue Oct 10 07:20:17 1989 Date: 8 Oct 89 18:14:45 GMT From: goldfish%cspolo%clyde%mcgill-vision.uucp@bloom-beacon.mit.edu (Paul Goldsmith) Organization: Concordia University, Montreal Quebec Subject: Re: the deafening silence Message-Id: <1341@clyde.Concordia.CA> References: <1989Oct5.224148.19484@elroy.jpl.nasa.gov> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1989Oct5.224148.19484@elroy.jpl.nasa.gov> dave%jplopto@jpl-mil.jpl.nasa.gov writes: > In the past few weeks I have noticed a marked discrepancy between > the amount of questions asked on this newsgroup and the amount of > answers received. > ... > This leads me to ask "Is this newsgroup alive?" "Does APOLLO listen?" > "Does APOLLO care?" > > ... > > Certainly if none of us users know the answer, someone from APOLLO (and > some of these people have posted in the past) would be in a position > to provide needed answers. Or at least a "Well, hey, got your message > and we're working on it/looking at it/thinking about it/etc." Dave ( and anyone else out there who is listening) Yes there are people out here who hear you. Unfortunately, my inquiries with Apollo get only that: - they neither acknowledge the use of internet, nor - officially support its use. I have spent some time talking on the phone with "the powers that be" at Apollo and while they always respond politely, the issue of providing hard information to knowledgeable customers seems to create some difficulties. Several of their people have undertaken to post comments to this group, however, I believe this is on an unofficial basis only. Perhaps the thing to do is for EVERYONE reading this group to dial the customer support 800 number and verbally register a request to have an official Apollo representative posting to this group. Perhaps that should be accompanied by a letter from your organizations' purchasing officer... A while back a Mr. Jim Wright offered to provide an anonymous FTP site for the almost mythical Apollo patch tapes and other Apollo specific data of a general interest. I have seen nothing since his original posting, though he did reply to my note thanking him for his initiative. (What is happening on that front Jim?) While we keep hearing that Apollo is now part of HP and "eventually" the support issue will be delt with, "eventually" we will all be dead; and systems run in the present tense. I encourage anyone at Apollo to comment on this posting. I challenge Apollo to post an official reply. Paul Goldsmith goldfish@concour.cs.concordia.ca - Goldfish (Shirley Maclaine told me there would be LIFETIMES like this) From apollo-request@umix.cc.umich.edu Tue Oct 10 17:01:16 1989 Date: Tue, 10 Oct 89 10:51:59 CDT From: Andrew M. Wescott Message-Id: <8910101551.AA02478@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: C++ on the DN10000 Status: O We have someone here interested in a dn10k, but they are hung up on C++. So could someone more enlightened than I shed some light on the staus of Apollo's C++ product on the dn10k, as well as the availability of GNU's C and C++. Thanks, Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Tue Oct 10 17:03:07 1989 Date: 10 Oct 89 13:58:24 GMT From: roode%hydra.cf.uci.edu%orion.oac.uci.edu%uci-ics.uucp@cs.ucla.edu (Dana Roode) Organization: University of California, Irvine Subject: Startup files under Aegis 9.7 Message-Id: <3420@orion.cf.uci.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O We've been running a group of Apollo DN3000 and 3500s running 10.1 for sometime, but recently we've had to help some folks with their DN3000s (1 3500) running Aegis 9.7. Im having a hard time figuring out how the startup files work - in particular, which ones are executed when and how the system determines this. Picking a startup file depends on the "type" of system - how can I verify what "type" a system thinks it is? One particular case is a diskless DSP node that, according to my interpretation of the manuals, should run /sys/node_data/startup.spm. I make changes to that file, they seem to be ignored. The other systems all have disks and monitors - they should execute startup.1280bw or .1280color? Where do startup.19l and startup.color fit in? Please reply directly to me, as I might miss entries to this newgroup. Any help would be greatly appreciated, kind comp.sys.apollo folks have made more sense to me than all of the Apollo manuals put together. Dana Roode Academic Computing UC Irvine From apollo-request@umix.cc.umich.edu Tue Oct 10 17:07:27 1989 Date: 10 Oct 89 18:45:27 GMT From: majka%moose.cs.ubc.ca%ubc-cs%van-bc.uucp@uunet.uu.net (Marc Majka) Organization: UBC Department of Computer Science, Vancouver, B.C., Canada Subject: Re: Apollo NFS V2.0 Message-Id: <5223@ubc-cs.UUCP> References: <7847@charlie.OZ> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O In article <7847@charlie.OZ> robert@aragorn.cm.deakin.oz.au (Robert Ruge) writes: >... I am running SR10.1 on a 3010 and have had troubles >getting NFS running... >The message I get from a 'mount -o soft aragorn:/u /u' is 'nfsmount >returned in error', ... I haven't had this problem with NFS. Make sure that /u does *not* exist when you do the mount. Apollo NFS uses "gateway" type files for NFS mount points. It creates them on the fly. If you try something like: % mkdir /bar % mount foo:/bar /bar It will fail! Something else for us old UNIX hacks to remember. --- Marc Majka - System Manager UBC Computer Science From apollo-request@umix.cc.umich.edu Tue Oct 10 17:19:11 1989 Date: 10 Oct 89 19:09:31 GMT From: achille%cernvax%mcsun.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Re: The deafening silence Message-Id: <1114@cernvax.UUCP> References: <1989Oct8.095232.29536@elroy.jpl.nasa.gov>, <623967163.560000.ALBRECHT@CALIPH> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O As I asked 2 questions recently, I'd like to confirm that I got private e-mail from Apollo's nice guys, who helped me (thanks !). I have the answer to one of those questions, may be this can help other people: Q: rmt_scsi driver cannot be open from fortran for sequential unformatted access: A: bug in rmt_scsi fixed in a the next Omniback patch, sr10.2. To be fair, I'll say that I got very often e-mail from Apollo people when they could help. Achille Petrilli Cray & PWS Operations From apollo-request@umix.cc.umich.edu Tue Oct 10 18:59:56 1989 Date: 10 Oct 89 20:06:17 GMT From: seth@cs.ucla.edu (Seth Goldman) Organization: UCLA Computer Science Department Subject: GMF/GPR to postscript? Message-Id: <27943@shemp.CS.UCLA.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O I need to print gmf/gpr files to a postscript printer but I'm not running apollo's print server. I have a program I got a long time ago which generated postscript for inclusion in scribe documents and that used to work. Unfortunately our file servers have been dying lately and the sources are no longer available to me. Has anyone got an up to date (SR10.1) version that will take the file produced by CPSCR and generate postscript? Thanks in advance, Seth Goldman ARPA: seth@CS.UCLA.EDU UUCP: ...!{ihnp4,cepu,trwspp,sdcrdcf,ucbvax}!ucla-cs!seth USMail: A.I. Lab, 3531 Boelter Hall, UCLA, Los Angeles, CA 90024 From apollo-request@umix.cc.umich.edu Tue Oct 10 20:55:50 1989 Date: 10 Oct 89 18:47:00 GMT From: dawson%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Keith Dawson) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: X Without DM Message-Id: <4625f8c2.20b6d@apollo.HP.COM> References: <8136@leadsv.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O > I am running X11R3 on a DN3000 under sr10 with only bsd4.3 loaded. Can > someone tell me how to start X on the console with out first running > dm then starting X? It's not clear whether you got X.V11R3 from ADUS and are running on SR10.1, or built it yourself on SR10.0. But in neither case can you do what you're asking. At SR10.2, the product version of X -- the Domain/X11 "share-mode" server, which will be bundled with base software -- has latent support for starting up X without the DM. Here's how (I realize that few of you have SR10.2 yet): 1 - touch /etc/daemons/xdm 2 - edit /etc/ttys and change the line console "/etc/dm_or_spm" apollo on secure # use mkcon to redirect console output -- to -- console "/etc/dm_or_spm -x" apollo on secure # use mkcon to redirect console output 3 - edit /usr/X11/lib/xdm/Xservers and be sure that this exact line is present: :0 secure /bin/nice --10 /etc/Xapollo -D1 s+r+ Then reboot. This should start up xdm as your authenticator. Be sure that your password has been set with an SR10 registry; xdm won't allow login from sr9.7- encrypted passwords. When MIT ships X.V11R4, currently planned for December, you will be able to build and run it on any "vanilla" SR10.1 or SR10.2 system; and there will be support for starting X without the DM. ____________________________________________________________ My opinions Keith Dawson Hewlett Packard Co. 508-256-0176 x5739 are my own. Graphics Technology Division / East 300 Apollo Dr. (CHR.03.DE) Chelmsford, MA 01824 USA My convictions Internet: dawson@apollo.hp.com are not for UUCP: {mit-eddie,yale,uw-beaver}!apollo!dawson public display. From apollo-request@umix.cc.umich.edu Tue Oct 10 23:00:35 1989 Date: 11 Oct 89 00:24:28 GMT From: jwright%atanasoff%dino.uucp@uunet.uu.net (Jim Wright) Organization: Iowa State U. Computer Science Department, Ames, IA Subject: Re: the deafening silence (and archive sites) Message-Id: <1614@atanasoff.cs.iastate.edu> References: <1989Oct5.224148.19484@elroy.jpl.nasa.gov>, <1341@clyde.Concordia.CA> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O I'm just a tiny cog in the vast machine of Apollo sites, but I've made my share of squeaks in the past. I'd like to thank all Apollo folks for past and hopefully future support provided to net users. I really think this is the way to go. In article <1341@clyde.Concordia.CA> goldfish@cspolo.CS.Concordia.CA (Paul Goldsmith) writes: | | A while back a Mr. Jim Wright offered to provide an anonymous FTP site for the | almost mythical Apollo patch tapes and other Apollo specific data of a general | interest. I have seen nothing since his original posting, though he did reply | to my note thanking him for his initiative. (What is happening on that front | Jim?) I got ZERO response from anyone/anything at Apollo. The offer still stands, but I consider the ball to be in Apollo's court. In conjunction with comp.virus/VIRUS-L, we have established a number of archive sites throughout the world. These support various computers as well as holding back issues, documentation and tech reports. This past summer we added a number of sites to support Unix virus/worm/security issues. The archives include the Internet Worm reports, Sun patch tapes, various security fixes, etc. The "getting together" phase was just being wrapped up at the end of summer. Before the sites could be coordinated or filled with goodies, the academic year began. Traffic amongst the site coordinators lately has been low. The structure is there, but things haven't really taken off yet. I generally coordinate all the archives, but actively "head" the IBMPC sites. I don't have the time to dive into the Unix stuff as I would like to. Chris Myers has volunteered to head up the Unix archives. I'll include the current list of sites. Anyone with interest in this is invited to contact Chris or myself. Another contact would be Ken van Wyk, moderator of comp.virus/VIRUS-L. His job is with the Computer Emergency Response Team at CMU, and he would like to see comp.virus expand to include more Unix related discussion. (He's currently away for a few weeks, so be patient.) Chris Myers, chris@wugate.wustl.edu Ken van Wyk, krvw@sei.cmu.edu Jim Wright, jwright@atanasoff.cs.iastate.edu ------------------ # Anti-viral and security archive sites for Unix # Listing last changed 30 September 1989 # Note that this listing is preliminary, and will likely change. # I know the information is far from complete, but I thought it would # be a good idea to get this out now instead of wait. attctc Charles Boykin Accessible through UUCP. cs.hw.ac.uk Dave Ferbrache NIFTP from JANET sites, login as "guest". Electronic mail to . Main access is through mail server. The master index for the virus archives can be retrieved as request: virus topic: index For further details send a message with the text help The administrative address is netCS Hans Huebner netCS is a public access Unix site in Berlin which is also accessible through UUCP. sauna.hut.fi Jyrki Kuoppala Accessible through anonymous ftp, IP number 128.214.3.119. (Note that this IP number is likely to change.) ucf1vm Lois Buwalda Accessible through... wuarchive.wustl.edu Chris Myers Accessible through anonymous ftp, IP number 128.252.135.4. A number of directories can be found in ~ftp/usenet/comp.virus/*. -- Jim Wright jwright@atanasoff.cs.iastate.edu From apollo-request@umix.cc.umich.edu Wed Oct 11 00:54:29 1989 Message-Id: <8910110304.AA07620@umix.cc.umich.edu> Date: Wed, 11 Oct 89 10:57 H From: Subject: Re: INPROT & ACL To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK Status: O (I got a returned mail fr Postmaster@apollo.com. Im sending this again) Re: INPROT & ACLs There was a posting about INPROT & ACL not long ago. I wonder whether there is a ACL template available now? The default ACLs provided by SR10.1 seems to be very loose. Many dirs can be accessed by the world with 'w' right. I'm afraid the system would crash in no time if I try to patch them. A ACL template will be very handy. --AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Wed Oct 11 00:57:32 1989 Message-Id: <8910110301.AA07530@umix.cc.umich.edu> Date: Wed, 11 Oct 89 10:54 H From: Subject: rsh To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK Status: O (I got returned mail fr Postmaster@apollo.com. Im sending again) Re: rsh We've a DSP90 sitting on both Domain Ring and Ethernet. I'm unable to get rsh to work from DSP90 to other nodes on the Ethernet side such as our Sun and HP9000. The error messages are "Login Incorrect" or "Permission Denied" if "-l" is specified. What puzzled me is that I can rsh from Sun and HP9000 (remsh) to DSP90, even between Sun and HP9000, but not from DSP90 to the rest. I've check the contents and access rights of /etc/hosts.equiv and .rhosts in the respective home dirs. They all appear ok to me. Is there anyone can help me please? We are running SR10.1 with default SYSTYPE=bsd4.3. --AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Wed Oct 11 00:59:50 1989 Message-Id: <8910110257.AA07489@umix.cc.umich.edu> Date: Wed, 11 Oct 89 10:50 H From: Subject: Printer Server (prsvr) To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK Status: O (I got a returned mail from Postmaster@apollo.com. Im sending this again) After having read the recent postings on "the deafeaning silence", I repost my mail here. Hope that someone would help. BTW, this is my first posting ever. I'd got a response for my second posting on SPM thru' private mail. Thanks. Here you go.... 1) We've a Seikosha dot-matrix printer connected to a SR10.1 node running BSD4.3. We used 'genicom' device driver in our prsvr configuration file. After having setup prsvr & prmgr, our text files can be printed on the Seikosha printer using prf, but almost every printed line is prefixed with 120e0m. (I presume it's genicom printer control code.) Right now we use 'prf -trans' to print our text files, that means we lost all the good features of prf such as -head, -banner & etc. Q: Is there a way to substitute the genicom control codes by other dot-matrix printer control codes? How? Q: Is there a generic device driver available for printing text file on a dot-matrix or line printer which has a serial/RS232 port? 2) I've tried to build a simple device driver by following the example shown in 5.1.2 of "Printing in the Aegis Environment". I encountered the following problem during bind: Unresolved globals: add_db_range_c First referenced in driver_ex.bin add_db_value_c "" get_db_value_c "" inq_entry_c "" Q: Where is the lib for there routines? 3) What is TML as mentioned in "Printing in the Aegis Environment"? 4) We've managed to set up lpd in a separate testing. We're able to get lpr to work w/o prsvr & prmgr. The problem is that the output is in double spacing. Any body knows how to fix it? Thanks for your helps in advance. --AnnKian Yeo Email: YEOAK@NUSDISCS.BITNET or YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Wed Oct 11 05:19:12 1989 Date: 11 Oct 89 08:56:19 GMT From: news%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%ginosko%uakari.primate.wisc.edu%ctrsol%cica. (Dave Hayes) Organization: Jet Propulsion Laboratory Subject: Re: Re: the deafening silence Message-Id: <1989Oct11.085619.23858@elroy.jpl.nasa.gov> References: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O In article tpfabian@nasamail.nasa.gov (THEODORE FABIAN) writes: > btw... I'm interested in hearing about your thoughts on ADUS.. > are you a member?? what did you think of the recent conference?? > do you think the group will survive?? etc. etc. etc. > > Sadly, I am not a member of ADUS. If I only had the time, I would be. I spend all my time hacking APOLLO systems.... As an example, it is...oh...about 1:30AM at the time I post this. -Dave Hayes No .sig till I get my APOLLO's up on the internet. From apollo-request@umix.cc.umich.edu Wed Oct 11 05:20:07 1989 Date: 11 Oct 89 09:09:26 GMT From: news%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc.uucp@ucsd.edu (Dave Hayes) Organization: Jet Propulsion Laboratory Subject: Re: the deafening silence Message-Id: <1989Oct11.090926.24253@elroy.jpl.nasa.gov> References: <1989Oct5.224148.19484@elroy.jpl.nasa.gov>, <46208967.208ba@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O Ollie Jones writes: >For what it's worth, our news-posting software has been "living >in interesting times" lately, because HP makes extensive internal >use of news, and we've been getting updated to be compatible >with that. For a while, outbound postings were fouled up. Therefore, >someone may have answered your posting, and you may not have received >the answer. Sorry. OH! Ok...I had thought that this might be the case, but you never know until you actually make some noise. >And, I hope you won't hold it against me and >other apollo R&D USENET readers if we sometimes >don't answer every question. Not personally, no. Ideally you guys would at least ACKNOWLEDGE most messages that don't get much of an answer (e.g. "Gee, uh...got your message but couldn't answer it"). >I looked back in the history for your message. It got flushed... >Why don't you repost it? Well...all I really want are valid template files for use with INPROT that give you as secure a system as the darned ACL's can make it. When I posted my original message, I was struggling with things like finding out which parts of the OS I could get away with protecting before the OS was protected against itself. I just figured that it was truly a waste to provide INPROT and not provide templates. You guys had templates at 9.7, why not at 10.1? -Dave Hayes From apollo-request@umix.cc.umich.edu Wed Oct 11 07:20:18 1989 Date: 11 Oct 89 10:49:19 GMT From: warren%ginosko%uakari.primate.wisc.edu%uwm.edu%mailrus.uucp@tut.cis.ohio-state.edu (Warren Lavallee) Organization: Samsung Software America, Inc. Subject: Ethernet board for Apollo3000 Actually a 3Com503 Board? Message-Id: <4548@ginosko.samsung.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O Hello All, We have an Apollo 3000 which is a 68020 box based on an AT bus [just like a PC]. Our machine has a token ring board which is of no use to us. Apollo offers another board that supports tcp/ip. My boss being notably tight-fisted balks at spending $700 for a board. On the other I suspect that the Apollo board is merely a 3COM503 Ethernet II. It would be nice to verify that. Does anyone know? Thanks alot... -- Samsung Software America. Warren J. Lavallee Systems Administator. UUCP: warreng@ginosko.UUCP NEARnet/Internet: warren@samsung.com ...and my heart beats like a drum, all night... From apollo-request@umix.cc.umich.edu Wed Oct 11 09:35:33 1989 Date: 10 Oct 89 14:52:49 GMT From: pjs269%tijc02%rti.uucp@mcnc.org (Paul Schmidt) Organization: Texas Instr., Johnson City TN Subject: Apollo hangs on VT100 emulator rlogin Message-Id: <713@tijc02.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O We are running SR9.7 and have been having a problem with the remote login to another computer. The ring has 16 nodes using a single gateway to ethernet. The problem is that occasionally the Apollo will hang for many seconds. The remote computer times the Apollo out and disconnects. We are running with large size vt100s (>24x80). My theory is that the Apollo software on Ethernet takes too long to process collisions on the network. This is because of the following evidence: 1) The gateway node is not being used so it is not a problem with the gateway being overloaded. 2) We had some faulty hardware on the network that produced bad packets. The Apollo software would halt for minutes at a time, but would seem to recover several minutes after the packets were gone. If anyone can add support or disprove this theory, I would appreciate the input. From apollo-request@umix.cc.umich.edu Wed Oct 11 11:18:57 1989 Message-Id: <8910111317.AA04126@umix.cc.umich.edu> Date: 11 Oct 89 08:11:00 CST From: "DAVE ERSTAD" Subject: Re: Startup files under Aegis 9.7 To: "apollo" Status: O A DSP should bring up the SPM (rather than the DM, as on a head-ed node) at boot time, which will execute the startup.spm file (assuming, of course, you're getting past the phase II boot shell). Any startup files you don't recognize probably deal with older hardware. For example, startup.19l works with the 19" landscape displays found on DN300, 320, and 330 models. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Wed Oct 11 11:36:07 1989 From: geeb@caen.engin.umich.edu (Mark A Gebert) Message-Id: <462a39268.000bfe8@caen.engin.umich.edu> To: apollo@umix.cc.umich.edu Cc: geeb@caen.engin.umich.edu Subject: DSP90 and a Megatape Date: Wed, 11 Oct 89 11:05:12 -0400 Status: O Has anyone out there have experience with connecting a Megatape 8mm tape drive to a DSP90. At the current time we have one working on a DSP80. But with our conversion to sr10 we need to get one working quickly on the 90. Here's the set up: tapedrive is hooked to a Tapemaster A controler in a DSP90 with 3Megs. A the current time when I try to do rbak I get errors "such tape unit not on line" or the drive will give me straight read errors on the tape (and the tape can be read by the DSP80). Any suggestions? PLEASE RESPOND DIRECTLY TO ME geeb@caen.umich.engin.edu Thanx, --geeb From apollo-request@umix.cc.umich.edu Wed Oct 11 12:17:40 1989 Date: 11 Oct 89 12:50:11 GMT From: shull%scrolls.wharton.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@speedy.wisc.edu (Christopher E. Shull) Organization: Decision Sciences Dept, Wharton School, U of Pennsylvania Subject: Re: Ethernet board for Apollo3000 Actually a 3Com503 Board? Message-Id: <15362@netnews.upenn.edu> References: <4548@ginosko.samsung.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O In article <4548@ginosko.samsung.com> warren@samsung.com (Warren Lavallee) writes: [...] > We have an Apollo 3000 which is a 68020 box based on an AT bus [just >like a PC]. Our machine has a token ring board which is of no use to >us. Apollo offers another board that supports tcp/ip. My boss being >notably tight-fisted balks at spending $700 for a board. On the other I >suspect that the Apollo board is merely a 3COM503 Ethernet II. It would >be nice to verify that. [...] The only problems are: 1) there is a special chip that Apollo adds to the 3COM503 board that lets it figure out its unique 48-bit Ethernet hardware address (based on the Apollo's node id), and, 2) the original Apollo DN3000's didn't understand anything but token ring boards, and there is a boot PROM (or something) on the motherboard that needs to be replaced for them to accept an Ethernet board as its primary network. Good luck! -Chris Christopher E. Shull shull@scrolls.wharton.upenn.edu Decision Sciences Department shull@wharton.upenn.edu The Wharton School University of Pennsylvania Philadelphia, PA 19104-6366 215/898-5930 --------------------------------------------------------------------------- "Damn the torpedoes! Full speed ahead!" Admiral Farragut, USN, 1801-1870 --------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Wed Oct 11 16:35:13 1989 Date: 11 Oct 89 17:48:11 GMT From: rnewman%chip.uucp@nosc.mil (Rey Newman) Organization: M/A-COM Government Systems Inc., San Diego, CA Subject: GNU-Emacs Message-Id: <267@chip.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O Hello, I would like to find out how to obtain sources for GNU-Emacs for Apollos. I understand from a posting on the net that someone has done a fair amount of work to standard GNU to make it work well with Apollos. Any information will be appreciated. \Rey Newman M/A-COM Linkabit From apollo-request@umix.cc.umich.edu Wed Oct 11 20:31:40 1989 Date: Wed, 11 Oct 89 16:39:49 CDT From: Andrew M. Wescott Message-Id: <8910112139.AA00669@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: Undump for TeX on Apollos Status: O Does anyone have a working version of TeX undump for SR 10.1 Apollos ? Any other Apollo/TeX related tips would be much appreciated. I just downloaded everything from labrea.stanford.edu. I get to build TeX for someone else, but I don't know how to use it (Interleaf freak) ! Thanks, Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Wed Oct 11 22:26:05 1989 Date: 11 Oct 89 23:01:47 GMT From: dkinney%hhb%pyrnj.uucp@rutgers.edu (David Kinney) Organization: HHB Systems, Mawah, NJ Subject: How to get around "Text file busy" ? Message-Id: <285@hhb.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Status: O I've got a problem that neither RTFM, nor even calling Apollo Tech. Support has helped. Basically, I have two processes: the first one opens a file for writing and begins writing to it. Shortly there- after, a second process, which is on another node, attempts to open the file for reading and is blocked with a "Text file busy" error. I know that if both processes are on the same node, everything works. However, the application that I'm working on is for a distributed environment; one of it's principles is that the first process will be running on a high powered node somewhere and the second process will be running on a node that is sitting on an engineer's desk. An eventual solution might be to use X Windows, but currently the graphics stuff involved hasn't been modified to work with X. Any suggestions on how to work around this problem would be appreciated. Thanks in advance, David Kinney ******************************************************************************* David Kinney, Portations Manager, HHB Systems UUCP: {rutgers,pyrnj,princeton}!hhb!dkinney US Snail: HHB Systems 1000 Wyckoff Ave. Mahwah NJ 07430 Phone: 201-848-8000 X345 ******************************************************************************* -- David Kinney, Portations Manager, HHB Systems UUCP: {rutgers,pyrnj,princeton}!hhb!dkinney US Snail: HHB Systems 1000 Wyckoff Ave. Mahwah NJ 07430 Phone: 201-848-8000 X345 From apollo-request@umix.cc.umich.edu Wed Oct 11 22:31:57 1989 From: tpfabian@nasamail.nasa.gov (THEODORE FABIAN) Date: Wed, 11 Oct 89 16:47 PDT Message-Id: Cc: Subject: RE: Ethernet board for Apollo3000 Actually a 3Com503 Board? X-Lines: 49 Status: O regarding the following: From: warren%ginosko%uakari.primate.wisc.edu%uwm.edu%mailrus.uucp@tut.cis.ohio-state.edu (Warren Lavallee) Subject: Ethernet board for Apollo3000 Actually a 3Com503 Board? Hello All, We have an Apollo 3000 which is a 68020 box based on an AT bus [just like a PC]. Our machine has a token ring board which is of no use to us. Apollo offers another board that supports tcp/ip. My boss being notably tight-fisted balks at spending $700 for a board. On the other I suspect that the Apollo board is merely a 3COM503 Ethernet II. It would be nice to verify that. Does anyone know? Thanks alot... -- Samsung Software America. Warren J. Lavallee Systems Administator. ----------------- yes, I believe the alternate board you refer to is a 3COM 503 board.. at least the ones we're using are... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Thanks, * * * * Ted Fabian * * * * NASA Lewis Research Center * * Cleveland, Ohio * * * * phone: 216-433-6307 * * FTS: 297-6307 * * * * email: tpfabian@nasamail.nasa.gov * * tfabian@earth.lerc.nasa.gov * * tfabian@csd.lerc.nasa.gov * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From apollo-request@umix.cc.umich.edu Thu Oct 12 00:26:35 1989 Date: 11 Oct 89 12:06:40 GMT From: andrewn%syma%icdoc%ukc%mcsun.uucp@uunet.uu.net (Andrew D Nimmo) Organization: University of Sussex Subject: info on libmp needed Message-Id: <1420@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I need to get information on the multiple precision integer routines in libmp (with Domain/OS). Can anyone from Apollo send info and bug status. I can take TeX, troff, postscript, Context DOC if you have any papers etc on the subject. Thanks. Andrew. -- Andrew D. Nimmo, VLSI and Graphics Research Group, EAPS II, University of Sussex, Falmer, BRIGHTON, East Sussex, BN1 9Qt TEL: +44 273 606755 x 2617 EMAIL: (JANET) andrewn@syma.sussex.ac.uk | (UUCP) ...mcsun!ukc!syma!andrewn From apollo-request@umix.cc.umich.edu Thu Oct 12 00:33:14 1989 Message-Id: <8910120144.AA08404@umix.cc.umich.edu> Date: Thu, 12 Oct 89 09:36 H From: Subject: Returned Mail To: apollo@umix.cc.umich.edu X-Original-To: Postmaster@apollo.com, apollo@umix.cc.umich.edu, YEOAK Re: Returned Mail Can anybody help to explain to me why I keep on getting returned mails from Postmaster@apollo.com please? >From: com%"Postmaster@apollo.com" 11-OCT-1989 14:12:25.93 >To: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU >CC: >Subj: Returned Mail > >Received: From CUNYVM(MAILER) by NUSDISCS with Jnet id 4031 > for YEOAK@NUSDISCS; Wed, 11 Oct 89 14:12 H >Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.03B) with BSMTP id 8342; Wed, > 11 Oct 89 02:12:47 EDT >Received: from amway by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with TCP; Wed, 1 1 > Oct 89 02:12:42 EDT >Received: from xuucp.ch.apollo.com by amway id Wed, 11 Oct 89 > 02:11:43 EDT >Received: by xuucp.ch.apollo.com id ; Wed, 11 Oct > 89 02:00:57 EDT >Message-Id: <8910110600.AA07845@xuucp.ch.apollo.com> >Received: by daphne id AA07437; Wed, 11 Oct 89 02:01:07 EDT >From: Postmaster@apollo.com >Date: Wed, 11 Oct 89 01:47:56 EDT >Subject: Returned Mail >To: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU > > >Error encountered while attempting to deliver mail. > >Error sending to "apollo-list@ch", message returned to sender. > > >------------- RETURNED MESSAGE FOLLOWS ------------- > > Received: from sharkey.cc.umich.edu by amway id Wed, 11 Oc t > 89 01:59:14 EDT > Received: from umix.cc.umich.edu by sharkey.cc.umich.edu (5.61/gossip-1.1) > id AA27886; Wed, 11 Oct 89 01:43:40 -0400 > Received: by umix.cc.umich.edu (5.54/umix-2.0) > id AA08895; Tue, 10 Oct 89 23:56:22 EDT > Received: by umix.cc.umich.edu (5.54/umix-2.0) > id AA07620; Tue, 10 Oct 89 23:04:26 EDT > Received: from NUSDISCS.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) > with BSMTP id 9325; Tue, 10 Oct 89 23:00:13 EDT > Date: Wednesday, October 11, 1989 2:57:00 pm (EDT) > From: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU > Subject: Re: INPROT & ACL > To: apollo@umix.cc.umich.edu >X-Original-To: apollo@umix.cc.umich.edu, YEOAK -- AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Thu Oct 12 11:16:39 1989 Date: 9 Oct 89 16:51:00 GMT From: oj%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: the deafening silence Message-Id: <46208967.208ba@apollo.HP.COM> References: <1989Oct5.224148.19484@elroy.jpl.nasa.gov> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1989Oct5.224148.19484@elroy.jpl.nasa.gov> dave%jplopto@jpl-mil.jpl.nasa.gov writes: >I have recently posted an article to which I have gotten no response. >This leads me to ask "Is this newsgroup alive?" "Does APOLLO listen?" >"Does APOLLO care?" For what it's worth, our news-posting software has been "living in interesting times" lately, because HP makes extensive internal use of news, and we've been getting updated to be compatible with that. For a while, outbound postings were fouled up. Therefore, someone may have answered your posting, and you may not have received the answer. Sorry. Sometimes a posting gets a personal email response, rather than a posted response. So it's not completely fair to assume nobody here at HP-Apollo is paying attention when someone else's article doesn't get responded to. We USENET users are not supposed to use USENET for commercial purposes, and formal customer support is definitely a commercial enterprise. So I hope you won't hold it against my co-workers in the customer support department if they don't always receive or respond to USENET messages. And, I hope you won't hold it against me and other apollo R&D USENET readers if we sometimes don't answer every question. All of us are very interested in making sure our customers succeed, but sometimes the best way to do that is to spend a couple of weeks hustling to get the sr10.2 bits in the can, rather than reading news. OK, OK, I confess, I haven't looked at news for a couple of weeks, because of SR10.2 :-) Excuses, excuses, I know. Sorry. You should know that many postings with useful questions and/or serious problem reports do get circulated and (sometimes) acted on here at Apollo. I looked back in the history for your message. It got flushed... Why don't you repost it? Ollie Jones (speaking for myself, not necessarily for HP Apollo Systems Division; this disclaimer is for real, not just a formality; I'm not authorized to speak on behalf of the company in this forum.) From apollo-request@umix.cc.umich.edu Thu Oct 12 12:10:19 1989 Date: 11 Oct 89 11:29:23 GMT From: jnp%mjolner%santra%tut%sunic%luth%eru.uucp@bloom-beacon.mit.edu (J|rgen N|rgaard) Organization: Nokia Telecommunications Oy, Espoo, Finland Subject: Re: Why is /etc/reboot so unreliable? Message-Id: References: <8909291722.AA00609@civilgate.ce.uiuc.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu (System: DN3500/SR10.1/BSD4.3/ADUS X11R3) Okay, my experience is that reboot'ing from the DM is unlikely to work; ends with trashed screen. Cure: reset ! Run via rlogin's or xterm's work in more (>>90%) of the cases. Whereas shutdown -r doesn't in either case. -- -- -- | Regards, J|rgen N|rgaard ('|' is '\o{}' in \LaTeX{}) | | e-mail: jnp@tele.nokia.fi | telephone: <..>-358-0-511-5671 | -- mail: Nokia Telecommunications, PL 33, SF-02601 Espoo, Suomi Finland -- From apollo-request@umix.cc.umich.edu Thu Oct 12 13:21:29 1989 Date: 12 Oct 89 14:56:35 GMT From: manis%faculty.cs.ubc.ca%ubc-cs.uucp@beaver.cs.washington.edu (Vincent Manis) Organization: The Invisible City of Kitezh Subject: Re: Apollo hangs on VT100 emulator rlogin Message-Id: <5241@ubc-cs.UUCP> References: <713@tijc02.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu My experiments in using vt100 with rlogin were quite unsuccessful. It would quite repeatedly hang just after I exited from GNU Emacs on the remote system (I'm on a 3500 running SR 10.1, and was rlogging in to various Suns running SunOS 4.0). vt100's bugs have been loudly complained about here. For the record, the only way I have managed to use it without problems is via the command vt100 -std telnet (I thought that I could at least have a `big VT-100', but non-standard screen sizes seem to elicit scrolling problems). With any luck, the vt100 command in 10.2 should be a bit more trustworthy. ____________ Vincent Manis | manis@cs.ubc.ca ___ \ _____ The Invisible City of Kitezh | manis@cs.ubc.cdn ____ \ ____ Department of Computer Science | manis%cs.ubc@relay.cs.net ___ /\ ___ University of British Columbia | uunet!ubc-cs!manis __ / \ __ Vancouver, BC, Canada V6T 1W5 | (604) 228-2394 _ / __ \ _ "There is no law that vulgarity and literary excellence cannot ____________ coexist." -- A. Trevor Hodge From apollo-request@umix.cc.umich.edu Thu Oct 12 15:21:16 1989 Date: Thu, 12 Oct 1989 18:07:48 MET From: Harald Hanche-Olsen To: apollo@umix.cc.umich.edu Cc: rnewman%chip.uucp@nosc.mil Subject: GNU-Emacs Message-Id: Rey Newman wants to know about GNU Emacs for Apollos. Such adaptations have been made by Leonard N. Zubkoff . My copy I got from someone else who got it from I don't know where, but you might ask Zubkoff himself. Or, you might look in the same place the rest of the Emacs source comes from (somewhere at MIT, I believe). UNIX fans beware: Zubkoff uses Apollo specific calls for many things, including writing files. The alleged advantage of this is to preserve the Apollo file type, but you will find that file permissions com out rather different than expected. [ This seems to be a general problem with much Apollo software, which I find extremely annoying. (Flame off.) ] - Harald Hanche-Olsen The Norwegian Institute of Technology From apollo-request@umix.cc.umich.edu Thu Oct 12 15:27:42 1989 Date: 12 Oct 89 02:03:16 GMT From: stroyan%hpfcdq%hpfcso.uucp@hplabs.hp.com (Mike Stroyan) Organization: Hewlett-Packard - Fort Collins, CO Subject: Re: Character I/O &Starbase(HP) Message-Id: <19710002@hpfcdq.HP.COM> References: <4050@cosmo2.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu When asking about HP systems that are not from the Apollo Division, posting to comp.sys.hp instead of comp.sys.apollo will be more likely to catch the eye of someone with the answer to your question. HP Windows/9000 has three different input modes, ASCII, Two-Byte, and Packetized. I assume from your question that you are using either the Two-Byte or Packetized input mode. In these modes the byte pairs or packets that you receive from read or winput_read will include data_byte and control_byte members. The control_byte value indicates what type of event occured. The event may be a normal key press or release, or a special key press or release. In the case of packetized input mode, the event may be a window event such as a window move. You need to examine the flags in the control_byte to determine what the data_byte means. For a normal key event the data_byte will contain ascii values. For a special key event the data_byte will contain one of the #define constants from /usr/include/window.h. The code fragment below shows how to check for the keys that you mentioned when interpreting a packet from winput_read. An example program which handles all keys and other events appears in the "HP Windows/9000 Programmer's Manual." if (event->control_byte & K_EVENT) { if (event->control_byte & K_SPECIAL) { /* a special key */ switch (event->data_byte) { case K_RETURN: printf("RETURN\n", event->data_byte); break; case K_BACKSPACE: printf("BACKSPACE\n", event->data_byte); break; default: break; } } else { /* a normal key */ printf("'%c'\n", event->data_byte); } } Mike Stroyan, stroyan@hpfcla.hp.com From apollo-request@umix.cc.umich.edu Thu Oct 12 16:29:11 1989 Message-Id: <8910100313.AA17547@umix.cc.umich.edu> Date: Tue, 10 Oct 89 11:07 H From: Subject: Server Process Manager (SPM) To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK After having read the recent postings on "the deafeaning silence", I repost my mail here. Hope that someone would help. BTW, this is my first posting ever. I'd got a response for my second posting on SPM thru' private mail. Thanks. Here you go.... 1) We've a Seikosha dot-matrix printer connected to a SR10.1 node running BSD4.3. We used 'genicom' device driver in our prsvr configuration file. After having setup prsvr & prmgr, our text files can be printed on the Seikosha printer using prf, but almost every printed line is prefixed with 120e0m. (I presume it's genicom printer control code.) Right now we use 'prf -trans' to print our text files, that means we lost all the good features of prf such as -head, -banner & etc. Q: Is there a way to substitute the genicom control codes by other dot-matrix printer control codes? How? Q: Is there a generic device driver available for printing text file on a dot-matrix or line printer which has a serial/RS232 port? 2) I've tried to build a simple device driver by following the example shown in 5.1.2 of "Printing in the Aegis Environment". I encountered the following problem during bind: Unresolved globals: add_db_range_c First referenced in driver_ex.bin add_db_value_c "" get_db_value_c "" inq_entry_c "" Q: Where is the lib for there routines? 3) What is TML as mentioned in "Printing in the Aegis Environment"? 4) We've managed to set up lpd in a separate testing. We're able to get lpr to work w/o prsvr & prmgr. The problem is that the output is in double spacing. Any body knows how to fix it? Thanks for your helps in advance. --AnnKian Yeo Email: YEOAK@NUSDISCS.BITNET or YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Thu Oct 12 17:22:54 1989 Date: 11 Oct 89 19:39:13 GMT From: jch%hpfcdq%hpfcso.uucp@hplabs.hp.com (Jan Hardenbergh) Organization: Hewlett-Packard - Fort Collins, CO Subject: Re: netlib servers Message-Id: <19710001@hpfcdq.HP.COM> References: <8910051433.AA03873@lnic1.hprc.uh.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Alternatives to netlib@mcs.anl.gov. The index from netlib suggests trying research ( at AT&T, I think it is a UUCP hub ), ihnp4 ( Bell Labs in Chicago ) or mcvax (Math Centrum in Amsterdam ). -Jan Hardenbergh - jch@apollo.com - (508)-256-6600 Hewlett-Packard Company/ Graphics Technology Division From apollo-request@umix.cc.umich.edu Thu Oct 12 17:31:32 1989 Date: 11 Oct 89 20:53:30 GMT From: davem%hpubvwa%hplsla%hp-pcd.uucp@hplabs.hp.com (Dave MacDonald) Organization: Hewlett-Packard Bellevue Sales Subject: Re: rsh Message-Id: <11530001@hpubvwa.NSR.HP.COM> References: <8910110301.AA07530@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have a settup here similar to what you mentioned, but using a DN3500 with SR10.1 as a gateway. I experimented a bit with rsh using the -l option and had no problems talking to HP9000/300s. However, note that the user specified in the -l option must have an entry like the following in his/her .rhosts file on the destination system: hostname username Hostname is the hostname of the system executing the rsh, and username is the logon id of the user on that system you are granting permission to. I hope this helps... From apollo-request@umix.cc.umich.edu Thu Oct 12 17:36:43 1989 Date: 12 Oct 89 17:58:58 GMT From: andyg%marque%uwm.edu%gem.mps.ohio-state.edu.uucp@apple.com (Andy Green) Organization: Marquette University - Milwaukee, Wisconsin Subject: Disks on 3500 Message-Id: <9578@marque.mu.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We gave a small network of 3500's and a single DN10000. As usual we are seeking some ways to save money and expand our memory. Someone mentioned that you can buy 700 MB disks from TOPS computer for substantially less than Apollo's price. Does any one have any information on these drives? Has anyone actually installed one on a 3500? Any information would be appreciated. Andy Greene Medical College of Wisconsin 8701 Watertown Plank Rd. Milwaukee, Wi 53226 414-257-8532 andyg@marque.mu.edu From apollo-request@umix.cc.umich.edu Thu Oct 12 17:42:35 1989 Date: 12 Oct 89 16:15:00 GMT From: tim%apollo%hp-sdd.uucp@hplabs.hp.com (Timothy R. Giebelhaus) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: the deafening silence (and archive sites) Message-Id: <462f7f81.20b6d@apollo.HP.COM> References: <1989Oct5.224148.19484@elroy.jpl.nasa.gov>, <1341@clyde.Concordia.CA>, <1614@atanasoff.cs.iastate.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I want to stress that I am talking for myself and not necessarily Apollo/HP in the first part of this article. Like Dave E. says, help over the news system is a privilege, NOT a right. The people in R&D are being extremely kind in donating their time to helping people with their problems directly. It is not something they are required to do. It is customer service's job to field questions from the general public. The people in customer service who answer questions over news are being kind in that that they are not checking to see who payed a service contract and they are not given credit for the time they spend giving the answer. Now, this may be a problem. Getting help over news seems to be something which more than a few customers desire. There are some problems with this though. Apollo/HP can't afford to give unlimited free help to every person who has bought their machines. I'm sure everyone sees that Apollo/HP would not be in bussiness for very long at all if they attempted to give all this free help. So, what Apollo/HP and other companies do is offer service contracts. This is a method of recovering the cost of giving help to the customers who buy the machines. The service contract is necessary so the company can stay profitable and still offer help. If the company is not profitable, the company ceases to exist. Now the company needs some method of verifing that a customer has a service contract before helping them... else why would the customer buy the service contract. If news is used to answer questions, there is no way to verify that the customer has a service contract and so a service contract is no longer necessary for the customer. I had seen it written in one of the articles that the customers have a right to have a working machine and thus, it was implied, they have a right to all the free help necessary in order to get the machine working. No computer vendor would be so foolish to try to sell something as complicated as a workstation and promise that it works 100%. The workstation is sold with problems (many of them are documented at the time of the sale). The customer is then offered a service contract to help take care of the problems the workstation does have. Without the service contract or any software update rights, the software stays as is bought. All companies do this... at least all that are still in business. It is back to the free help, no contract, no profit, no company problem. Please feel free to use the news, but please remember it is not an offical way of getting help. Customer service is the offical way of getting help. If anyone has suggestions for how to make news help practical, please let me know and I'll make sure it is seriously considered by Apollo/HP management. As for ADUS, it is not owned by Apollo/HP. Thus, nothing will happen to it that ADUS does not wish to happen to it. It is true, however, that Apollo does make donations to ADUS which they may or may not stop doing. In such a case dues or some other fund raising method would be necessary to maintain ADUS. As Apollos and HP machines become the same, I would see joining the HP organization as a plus... but that is just the way I see it. Having said all this, let me say that all of the above is my personal view and may or may not be anything my company agrees with. The below, I believe, I can say officially. IF YOU HAVE ANY PROBLEMS WITH CUSTOMER SERVICE SOFTWARE SUPPORT IN NORTH AMERICA, please give me a call, and I will help you out. If you are in the North Central region (North Dakota to Pittsburg to Kentucky to Kansas) I can help you out direclty. If you are outside the region, I can set you up with people who can help you. I am not saying, I can give you things outside of your contract. The resources do not exist for that. I'll work very long hours till you do get the service you are buying, though. You can reach me at: Tim Giebelhaus Apollo Computer 7900 International Dr. Bloomington, MN 55425 Phone: (612) 854-5791 FAX: (612) 854-7191 Voice mail: (800) 631-3511 x9557 E-mail: tim@apcimsp.uucp tim@apollo.hp.com UUCP: uunet!hi-csc!giebelhaus ARPA: hi-csc!giebelhaus@umn-cs.arpa Nobody I know admits to sharing my opinions. I don't even have a pet which will share my opinion. From apollo-request@umix.cc.umich.edu Thu Oct 12 19:19:52 1989 Date: Thu, 12 Oct 89 16:23:15 -0400 From: paul@speedmetal.engin.umich.edu (Paul Killey) Message-Id: <8910122023.AA06234@speedmetal.engin.umich.edu> To: apollo@umix.cc.umich.edu Subject: Administrivia ... As nearly as I can tell, the alias this list gets sent to at apollo.com is bouncing mail to this list back. I don't know if anything is being read at apollo.com via this list or if they see it via news, or what. We are trying to figure things out. --paul From apollo-request@umix.cc.umich.edu Thu Oct 12 19:24:18 1989 Date: 12 Oct 89 17:19:29 GMT From: lori%hacgate%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc.uucp@ucsd.edu (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: Ethernet board for Apollo3000 Actually a 3Com503 Board? Message-Id: <5520@hacgate.UUCP> References: <4548@ginosko.samsung.com>, <15362@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <15362@netnews.upenn.edu> shull@scrolls.wharton.upenn.edu (Christopher E. Shull) writes: >[...] > 2) the original Apollo DN3000's didn't understand anything but > token ring boards, and there is a boot PROM (or something) on > the motherboard that needs to be replaced for them to accept > an Ethernet board as its primary network. Actually, this little PROM isn't necessary at all. The only thing it is used for (apparently) is self-diagnostics at reset time. If you take out your ring card (like I did from my DN3000), the diagnostics will fail because the Domain PROM tells it to look for a ring card. But since this check comes last, the loss is trivial. You can EX AEGIS anyway. According to our service rep., replacement of this PROM is included as part of regular maintenance. I haven't bothered. ...lori From apollo-request@umix.cc.umich.edu Thu Oct 12 19:29:29 1989 Date: 12 Oct 89 22:01:41 GMT From: apippin%polyslo%sdsu%bionet.uucp@apple.com (Pinhead@Spikes.slo.ca.EDU) Organization: Viking Tours & Travels Subject: Help - new disk in network Message-Id: <1989Oct12.220141.10854@polyslo.CalPoly.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am about to install a disk onto what was a diskless machine in a network. We had 5 disked machines, and are changing over to all ten being disked. What documentation or tips should I follow? abp. -- Andy Pippin Today's Moral: Go get wasted on Romulan Ale (apippin@polyslo.CalPoly.EDU) and don't mess with Spock. From apollo-request@umix.cc.umich.edu Thu Oct 12 19:35:02 1989 Date: 12 Oct 89 21:26:00 GMT From: flinn%apollo.uucp@beaver.cs.washington.edu (Donald Flinn) Organization: Apollo Computer, Chelmsford, MA Subject: Re: INPROT & ACL Message-Id: <46309573.20b6d@apollo.HP.COM> References: <8910110304.AA07620@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Folks In response to the requests for an acl template for inprot: We will be shipping a closed acl template with SR10.2. Honest guy's we really do listen. Don From apollo-request@umix.cc.umich.edu Thu Oct 12 21:22:48 1989 Date: 12 Oct 89 13:07:56 GMT From: clif%ticipa%ti-csl%pollux%attctc%texbell%wuarchive%brutus.cs.uiuc.edu%gem.mps.ohio-state.edu. (Clif Harden) Organization: TI PAC Wafer Fab Systems, Dallas Subject: Re: Apollo NFS V2.0 Message-Id: <238@ticipa.ti.com> References: <7847@charlie.OZ> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <7847@charlie.OZ>, by robert@aragorn.cm.deakin.oz.au (Robert Ruge): > I am hoping that somebody can help me with an NFS installation problem > that I am having. I am running SR10.1 on a 3010 and have had troubles > getting NFS running. > > The message I get from a 'mount -o soft aragorn:/u /u' is 'nfsmount > returned in error', and when I run nfsmount itself or even showmount I > get an 'IOT Trap' message. > We run SR10.1 NFS 2.0 here on our network with no problems. I tryed the command that you gave and it worked with no problems. This is the way I do the command, it might be something you want to try. mount -v -t nfs -o soft aragorn:/u /u There are some Apollo software patches for NFS 2.0. If you don't have them that might be your problem. Clif Harden TI PAC Apollo Network Adminstrator Texas Instruments PO Box 655012 M/S 3635 Dallas, TX 75265 From apollo-request@umix.cc.umich.edu Thu Oct 12 21:40:19 1989 Date: Thu, 12 Oct 89 19:31:20 CDT From: Andrew M. Wescott Message-Id: <8910130031.AA02364@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: The Deafening Silence ... Okay, I'm convinced that this news group is not dead. But then I never said it was. I have received countless unofficial responses from Chelmsford folks the past year. Things did seem to tail off recently but I think excuses relating to the transition, etc. are valid ones. Its obvious from all the internal responses on this question that Apollo employees are still interested in an "unofficial" way. In regard to the real Customer Support people, I think we should count our blessings. Overall, they do a very good job. I've heard some real horror stories about customer service at other anonymous workstation companies. Let's move on to solving problems. I'm alive ! How about you ? Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Thu Oct 12 23:20:27 1989 Date: 13 Oct 89 00:23:50 GMT From: jwright%atanasoff%sharkey%shadooby%ginosko%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Jim Wright) Organization: Iowa State U. Computer Science Department, Ames, IA Subject: Re: the deafening silence Message-Id: <1621@atanasoff.cs.iastate.edu> References: <1341@clyde.Concordia.CA>, <1614@atanasoff.cs.iastate.edu>, <462f7f81.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <462f7f81.20b6d@apollo.HP.COM> tim@apollo.HP.COM (Timothy R. Giebelhaus) writes: | Like Dave E. says, help over the news system is a privilege, NOT a right. [and good explanation of why this is so] | If anyone has suggestions for how to make news help practical, | please let me know and I'll make sure it is seriously considered by | Apollo/HP management. I don't think help for individuals' problems will ever be practical using news. But I think there is a place for publicly releasing information. Informing customers of common, known problems (often merely problems with customers misunderstanding something) seems a good thing. Also releasing a list of what is on the patch tapes. I'm not asking to get free patches, but I don't think it is unreasonable to know what is on past and forthcoming tapes. I can only see that generating interest in obtaining service contracts. It would also seem practical to use email in addition to telephones to provide individual customer support. Requiring the service contract number would be easy and easily enforceable. I am generally more coherent when I have the chance to sit down and organize things at my leisure. I can see a few arguments against this, so I'm not holding my breath. (The more I think about this, the more reasons I can see against it. In fact, I'm kind of surprised that bug reports via email are allowed. :-) | IF YOU HAVE ANY PROBLEMS WITH CUSTOMER SERVICE SOFTWARE SUPPORT IN NORTH | AMERICA, please give me a call, and I will help you out. This is true. I've gotten help from Tim in the past. He's been knowledgeable and responsive. Thanks! -- Jim Wright jwright@atanasoff.cs.iastate.edu From apollo-request@umix.cc.umich.edu Thu Oct 12 23:50:39 1989 Message-Id: <8910130157.AA16299@mitre.arpa> Organization: The MITRE Corp., Washington, D.C. To: Andrew M. Wescott Cc: apollo@umix.cc.umich.edu, art@mitre.mitre.org Subject: Re: C++ on the DN10000 In-Reply-To: Your message of Tue, 10 Oct 89 10:51:59 CDT. <8910101551.AA02478@lnic1.hprc.uh.edu> Date: Thu, 12 Oct 89 21:57:20 EDT From: Art McClinton We have ordered and received C++ for the DN10000. Must admit that it only arrived last week and have not installed it yet. C++ is a pre-compiler for C, so do not forget to order both. Apollo does have an order number to purchase both at a substantial discount over the individual prices. * *---Art * *Arthur T. McClinton Jr. ARPA: ART@MITRE.ARPA *Mitre Corporation MS-Z305 Phone: 703-883-6356 *1820 Dolley Madison Blvd Internal Mitre: ART@MWVMS or M10319@MWVM *McLean, Va. 22102 * =-=- This note is in response to yours which follows -=-= We have someone here interested in a dn10k, but they are hung up on C++. So could someone more enlightened than I shed some light on the staus of Apollo's C++ product on the dn10k, as well as the availability of GNU's C and C++. Thanks, Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Fri Oct 13 03:49:54 1989 Date: 13 Oct 89 04:54:16 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: the deafening silence (and archive sites) Message-Id: References: <1989Oct5.224148.19484@elroy.jpl.nasa.gov> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <462f7f81.20b6d@apollo.HP.COM> tim@apollo.HP.COM (Timothy R. Giebelhaus) writes: ..... Deleted ..... I agree with what you described in the sections I have deleted. Please feel free to use the news, but please remember it is not an offical way of getting help. Customer service is the offical way of getting help. If anyone has suggestions for how to make news help practical, please let me know and I'll make sure it is seriously considered by Apollo/HP management. Since you asked for ideas here is one, which may be available, but I am not aware of it. We use both Apollo and Sun equipment in the area I work. Since I have had trouble getting timely responses from Sun on phone calls, I starting using there email service address. I found that I was able to get a reasonably fast response and if follow up was required by phone I usually got direct access to the people with the answer. Going the route of calling generally meant you had to deal with a middle man. Now I am not saying Apollo has the same problem, but many times it may be more convenient to seek information through email, like the people are doing that started this discussion. There was a mention of sending in APRs(?) by email, which I have done. However, as I understand it, you are only suppose to do this AFTER discussing the problem through the support center. Please correct me if I am wrong about this policy. As far as assuring that the support is mainly going to paying customers, Sun handles this by requiring certain information about your equipment to validate that you have a service contract. Apollo/HP could do the same thing, with the site ID being one of those pieces of information. One final note, Mentor goes even a step further by having a BBS. With this system, you can get the latest bug reports, release notes, etc. Problems can be uploaded and fixes or other helpfull items can be downloaded. I have heard of other companies providing this capablilty. Again to keep this restricted to service contract holders, before using the service you have to request an ID and password. I think this covers some of the possiblities of handling support by electronics means. Please consider these ideas in any discussions you may have on improving user support. Alan Bair SPS CAD Austin, Texas Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Fri Oct 13 05:17:08 1989 Date: 12 Oct 89 19:25:16 GMT From: danny%idacom%aunro%atha%philmtl.uucp@uunet.uu.net (Danny Wilson) Organization: IDACOM Electronics Ltd., Edmonton, Alta. Subject: Re: Ethernet board for Apollo3000 Actually a 3Com503 Board? Message-Id: <755@idacom.UUCP> References: <4548@ginosko.samsung.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <4548@ginosko.samsung.com>, warren@samsung.com (Warren Lavallee) writes: > We have an Apollo 3000 which is a 68020 box based on an AT bus [just > like a PC]. Our machine has a token ring board which is of no use to > us. Apollo offers another board that supports tcp/ip. [...] Two comments: 1. When you order a workstation you have the choice of PHYSICAL interface i.e. either Token Ring or Ethernet 2. The TCP/IP protocol is generally independant of PHYSICAL interface and can run over both token ring and ethernet. It appears that what you really _want_ is to run on an ethernet physical interface with TCP/IP as your transport (and other) protocols... -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta alberta!idacom!danny C A N A D A X.400 danny@idacom.cs.ubc.cdn From apollo-request@umix.cc.umich.edu Fri Oct 13 05:24:19 1989 Message-Id: <8910130856.AA04364@umix.cc.umich.edu> Date: Fri, 13 Oct 89 16:49 H From: Subject: Re: rlogin & rsh To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK Re: rsh & rlogin I've collected more info regarding our rsh problem. I've tried to rlogin from DSP90 tp HP9000 and SUN. (Our DSP90 runs SR10.1 with default SYSTYPE=BSD4.3 and sits on Domain Ring and Ethernet.) Observed the following: (1a) DSP90> rlogin hp90000 Password: -- always failed and normal login is prompted (1b) DSP90> rlogin sun remuser too long (2a) DSP90> rlogin hp9000 -l yeoak -- login is ok w/o password prompting (2b) DSP90> rlogin sun -l yeoak remuser too long Our SUN (SunOS 3.5) responded differently from HP9000 (HP-UX 6.5) as shown in (1) & (2). I don't know why but I suspect that the userid of SR10.1 is not sent properly to SUN and HP9000 as in (1a),(1b) & (2b). Since rlogin & rsh adopted the same authentication procedures, I don't think it's the problem of /etc/hosts or .rhosts as shown in (2a). Can anybody give some pointers please? Is there any bug reported about rsh/rlogin? --AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Fri Oct 13 09:20:17 1989 Date: Fri, 13 Oct 89 08:22:07 EDT From: crh@apollo.eng.ohio-state.edu (Charlotte Hawley) Message-Id: <8910131222.AA04402@apollo.eng.ohio-state.edu> To: apollo@umix.cc.umich.edu Subject: Memory Upgrades We want to upgrade the memory in an DN3500. Someone told us about a company named Clearpoint? Anyone out there know where this company is located and/or the telephone number. Or any other sources other than Apollo? Charlotte Hawley Ohio State Univ. From apollo-request@umix.cc.umich.edu Fri Oct 13 11:18:54 1989 Date: 13 Oct 89 14:39:21 GMT From: roode%hydra.cf.uci.edu%orion.oac.uci.edu%usc%gem.mps.ohio-state.edu.uucp@apple.com (Dana Roode) Organization: University of California, Irvine Subject: Tek401x emulation Message-Id: <3452@orion.cf.uci.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Short question: what's the {easiest,best,cheapest} way to do Tek401x emulation on an Apollo running 9.7 Aegis? running 10.1 Aegis? I seem to remember a comment in the Apollo X11 distribution about their xterm not support TEK mode. Dana Roode Roode@orion.cf.uci.edu From apollo-request@umix.cc.umich.edu Fri Oct 13 15:22:22 1989 Date: 13 Oct 89 14:34:06 GMT From: lau%kings.wharton.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@speedy.wisc.edu (Yan K. Lau) Organization: A Private Heaven Subject: Re: Ethernet board for Apollo3000 Actually a 3Com503 Board? Message-Id: <15478@netnews.upenn.edu> References: <4548@ginosko.samsung.com>, <15362@netnews.upenn.edu>, <5520@hacgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <5520@hacgate.UUCP> lori@hacgate.UUCP (Lori Barfield) writes: > >Actually, this little PROM isn't necessary at all. The only thing it ... >But since this check comes last, the loss is trivial. You can EX AEGIS >anyway. > >...lori I think there is one caveat here. The PROM (?) is necessary for *diskless* machines (yes, we have a few) to be able to boot over the ethernet. We have a node without this PROM still running SR9.7 because we can't get it the recognize the DI E command to run the SR10 invol. Yan. )~ Yan K. Lau lau@kings.wharton.upenn.edu The Wharton School ~/~ 128.91.11.233 University of Pennsylvania /\ Darker grows the moon And shadows steal across the prison of my room From apollo-request@umix.cc.umich.edu Fri Oct 13 15:30:10 1989 Date: 13 Oct 89 13:56:04 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: Re: Ethernet board for Apollo3000 Actually a 3Com503 Board? Message-Id: <1989Oct13.135604.13512@quintro.uucp> References: <4548@ginosko.samsung.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <4548@ginosko.samsung.com> warren@samsung.com (Warren Lavallee) writes: >Hello All, > > We have an Apollo 3000 which is a 68020 box based on an AT bus [just >like a PC]. Our machine has a token ring board which is of no use to >us. Apollo offers another board that supports tcp/ip. My boss being >notably tight-fisted balks at spending $700 for a board. On the other I >suspect that the Apollo board is merely a 3COM503 Ethernet II. It would >be nice to verify that. > Last year we were asking the same question and our Apollo SE said, "Yes, it is a 3Com board, but it has an Apollo PROM". -- Roger E. Benz Phone = (217) 223-3211 Quintron Corporation Quincy, Il UUCP: tiamat!quintro!reb@uunet or quintro!reb@lll-winken From apollo-request@umix.cc.umich.edu Fri Oct 13 21:22:22 1989 Date: 13 Oct 89 17:27:45 GMT From: lori%hacgate%usc.uucp@apple.com (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: Memory Upgrades Message-Id: <5533@hacgate.UUCP> References: <8910131222.AA04402@apollo.eng.ohio-state.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910131222.AA04402@apollo.eng.ohio-state.edu> crh@APOLLO.ENG.OHIO-STATE.EDU (Charlotte Hawley) writes: > >We want to upgrade the memory in an DN3500. Someone told >us about a company named Clearpoint? Anyone out there know >where this company is located and/or the telephone number. ClearPoint has a good rep., but ain't as cheap as some, I've heard. They have been around awhile, and offer lifetime warrantees. >Or any other sources other than Apollo? A company named DataRAM has just expanded to the Apollo RAM market. They have been in the DEC, etc., market for over 20 years, according to their brochure. Their products are covered by lifetime warrantees as well, and guarantee next business day replacement via FedEx, free of charge. This sounds pretty good to me, so now can someone compare their prices for us? DataRAM charges $675 for 2MB boards and $1550 for 4MB boards. I didn't ask about 1MB boards. Shipping/handling is about $5. The (very impressive) salesperson I dealt with was Hugh Tucker, 714-836-5988 BTW, these were list prices I was given. So how are ClearPoint's prices? ...lori P.S. 4MB boards only work with x500 series Apollos. From apollo-request@umix.cc.umich.edu Fri Oct 13 23:19:52 1989 Date: Fri, 13 Oct 1989 22:13:11 MET From: Harald Hanche-Olsen To: apollo@umix.cc.umich.edu Subject: Re: Tek401x emulation Message-Id: Dana Roode (address too weird for me to Cc: to it) asked about Tektronix emulation in xterm. The xterm in Apollo's X11 distribution DOES support Tektronix mode; the way I read the comment in the release notes, Apollo does not support that mode - meaning they won't try to fix it if it doesn't work. The code is probably straight out of the official X distribution, and I imagine it is reasonably robust. I sure hope so - I intend to use it myself... - Harald Hanche-Olsen The Norwegian Institute of Technology From apollo-request@umix.cc.umich.edu Fri Oct 13 23:24:30 1989 Date: 13 Oct 89 19:59:56 GMT From: gale%software.org.uucp@uunet.uu.net (Charles Van Gale) Organization: Software Productivity Consortium, Herndon, Virginia Subject: screen 2.0 Message-Id: <427@sunny.software.org> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu After reading about screen in this group I grabbed it from uunet and tried it out. However, I am getting a 'bind: I/O error' on my SR10 node when I run it. This is version 2.0a by Oliver Laumann, are there any apollo mod's that I need to apply? (Will this program in fact eliminate all those Apollo VT100 blues?) From apollo-request@umix.cc.umich.edu Sat Oct 14 01:18:34 1989 Message-Id: <8910140409.AA22141@umix.cc.umich.edu> Date: Sat, 14 Oct 89 12:02 H From: Subject: RE: rlogin & rsh To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK Re: rlogin & rsh I've posted this before and managed to solve part of the problem, ie rsh. The problem was that rsh didn't work from DSP90 (running SR10.1 with SYSTYPE=bsd4.3) to HP9000 and SUN. The way I solved is to add in group name in the respective .rhosts files of the destination nodes. Eg. in ~yeoak/.rhost of the HP9000 or SUN node where I want to rsh from DSP90: dsp90 yeoak.compsc where dsp90 is the hostname yeoak is the username compsc is the groupname note: yeoak.compsc.none is defined in node dsp90's SR10.1 registry but yeoak.staff is defined in hp9000 /etc/passwd & /etc/group So when I did (from DSP90): rsh HP9000 -l yeoak "ls" and I got the result. But if I did: rsh HP9000 "ls" and still... "login incorrect" is returned. Anybody has any idea why it is do? Is this documented? Is this a "legitimate" solution? --AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Sat Oct 14 05:19:53 1989 Date: 13 Oct 89 19:40:36 GMT From: lori%hacgate%elroy.jpl.nasa.gov%henry.jpl.nasa.gov.uucp@ames.arc.nasa.gov (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: Tek401x emulation Message-Id: <5535@hacgate.UUCP> References: <3452@orion.cf.uci.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <3452@orion.cf.uci.edu> roode@hydra.cf.uci.edu (Dana Roode) writes: >Short question: what's the {easiest,best,cheapest} way to do Tek401x >emulation on an Apollo running 9.7 Aegis? running 10.1 Aegis? I >seem to remember a comment in the Apollo X11 distribution about >their xterm not support TEK mode. I remember an Apollo-supplied program called "4014" for SR9; don't know if any such animal exists for SR10. Some people at TRW asked me for help with it awhile ago....willing to call them for details if you think it's what you want. The emulation was pretty good (IMHO); it plotted graphics well. ...lori From apollo-request@umix.cc.umich.edu Mon Oct 16 09:28:21 1989 Date: Mon, 16 Oct 89 08:26:28 EDT From: crh@apollo.eng.ohio-state.edu (Charlotte Hawley) Message-Id: <8910161226.AA07066@apollo.eng.ohio-state.edu> To: apollo@umix.cc.umich.edu Subject: Request for info about Clearpoint Thanks for all the response and valuable info on memory upgrades. From apollo-request@umix.cc.umich.edu Mon Oct 16 11:25:04 1989 Date: 16 Oct 89 13:12:47 GMT From: arnaud%cbnews%att.uucp@ucbvax.Berkeley.EDU (alain.arnaud) Organization: AT&T Bell Laboratories Subject: Re: Memory Upgrades Message-Id: <10282@cbnews.ATT.COM> References: <8910131222.AA04402@apollo.eng.ohio-state.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Clearpoint Research Corp 35 Parkwood Drive Hopkinton, Mass 01748 1-800-253-2778 or 1-508-435-2200 Std Disclaimer + Just a consultant Guest Account: arnaud@angate.att.com Permanent Address: uunet!ecla!arnaud From apollo-request@umix.cc.umich.edu Mon Oct 16 15:31:38 1989 Date: 16 Oct 89 15:14:00 GMT From: pato%apollo%hp-sdd.uucp@hplabs.hp.com (Joe Pato) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: rlogin & rsh Message-Id: <46436727.20b6d@apollo.HP.COM> References: <8910140409.AA22141@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910140409.AA22141@umix.cc.umich.edu> YEOAK@NUSDISCS.BITNET writes: >Re: rlogin & rsh > >I've posted this before and managed to solve part of >the problem, ie rsh. The problem was that rsh didn't work >from DSP90 (running SR10.1 with SYSTYPE=bsd4.3) to HP9000 >and SUN. The way I solved is to add in group name in the >respective .rhosts files of the destination nodes. Eg. in ~yeoak/.rhost >of the HP9000 or SUN node where I want to rsh from DSP90: > > dsp90 yeoak.compsc > > where dsp90 is the hostname > yeoak is the username > compsc is the groupname > note: yeoak.compsc.none is defined in node dsp90's SR10.1 registry > but yeoak.staff is defined in hp9000 /etc/passwd & /etc/group > >So when I did (from DSP90): rsh HP9000 -l yeoak "ls" >and I got the result. But if I did: rsh HP9000 "ls" >and still... "login incorrect" is returned. > >Anybody has any idea why it is do? Is this documented? Is this a "legitimate" >solution? > >--AnnKian Yeo > Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU > Department of Information Systems and Computer Science (DISCS) > National University of Singapore (NUS) The problem you have encountered is that the passwd files on the HP and on the apollo (the registry on Domain/OS) are not in synch. Rlogin and Rsh rely on account names being the same on the two machines - if they are different you must use "rsh -l " and make the appropriate annotation in the .rhost file. The problem is further complicated in that account names in Domain/OS are not necessarily a simple username. Account names are of the form Person.Group.Org. The registry allows an administrator to choose an abbreviation for an account name - i.e., the administrator can choose to allow people to login with just a person name. e.g., The account "bob.staff.none" can be abbreviated to "bob" if the abbreviation for the account is . If everyone has a primary login account (an account that is abbreviated to ) then UNIX tools (e.g., getpwuid(getuid())) will extract a simple name from the registry database and work as expected. If not, then you have to make sure that the foreign machine's /etc/passwd file has the appropriate person.group or person.group.org entries. (In your case, the HP passwd file and the apollo registry were not in synch) These problems go away if you run Apollo's portable Passwd Etc product on the foreign machines. Using Passwd Etc, all machines have direct access to the shared registry database - and this way the accounts database (passwd files) cannot get out of synch. Currently Passwd Etc is available for SunOS >3.4 and Vax Ultrix 2.2. An HP/UX version of the product is not yet available. Joe Pato Apollo Computer A Subsidiary of Hewlett-Packard NSFNET: pato@apollo.com UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato From apollo-request@umix.cc.umich.edu Mon Oct 16 17:49:20 1989 Date: 16 Oct 89 16:49:00 GMT From: dawson%apollo.uucp@EDDIE.MIT.EDU (Keith Dawson) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: Tek401x emulation Message-Id: <4643bbbb.20b6d@apollo.HP.COM> References: <3452@orion.cf.uci.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > The xterm in Apollo's X11 distribution DOES support Tektronix > mode; the way I read the comment in the release notes, Apollo > does not support that mode - meaning they won't try to fix it if > it doesn't work. The code is probably straight out of the > official X distribution, and I imagine it is reasonably robust. > I sure hope so - I intend to use it myself... This is about right. Versions of Domain/X11 for both SR9.7 and SR10.1 are based on X.V11R2 from MIT. The R2 xterm as it came from MIT had a number of problems including, we have been told, some in the Tek4014 code. We fixed a bunch of these on the VT100 side. The reason we don't offer Tek4014 support at SR9.7/SR10.1 is simply one of time and re- sources. Tek4014 should work as well as it does in any other pure MIT R2 X environment. At SR10.2, when X Window System support is bundled with base software (at no extra charge), we have moved to X.V11R3 for all libraries and clients. The R3 xterm is considerably cleaner; there are no outstand- ing problems reported against Tek4014. So we'll be supporting xterm Tek4014 at SR10.2. ____________________________________________________________ My opinions Keith Dawson Hewlett Packard Co. 508-256-0176 x5739 are my own. Graphics Technology Division / East 300 Apollo Dr. (CHR.03.DE) Chelmsford, MA 01824 USA My convictions Internet: dawson@apollo.hp.com are not for UUCP: {mit-eddie,yale,uw-beaver}!apollo!dawson public display. P.S. -- one reader got somewhat alarmed at the signature above. The Apollo Systems Division is alive and quite well. I just don't happen to work in that division. From apollo-request@umix.cc.umich.edu Mon Oct 16 21:47:52 1989 Date: 16 Oct 89 22:10:52 GMT From: benu%bnlux0.uucp@sbcs.sunysb.edu (David Hassel) Organization: Brookhaven National Lab., Upton, N.Y. Subject: Apollo ethernet routing Message-Id: <1504@bnlux0.bnl.gov> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have several Apollos connected via a token ring and one gateway with an AT ethernet board from Apollo. The nodes on the token ring all have an address of 134.88.14.x including the TR side of the gateway. The gateways ethernet side has an address of 134.88.1.14. We are only able to talk to hosts with an address of 134.88.1.x on the ethernet from the gateway. The other machines on the TR can't access theses hosts. How do I convince the gatway nodes routed that it is a geatway to 134.88.1? Here is our present setup on the gateway osiris: (rc.local) /etc/ifconfig lo0 localhost /etc/ifconfig dr0 134.88.14.1 netmask 255.255.255.0 broadcast\ 134.88.255.255 /etc/ifconfig eth0 134.88.1.14 -trailers netmask \ 255.255.255.0 broadcast 134.88.255.0 (networks) loopback 127 physx 134.88.26 cis-apollo 134.88.14 ccs-gate 134.88.1 semassu 134.88 (hosts) 127.0.0.1 localhost 134.88.14.1 osiris-tr osiris 134.88.14.2 tyr . . . 134.88.14.53 dl_anubis 134.88.1.14 osiris-gw 134.88.1.1 IPGATE ipgate ipgate:: 134.88.26.1 SMUNIX smunix smunix:: Smunix and ipgate have no troubles talking with each other and when I change smunix's address to 134.88.1.26, it can talk to the apollo gateway. What are we going wrong? Thanks, Dave Hassel PS: We have also tried a netmask of 255.255.0.0 but then the gateway can't even talk to 134.88.1.1 From apollo-request@umix.cc.umich.edu Tue Oct 17 03:51:51 1989 Date: Mon, 16 Oct 89 21:14:03 CDT From: Andrew M. Wescott Message-Id: <8910170214.AA02999@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu Subject: Appeal to the TeX Gurus Again ! I am trying to compile mfware/gftopxl.web from the UNIX TeX distribution. Actually, I downloaded gftopxl.web from labrea.stanford.edu (it is not a standard part of the distribution). All the other files in mfware have an accompanying .ch file. Where do I get gftopxl.ch, or how do I build it ? Could someone also send me the nroff source to the tex manpage, tex.1l ? I accidentally deleted it, and the individual file doesn't seem available on the ftp server. Thanks, Andrew Wescott University of Houston Department of Chemical Engineering P.S. Is there a newer version of dviapollo that doesn't use pxl fonts ? From apollo-request@umix.cc.umich.edu Tue Oct 17 09:35:56 1989 Message-Id: <8910171131.AA01220@umix.cc.umich.edu> 17 Oct 89 10:09:11 BST Oct 89 10:09:11 BS Via: UK.AC.PCL.MOLE; 17 OCT 89 10:09:09 BST Date: Tue, 17 Oct 89 10:12 GMT From: NAME To: APOLLO@UMIX.CC.UMICH.EDU Subject: 2 Programming Questions (i) Is there any way to get the actual error status of an invoked shell command rather than the completion status? (Or to determine it after receiving the PGM_$WARNING status in pgm_$invoke) (ii) Is there a quick way to get a file's type-uid/size for inclusion in a directory listing? Stream_$inquire takes forever and a day. Thanks in advance, - m a r c u s - From apollo-request@umix.cc.umich.edu Tue Oct 17 13:26:21 1989 Date: Tue, 17 Oct 1989 17:36:39 MET From: Harald Hanche-Olsen To: apollo@umix.cc.umich.edu Cc: David Hassel Subject: Re: Apollo ethernet routing Message-Id: The problems of David Hassel are having remind me of a similar problem of our own. What we have discovered is that, apparently, a bug in the Apollo networking software (tcpd?) does not allow you to communicate with a directly attached subnet. I don't know if the network at Brookhaven uses directly attached subnets, but ours does. We have a class B network (129.241.0.0) on which netmask 255.255.255.0 is used, so that host 129.241.x.y is on subnet x. Some subnets are directly attached to one big ethernet, while others are connected via gateways. To get to a directly attached host 129.241.x.y from another, 129.241.u.v, say, the standard trick is the following invocation, from the latter machine: route add 129.241.x.y 129.241.u.v 0 The magic is in the metric of 0, which announces that the machine is directly available. However, on our Apollos the above command causes the route to be added with a metric of 1, rendering this trick useless. In our case, the solution is to use netmask 255.255.0.0 and rely upon ugly tricks like proxy ARP (a service kindly provided to us by the local network management) to reach non-directly attached subnets. Maybe Hassel is running into the same kind of problem? As to his PS remark, I think I can explain why netmask 255.255.0.0 does not work for him: Then the sequence /etc/ifconfig dr0 134.88.14.1 ... /etc/ifconfig eth0 134.88.1.14 ... means that both interfaces are on the same network, which the networking software will (correctly) reject. Most likely, eth0 will be marked down as a result of these commands(?). If I have understood the problem correctly, there is only one solution, and that is to obtain a new network number (say, a class C one) to be used on the token ring, and then use netmask 255.255.0.0 on the ethernet side. Or, you can try to make Apollo fix the bug. Good luck... :-) PS. If there is no bug at all, I would be delighted to hear about it and how to add a route with metric 0. Or if there is a bug, maybe there is a fix for it? I am all ears... - Harald Hanche-Olsen The Norwegian Institute of Technology From apollo-request@umix.cc.umich.edu Thu Oct 19 13:29:18 1989 Date: 19 Oct 89 11:58:24 GMT From: jamieson%soleil.uucp@rutgers.edu (Steve Jamieson) Organization: Harris Semiconductor, Somerville, NJ Subject: SNMP agent for apollo Message-Id: <822@soleil.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am currently using an implementation of SNMP on my network. I am interested to find out if anyone knows of an SNMP agent that will run on an Apollo. I have about thirty five Apollos and it would be real helpful. One written under 9.7 or 10.1 would be good. steve jamieson Harris Semiconductor rutgers!soleil!jamieson (feed) From apollo-request@umix.cc.umich.edu Thu Oct 19 13:36:22 1989 Date: 19 Oct 89 03:20:24 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%ginosko%uakari.primate.wisc. (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: Tek401x emulation Message-Id: <21071@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Danford Corporation (San Pedro, CA) used to (and may still) sell a TEK-4010 emulator, as well as a TEK-4113 emulator. Their programs have a 'mailbox' mode that can be used with TCP-IP, etc. Another company (whose name I can't remember right now) offers TEK emulators as well as VT-100 emulators (like TEK-4105). I seem to recall the name Brighton, or something like that as the name. UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com From apollo-request@umix.cc.umich.edu Thu Oct 19 14:13:09 1989 Date: 18 Oct 89 20:27:20 GMT From: danny%idacom%ncc%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Danny Wilson) Organization: IDACOM Electronics Ltd., Edmonton, Alta. Subject: Japanese language support Message-Id: <764@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am looking for a worprocessor/page makeup etc package that produces text in Japanese Katakana/Hiragana/Kanji that runs on an Apollo workstation. Does anyone know if such a beast exists? What does Apollo Japan offer? -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta alberta!idacom!danny C A N A D A X.400 danny@idacom.cs.ubc.cdn From apollo-request@umix.cc.umich.edu Thu Oct 19 15:28:27 1989 Date: 18 Oct 89 21:29:26 GMT From: lori%hacgate%usc%ginosko%uakari.primate.wisc.edu%uwm.edu%gem.mps.ohio-state.edu.uucp@tut.cis (Lori Barfield) Organization: Hughes Aircraft Company, El Segundo CA Subject: Heterogeneously Distributed DBMS Message-Id: <5659@hacgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are looking at purchasing a DBMS that will distribute across Apollo, Sun, and VAX/VMS. There is already a copy of Interbase in house, which we have yet to test run. We need to know what other DBMS run across all three platforms. Do Ingres, ORACLE, or Sybase run on the Apollo? Ingres will be closed for awhile due to the 'quake. Does anyone know the numbers for ORACLE or Sybase? Anyone have any recommendations? Thanks! ...lori From apollo-request@umix.cc.umich.edu Thu Oct 19 15:38:02 1989 Date: 17 Oct 89 17:27:47 GMT From: bgo%pbhya%pacbell.uucp@ames.arc.nasa.gov (Bud Odekirk) Organization: Pacific * Bell, San Ramon, CA Subject: GETTING RID OF APOLLO Message-Id: <30474@pbhya.PacBell.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone out there have multiple PC's connected to an Apollo network ? We are getting ready to SHIT CAN Apollo. We have formed a committee to find an alternative to Apollo as soon as possible. Our main uses of Apollo are E-mail and some file sharing. We converted from DPSS mail to Unix mail a couple of months ago and we have had nothing but problems since. Apollo's solution to all of our problems is to convert to SR10. We figured that it would cost us in excess of 1 million dollars and we're not sure that will solve our problems. We have about 460 IBM PC's (or compatible) connected to the Apollo network using DTERM and PCI. Our Sysadmin tells me that we are the only ones that have this configuration and that is why no one else is encountering the same kind of problems. If anyone has a Apollo system that they are accessing with a large number of PC's, I would appreciate hearing from them. Thanks /\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/ 2600 Camino Ramon, Room 3W600E San Ramon, Ca. 94583 415 823-1379 {att,bellcore,sun,ames,pyramid}!pacbell!pbhya!bgo \*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/ From apollo-request@umix.cc.umich.edu Thu Oct 19 15:52:16 1989 Date: 18 Oct 89 19:37:26 GMT From: marmen%is2%bnrgate%bigsur%bnr-fos%bnr-vpa%utzoo%utgpu%jarvis.csri.toronto.edu%mailrus%uwm.edu% (Rob Marmen 1532773) Subject: Re: Wanted: tn3270 for Apollo SR10 Message-Id: <118@bnrgate.bnr.ca> References: <1209@kuling.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1209@kuling.UUCP>, victor@kuling.UUCP (Bjorn Victor) writes: > A friend of mine is looking for a public domain/free/very cheap > implementation of TN3270 for Apollo SR10. He would very much like it > to have 3278/3279 functionality. > We use software from Apollo called ETH_3270. It is an Apollo 'special' and they do not market it. Talk to your local Apollo salesman. We are running it on over 400 sr10.1 machines. We also had the original tn3270 distribution. It can be compiled and run under sr10.1. However, since we have modified the code, our laywers will not allow it out again. No special mods are required to get it to run. Hope this helps. Cheers, rob... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Robert Marmen marmen@bnr.ca OR | | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | | (613) 763-8244 My opinions are my own, not BNRs | From apollo-request@umix.cc.umich.edu Thu Oct 19 16:02:14 1989 Date: 17 Oct 89 18:19:26 GMT From: danny%idacom%aunro%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Danny Wilson) Organization: IDACOM Electronics Ltd., Edmonton, Alta. Subject: Re: Apollo NFS V2.0 Message-Id: <758@idacom.UUCP> References: <7847@charlie.OZ>, <238@ticipa.ti.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <238@ticipa.ti.com>, clif@ticipa.ti.com (Clif Harden) writes: > > We run SR10.1 NFS 2.0 here on our network with no problems. > I tryed the command that you gave and it worked with no problems. > > This is the way I do the command, it might be something you want to try. > mount -v -t nfs -o soft aragorn:/u /u Since we run these large, power hungry Mentor Graphics CAD applications, we usually try to distribute our servers around several nodes. node A /O\ nfsd, mountd Node A and B are / \ DN3000's with 4Mb RAM | | Token Ring \ / node B \O/ | Ethernet -------------+----------------------------- To realize this, we run the NFS servers on a node one the ring _different_ from the gateway node to the Ethernet (which connects to some Suns and a Vax) However, it we always get timeouts when trying to access DOMAIN files from one of the Suns. I could guess that the nfsd gets paged out when there is no activity (after you _do_ get into the directory, the response time seems normal). We have changed the mount command so that there are lots retries etc. Has anyone configured like this and did it work? -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta alberta!idacom!danny C A N A D A X.400 danny@idacom.cs.ubc.cdn From apollo-request@umix.cc.umich.edu Thu Oct 19 16:03:35 1989 Date: 18 Oct 89 14:31:47 GMT From: davidb%inmos%ukc%mcsun.uucp@uunet.uu.net (David Boreham) Organization: INMOS Limited, Bristol, UK. Subject: Disk Drives Message-Id: <2588@ganymede.inmos.co.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The recent postings on Apollo/3Com Ethernet boards set me thinking about disk drives. What I'd like to know is can you buy bare Maxtor disk drives an upgrade DN3550's with WD7000 controllers to 760Mb ? I know that the 348Mb drives are Maxtor XT4380E, are the 760Mb drives Maxtor XT8760E ? Also are they standard drives like you can buy from bare drive suppliers ? As a supplementary question, does anyone know if the SMS controller cards are available from anyone but apollo ? (The reason for all this is that bare drives cost less than half the apollo upgrade price). Could everyone mail replies and I'll summerise to the net. Thanks. -- David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb Bristol, England | (us): uunet!inmos-c!davidb +44 454 616616 ex 543 | Internet : @col.hp.com:davidb@inmos-c From apollo-request@umix.cc.umich.edu Thu Oct 19 16:05:16 1989 Date: 17 Oct 89 14:13:16 GMT From: marmen%is2%bnrgate%bigsur%bnr-fos%bnr-vpa%utzoo%utgpu%jarvis.csri.toronto.edu%mailrus%hellgate. (Rob Marmen 1532773) Subject: Apollo SR10 Registry Performance Message-Id: <114@bnrgate.bnr.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Our site has approximately 440 Apollos on ethernet running sr10.1. The Apollos are setup to run BSD4.3 unix exclusively. AEGIS is not installed. We are experiencing some difficulties with registry nodes being excessively overworked and occassionally melting down. Apollo is recommending that we increase the number of registry servers. However, they cannot recommend what the proper ratio should be, nor can they tell us if the severe performance degradation will drop to an acceptable level. Word about the poor registry performance has gotten out to the users and they are refusing to have registries placed on their machines. Has anyone experienced this registry degradation? If so, what was the solution? Finally, what ratio of registry servers to nodes are you running? Our ratio is approximately 1/45. If I can get data on the proper ratio, then I'll be able to convince the users to have registries placed on their nodes. cheers, rob... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Robert Marmen marmen@bnr.ca OR | | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | | (613) 763-8244 | From apollo-request@umix.cc.umich.edu Thu Oct 19 21:08:00 1989 Message-Id: Date: Thu, 19 Oct 89 17:47 EDT From: liwen@software.org (Andrew Liwen) To: apollo@umix.cc.umich.edu, jamieson%soleil.uucp@rutgers.edu Subject: Re: SNMP agent for apollo We are currently in the process of designing an SNMP based system, under SR10.1, for the Apollos. I have looked at the CMU and MIT PD sources and am leaning toward CMU as a base. We want to build a system that will work with Suns and VAXen as well, however the Apollo base will be the first. We have about 200 Apollos, 20+ Suns, and 20+ VAXen here. However the number of Suns and VAXen will grow so the tools will need to be portable to them. I'll let you know of our progress and be glad to share what we get done. BTW, what SNMP implementation are you using on your net? I'd like to compare notes. //Andy Liwen From apollo-request@umix.cc.umich.edu Thu Oct 19 21:16:03 1989 Date: 17 Oct 89 21:47:19 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: DOS floppies on apollo Message-Id: <1989Oct17.214719.18843@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu A while back someone posted that they have a program to read/write DOS floppies without using DPCC or DPCE. Could someone please send me some information about this product. -- Roger E. Benz Phone = (217) 223-3211 Quintron Corporation Quincy, Il UUCP: tiamat!quintro!reb@uunet or quintro!reb@lll-winken From apollo-request@umix.cc.umich.edu Thu Oct 19 21:16:20 1989 Date: 17 Oct 89 22:07:09 GMT From: lori%hacgate%usc.uucp@ucsd.edu (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: Memory Upgrades Message-Id: <5650@hacgate.UUCP> References: <8910131222.AA04402@apollo.eng.ohio-state.edu>, <5533@hacgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910131222.AA04402@apollo.eng.ohio-state.edu> crh@APOLLO.ENG.OHIO-STATE.EDU (Charlotte Hawley) writes: > >We want to upgrade the memory in an DN3500. Someone told >us about a company named Clearpoint? I followed up last week to this request with a post about DataRam. Clearpoint saw the post, and gave me a call. As far as prices are concerned, comparing list prices isn't meaningful since Clearpoint's discount was very substantial. For us, they are in the same ballpark as DataRam. I suggest anyone interested in prices should call directly for a quote rather than relying on what someone else paid. (Usually a good idea, but especially true in this case.) Both companies have trade-in policies for upgrades. (If you own a Mentor workstation, you probably already have Clearpoint memory in your machine.) I haven't seen any other followups to this post. Did I miss the mention of any other RAM suppliers? I have a DN3000 suffocating with only 4MB of RAM. We need to look around before we buy. ...lori From apollo-request@umix.cc.umich.edu Thu Oct 19 21:16:29 1989 Date: 17 Oct 89 15:20:53 GMT From: victor%kuling%bmc%sunic%luth%eru.uucp@bloom-beacon.mit.edu (Bjorn Victor) Organization: Department of Computer Systems, Uppsala University, Sweden Subject: Wanted: tn3270 for Apollo SR10 Message-Id: <1209@kuling.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu A friend of mine is looking for a public domain/free/very cheap implementation of TN3270 for Apollo SR10. He would very much like it to have 3278/3279 functionality. If anybody knows of such a thing, please respond to me (victor@DoCS.UU.SE). Footnote: Apollo SR10 claims to be BSD4.3, so if anybody knows a portable BSD4.3 implementation, please tell me. -- -- Bjorn Victor victor@DoCS.UU.SE Dept. of Computer Systems or victor%DoCS.UU.SE@uunet.UU.NET Uppsala University, Sweden "I'd rather hack a Lisp Machine!" Message failed for the following reason: Bad Queue Entry - Internal Error. Truncated message may be delivered. ---------------------------------------- Date: Mon, 16 Oct 89 21:25 +0100 From: NEWSMGR@BMC.UU.SE Subject: Usenet News Item(s) from BMC To: newsmgr@mtad.uas.uu.se X-VMS-To: IN%"newsmgr@mtad.uas.uu.se" From apollo-request@umix.cc.umich.edu Thu Oct 19 21:38:02 1989 Date: 18 Oct 89 15:42:35 GMT From: kint%software.org.uucp@uunet.uu.net (Rick Kint) Organization: Software Productivity Consortium, Herndon, Virginia Subject: Re: 2 Programming Questions Message-Id: <431@sunny.software.org> References: <8910171131.AA01220@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910171131.AA01220@umix.cc.umich.edu> MARCUS@MOLE.PCL.AC.UK writes: > >(ii) Is there a quick way to get a file's type-uid/size for inclusion in a > directory listing? Stream_$inquire takes forever and a day. stream_$inquire has the unfortunate characteristic of opening files first (like the name implies), which means it isn't too useful for getting attributes for, say, pty files--it hangs. As anyone who has used Apollos for any length of time will guess, there is an unreleased call which does exactly what he seeks... There is also a legal way of doing this, using a UNIX call. The stat call is used to get information about files. This uses the "struct stat" data structure, defined in /usr/include/sys/stat.h. The size of a file in bytes is in the member st_size (declared as an off_t, which is a long) and the block count is in st_blocks (a long). These are standard UNIX file attributes. The type UID is hidden, since it's not standard UNIX. At SR9.X, the type UID of a file is contained in the member st_spare4 (declared: long st_spare4[2]) and at SR10 the type UID is in st_rfu[0] and st_rfu[1] (declared: long st_rfu4[5]). In both cases the first long (st_spare4[0] and st_rfu[0]) is the high part of the UID. This is observed behavior; it isn't documented in anything that I've seen, but canned type UIDs are pretty distinctive in hex. Three problems arise: first, this is C, but using stat from another language shouldn't be too hard; use the insert files for different languages in /sys/ins to see how things are mapped between languages. UNIX calls don't use the std_$call convention, so you need to make sure that pointers are really pointers. Second, if you're at SR9.X and don't have Domain/IX, this information won't help you. The third is a bigger problem. Inclusion of the type UID in struct stat is undocumented (and therefore unsupported) behavior: stat.h at SR10 explicitly states that st_rfu is "reserved to Apollo". The member containing the type UID changed from SR9.7 to SR10, and may very well change again. Programs using this behavior may break in the future. This is not a criticism; Apollo was between Scylla and Charybdis here. If they were to add a new member st_typeuid to struct stat, someone would use this as further evidence that SR10 isn't "JLRU" and make much ado over nothing. Nonetheless, it would be nice to have a dependable, supported way to access Apollo-specific file attributes. And if anyone from Apollo is listening: just what does the name "rfu" stand for? For some reason, the expression "JLRFU" comes to mind... -- Rick Kint CSNET: kint@software.org Software Productivity Consortium ARPANET: kint%software.org@relay.cs.net Herndon, VA UUNET: ...!uunet!sunny!kint From apollo-request@umix.cc.umich.edu Thu Oct 19 21:41:25 1989 Date: Thu, 19 Oct 89 17:14:28 EDT From: markg@caen.engin.umich.edu (Mark Giuffrida) Message-Id: <4653bf071.0017b5e@caen.engin.umich.edu> To: apollo@umix.cc.umich.edu Subject: Re: GETTING RID OF APOLLO We are getting ready to SHIT CAN Apollo. We have formed a committee to find an alternative to Apollo as soon as possible. Our main uses of Apollo are E-mail and some file sharing. We converted from DPSS mail to Unix mail a couple of months ago and we have had nothing but problems since. Let me guess, "Unknown mailer error #". The big problem is that /bin/mail assumes it can always attach to its mailbox (i.e., its not mounted and never locked) and plop in the msg. And since Berkeley doesn't like to make changes to sendmail, its likely only to get fixed by the vendor. Since the vendor, Apollo, doesn't use sendmail internally, they are not likely to even see the problem. Your only recourse here is to do what we did and thats to make the modifications to /usr/lib/sendmail,/bin/mail,/usr/ucb/mail yourselfs. The changes are small, yet understanding sendmail is not. Of course we are working on (yes, I know I said this a few months ago) a public release version of our changes. But let me tell you. Once it is set up correctly on the Apollos, you have 1 /usr/spool/mail directory, not N of them (where N equals the number of nodes in your network). And not through NFS. If you think you have problems now, then try setting up your spool directory through nfs and you'll see the joys of maintaining hundreds of mounts points with these non-apollo unix workstations you are planning to buy. Apollos can work to your advantage if set them up correctly. Apollo's solution to all of our problems is to convert to SR10. We figured that it would cost us in excess of 1 million dollars and we're not sure that will solve our problems. This is not the solution. The solution is to get corrected code. But I am still confused over what you are implying. Do you really want to run the same version of the os when there is a newer one available? Do you think that switching vendors is going to alleviate the particular problem of being told to run the next release of their OS. Every vendor enhances their OS and schedules new releases. They vary from a few months to every year or so. This is *every* Vendor. Get used to it. If you don't want to "keep up" and upgrade, then buy all PC's or all Mac's or something that a system administrator is not needed for. I'm also willing to bet you have software maintenance through Apollo which means you are *paying* them to enhance your os. Now that sounds like a waste of money to me. ------------------------------------------------------ Mark Giuffrida University of Michigan markg@caen.engin.umich.edu Naturally, these comments are strictly my own views. ------------------------------------------------------ From apollo-request@umix.cc.umich.edu Thu Oct 19 22:35:29 1989 Date: Thu, 19 Oct 89 16:08:35 CDT From: Andrew M. Wescott Message-Id: <8910192108.AA02196@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu, bgo%pbhya%pacbell.uucp@ames.arc.nasa.gov Subject: Re: GETTING RID OF APOLLO Learn some manners. I don't respond to overzealous idiots. Andrew Wescott University of Houston From apollo-request@umix.cc.umich.edu Thu Oct 19 22:37:48 1989 Date: Thu, 19 Oct 89 16:10:52 CDT From: Andrew M. Wescott Message-Id: <8910192110.AA02203@lnic1.hprc.uh.edu> To: apollo-request.umix.cc.umich.edu@lnic1.hprc.uh.edu, apollo@umix.cc.umich.edu Please remove me from the subscriber's list immediately. Andrew Wescott University of Houston Department of Chemical Engineering From apollo-request@umix.cc.umich.edu Thu Oct 19 22:43:07 1989 Date: 19 Oct 89 19:19:28 GMT From: marmen%is2%bnrgate%bigsur%bnr-fos%bnr-vpa%utzoo%utgpu%jarvis.csri.toronto.edu%mailrus%cs.utexas. (Rob Marmen 1532773) Subject: Intermittent DN4500 Problem Message-Id: <119@bnrgate.bnr.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are experiencing an intermittent problem on some of our dn4500s. These machines are equiped with 16 meg of memory, a 348 meg disk drive and an f series monitor. The machines will mysteriously reboot themselves. They will display the rainbow, run diagnostics and bring up the o/s. The error log will sometimes show a memory parity error, but sometimes no error is logged, just the startup. We have trapped a crash in progress and the error was "memory parity error". However, the workstation had several different and verified sets of memory boards. We suspect that the message is a fake. When the machine crashes with users logged in, the users had been running a large application with large data files. The most common operation before the crash was a save of the data to disk. Needless to say, the users are not happy. The problem is not network or application related. Some machines are extremely reliable, while a machine next to it will crash once a day. Local Apollo support has been doing a fantastic job trying to debug the problem. However, I would like to know if anyone else has seen the problem? We're rapidly running out of ideas. Anything at this point will be welcome. Thanking everyone in advance... rob... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Robert Marmen marmen@bnr.ca OR | | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | | (613) 763-8244 My opinions are my own, not BNRs | From apollo-request@umix.cc.umich.edu Thu Oct 19 22:52:36 1989 Date: 19 Oct 89 23:44:16 GMT From: turner%bwana.sps.mot.com%dover%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu Organization: Motorola, Inc., Semiconductor Products Sector Subject: SCSI drives for the DN2500 Message-Id: <1912@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anybody in netland know where I can buy "SCSI" drives for a DN2500, other than Apollo. The vendors I've talked to have said, "We have SCSI drives but I'm sure our SCSI drives will work with the DN2500." Reason: Third party 637Meg SCSI drive costs about $3000. Apollo's 200Meg drives costs $3000. What can I say, I'm cheap. Robert ----- Law of the Net: Triva begets triva tenfold. All opinions are. Robert Turner (602) 994-6837 ...!uunet!dover!turner or turner@dover.sps.mot.com From apollo-request@umix.cc.umich.edu Fri Oct 20 00:49:25 1989 Date: 19 Oct 89 18:42:31 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: font size in knowledge broaker (and other applications) Message-Id: <1989Oct19.184231.22051@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are currently looking at a beta version of knowledge broader and our first reaction is "The font size is too small". Does anyone know how to change the font to a larger font? I would also like to change the font size used by dialogue. FLAME ON A general comment I have about the font sizes used by Apollo is, "You guys must have great vision!" The default fonts used are much too small and fine. They are too hard to read and cause a lot more eye strain than necessary. FLAME OFF For our monochrome stations we use the f7x13.b as our normal font. The size is ok and the bold gives a brighter font (which is needed to overcome the low intenesty screen and normal office light). For our color stations we use the default. Could someone please comment on why Apollo uses such a small font. -- Roger E. Benz Phone = (217) 223-3211 Quintron Corporation Quincy, Il UUCP: tiamat!quintro!reb@uunet or quintro!reb@lll-winken From apollo-request@umix.cc.umich.edu Fri Oct 20 09:23:05 1989 From: tpfabian@nasamail.nasa.gov (THEODORE FABIAN) Date: Thu, 19 Oct 89 21:12 PDT Message-Id: Cc: Subject: RE: Heterogeneously Distributed DBMS X-Lines: 34 In response to which platforms Oracle runs on... We are currently running Oracle on VAX/VMS hosts, Apollo DN3000 hosts, IBM 3090 hosts, and IBM 80386 based PC hosts... Files are portable to a point.. and code is portable if you don't include things that are specific to one platform.. eg. the VAX version uses field updating, while the IBM version uses screen updating.. (maybe I'm calling this by the wrong term..) however, it's easy to go one way.. harder to go the other... IBM into VAX is the easy route.. VAX into IBM harder... back to the Apollo version.. we just received it recently.. it requires at least 9.x OPerating System.. relies on TCP/IP to share resources over the normal DOMAIN XNS... seems to be well acceptted so far by the programmers and users... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Thanks, * * * * Ted Fabian * * * * NASA Lewis Research Center * * Cleveland, Ohio * * * * phone: 216-433-6307 * * FTS: 297-6307 * * * * email: tpfabian@nasamail.nasa.gov * * tfabian@earth.lerc.nasa.gov * * tfabian@csd.lerc.nasa.gov * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From apollo-request@umix.cc.umich.edu Fri Oct 20 09:23:53 1989 Message-Id: <8910201309.AA03753@umix.cc.umich.edu> Date: Fri, 20 Oct 89 08:54:51 EDT From: Scott Ferguson Subject: Apollo Contracts & Pricing To: apollo@umix.cc.umich.edu Seeing as many people are having a beef about Apollo's upgrade prices, I figured I'd throw in a little more. We all agree that Apollo's hard disks and RAM are WAY OVERPRICED. Well, let's make another comparison: Anyone have a maintenance contract for MAC's or IBM PC's? I know that maintenance on PS/2's is on the order of less than $100/year, while a DN3000 is on the order of $150 per MONTH. As a credit to Apollos designers, these 68020 and later machines are unstoppable, but therefore the maintenance isn't worth the dollars involved, if you ask me. Seems to me some hardware-oriented entrepreneur could make big dollars going into independent Apollo hardware service. I do believe I'm getting my money out of software maintenance, because of the upgrades the maintenance helps to fund. However, maintenance on hardware doesn't give me free updates on hardware, eh? Wouldn't that be nice...well, enough daydreaming :-) From apollo-request@umix.cc.umich.edu Fri Oct 20 11:29:07 1989 Message-Id: <8910201314.AA03980@umix.cc.umich.edu> Date: Fri, 20 Oct 89 09:01:38 EDT From: Scott Ferguson Subject: RE: Font Sizes To: apollo@umix.cc.umich.edu I don't see as how the default font should be worth any agony. There's enough utilities for changing the font, and there's plenty of nice fonts to go around. The only quirk I've seen is that it's pretty hard to change the font in the DM command window. Ever seen the default font in X11? Jeez! Which brings up my question: Does anyone know the command for loading different fonts in X11 xterm windows? Scott Ferguson ferguson@erenj.bitnet p.s. Back when 9.5 came out, I thought it was real nice when Apollo gave out the Times and Helvetica fonts with the OS. Thanks. From apollo-request@umix.cc.umich.edu Fri Oct 20 11:30:38 1989 Return-Path: Message-Id: <8910201455.AA02020@okc-unix.af.mil> Date: Fri Oct 20 09:51:39 1989 From: rkw@okc-unix.af.mil (Ron Wallman MMECTA) Subject: E-MAIL Address change Notice To: apollo@umix.cc.umich.edu Status: N Please take note my current E-mail Address "rkw@okc-unix.arpa" is being changed to "rkw@okc-unix.af.mil" Thanks. Ronald K Wallman Oklahoma City Air Logistics Center OC-ALC/MMECTR Bldg 3220 Tinker AFB, OK 73145-5990 (405)-736-7184 DDN Mail Address: rkw@okc-unix.af.mil From apollo-request@umix.cc.umich.edu Fri Oct 20 11:39:03 1989 Date: Fri, 20 Oct 89 10:54:00 EDT From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8910201454.AA25638@richter.mit.edu> To: apollo@umix.cc.umich.edu, kint%software.org.uucp@uunet.uu.net Subject: Re: 2 Programming Questions Well, the file size can be obtained from the MS_$ATTRIBUTES call (which is an Apollo specific call). The type UID can be obtain from IOS_$INQ_TYPE_UID (also an Apollo specific call). I don't know if the combination of these 2 calls is faster than STREAM_$INQUIRE or IOS_$INQUIRE... In any case you probably should use the IOS call rather than the STREAM calls. They are the newer implementation. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Oct 20 11:45:27 1989 Date: Fri, 20 Oct 89 10:11:17 EDT From: pha@caen.engin.umich.edu (Paul H. Anderson) Message-Id: <46574bed8.000f088@caen.engin.umich.edu> To: apollo@umix.cc.umich.edu, marmen@ucbvax.Berkeley.EDU Subject: Re: Apollo SR10 Registry Performance From: marmen@ucbvax.Berkeley.EDU Message-Id: <114@bnrgate.bnr.ca> Subject: Apollo SR10 Registry Performance Our site has approximately 440 Apollos on ethernet running sr10.1. The Apollos are setup to run BSD4.3 unix exclusively. AEGIS is not installed. We are experiencing some difficulties with registry nodes being excessively overworked and occassionally melting down. Apollo is recommending that we increase the number of registry servers. However, they cannot recommend what the proper ratio should be, nor can they tell us if the severe performance degradation will drop to an acceptable level. Word about the poor registry performance has gotten out to the users and they are refusing to have registries placed on their machines. Has anyone experienced this registry degradation? If so, what was the solution? Finally, what ratio of registry servers to nodes are you running? Our ratio is approximately 1/45. If I can get data on the proper ratio, then I'll be able to convince the users to have registries placed on their nodes. cheers, rob... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Robert Marmen marmen@bnr.ca OR | | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | | (613) 763-8244 | Here at UM, we are getting towards the end of switching over 500 nodes to SR10.1, and have dealt with a number of unusual problems in the transition. 1) the SR10 print server eliminated some optimizations for printing of bitmaps. While Apollo apparently intends to replace the lost speed, the stock 10.1 prsvr basically is quite slow. For what it is worth, Mentor Graphics, and probably other companies as well, haven't really caught up with the new NCS based printing scheme, so vendor's packages such as Mentor have had some problems with printing. 2) We broke the cvtrgy program (for converting sr10 registry to sr9 registry) by going over about 5600 accounts, which created a full_names file that was too large, and as a result broke one of the libraries on the 9.7 machines. This was fixed, but the patch won't show up until a later release than the stock 10.1 tapes. If you see a failure of this type (with large # of accounts), call Apollo tech support - they already have the fix. 3) Because the registry is now server based, rather than filesystem based (a really excellent idea!), strange things can happen that don't really show up very well, except as unstable load on the servers. In particular, if you have a single registry, and think that adding one additional slave will halve the load on the master, then think again. If one or the other becomes unavailable, the clients will time out, then switch to the other one, and not switch back until that choice times out. So what you tend to get is the entire network load switching from node to node. The solution is to make sure that you add enough servers to truly balance the load by offering a choice of remaining servers even if one goes down. In my opinion, three servers is not enough, even for only 100-150 nodes. Four servers may be a little marginal, and more would be better. After getting four or five servers, there is less need for additional ones, since as I mentioned before, the load will tend to be balanced better. Someone at Apollo mentioned something like 1 server for every 150 SR10 nodes, which is something I can agree with, but for the first 150 nodes, you probably want to see at least four servers. The performance of the registry depends largely on the offered load. In our environment (lots of student labs), we see a fair amount of registry activity, due to the dynamicly changing load caused by students moving between nodes at random (and doing it often - you can expect complete lab turnover in the 10 minutes between classes). So... if you are in a more stable environment, the servers will see less load. If you have a large registry, however, like we do (thousands of accounts), you can expect the server to pretty much eat up a DN3000 with 4 megs. A DN4000 with 8Megs can be used interactively, but is somewhat slower than I would like. But keep in mind that what I would really like is a desktop DN10000 (hint for Randy, my boss!). 4) The registry also had a problem that we are still working on, where creation of large numbers of accounts (300 per day) bogs the registry down to the point where we can do only a few transactions per minute. Since this may be related to problem 3) above, and because we can no longer easily test it, we expect to have to wait until next term before we get a high number of new accounts. Good luck! Paul Anderson CAEN Apollo Systems Programmer University of Michigan From apollo-request@umix.cc.umich.edu Fri Oct 20 13:34:55 1989 Date: Fri, 20 Oct 89 11:03:31 EDT From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8910201503.AA25685@richter.mit.edu> To: apollo@umix.cc.umich.edu, marmen%is2%bnrgate%bigsur%bnr-fos%bnr-vpa%utzoo%utgpu%jarvis.csri.toronto.edu%mailrus%cs.utexas. Subject: Re: Intermittent DN4500 Problem Hmm ... this may not be the same problem, but's here's something to check. We bought a brand new DN3500 with 8MB and a 690MB disk. No floppy or tape. It, too, would crash mysteriously and would kill users disk I/O intensive jobs with disk errors. Yet, there were no messages in the error logs. Our field service personel found that the disk controller board that had been shipped with the machine had been configured with either (or maybe both, I don't rememeber clearly) the floppy and/or the tape enabled (this was the Western Digital multifunction controller). He re-configured the board, and all has been fine since then. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Oct 20 13:37:30 1989 Date: 20 Oct 89 02:36:20 GMT From: murase%siva%nttlab%icot32%kddlab.uucp@uunet.uu.net (Hiroshi Murase) Organization: NTT Basic Research Laboratories, Tokyo, Japan. Subject: Re: Japanese language support Message-Id: <12736@siva.ntt.JP> References: <764@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <764@idacom.UUCP> danny@idacom.UUCP (Danny Wilson) writes: > I am looking for a worprocessor/page makeup etc package that produces > text in Japanese Katakana/Hiragana/Kanji that runs on an Apollo workstation. > > Does anyone know if such a beast exists? What does Apollo Japan offer? I found 'Apollo Publiss' in Japan Domain show '89, which includes Japanese text editor (of cource Katakana/Hiragana/Kanji), figure-drawing tools, an image scanner driver, a layout editor and data conversion tools from other wordprocessors. I do not know it in detail, but it looks fine. You can get it from Marubeni Hytech, +81-3-817-4932(tel). -- Hiroshi Murase NTT Basic Research Labs. (in Japan) murase%nttlab.ntt.jp@relay.cs.net From apollo-request@umix.cc.umich.edu Fri Oct 20 15:39:12 1989 Date: Fri, 20 Oct 89 12:43:05 CDT From: lray@civilgate.ce.uiuc.edu (Ray) Message-Id: <8910201743.AA00893@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu I need a supported way to log out a user from either a program or a shell script. The reason why I need this is I wish to prevent DM login by a user if the home directory does not exist. At SR9, I forced a shell script for all DM logins that simply did: if not existf ^HOME then # code to display messageand wait goes here xdmc lo end if At SR10.0 and SR10.1, I changed the way startups worked to provide maximum flexibility. A server now starts at login time, and looks for the home directory. If it doesn't exist, I create a window on the screen with a "Sorry, files are unavailable at this time" message. I then do a pad_$dm_command to effect a logout. However, using pad_$dm_command from a program to log someone out is precarious at best. It only works on some machine types at SR10.1, and at SR10.2 it will probably fail regularly. It fails in several ways. Most commonly, it says "unable to stop all processes, want to blast them?" If the logout program is run using /etc/server, the result is very strange. The window the program creates (and hence the program itself) will never cease except by shutting down the DM (it cannot be signaled because it is in pad_$dm_command). I believe the latter is caused by pad_$dm_command waiting for the operation to complete, and hanging. Perhaps it is remembering a parent/child relationship with the user (although started with a cps). Parhaps it is something else. QUESTION: How can I force a user logged into the console off the system? How can I get something that will work regardless of the windowing system the user elects? I'm willing to do any programming necessary to accomplish this. Just spendin' my days, Leland Ray Systems Administrator Soakin' in them cathode rays. UIUC - Dept. Civil Engineering (217) 333-3821 From apollo-request@umix.cc.umich.edu Fri Oct 20 16:21:39 1989 Date: 20 Oct 89 16:31:36 GMT From: maf@speech2.cs.cmu.edu (Michael Franzini) Organization: Carnegie-Mellon University, CS/RI Subject: NFS on Apollo? Message-Id: <6606@pt.cs.cmu.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Has anyone managed to get an Apollo 10K to work with NFS? Limited disk space has placed serious constraints on our ability to use our 10000s. However, we have ample disk space on several Sun workstations linked with NFS. If there were any way we could get our Apollo to work on this network, our biggest problem would be solved. Alternatively, if it were possible for the Apollo to access the disk on one of our Next workstations over the ethernet, that would be an equally attractive solution. Any advice (or pointers to sources of advice) would be greatly appreciated. maf@cs.cmu.edu Michael Franzini Department of Computer Science Carnegie Mellon University From apollo-request@umix.cc.umich.edu Fri Oct 20 17:23:35 1989 Date: 20 Oct 89 19:10:09 GMT From: clif%ticipa%ti-csl%pollux%texsun%newstop%sun-barr.uucp@apple.com (Clif Harden) Organization: TI PAC Wafer Fab Systems, Dallas Subject: Re: Apollo NFS V2.0 Message-Id: <239@ticipa.ti.com> References: <758@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <758@idacom.UUCP>, by danny@idacom.UUCP (Danny Wilson): > > To realize this, we run the NFS servers on a node one the ring _different_ > from the gateway node to the Ethernet (which connects to some Suns and a > Vax) I am assuming that you mean the your gateway node is not running as a NFS server. Running the gateway node as a NFS server won't cause you any problems. In fact it may be part of your problem. We had a problem quite similar to this. We mounted files from our microvax to our gateway node which had NFS running. Some of our nodes didn't have NFS running, these nodes could see the NFS mounted files but could not access them properly, they timed out trying to access them. Just because you have NFS running on some of your nodes doesn't mean all your nodes can use the NFS mounted files. Those nodes that don't have NFS installed probably won't work correctly. I suppect that if your gateway node isn't running NFS it may be having trouble handling the NFS requests. I run NFS on all the nodes in my network and I don't have any NFS problems. Clif Harden TI PAC Apollo Network Adminstrator Texas Instruments PO Box 655012 M/S 3635 Dallas, TX 75265 From apollo-request@umix.cc.umich.edu Fri Oct 20 19:15:21 1989 Date: 20 Oct 89 11:01:27 GMT From: achille%cernvax%mcsun%sunic%luth%eru.uucp@bloom-beacon.mit.edu (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Doamin on Ethernet problem Message-Id: <1127@cernvax.UUCP> References: <119@bnrgate.bnr.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi there, we are experiencing lot of problems on ours, ethernet based, Apollos. The problem has been seen both on 3500 and 3000 with ethernet as primary (and only in most cases) network. The node will loose contact with the network, both at DDS and tcp/ip level, rtstat -dev shows enormous numbers for 'no resources', some 20000 per second (yes, twenty thousand !), but the node is not receiving even 20 per second (we checked that with an ethernet analyzer). We are running sr10.1 on one of the nodes we've been investigating more. There some 30 machines on ethernet mostly running 9.7, plus 2 dn10000 (sr10.1) and 1 3500 (sr10.1) and 1 3000 (sr10.1, secondary network). We traced down the problem to be related to dn3xxx to dn10k interactions. A way to reproduce the problem, 100 %, is to do from the dn3xxx: ls -l //dn10k This will slowly start telling you that does not find some directories (that are there) and the number of 'no resources' will skyrocket. Now the dn3xxx is gone. The dn10k is instead perfectly happy. Has anybody seen that ? Is there any patch available ? Our SSR cannot reproduce the problem in their place (don't have a dn10k and they run on ring) and we are a little bit unconfortable in letting them try these things on our net :-) The work-around we've found is to NOT access any dn10k from dn3xxx ethernet based nodes (which of course defeats the whole purpose of networking). For the time being it's OK given the small number of dn10ks and of sr10 machines, but what can we do in a few months time when everybody will go sr10 ? Help !!! Thanks in advance, Achille Petrilli Cray & PWS Operations From apollo-request@umix.cc.umich.edu Fri Oct 20 23:19:20 1989 Date: 20 Oct 89 23:46:00 GMT From: daemon%imagen.uucp@ucbvax.Berkeley.EDU (M.V.S. Ramanath) Subject: GNU emacs 18.51 on SR10.1 Message-Id: <4561@imagen.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm trying to build Leonard Zubkoff's port of 18.51 on SR10.1. The first attempt failed in the 'clnz' directory. Since that stuff relates to the Concept LNZ terminal which I don't need, I tried again after removing the references to CLNZ, clnz.o, and txtcmp.o in src/config.h. This time the build succeeded, the executable seems to run perfectly but when I exit emacs, the window input pad is no longer there and so the window is completely dysfunctional. Any help is much appreciated. Ram (imagen!ram@sun.com) From apollo-request@umix.cc.umich.edu Sat Oct 21 01:16:24 1989 Date: 20 Oct 89 17:50:00 GMT From: oj%apollo.uucp@beaver.cs.washington.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: sendmail at apollo (formerly Re: GETTING RID OF APOLLO) Message-Id: <4658104f.20b6d@apollo.HP.COM> References: <4653bf071.0017b5e@caen.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <4653bf071.0017b5e@caen.engin.umich.edu> markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) writes: >Since the vendor, Apollo, >doesn't use sendmail internally, they are not likely to even see the problem. We're changing (albeit slowly). I've personally been using sendmail on my node for about a year--and it works. I couldn't do my job without reliable email. The present policy is to encourage internal users to use sendmail-based stuff, but not to cut off the other mail system. Furthermore, our relationship with the rest of HP is making it harder for us to get away with ignoring U***X mail. The good news is that our internal system administration department started actually *supporting* sendmail a few months back...Hooray! So, we're being dragged, kicking and screaming, from the Dark Ages into the early 1980's. :-) I think you'll be happy with some of the stuff we're working on now. /oj (speaking for myself, not necessarily for HP's Apollo Systems Division) From apollo-request@umix.cc.umich.edu Sat Oct 21 01:19:14 1989 Date: 20 Oct 89 19:54:00 GMT From: oj%apollo.uucp@beaver.cs.washington.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Font Sizes Message-Id: <46587e99.20b6d@apollo.HP.COM> References: <8910201314.AA03980@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910201314.AA03980@umix.cc.umich.edu> SRFERGU@ERENJ.BITNET (Scott Ferguson) writes: > >Ever seen the default font in X11? Jeez! Yeh, it's bad.... >Does anyone know the command for loading different fonts in X11 xterm windows? There are a bunch of ways of doing this. Best: put lines in your ~/.Xdefaults file like this (as long as you have XV11R3 fonts on your machine): xterm*vt100*boldFont: *-courier-medium-r*-140-* xterm*vt100*font: *-courier-bold-r*-140-* This uses courier bold 14 point for normal text and non-bold for "standout" text. A bit quirky, but I find the bold easier to read. Second best: issue the command xterm -font "*-courier-bold-r*-140-*" This specifies the font explicitly. It seems to get overridden by the ~/.Xdefaults spec if you have one. >Back when 9.5 came out, I thought it was real nice when Apollo gave out >the Times and Helvetica fonts with the OS. Thanks. You're welcome. Adobe was nice enough to donate the same Times, Helvetica, Courier, and Symbol font bitmaps to the XV11R3 tape. Bitstream donated bitmaps for a font known as Charter to the same tape. All of these fonts are of high quality. I like Charter because it looks nice and they offer a 33-point version. However, you can't use variable-width fonts with xterm. We put all these fonts on our SR10.1 X distribution. /oj (speaking for myself, not necessarily for HP Apollo Systems Division) From apollo-request@umix.cc.umich.edu Sat Oct 21 01:26:18 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8910210447.AA02085@icaen.uiowa.edu> Date: Fri, 20 Oct 89 22:15:33 CDT Subject: Re: Doamin on Ethernet problem To: achille%cernvax%mcsun%sunic%luth%eru.uucp@bloom-beacon.mit.edu, apollo@umix.cc.umich.edu WRT posting <1127@cernvax.UUCP> > Hi there, we are experiencing lot of problems on ours, ethernet based, > Apollos. > The problem has been seen both on 3500 and 3000 with ethernet as primary > (and only in most cases) network. > The node will loose contact with the network, both at DDS and tcp/ip level, > rtstat -dev shows enormous numbers for 'no resources', some 20000 per second I can think of 2 possible causes of this problem: 1) The "ethernet8_microcode" that was shipped with sr10.1 is seriously flawed. The sr9.7 version was not perfect but not nearly as bad as the 10.1. It is worst in a DDS & IP Ethernet environment, if you are only running IP the sr9.7 was OK the sr10.1 was marginal. There are various sr10.1 patches out for this but most of them aren't worth messing with. The best solution is to get a copy of "/sys/ethernet8_microcode" from a sr10.2 system, even from the Beta1 sr10.2 release. This "ethernet8_microcode" works VERY well and can be safely installed on sr9.7 & sr10.x systems. We've been using it for 2 months now and are quite pleased with it. Talk to your local Apollo office, they may be able to get it for you. Just copy the file into /sys and reboot. Here's a "rtstat" off one of our ring/E-net gateways, note the low E-net error rates: $ rtstat -dev -net ---------------------------------------------------------------- 80FF1500.12E88 pkts routed: 526964 queue oflo: 0 Ring pkts sent: 2559538 pkts rcvd: 2743208 NACKs 987 WACKs 27872 Xmit bus err 0 Xmit timeouts 303 Token inserted 58 Rcv DMA EOR 0 Rcv CRC error 0 Rcv timeouts 1 Rcv bus error 0 Rcv xmtr error 1033 towards net: 80FF1500 ref cnt: 2389382 towards net: 80FF1300 ref cnt: 229121 ETH802.3_AT pkts sent: 309484 pkts rcvd: 266299 Hdwr xmits 1700895 Hdwr rcvs 3304708 CRC errors 0 Misalignments 5 No resource 0 Over-run 2 Adapter err 0 Full socket 694 towards net: 80FF4000 ref cnt: 313524 2) There is a bug in the sr10.0 & sr10.1 implementation of the "rgyd". This can cause various strange problems that often look like the rgyd dying. When this happens, system operations that deal with user IDs or protections (like "getpwuid") may cause network retrys. You say that "ls -l" will generate the problem, the "-l" option causes "rgyd" operations because of the need to extract the owner name. If you do a dn3k to dn10k network operation that doesn't involve "rgyd" operations does the problem still happen? Try a utility like "/com/lst" (sr10; under sr9.7 its "/systest/lst"). Dave Funk From apollo-request@umix.cc.umich.edu Sat Oct 21 03:18:10 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8910210538.AA02105@icaen.uiowa.edu> Date: Sat, 21 Oct 89 00:06:47 CDT Subject: Re: Apollo SR10 Registry Performance To: apollo@umix.cc.umich.edu, marmen@ucbvax.Berkeley.EDU WRT posting <114@bnrgate.bnr.ca> > Our site has approximately 440 Apollos on ethernet running sr10.1. > The Apollos are setup to run BSD4.3 unix exclusively. AEGIS is not > installed. We are experiencing some difficulties with registry nodes > being excessively overworked and occassionally melting down. I agree with all that Paul Anderson said <46574bed8.000f088@caen.engin.umich.edu> and would add: 1) "rgyd" can be a memory hog. It likes to keep the whole data base in memory and can use a lot. On our system (3000+ accounts) a "rgyd" uses about 6 Mb (based on a "ps agux"). It accounts for a lot of page faults on a system that has 8 Mb of memory (I hate to think of what it would to to a 4 Mb system :-). If possible, run it on a system that has plenty of RAM (particularly your master rgyd). Don't run it on the same node as other memory hungry daemons. EG put rgyd & glbd on different nodes. 2) If you have too many rgyds then your master rgyd will spend a lot of time (cpu & network) making sure that all the slaves stay in sync. A registry change (new account, password chage, shell change, etc) must be distributed to all the slaves. 3) There is a bug in the sr10.0 & sr10.1 rgyd implementation that can cause problems when your rgyds are left up for long periods of time on a system that is active. We have 3000+ accounts and do "cvtrgy"s daily. We've found that we have to reboot the master rgyd node at least once a month. This is supposed to be fixed at sr10.2. Dave Funk From apollo-request@umix.cc.umich.edu Sat Oct 21 05:18:46 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8910210706.AA02114@icaen.uiowa.edu> Date: Sat, 21 Oct 89 00:47:12 CDT Subject: Re: DM logout tool To: lray@civilgate.ce.uiuc.edu, apollo@umix.cc.umich.edu WRT posting <8910201743.AA00893@civilgate.ce.uiuc.edu>: > I need a supported way to log out a user from either a program > or a shell script. > The reason why I need this is I wish to prevent DM login by a user > if the home directory does not exist. > At SR9, I forced a shell script for all DM logins that simply > did: > if not existf ^HOME then > # code to display messageand wait goes here > xdmc lo > end if > > QUESTION: How can I force a user logged into the console off the > system? What you want can be done if it is done correctly. Your problem is that the simple approach ("xdmc lo" & pad_$dm_cmd(sid,'lo',...) has some undesireable side effects due to a limitation (feature? ;-) of the Display Manager. To put it bluntly if you do "xdmc lo" you mess up the DM. The symptoms are subtle at first but they can get bad. Try this experiment. Take a node that is in known good state, (reboot it if you don't know for sure) and watch carefully what happens when you log in. First you see the "login:" prompt (sr10; "Please log in:" for pre-sr10). Type in a login ID & hit return, the "Password:" prompt appears. Type in the password & hit return, the prompt dissappears and a few seconds later things happen. Assuming that you've given it a valid ID & password, an inital shell appears and ONLY THEN the "Command:" prompt appears in the DM input window. Hit the "CMD" key, type in "lo" & return. Note that the "Command:" prompt dissappears for a few seconds before the "login:" comes back. Log back in and now type in "xdmc lo" in the shell to log out; you've just messed up the DM and here come the first symptoms. Log back in again but pay carefull attention to what happens in the DM input window. Type in the login ID, hit return, and watch closely. You'll see the "login:" prompt dissappear, the "Command:" prompt appear for a fraction of a second, and then the "Password:" prompt appears. Type in the password, hit return, and watch again. The "Password:" prompt dissappears but now the "Command:" prompt appears instantly, before any thing else begins to happen. Once a "xdmc lo" has been done, the symptoms are there. If the node is run long enough in this state then other symptoms can occur like garbage characters & little triangles appearing along with or in place of the "Command:" prompt. Once this starts, the only cure is to reboot the node (or reload the DM with an "EX" & "GO"). If you put the "xdmc lo" in a shell script, then you'll have a read lock left on the file after it is used. If you try to put it in a program with a pad_$dm_cmd(sid,'lo',..) then you have all kinds of strange problems with the process hanging. So how do you log out from a shell script or program with out all these problems? The answer is to use the correct incantation. Don't use "xdmc lo" use instead "xdmc tdm;es 'lo';en". This strange command sequence sends the cursor to the DM command window, inserts the text 'lo' there, and then "pushes the return key". The important thing is that this will let the "xdmc" operation finish before the DM "sees" the 'lo' command. To deal with the case of the user hitting the "READ", "EDIT", or "HELP" key and then just walking away, use "xdmc tdm;en;tl;es 'lo';en". To put this inside a program use pad_$dm_cmd(sid,'tdm;en;tl;es ''lo'';en',...). This will deal with a DM login, I don't yet know how to deal with 'X' as the "login" environment. Maybe some 'X' guru can help here. One passing though, if (at sr10) you want to use the sledge hammer approach, you could kill all the user's processes and then kill the DM. Init will happily create a new DM if the current one dies. Of course you may not get things like changed key defs saved or open edits saved, but the user will be out of there. A few final DM goodies: there is an undocumented Word-Wrap mode for edit pads. Look at page 15 in the Feburary '89 issue of "The ADUS Ring". Ever wish for an "again" key for DM commands? Try the "undo" key in the DM "command:" window. Dave Funk From apollo-request@umix.cc.umich.edu Sat Oct 21 13:19:17 1989 Date: Sat, 21 Oct 89 10:19:40 CDT From: Andrew M. Wescott Message-Id: <8910211519.AA03400@lnic1.hprc.uh.edu> To: achille%cernvax%mcsun%sunic%luth%eru.uucp@bloom-beacon.mit.edu, apollo@umix.cc.umich.edu Subject: Re: Doamin on Ethernet problem Delete /sys/ethernet8_microcode on your SR 10.1 DN3xxx machines, and you'll probably be pleasantly surprised. Don't forget to reboot. There is a patch available, but things will work o.k. without it. From apollo-request@umix.cc.umich.edu Sat Oct 21 21:15:39 1989 Date: 21 Oct 89 22:49:57 GMT From: rohlicek%bbn.com@bbn.com (Robin Rohlicek) Subject: 3rd party disks for Apollo DN10000? Message-Id: <47227@bbn.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm looking for pointers for 3rd party vendors who have EDSI (or SCSI) controllers for the DN10000. I'd like to hang several (4 to 8) Wren VI's off the VME bus. Disk striped ESDI controller would be nice. I'll summarize to comp.sys.apollo if I get replies. Robin Rohlicek. BBN STC, Cambridge MA. From apollo-request@umix.cc.umich.edu Sun Oct 22 19:23:14 1989 Date: 22 Oct 89 20:13:28 GMT From: art%csuf3b%sdsu%usc%ginosko%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Art Morton) Organization: Calif. State Univ., Fresno, Ca Subject: Interop Demo Message-Id: <1692@csuf3b.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu At the Interop Conference in San Jose California an Apollo/1000 machine was demonstrated for interconnectivity. In its files were WEFAX/GEOS-E and TIROS and USSR weather satellite pictures. These pictures were displayed under X windows in GIFF format. Does anyone know what ftp site these pictures came from? art art@csufres.fresno.edu From apollo-request@umix.cc.umich.edu Mon Oct 23 04:26:26 1989 Date: 19 Oct 89 11:58:24 GMT From: jamieson%soleil.uucp@rutgers.edu (Steve Jamieson) Organization: Harris Semiconductor, Somerville, NJ Subject: SNMP agent for apollo Message-Id: <822@soleil.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am currently using an implementation of SNMP on my network. I am interested to find out if anyone knows of an SNMP agent that will run on an Apollo. I have about thirty five Apollos and it would be real helpful. One written under 9.7 or 10.1 would be good. steve jamieson Harris Semiconductor rutgers!soleil!jamieson (feed) From apollo-request@umix.cc.umich.edu Mon Oct 23 09:41:21 1989 Date: 23 Oct 89 02:02:55 GMT From: walsh%stdc01%rti.uucp@mcnc.org (Mike Walsh) Organization: Star Technologies, Graphicon Products Division (RTP, N.C) Subject: Mentor Graphics & DN2500 Message-Id: <574@stdc01.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I posted this a couple of weeks ago, and recieved no replies and saw not postings. We have had problems with our newsfeed so If this is a repeat I apologize. The company I work for has recently transitioned to Mentor Graphics EDA tools. Although expensive, we have found them to work very well for most of our needs. The time has come to do some customizing of the user interface to ease some of the operations that we do to our schematics. Does anyone out there in net-land have any experience in creating/modifying the popup windows supplied with NetEd. I have successfully added items to the menus, but I would like to create a popup form, (Mentor refers to them as Dialog Boxes) have a user fill in some information in that form, and then process the information. I have scoured the manuals and have not been able to find anything. Is what I want to do even possible? The books seem to say it is, but I can not find any examples. Is there an unreleased tool for creating popup forms? I'd appreciate any help or suggestions that any one has to offer. We are currently running Mentor Graphics version 6.1. My second question, does anyone know whether or not Mentor is going to support the new DN2500 ? ... Mike Mike Walsh, Electrical Engineer Star Technologies, Graphicon Products Division Reserach Triangle Park, NC walsh@stdc01.UUCP { ...!uunet!mcnc!rti!stdc01!walsh } From apollo-request@umix.cc.umich.edu Mon Oct 23 15:11:03 1989 From: van%tcipro.uucp@unix.sri.com Message-Id: <8910231803.AA11792@unix.sri.com> Date: Mon, 23 Oct 89 10:29:43 PDT To: apollo%umix.cc.umich.edu%sri-unix.uucp@unix.sri.com Subject: GNU emacs 18.51 on SR10.1 I recently compiled GNU emacs 18.55 on SR10.1 and ran into the same problem described by M.V.S. Ramanath, namely that upon exiting emacs the window it was in became unusable. I have found that by using the vt100 terminal emulator, I can get around this problem. Before calling up emacs, typing 'vt100' invokes the emulator-- emacs can then be run and exited normally. Ctrl-D exits from the emulator. --Van (van@psych.stanford.edu) From apollo-request@umix.cc.umich.edu Mon Oct 23 17:05:51 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8910231917.AA00289@icaen.uiowa.edu> Date: Mon, 23 Oct 89 14:05:22 CDT Subject: Re: SNMP agent for apollo To: apollo@umix.cc.umich.edu, jamieson%soleil.uucp@rutgers.edu WRT posting <822@soleil.UUCP>: > I am currently using an implementation of SNMP on my network. I am > interested to find out if anyone knows of an SNMP > agent that will run on an Apollo. I have about thirty five Apollos > and it would be real helpful. One written under 9.7 or 10.1 would > be good. I have looked at porting SNMP to Apollo and there is one major problem. SNMP assumes that you have a Berkeley (or derivitives) kernal, it wants to open "/dev/kmem" and go grubbing around in kernal memory to put out IP stuff (stats, routing tables, etc). As the Apollo kernal is totally different (in fact the tcp/ip tables aren't even in the kernal) this won't work very well. The info is actually in a file in user space (`node_data/tcp_data sr9.x & `node_data/systmp/tcp_data sr10) and its format is undcoumented. It could be done but it would be messy. There is hope though; at sr10.2 there are some new "ioctl" calls, that are released, to export this kind of information to user processes. With these calls at sr10.2 it should be relatively easy to port SNMP. Dave Funk From apollo-request@umix.cc.umich.edu Mon Oct 23 19:01:15 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8910231937.AA00299@icaen.uiowa.edu> Date: Mon, 23 Oct 89 14:27:55 CDT Subject: Re: Doamin on Ethernet problem To: apollo@umix.cc.umich.edu I want to clarify my posting <8910210447.AA02085@icaen.uiowa.edu> on the DDS on Ethernet problem: > the sr9.7 was OK the sr10.1 was marginal. There are various sr10.1 patches > out for this but most of them aren't worth messing with. The best solution > is to get a copy of "/sys/ethernet8_microcode" from a sr10.2 system, even The sr10.1 patch #m0017 is the patch that "isn't worth messing with". Patch #m0038 (from tape M68K_8907 or newer) is the same as the sr10.2 release microcode and this one DOES work and should be used. My Apollogies for any confusion that this caused. Dave Funk From apollo-request@umix.cc.umich.edu Mon Oct 23 20:52:19 1989 Message-Id: <8910232135.AA06237@umix.cc.umich.edu> Date: Mon, 23 Oct 89 16:35:07 EDT From: Scott Ferguson Subject: ms_$mapl and fseek/fread To: apollo@umix.cc.umich.edu I am using ms_$mapl to create a giant file (a collation of 300-800 image files, each approximately 512x320 in size, two bytes per pixel) for later tomographic inversion (CT-scan stuff). Now, like a smartass, I want to read the file using standard fseek and fread calls. I want to do this because we have an Ardent on the network which does blinding FFT's and has NFS. When I do fseek, I get "no problem" back from the OS, but fread returns a value of 0 bytes read. Then, I call perror to get the file error, and it gives me a zero error also. SO, there's no error condition, but I didn't get any bytes. Is what I'm trying feasible, or do I have to create the file with stdio calls in order to read it back? Thanks in advance, Scott Ferguson ferguson@erenj.bitnet Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 From apollo-request@umix.cc.umich.edu Mon Oct 23 21:00:29 1989 Date: 21 Oct 89 21:06:36 GMT From: danny%idacom%aunro%atha.uucp@decwrl.dec.com (Danny Wilson) Organization: IDACOM Electronics Ltd., Edmonton, Alta. Subject: Re: GETTING RID OF APOLLO Message-Id: <771@idacom.UUCP> References: <4653bf071.0017b5e@caen.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <4653bf071.0017b5e@caen.engin.umich.edu>, markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) writes: > [...] > Your only recourse here is to do what we did and thats to make the > modifications to /usr/lib/sendmail,/bin/mail,/usr/ucb/mail yourselfs. > The changes are small, yet understanding sendmail is not. > Of course we are working on (yes, I know I said this a few months ago) > a public release version of our changes. Unless I am missing something, Apollo distributes BINARY code versions of all its programs (like everyone else). With this in mind, it seems quite impossible to modify /usr/lib/sendmail, /bin/mail etc without having the source code. Where is the source code coming from? -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta alberta!idacom!danny C A N A D A X.400 danny@idacom.cs.ubc.cdn From apollo-request@umix.cc.umich.edu Mon Oct 23 21:10:43 1989 Date: 21 Oct 89 21:01:12 GMT From: danny%idacom%aunro%atha.uucp@decwrl.dec.com (Danny Wilson) Organization: IDACOM Electronics Ltd., Edmonton, Alta. Subject: Re: Intermittent DN4500 Problem Message-Id: <770@idacom.UUCP> References: <119@bnrgate.bnr.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <119@bnrgate.bnr.ca>, marmen@is2.bnr.ca (Rob Marmen 1532773) writes: > > We are experiencing an intermittent problem on some of our > dn4500s. These machines are equiped with 16 meg of memory, a 348 > meg disk drive and an f series monitor. > > The machines will mysteriously reboot themselves. We have a similar, but perhaps unrelated problem on a DSP90 with 3 Mb. This node, connected to a 9-track tape, does routine backups via a bourne shell script (using wbak). Once in a while during the backup, the machine will orderly shut itself down. The message on the console simply says "Beginning shutdown sequence" kills off all the processes and proclaims "Shutdown is successful". Mentor has not been able to pinpoint exactly why this happens. Anyone else seen this? -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta alberta!idacom!danny C A N A D A X.400 danny@idacom.cs.ubc.cdn From apollo-request@umix.cc.umich.edu Mon Oct 23 22:57:00 1989 Date: 23 Oct 89 19:55:27 GMT From: marmen%is2%bnrgate%bigsur%bnr-fos%bnr-vpa%utzoo%utgpu%jarvis.csri.toronto.edu%mailrus.uucp@tut. (Rob Marmen 1532773) Subject: Re: Apollo SR10 Registry Performance Message-Id: <127@bnrgate.bnr.ca> References: <46574bed8.000f088@caen.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Thanks for the reply. There are a couple of more pieces of information that are relevant. 1) We are running BETA sr10.2 regitries. This was needed to fix a problem with a server responding 20 times to each registry request. The new registries fix that problem. This was quite serious because we are 100% ethernet and the network load was phenominal. Also, HPApollo are working on an ethernet microcode fix to cure a problem with short interpacket spacing. 2) Our site is 100% BSD unix. This puts an additional load on the servers because the /etc files are now streams to the server. It's amazing how many programs look at these files constantly. The applications have not been modified to take in to account that there are now network accesses instead of disk accesses. Under sr9.7, we had a ratio of 1 registry for 35 nodes. In addition, the workstations were modified so that the /etc directory was resident on each nodes. Otherwise the performance was unacceptable. At this point, we are going to experiment with a ratio of 1 server for 20 workstations. It's just a guess, but we reason that since the unix programs are going to constantly look at the /etc files, then the number of servers should actually be greater than a sr9 site. Any comments? cheers, rob... PS. Again, thanks for the reply. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Robert Marmen marmen@bnr.ca OR | | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | | (613) 763-8244 My opinions are my own, not BNRs | From apollo-request@umix.cc.umich.edu Mon Oct 23 23:04:57 1989 Date: 23 Oct 89 19:58:26 GMT From: marmen%is2%bnrgate%bigsur%bnr-fos%bnr-vpa%utzoo%utgpu%jarvis.csri.toronto.edu%mailrus%uwm.edu% (Rob Marmen 1532773) Subject: Re: Doamin on Ethernet problem Message-Id: <128@bnrgate.bnr.ca> References: <119@bnrgate.bnr.ca>, <1127@cernvax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1127@cernvax.UUCP>, achille@cernvax.UUCP (achille petrilli) writes: > The node will loose contact with the network, both at DDS and tcp/ip level, > rtstat -dev shows enormous numbers for 'no resources', some 20000 per second > (yes, twenty thousand !), but the node is not receiving even 20 per second > (we checked that with an ethernet analyzer). > > We traced down the problem to be related to dn3xxx to dn10k interactions. > A way to reproduce the problem, 100 %, is to do from the dn3xxx: > > ls -l //dn10k > > This will slowly start telling you that does not find some directories (that > are there) and the number of 'no resources' will skyrocket. > Now the dn3xxx is gone. The dn10k is instead perfectly happy. > > Achille Petrilli > Cray & PWS Operations I would check the following: 1) Ethernet microcode revision level. You should be running a version no earlier than March of this year. The previous micocode was very buggy. The code is stored in /sys/ethernet8_microcode. 2) Does the number of crc and misalignment errors skyrocket as well? If so, then it may be microcode, or you have a bad connection between the two machines. I have seen drops (using utp) which technically checkout o.k., but because of a loose wire or connection, will generate lots of bad packets. rob... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Robert Marmen marmen@bnr.ca OR | | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | | (613) 763-8244 My opinions are my own, not BNRs | From apollo-request@umix.cc.umich.edu Tue Oct 24 07:29:22 1989 Date: 23 Oct 89 17:40:42 GMT From: dente%els%mucs%ukc%mcsun.uucp@uunet.uu.net (Colin Dente) Organization: University of Manchester, UK Subject: Re: Apollo NFS V2.0 Message-Id: <292@m1.cs.man.ac.uk> References: <7847@charlie.OZ>, <238@ticipa.ti.com>, <758@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <758@idacom.UUCP> danny@idacom.UUCP (Danny Wilson) writes: > >[Description of NFS set up at IDACOM] > > node A /O\ nfsd, mountd Node A and B are > / \ DN3000's with 4Mb RAM > | | Token Ring > \ / > node B \O/ > | Ethernet > -------------+----------------------------- > >To realize this, we run the NFS servers on a node one the ring _different_ >from the gateway node to the Ethernet (which connects to some Suns and a >Vax) > >However, it we always get timeouts when trying to access DOMAIN files >from one of the Suns. I could guess that the nfsd gets paged out when >there is no activity (after you _do_ get into the directory, the response >time seems normal). We have changed the mount command so that >there are lots retries etc. > >Has anyone configured like this and did it work? Sorry for the big quote - but it all seems relevant. We have a similar configuration - except we are running the NFS stuff on the gateway node (DN3010, 4Mb, 10.1) (+ we have a few more nodes on the token ring), and response is *AWFUL*. Accessing domain files from a Sun on the same piece of ethernet as the Apollo will often result in many timeouts - (that is, the Sun says 'NFS server not responding' followed a few seconds later by 'NFS server OK'. Typically, you might expect 20 timeouts when shifting 5Mbytes of data across via NFS. In another building, I have a very similar setup, but with a DN590-T (12Mb, ETH802.3_VME interface, 10.1) as the gateway - this behaves similarly, except the NFS server on that often goes away for ever (well, until I get bored - i.e. >1 hour). In both cases the ethernet is very lightly used - peak load is about 10%, average 2-3%. I'm told that you have to patch the ethernet8_microcode on pre SR10.2 releases of the OS, but surely this only applies to the AT bus machines? or am I wrong there? - anyway - I'm waiting for the relevant patch. As a matter of interest, I had exactly the same situation with NFS V1.0 running on a DSP80A (3Mb, SR9.7.1, COM-ECMB) - I just put it down to crap hardware - seems I was unfairly demeaning the poor little bugger. Has anyone found these problems? - or a cure? - will patching the ethernet8_microcode solve my troubles? - will we all live happily ever after? - help????!!!! Colin Dente | JANET: dente@uk.ac.man.ee.els Dept. of Electrical Engineering | ARPA: dente@els.ee.man.ac.uk University of Manchester | UUCP: ...!mcvax!ukc!man.ee.els!dente England | These might work now, but then again... From apollo-request@umix.cc.umich.edu Tue Oct 24 09:26:48 1989 Date: 23 Oct 89 18:16:40 GMT From: stephen%infmx%pyramid.uucp@hplabs.hp.com (Stephen Campbell) Organization: Informix, Menlo Park, Ca. U.S.A. Subject: Colour on Apollo DN 3000 Message-Id: <2549@infmx.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello terminal experts! Does anyone know if it is possible via escape sequences to set and control colours on an Apollo Domain 3000? (in the same way as underline, blink etc. are set) Thanks in advance, Stephen Campbell. Informix West Germany. email:...!pyramid!infmx!stephen From apollo-request@umix.cc.umich.edu Tue Oct 24 09:33:29 1989 Message-Id: <8910241250.AA03415@umix.cc.umich.edu> Date: Tue, 24 Oct 89 08:37:09 EDT From: Scott Ferguson Subject: DN580-T EX/GO problem To: apollo@umix.cc.umich.edu I tend to fix a lot of node problems by doing the old DM 'EX' and 'GO'. Unfortunately, my DN580-T doesn't like this. When I 'ex' the DM, I get successfully back to the phase 2 shell, and type 'go'. It gets past my favorite copyright paragraph, clears the screen, and then right before coming up with the DM input/output windows, it drops back to the phase 2 shell with an error code. The status code means 'Load address already occupied.' Now I can't get back up without shutting all the way down. Is this a hardware problem? Or is there a patch? Thanks. Scott Ferguson ferguson@erenj.bitnet Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 From apollo-request@umix.cc.umich.edu Tue Oct 24 11:24:50 1989 Date: 24 Oct 89 08:06:44 GMT From: jnp%mjolner%santra%tut%sunic%luth%eru.uucp@bloom-beacon.mit.edu (J|rgen N|rgaard) Organization: Nokia Telecommunications Oy, Espoo, Finland Subject: Re: GNU-Emacs Message-Id: References: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article hanche@imf.unit.no (Harald Hanche-Olsen) writes: > Rey Newman wants to know about GNU Emacs for Apollos. Such adaptations have > been made by Leonard N. Zubkoff . My copy I got from someone > else who got it from I don't know where, but you might ask Zubkoff himself. > Or, you might look in the same place the rest of the Emacs source comes from > (somewhere at MIT, I believe). > > UNIX fans beware: Zubkoff uses Apollo specific calls for many things, > including writing files. The alleged advantage of this is to preserve the > Apollo file type, but you will find that file permissions com out rather > different than expected. [ This seems to be a general problem with much > Apollo software, which I find extremely annoying. (Flame off.) ] > > - Harald Hanche-Olsen > The Norwegian Institute of Technology Actually, if you can live without support for DM-windows and use exclusive, say, X-windows, all you need from Zubkoff is the undump code. Beware this is on the fly so maybe something else. But anyway it is *very* limited what you need. I'm talking about SR10.1/BSD4.3/X11R3. I would like to thank Zubkoff (of Lucid *) for the undump-code, it is very useful when you just want plain UNIX. * = The name escapes me right now. -- -- -- | Regards, J|rgen N|rgaard ('|' is '\o{}' in \LaTeX{}) | | e-mail: jnp@tele.nokia.fi | telephone: <..>-358-0-511-5671 | -- mail: Nokia Telecommunications, PL 33, SF-02601 Espoo, Suomi Finland -- From apollo-request@umix.cc.umich.edu Tue Oct 24 15:37:52 1989 Date: Tue, 24 Oct 89 11:42:57 EDT From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8910241542.AA02474@richter.mit.edu> To: SRFERGU%ERENJ.BITNET@CORNELLC.cit.cornell.edu Subject: Re: ms_$mapl and fseek/fread Cc: apollo@umix.cc.umich.edu The MS calls will create a file with a type-UID of "NIL". The Unix system I/O calls all use the stream I/O system, ie. files with types of UASC, UNSTRUCT, REC, etc. They can't read a NIL file because they don't know how to extract the data from the file (does the file have a header? does it have a record structure? etc.). What you probably want to do is to use either IOS_$CREATE or one of the Unix calls to create an UNSTRUCT file, (which is a stream I/O system file which has neither a header nor a record structure embedded in the file) close the file, and then re-open it with MS_$MAPL or with the Unix mapped-segment calls. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Tue Oct 24 19:34:32 1989 Date: Tue, 24 Oct 89 07:13:34 HST From: kent@humu.nosc.mil (Kent K. Kuriyama) Message-Id: <8910241713.AA12174@humu.nosc.mil> To: ferguson%erenj.BITNET@umix.cc.umich.edu Cc: apollo@umix.cc.umich.edu Subject: Re: DN580-T EX/GO problem >Date: Tue, 24 Oct 89 08:37:09 EDT >From: Scott Ferguson >Subject: DN580-T EX/GO problem >To: apollo@umix.cc.umich.edu > > >I tend to fix a lot of node problems by doing the old DM 'EX' and 'GO'. >Unfortunately, my DN580-T doesn't like this. When I 'ex' the DM, I get >successfully back to the phase 2 shell, and type 'go'. It gets past my >favorite copyright paragraph, clears the screen, and then right before >coming up with the DM input/output windows, it drops back to the phase 2 >shell with an error code. The status code means > > 'Load address already occupied.' > >Now I can't get back up without shutting all the way down. Is this a hardware >problem? Or is there a patch? > We have two DN-580-T's one runs 9.7 the other 10.1. We have not seen that problem occur. Kent Kuriyama Voice (808) 257-1618 Naval Ocean Systems Center FAX (808) 257-5231 Hawaii Laboratory Box 997, Code 531 kent@nosc.mil Kailua, HI 96734 From apollo-request@umix.cc.umich.edu Tue Oct 24 21:29:33 1989 Message-Id: <8910241901.AA14106@umix.cc.umich.edu> Date: Tue, 24 Oct 89 14:51:34 EDT From: Scott Ferguson Subject: GIFF To: APOLLO@UMIX.CC.UMICH.EDU Does anyone have a public domain GIFF reader available for Apollo/GPR and/or X11R3? If so, could you send me the source? Thanks a bunch. Scott Ferguson ferguson@erenj.bitnet Exxon Research & Engineering Annandale, NJ 08801 From apollo-request@umix.cc.umich.edu Tue Oct 24 21:43:00 1989 Message-Id: <8910241926.AA14629@umix.cc.umich.edu> Date: Tue, 24 Oct 89 15:13:00 EDT From: Scott Ferguson Subject: Re: ms_$mapl and fseek/fread To: apollo In-Reply-To: Your message of Tue, 24 Oct 89 11:42:57 EDT Actually, I should have mentioned that I create the file prior to ms_$mapl by using creat, write, and close. Then I append it by using ms_$mapl. Therefore, the file is of type 'uasc' and has the 32-byte header. I guess, though, that the header is different than it should be still. I think I'll skip this whole thing and go back to using stdio functions for portability. Scott From apollo-request@umix.cc.umich.edu Tue Oct 24 21:45:43 1989 Date: 22 Oct 89 21:47:31 GMT From: sharp%ksi.cpsc.ucalgary.ca%calgary%alberta%aunro%atha%philmtl.uucp@uunet.uu.net (Maurice Sharp) Organization: Knowledge Science Lab, U. of Calgary, Calgary, Canada. Subject: X11R3 - When ? Message-Id: <1951@cs-spool.calgary.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hiya, We here are wondering when Apollo is planning to release a version of X11R3. The current DomainX11 stuff is great. But it is not release 3. maurice Maurice Sharp University of Calgary Computer Science Department 2500 University Drive N.W. sharp@ksi.cpsc.UCalgary.CA Calgary, Alberta, T2N 1N4 ...!alberta!calgary!sharp From apollo-request@umix.cc.umich.edu Tue Oct 24 23:31:00 1989 Date: 23 Oct 89 21:24:11 GMT From: weiner%novavax%uflorida%uakari.primate.wisc.edu%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state. (Bob Weiner) Organization: Nova University, Fort Lauderdale, FL Subject: Apollo should use sendmail internally Message-Id: <1547@novavax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) writes: Since the vendor, Apollo, doesn't use sendmail internally, they are not likely to even see the problem. Your only recourse here is to do what we did and thats to make the modifications to /usr/lib/sendmail,/bin/mail,/usr/ucb/mail yourselfs. Mark brings up a good point, which I am fairly sure is true to a large extent (that is some internal Apollo users may use sendmail which will gateway to DPSS mail). As long as Apollo's major e-mail network is based on a proprietary solution, they will not have a solid testbed from which to make mail facilities work for large networks. (Note that there is little information coming from Apollo as to the status of their X.400 mail product, but since they have not released one yet, they are behind a number of other vendors.) I imagine the linkage to HP's large e-mail network will drive Apollo toward more standard e-mail facilities anyway, but I think the point should be made that Apollo needs a decent size network internally on which to stress test all of its products that are network-based. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087 From apollo-request@umix.cc.umich.edu Wed Oct 25 01:35:56 1989 Date: Tue, 24 Oct 89 20:53:37 CDT From: lray@civilgate.ce.uiuc.edu (Ray) Message-Id: <8910250153.AA01992@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: DN580-T EX/GO problem If you loaded your own libraries (via userlib.private and userlib.global), you will see this problem at SR9.5, SR9.6, and SR9.7. I've not seen this at SR10 at all, but I don't have any 580-T's either. -------------------------------------------------------------------- >I tend to fix a lot of node problems by doing the old DM 'EX' and 'GO'. >Unfortunately, my DN580-T doesn't like this. When I 'ex' the DM, I get >successfully back to the phase 2 shell, and type 'go'. It gets past my >favorite copyright paragraph, clears the screen, and then right before >coming up with the DM input/output windows, it drops back to the phase 2 >shell with an error code. The status code means > > 'Load address already occupied.' > >Now I can't get back up without shutting all the way down. Is this a hardware >problem? Or is there a patch? > From apollo-request@umix.cc.umich.edu Wed Oct 25 03:37:01 1989 Date: 25 Oct 89 06:09:53 GMT From: ctl%agate%agate.uucp@ucbvax.Berkeley.EDU (Case Larsen) Organization: none Subject: spm and remote root crp's Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I understand that some time ago, someone identified the problem that causes root crp's to fail. I have only recently begun to read this group and consequently missed the article. If model and OS version is important, we have DN3500s and 4500s running SR10.1. Could the original poster or someone with a copy send me mail? Thanks. (please no RTFM because TFM got stolen three weeks ago.) -- Case Larsen ctl@typhoon.berkeley.edu -- Case Larsen larsen@cory.berkley.edu (internet) (Best) ...!{ames|hplabs|decvax}!ucbvax.berkeley.edu!cory!larsen (UUCP) From apollo-request@umix.cc.umich.edu Wed Oct 25 07:40:00 1989 Date: 24 Oct 89 10:39:29 GMT From: gupta%prlhp1%idec%stl%ukc%mcsun%sunic%luth%eru.uucp@bloom-beacon.mit.edu (gupta) Organization: Philips Research Laboratories, Redhill, UK Subject: Lucid Lisp v3.00 on Apollo's Message-Id: <989@prlhp1.prl.philips.co.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I've just received Lucid Common Lisp version 3.00 for the Apollo. However, it won't run - I get the following message :- 153 % lisp ?(lisp) Dynamic Segments reduced from 64 to 31 since the Paging Volume has only ?(lisp) 10765 blocks available for Lisp (11332 total blocks * 95% Dynamic Limit). ?(lisp) cannot map pure regions from "//node_f135/sys/common_lisp/lisp.image" at 100000 - not enough address space available (process manager/mapped segment manager) ?(lisp) cannot invalidate impure paging file - reference to illegal address (OS/MST manager) I'm running SR9.7 - is that the problem ? Is v3.00 only for SR10 ? It can't be space as I've got some 11 MB free, on my disk - the first message about Dynamic Segments is not crucial. Any help will be appreciated. Thanks Ashok "Ash" Gupta Post : Philips Research Labs, Crossoak Lane, Redhill, Surrey, RH1 5HA, U.K. Voice: +44 293 785544 ext 5647 JANET: gupta@prl.philips.co.uk ARPA: gupta%prl.philips.co.uk@nsfnet-relay.ac.uk -- Ashok "Ash" Gupta Post : Philips Research Labs, Crossoak Lane, Redhill, Surrey, RH1 5HA, U.K. Voice: +44 293 785544 ext 5647 JANET: gupta@prl.philips.co.uk ARPA: gupta%prl.philips.co.uk@nsfnet-relay.ac.uk From apollo-request@umix.cc.umich.edu Wed Oct 25 09:35:25 1989 Message-Id: <8910251246.AA03459@umix.cc.umich.edu> Date: Wed, 25 Oct 89 08:39:21 EDT From: Scott Ferguson Subject: EX/GO Problem To: APOLLO@UMIX.CC.UMICH.EDU I didn't mention that I'm at 9.7 with my 580 problem, and I have an optical disk drive with a /lib/userlib.private library. So, I guess I'll just try to get to sr10 as soon as possible. By the way... if I just waited for 10.2 to come out, would I be able to transition straight from 9.7, or would I still have to put 10.1 on first? Thanks for all the replies. Scott Ferguson ferguson@erenj.bitnet Annandale, NJ From apollo-request@umix.cc.umich.edu Wed Oct 25 11:38:42 1989 Date: 25 Oct 89 13:08:47 GMT From: rudy%neptune%amdcad.uucp@ucbvax.Berkeley.EDU (Rudy Albachten) Organization: Advanced Micro Devices, Inc., Austin, Texas Subject: Re: Mentor Graphics & DN2500 Message-Id: <1113@neptune.AMD.COM> References: <574@stdc01.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <574@stdc01.UUCP> walsh@stdc01.UUCP (Mike Walsh) writes: >Does anyone out there in net-land have any experience in creating/modifying >the popup windows supplied with NetEd. I have successfully added items >to the menus, but I would like to create a popup form. Unfortunately, Mentor does not support user created forms. You can augment their popup menus with menus or items, define your own menus, use their forms in your menus, and associate menus with various windows (you obviously already know how to do this), but you can't define your own forms. Maybe in version 8.0 they'll support this obvious feature. Rudy Albachten Advanced Micro Devices PC Products Division, CAD Engineer/Supervisor rudy@neptune.amd.com From apollo-request@umix.cc.umich.edu Wed Oct 25 17:24:11 1989 Date: 24 Oct 89 02:34:05 GMT From: vince%bcsaic%ssc-vax%fluke.uucp@beaver.cs.washington.edu (Vince Skahan) Organization: Boeing Computer Services - Phila. Subject: Re: Apollo ethernet routing Message-Id: <16153@bcsaic.UUCP> References: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu we have over 15 subnets with various hosts either directly connected or gatewayed in (on Apollos or other unixy token rings) and have no such problem with essentially having to hard-route to find the subnet yyou're connected to. If you run the /etc/routed everywhere, it should plug-and-play (at sr9 or sr10). -- Vince Skahan Boeing Computer Services - Phila. (215) 591-4116 ARPA: vince@atc.boeing.com UUCP: bcsaic!vince Note: the opinions expressed above are mine and have no connection to Boeing... From apollo-request@umix.cc.umich.edu Wed Oct 25 17:37:05 1989 Date: 24 Oct 89 02:47:39 GMT From: vince%bcsaic%ssc-vax%fluke.uucp@beaver.cs.washington.edu (Vince Skahan) Organization: Boeing Computer Services - Phila. Subject: Re: Apollo SR10 Registry Performance Message-Id: <16155@bcsaic.UUCP> References: <114@bnrgate.bnr.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu one registry site per 45 nodes sounds a bit (a lot) short to me. I'm running a rgyd on a dn3000 (8MB) that is the gateway to my ring and I see the effects now and then. I seem to remember the docs saying something like "use as many as you need". I'd guess that something like one rgyd per 25 nodes or so would be a bit more reasonable (though I'd like to hear what rule-of-thumb Apollo has too...especially regarding what system to use and how much memory). Based on what I've seen, the amount of memory and the number of other processes you have makes a big difference (for example, if you run "at" or "cron:, you'll see lots more effect than if you have a rgyd.). -- Vince Skahan Boeing Computer Services - Phila. (215) 591-4116 ARPA: vince@atc.boeing.com UUCP: bcsaic!vince Note: the opinions expressed above are mine and have no connection to Boeing... From apollo-request@umix.cc.umich.edu Wed Oct 25 17:53:14 1989 Date: 24 Oct 89 02:42:30 GMT From: vince%bcsaic%ssc-vax%fluke.uucp@beaver.cs.washington.edu (Vince Skahan) Organization: Boeing Computer Services - Phila. Subject: Re: GETTING RID OF APOLLO Message-Id: <16154@bcsaic.UUCP> References: <30474@pbhya.PacBell.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu It strikes me that getting rid of Apollo because you can't devote the time (and pain...I've been there too) to learn sendmail is a pretty shaky decision. Yes, it's painfil but ti does work once you've bled enough. That doesn't make it right, and there's no excuse in my mind for the brain-dead sendmail.cf's you get by default from Apollo...but once you set it up it DOES work. our > 15 subnets will attest to it. I also agree with the bit about the file-locking in one /usr/spool/mail being a pain in the neck. We get around that by having on /usr/spool/mail PER RING and you hvae to know where somewhere is working to get mail to their ring. There are lots of semi-easy ways to get around it like: - sticking everyone in your .mailrc by alias - using system-wide /usr/lib/aliases that point to the right ring - messing with sendmail.cf to make pseudo-aliases by department, building, etc. It CAN be done but it (and unix - by definition) is never plug-and-play. This is not necessarily Apollos's fault but is more probably the result of being blindly unix-like (even when the unix way is lacking). -- Vince Skahan Boeing Computer Services - Phila. (215) 591-4116 ARPA: vince@atc.boeing.com UUCP: bcsaic!vince Note: the opinions expressed above are mine and have no connection to Boeing... From apollo-request@umix.cc.umich.edu Wed Oct 25 18:07:53 1989 Date: 25 Oct 89 17:42:13 GMT From: kerr%tron%umbc3%haven%aplcen%uakari.primate.wisc.edu%gem.mps.ohio-state.edu.uucp@tut.cis. (Dave Kerr) Organization: Westinghouse Electric Corporation Subject: Need help with 9.7 tcp_server - keeps crashing Message-Id: <449@tron.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, We are having a problem with the tcp_server at 9.7 and was hoping somebody out there might be able to help. We have several domain rings each with a gateway on ethernet. These gateways are running both Domain and Tcp routing. We do not have tcp/ip installed on all nodes in the network, so if we want to use ftp to transfer a file, we first crp onto one of the gateway machines then issue the ftp commands to transfer our files. Our problem is that the the tcp_server periodically crashes leaving a tcp_$panic message in the error log (see below). I received a patch (#157 or 158) but the problem persists. If I do a ps -axNu after the server has crashed there are processes that still show up (although they are hung) that indicate that a ftp connection was made, or in the process of being made by somebody that was crp'd onto the gateway node. One additional particular is that we are using ftp to connect to a VMS vax. This connection is made by first ftp'ing to an Ultrix vax, then using the Ultrix Vax to translate the tcp/ip info decnet. Has anybody seen this type of problem or know what might be going on? Is this problem caused by our crp'ing into the node instead of utilizing normal tcp routing? Does this go away at SR10.1? Thanks in advance for any pointers. Dave Gateway Particulars: DN3000 Node, 4mB Ram, 380mB disk, token ring (dr0) and ethernet (eth0) network interfaces, SR 9.7.0.3. Other info: B$ cd /sys B$ /com/ld -a ethernet8_microcode sys type blocks current type uid used length attr rights name file nil 11 11264 P ---dwrx ethernet8_microcode 1 entry listed, 11 blocks used. B$ cd /sys/node_data B$ tail tcp_error_log Fault Diagnostic Information Fault Status = 00000000: status 0 (OS) User Fault SR = 0000 User Fault PC = 00000000 A6-A7: 00000000 00000000 Supervisor ECB = 00000000 Supervisor SR = 0000 Supervisor PC = 00000000 Thursday, October 19, 1989 10:19:37 am (EDT) tcp_$panic: mbuf_$dtom: data pointer not inside mbuf pool Note: /com/crp from patch 96, although it is possible that other nodes crp'ing onto this node are using the original /com/crp program if that matters. B$ /systest/ssr_util/ts /com/crp /com/crp: Program_Module Name = CRP Time Stamp: 1988/01/14 16:31:11 EDT (Thu) -- Dave Kerr (301) 765-4453 kerr%tron.UUCP@umbc3.UMBC.EDU from an Internet site kerr@tron.UUCP from a smart uucp mailer From apollo-request@umix.cc.umich.edu Wed Oct 25 19:23:38 1989 Date: 25 Oct 89 14:11:00 GMT From: pato%apollo.hp.com%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Joe Pato) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: Apollo SR10 Registry Performance Message-Id: <46707186.20b6d@apollo.HP.COM> References: <127@bnrgate.bnr.ca>, <46574bed8.000f088@caen.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <127@bnrgate.bnr.ca>, marmen@is2.bnr.ca (Rob Marmen 1532773) writes: > Thanks for the reply. There are a couple of more pieces of information > that are relevant. > > 1) We are running BETA sr10.2 regitries. This was needed to fix > a problem with a server responding 20 times to each registry > request. The new registries fix that problem. This was quite > serious because we are 100% ethernet and the network load was > phenominal. Also, HPApollo are working on an ethernet microcode > fix to cure a problem with short interpacket spacing. The multiple replies to a request bug existed in an ALPHA version of the sr10.2 registry server. You were running this to circumvent other problems in your network. > > 2) Our site is 100% BSD unix. This puts an additional load on the > servers because the /etc files are now streams to the server. > It's amazing how many programs look at these files constantly. > The applications have not been modified to take in to account > that there are now network accesses instead of disk accesses. > Most Apollo supplied application programs do not scan the /etc/passwd file, they use the standard UNIX passwd file data accessor functions getpwnam() and getpwuid(). These operations are implemented as remote calls to the registry server and avoid having to transmit the entire passwd file. Third party applications should also be modified to use these functions rather than directly reading the file. If you have several applications that are scanning the password file frequently, you might want to create local copies of the passwd file. (To do so, you would move the /etc/passwd object to /etc/passwd.real and copy the /etc/passwd.real file to /etc/passwd periodically from cron). At sr10.2 we have modified the /etc/passwd object to cache the passwd file locally. When the object is opened, the type manager determines if the cached copy is current by contacting the registry server, and if not it will cache a new copy. This has two benefits over sr10 and sr10.1 - 1) the data in the passwd file is now current instead of potentially being 2 hours out of date and 2) the data is often retrieved from the local disk rather than across the network. The latter is especially true if there are infrequent updates to the passwd file - relative to the number of times the file is scanned. > Under sr9.7, we had a ratio of 1 registry for 35 nodes. In addition, the > workstations were modified so that the /etc directory was resident on each > nodes. Otherwise the performance was unacceptable. > > At this point, we are going to experiment with a ratio of 1 server for 20 > workstations. It's just a guess, but we reason that since the unix programs > are going to constantly look at the /etc files, then the number of servers > should actually be greater than a sr9 site. > > Any comments? cheers, rob... > > PS. Again, thanks for the reply. > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > | Robert Marmen marmen@bnr.ca OR | > | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | > | (613) 763-8244 My opinions are my own, not BNRs | I firmly believe that 1 registry server for 20 workstations is tremendous overkill. In the Apollo corporate internetwork we run 1 server for every 100 workstations. (And we only run so many servers because our internetwork stretches over 2 states and we want to have a server in every "important" network for reliability. We could get by on many fewer servers.) Statistics gathered over an average 2 business day period indicate that our corporate internetwork is handling about 25 registry operations per second. Peak access to the registry servers is between 35-40 operations per second. Stress tests on servers indicate that a server running on an unloaded 8 Mbyte DN2500 should be able to handle about 64 operations per second before clients perceive any real degradation in service. (This would indicate that a single dn2500 should be able to service our entire 3500+ node internetwork. Again, we would not want to do this for reliability reasons and due to the additional traffic from remote networks.) Paul Anderson's observations about the U. Mich. environment seem to be appropriate here. He observes that 1 server for every 150 machines seems adequate, but that you really need 4 servers for the first 150 machines for the load balancing strategy to work well. Joe Pato Apollo Computer A Subsidiary of Hewlett-Packard NSFNET: pato@apollo.com UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato From apollo-request@umix.cc.umich.edu Wed Oct 25 19:27:12 1989 Date: 25 Oct 89 20:29:00 GMT From: dawson%apollo.uucp@beaver.cs.washington.edu (Keith Dawson) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: X11R3 - When ? Message-Id: <4671c36f.20b6d@apollo.HP.COM> References: <1951@cs-spool.calgary.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Maurice Sharp writes: > We here are wondering when Apollo is planning to release a version > of X11R3. The current DomainX11 stuff is great. But it is not release 3. At SR10.2, Domain/X11 (the "share-mode" server) v1.2 will be bundled with base software. This is an R3 server in all the ways that matter. All supplied clients are the R3 versions, as are all the libraries (libXt, libX11, libXaw, ...). R3 font conventions are supported, as indeed they are in v1.1(.p), the SR10.1(.p) layered product. R2 clients continue to work with this server, with only the caveat that oldx11 must be added to the default font path. The only R3 features that are not available are backing store / save unders -- but these are optional features according to the protocol. ____________________________________________________________ My opinions Keith Dawson Hewlett Packard Co. 508-256-0176 x5739 are my own. Graphics Technology Division / East 300 Apollo Dr. (CHR.03.DE) Chelmsford, MA 01824 USA My convictions Internet: dawson@apollo.hp.com are not for UUCP: {mit-eddie,yale,uw-beaver}!apollo!dawson public display. From apollo-request@umix.cc.umich.edu Wed Oct 25 21:21:23 1989 Date: 25 Oct 89 17:31:00 GMT From: mishkin%apollo.hp.com%apollo.uucp@beaver.cs.washington.edu (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: ms_$mapl and fseek/fread Message-Id: <46712455.20b6d@apollo.HP.COM> References: <8910241926.AA14629@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8910241926.AA14629@umix.cc.umich.edu>, SRFERGU@ERENJ.BITNET (Scott Ferguson) writes: > > Actually, I should have mentioned that I create the file prior to > ms_$mapl by using creat, write, and close. Then I append it by > using ms_$mapl. Therefore, the file is of type 'uasc' and has the > 32-byte header. I guess, though, that the header is different than > it should be still. I think I'll skip this whole thing and go back to > using stdio functions for portability. First, let me make one thing clear: At sr10.0 and later, files of type "nil", or any other "managerless type" (i.e. a type listed by "lty", but with no type manager in "/sys/mgrs" or built in to "/lib/streams") is treated as having the type "unstruct" and can thus be read using stream I/O operations (stdio, read/write, ios_$, etc.). The "unstruct" type is basically just an uninterpreted bag of bytes -- no "header" in the front or other "meta-data" is presumed. At sr9.7 and later, the type "unstruct" is supported. This is the type of file you should create if you want to then access the file via mapping operations. (Note also that at sr10 and later, you can use the bsd mmap calls instead of the ms_$ calls.) In general, unless you really know what you're doing, you don't want to access via mapping other types of files. Note also that if you create a file via the ms_$ calls, its type will be "nil" and at sr10 and later, it can be accessed using stream I/O calls. -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com From apollo-request@umix.cc.umich.edu Thu Oct 26 03:20:55 1989 Date: 25 Oct 89 18:40:18 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%gem.mps.ohio-state.edu.uucp@ (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: Intermittent DN4500 Problem Message-Id: <21450@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Do you have a power line filter; e.g., surge supressor, uninterruptible power supply (UPS), etc.? Some machines do a better job of filtering electrical noise better than others. Also, have you tried reseating the PALs in the mother board? Finally, have you run /systest/ssr_util/lsyserr to dump the system error message file? Michael Lampi MDL Corporation (213) 782-7888 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com From apollo-request@umix.cc.umich.edu Thu Oct 26 03:21:37 1989 Date: 25 Oct 89 19:00:12 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%gem.mps.ohio-state.edu.uucp@ (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: ms_$mapl and fseek/fread Message-Id: <21451@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The problem with trying to read a file created via ms_$mapl calls using fseek and fread calls is that the file type is 'nil', and the streams manager/IOS doesn't know quite what to do with the fseek or fread call. I suggest that you either create the file with stdio calls or re-implement fseek/fread so they can read both nil and 'normal' filetypes. (This is not as hard as it seems on Apollo systems, since you can layer calls atop the system libraries and call a user-written routine that decides whether or not to call the system routine. See the -INLIB option switch of the binder for further info, or give me a call.) Michael Lampi MDL Corporation (213) 782-7888 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com From apollo-request@umix.cc.umich.edu Thu Oct 26 03:23:53 1989 Date: 25 Oct 89 18:40:13 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%gem.mps.ohio-state.edu.uucp@ (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: Disk Drives Message-Id: <21449@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From my experience at Danford Corporation, where they sell add-on disk drives for the DN-xx00 and DN-10000, it is far better to purchase the interface boards from Apollo that try to do it from their sources, especially in the case of the OMTI controllers that SMS made for Apollo. We had heard of failure rates as high as 50% for those controllers as shipped from SMS (this is 2nd hand, so take it with whatever cautions are desired); hence, it is better to have Apollo perform the necessary acceptance testing. As far as the disk drives go, yes, the drives are standard Maxtor 760 mb drives, and the smaller ones are either Maxtor or Micropolis (take your pick) 380 mb drives. By the way, I am no longer at Danford (was their Director of Engineering). I'm in the midst of starting a new company, and am thinking of offering disk drives and magneto-optical drives for the DN-2500 at low-low prices. Michael Lampi President MDL Corporation Torrance, CA FAX (213) 782-7927 TEL (213) 782-7888 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com From apollo-request@umix.cc.umich.edu Thu Oct 26 09:17:56 1989 Message-Id: <8910261243.AA02992@umix.cc.umich.edu> Date: Thu, 26 Oct 89 08:31:48 EDT From: Scott Ferguson Subject: ms_$mapl and stream I/O To: APOLLO@UMIX.CC.UMICH.EDU Thanks for the numerous replies about my ms_$mapl question. Here's a quick summary: 1) ms_$mapl creates 'nil' type files at 9.7, therefore I always create the file first with stdio calls. Therefore it's a 'uasc' file. 2) If I would just go to sr10, this would all get better. I've got one node at 10.1, and it's only a matter of time. 3) ms_$mapl gives me the single-level-store functionality, but it's just not compatible with anything else, so I'm just going to bag it and go back to what I was doing before my branch-office SSE pointed it out to me. Anyway, thanks for the replies, and I'll just drop the whole issue. Scott Ferguson ferguson@erenj.bitnet Exxon Research & Engineering Annandale, NJ 08801 From apollo-request@umix.cc.umich.edu Thu Oct 26 13:25:17 1989 Date: Thu, 26 Oct 89 11:45:57 EDT From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8910261545.AA05049@richter.mit.edu> To: apollo@umix.cc.umich.edu, sharp%ksi.cpsc.ucalgary.ca%calgary%alberta%aunro%atha%philmtl.uucp@uunet.uu.net Subject: Re: X11R3 - When ? X11 is part of the OS release for SR10.2, which I am currently beta testing. Call your sales office for the release date. It shouldn't be too much longer. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Thu Oct 26 17:20:41 1989 Date: 26 Oct 89 15:15:08 GMT From: collins%nvpna1%prles2%prle%phigate%hp4nl%mcsun%sunic%luth%eru.uucp@bloom-beacon.mit.edu (Donal O Coileain) Organization: Philips Research Labs (Nat Lab), Eindhoven, The Netherlands. Subject: Scanners on Apollo ? Message-Id: <753@prles2.UUCP> References: <8910110257.AA07489@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone know of any scanners which can be hooked up to Apollo for scanning graphic images and also OCR/ICR( character recognition ? ) I simply want files to be created using some simple interface ( nothing fancy ). Basically, I'm looking for the simplest scanner possible. Only to scan images in, with a tool to be able to display them if they get saved in some compressed format ( e.g FAX format ). Perhaps if there's an image editor as well, so you could put text on your scanned images, that would be useful. The OCR is to enable you to scan documents and get ascii text out. Obviously that would save on file size vs. it's equivalent image file. The tool would produce a simple file e.g scan.bitmap, scan.compressed, scan.ascii, etc. Thanks, G.Pritchett Philips Components Central Systems Support Group From apollo-request@umix.cc.umich.edu Thu Oct 26 17:27:01 1989 Date: 26 Oct 89 09:05:17 GMT From: mart%euteal%eutrc3%hp4nl%mcsun%sunic%luth%eru.uucp@bloom-beacon.mit.edu (Mart van Stiphout) Organization: Eindhoven University of Technology, The Netherlands Subject: Re: X11R3 - When ? Message-Id: <372@euteal.ele.tue.nl> References: <1951@cs-spool.calgary.UUCP>, <4671c36f.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Maurice Sharp writes: > We here are wondering when Apollo is planning to release a version > of X11R3. The current DomainX11 stuff is great. But it is not release 3. I'm using Domain X on a DN3000 under SR9.7 (because some of our commercial software does not yet run under 10. I'm running with the dm in a dominant role and just the X server in the background to be able to run X applications but without having to use the more than terrible uwm window manager (I'm very happy with dm). Very often there seems to be some kind of deadlock. This occurs if I click the mouse button to close to the edge of an X window. I also have trouble killing X. About 1 out of 3 times I logout I have to blast some process away. If I don't shut after blasting I'm bound to experience some strange behavior the next day, such as shells hanging. Has anyone experienced problems of the same nature? -- Mart van Stiphout mart@ele.tue.nl (It's not the fall that kills you, it's the sudden stop) From apollo-request@umix.cc.umich.edu Thu Oct 26 21:21:55 1989 Date: 26 Oct 89 22:51:00 GMT From: pato%apollo.hp.com%apollo.uucp@eddie.mit.edu (Joe Pato) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: Apollo SR10 Registry Performance Message-Id: <46774a1b.20b6d@apollo.HP.COM> References: <16155@bcsaic.UUCP>, <114@bnrgate.bnr.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <16155@bcsaic.UUCP>, vince@bcsaic.UUCP (Vince Skahan) writes: > one registry site per 45 nodes sounds a bit (a lot) short to me. I'm > running a rgyd on a dn3000 (8MB) that is the gateway to my ring and I > see the effects now and then. > > I seem to remember the docs saying something like "use as many as you > need". I'd guess that something like one rgyd per 25 nodes or so would > be a bit more reasonable (though I'd like to hear what rule-of-thumb > Apollo has too...especially regarding what system to use and how much > memory). > > Based on what I've seen, the amount of memory and the number of other > processes you have makes a big difference (for example, if you run "at" > or "cron:, you'll see lots more effect than if you have a rgyd.). > -- > Vince Skahan Boeing Computer Services - Phila. > (215) 591-4116 ARPA: vince@atc.boeing.com > UUCP: bcsaic!vince > Note: the opinions expressed above are mine and have no connection to Boeing... As I've state before, we expect that you can run about 100 machines per registry server. We do, however, expect that those registry servers are running on server nodes - not nodes in personal use. A slow machine (e.g., dn3000) with a reasonable amount of memory (>= 8 Mbytes) should do just fine. Joe Pato Apollo Computer A Subsidiary of Hewlett-Packard NSFNET: pato@apollo.com UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato From apollo-request@umix.cc.umich.edu Thu Oct 26 21:27:31 1989 Date: 26 Oct 89 20:17:00 GMT From: mishkin%apollo.hp.com%apollo.uucp@eddie.mit.edu (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: Apollo should use sendmail internally Message-Id: <4676c05b.20b6d@apollo.HP.COM> References: <1547@novavax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1547@novavax.UUCP>, weiner@novavax.UUCP (Bob Weiner) writes: > Since the vendor, Apollo, doesn't use sendmail internally, they are not > likely to even see the problem. Your only recourse here is to do what > we did and thats to make the modifications to > /usr/lib/sendmail,/bin/mail,/usr/ucb/mail yourselfs. > > Mark brings up a good point, which I am fairly sure is true to a large > extent (that is some internal Apollo users may use sendmail which will > gateway to DPSS mail). > > As long as Apollo's major e-mail network is based on a proprietary > solution, they will not have a solid testbed from which to make mail > facilities work for large networks. Let me make it clear that sendmail is getting quite heavy use internally at Apollo. In the past this was not true, but has become increasingly true over the last 6-12 months. I can't give you hard numbers, but rest assured that a number of us DEPEND on sendmail and friends to send mail. Now just so you don't think I'm misrepresenting the situation, understand that we ARE running some non-standard (unshipped software) to support "local delivery". From the sendmail user's point of view this means that sendmail invokes something other than /bin/mail to do local delivery. The reason is that there's a fundamental problem with the "standard" Unix mail model. Basically, I don't want to have to address mail I send to internal users directly to the machine that user gets mail on. I want to mail to "smith" not "smith@smiths-machine" or the like. Various people have gotten around this problem in various ways: (1) distribute aliases files to all machines (or use links and a distributed file system to link to one or more "central" copies), (2) arrange that all mail gets sent to a "smart" host which has an aliases file or the like and disposes of the mail properly, (3) pretend that your network is really one big timesharing system and use /bin/mail and trust that it will be able to write to a central /usr/spool/mail directory on some fileserver. I'm sure there are others. I don't think there is one "standard" way of dealing with this. We essentially do something like option (2). -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com From apollo-request@umix.cc.umich.edu Thu Oct 26 23:22:17 1989 Date: 26 Oct 89 09:31:36 GMT From: sm%stc%ukc%mcsun.uucp@uunet.uu.net (Simon Marchant) Organization: STC Telecomms, Harlow Technical Centre, Harlow Subject: Re: Mentor Graphics & DN2500 Message-Id: <1292@jura.tcom.stc.co.uk> References: <574@stdc01.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu A long time ago I was a 'Mentor Graphics' System Administrator and had cause to add menus to Neted. To do this it was necessary to write in a special menu description language a file and compile it with the Mentor Graphics "MISL" Compiler. The genorated code was then included or read by the NETED startup files in /idea/sys .... MISL is documented as part of NETED, but if I remember correctly there only a few pages of information. As I say it was a long time ago, but I hope this might be of some help. Simon Marchant, STC Telecom Harlow, Essex. From apollo-request@umix.cc.umich.edu Thu Oct 26 23:25:28 1989 Date: 26 Oct 89 14:33:46 GMT From: andrewn%syma%icdoc%ukc%mcsun.uucp@uunet.uu.net (Andrew D Nimmo) Organization: University of Sussex Subject: void function pointer..... Message-Id: <1464@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu When compiling the following code segment using CC V6.5_p and CC V6.6_m the the listed error appeared. When compiling on a Sequent Symmetry no such errors occur. I don't have the C reference manual to refer to, so would like to know the reason for the errors. Thanks, Andrew D. Nimmo ---- static void traverse (tree, fn, pre) /* traverses the tree, calling fn on each and every node */ fpexpr tree; void ((* fn)()); int pre; { fpexpr save = tree; if (pre) (* fn) (tree); switch (tree->exprtype) { case COND: 250 traverse (tree->fpexprv.conditional [0], (* fn), pre); traverse (tree->fpexprv.conditional [1], (* fn), pre); traverse (tree->fpexprv.conditional [2], (* fn), pre); break; case BU: case BUR: traverse (tree->fpexprv.bulr.bufun, (* fn), pre); traverse (tree->fpexprv.bulr.buobj, (* fn), pre); break; case WHILE: traverse (tree->fpexprv.whilestat [0], (* fn), pre); traverse (tree->fpexprv.whilestat [1], (* fn), pre); break; case COMP: (0250) traverse (tree->fpexprv.conditional [0], (* fn), pre); ******** Line 250 of "code.c": [Error #207] Illegal type "void" for argument 2. (0251) traverse (tree->fpexprv.conditional [1], (* fn), pre); ******** Line 251 of "code.c": [Error #207] Illegal type "void" for argument 2. (0252) traverse (tree->fpexprv.conditional [2], (* fn), pre); ******** Line 252 of "code.c": [Error #207] Illegal type "void" for argument 2. (0256) traverse (tree->fpexprv.bulr.bufun, (* fn), pre); ******** Line 256 of "code.c": [Error #207] Illegal type "void" for argument 2. (0257) traverse (tree->fpexprv.bulr.buobj, (* fn), pre); ******** Line 257 of "code.c": [Error #207] Illegal type "void" for argument 2. (0260) traverse (tree->fpexprv.whilestat [0], (* fn), pre); ******** Line 260 of "code.c": [Error #207] Illegal type "void" for argument 2. (0261) traverse (tree->fpexprv.whilestat [1], (* fn), pre); ******** Line 261 of "code.c": [Error #207] Illegal type "void" for argument 2. (0267) traverse (tree->fpexprv.compconstr.compexpr, (* fn), pre); ******** Line 267 of "code.c": [Error #207] Illegal type "void" for argument 2. (0276) traverse (tree->fpexprv.aains, (* fn), pre); ******** Line 276 of "code.c": [Error #207] Illegal type "void" for argument 2. (0281) traverse (tree->fpexprv.listobj.listel, (* fn), pre); -- Andrew D. Nimmo, VLSI and Graphics Research Group, EAPS II, University of Sussex, Falmer, BRIGHTON, East Sussex, BN1 9Qt TEL: +44 273 606755 x 2617 EMAIL: (JANET) andrewn@syma.sussex.ac.uk | (UUCP) ...mcsun!ukc!syma!andrewn From apollo-request@umix.cc.umich.edu Fri Oct 27 09:31:03 1989 Date: 27 Oct 89 12:18:35 GMT From: asherman%cpe%ulowell.uucp@harvard.harvard.edu Organization: Center for Productivity Enhancement Subject: GNU Emacs binaries Message-Id: <15447@bloom-beacon.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello, out there. I just recently discovered the Apollo binaries for emacs on prep.ai.mit.edu (pub/gnu/emacs*). Only one problem. They have 9.7 binaries for 68k machines and 10.1 binaries for the PRISM. No 10.1 68k's. The 9.7 and PRISM work quite nicely, but when I compile the 18.5n release I get all manners of nasties (it just outright core-dumps in an apollo window, and under X it's slower than I thought even EMACS could be). Now, what I need to know is: are there 10.1 binaries for the 68k's? If so where? Please reply via e-mail, as I don't get to read news very often. If you are also interested drop me a line and I'll send you the results. BTW an alternative is to find out how to compile this correctly, but I have a suspicion that this requires code that I don't have. -AJS From apollo-request@umix.cc.umich.edu Fri Oct 27 11:21:52 1989 Date: Fri, 27 Oct 89 09:03:01 EDT From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8910271303.AA06469@richter.mit.edu> To: collins%nvpna1%prles2%prle%phigate%hp4nl%mcsun%sunic%luth%eru.uucp@bloom-beacon.mit.edu Subject: Re: Scanners on Apollo ? Cc: apollo@umix.cc.umich.edu Mitsubishi International is selling a color page scanner which produces GPR bitmap files, which can then be processed later using your own application package. It's the only scanner I know of so far. DISCLAIMER: I wrote the simple scanner software that scans an image into a GPR bitmap file for Mitsubishi International. They paid me real money to do this, therefore I have a vested interest in this thing. However, I really have not seen any other scanners offerred for the Apollo systems. == Dave From apollo-request@umix.cc.umich.edu Fri Oct 27 11:26:16 1989 Return-Path: Message-Id: <8910271318.AA06054@okc-unix.af.mil> Date: Fri Oct 27 08:17:03 1989 From: rkw@okc-unix.af.mil (Ron Wallman MMECTA) Subject: Re: Scanners on Apollo ? To: apollo@umix.cc.umich.edu Status: N Context has a document scanning system. It is intented to be used with their documentation package, but may be of interest. Datacopy 830 line art scanner and Scaned Image Editor & scanner control software is around $6K depending on your company discounts. Calera CDP9000 batch OCR and document recognition software is around $36K depending on your company discounts. This is a new product, therefore it has it's growing pains. A sales point of contact is Rocco Papalio, Mentor Graphics, 214-233-9897. I have the complete system on my Apollo network. These scanners have been installed on DN3010s. Ronald K Wallman Oklahoma City Air Logistics Center OC-ALC/MMECTR Bldg 3220 Tinker AFB, OK 73145-5990 (405)-736-7184 DDN Mail Address: rkw@okc-unix.arpa From apollo-request@umix.cc.umich.edu Fri Oct 27 13:38:39 1989 Date: 27 Oct 89 12:38:14 GMT From: asherman%cpe%ulowell.uucp@harvard.harvard.edu Organization: ULowell Center for Productivity Enhancement Subject: Calls to mbx_$get_conditional are dying. Message-Id: <15448@bloom-beacon.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is there anyone out there who uses mailboxes under 10.1 in C? The problem that I'm having is that mbx_$get_conditional is exiting and not telling me what's wrong. This makes me a bit unhappy, needless to say. This is the code: long read_port_id[2]; char gbl_buf[1024]; status_$t stat; int retlen; char tmp_buf[1024]; #ifdef DEBUG printf("Calling mbx_$get_conditional.\n"); #endif mbx_$get_conditional(&read_port_id[port],tmp_buf,1024L,gbl_buf,&retlen,&stat); #ifdef DEBUG printf("Got out alive.\n"); #endif The output I get is: % test_io Calling mbx_$get_conditional. % This is confusing me badly. I want to call Apollo, but before I do, I want to know that this is not just a simple mistake on my part. thanks. -AJS(Harmil) From apollo-request@umix.cc.umich.edu Fri Oct 27 15:29:59 1989 Date: Fri, 27 Oct 89 14:05:30 EDT From: krowitz@richter.cc.umich.edu (David Krowitz) Message-Id: <8910271805.AA07344@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: Unix admin question (simple) Ok, I admit that I don't know anything about Unix ... On our Alliant, there is a directory named /usr/skel which contains example .login, .cshrc, .logout, etc files for setting up new user accounts with a default set of login/logout files. Is there a similar directory for SR10 that has good examples for the Apollo Unix environment? If not, is anyone willing the share their system's new-user's default files? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Oct 27 15:52:43 1989 Date: Fri, 27 Oct 89 14:05:30 EDT From: krowitz@richter.cc.umich.edu (David Krowitz) Message-Id: <8910271805.AA07344@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: Unix admin question (simple) Ok, I admit that I don't know anything about Unix ... On our Alliant, there is a directory named /usr/skel which contains example .login, .cshrc, .logout, etc files for setting up new user accounts with a default set of login/logout files. Is there a similar directory for SR10 that has good examples for the Apollo Unix environment? If not, is anyone willing the share their system's new-user's default files? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Oct 27 16:03:58 1989 Date: Fri 27 Oct 89 11:23:41-PST From: Steve Albrecht Subject: Re: GNU Emacs binaries To: asherman%cpe%ulowell.uucp@harvard.harvard.edu Cc: apollo@umix.cc.umich.edu, albrecht@caliph.cc.umich.edu Message-Id: <625515821.870000.ALBRECHT@CALIPH> In-Reply-To: <15447@bloom-beacon.MIT.EDU> Mail-System-Version: I now have 18.54 running ok on my DN4500 under Domain/OS 10.1. After ftp-ing apollo-emacs-10.1.tar.Z from labrea.stanford.edu, I unpacked it as follows: zcat emacs | tar -xvf - I confirmed that its type was coff by the following: ls -alT The file type was converted by: /etc/obty emacs cmpexe The result was an executable emacs file of type cmpexe. Note that this archive LACKS the lisp extensions. I assume that they are available on labrea.stanford.edu <36.8.0.47>. If not, the lisp extentions *might* be unchanged in the 18.55 sources (not yet ported to Apollo) that are also on labrea. I assume that the apollo-specific changes for 18.54 are on labrea.stanford.edu in pub/gnu/apollo-emacs.tar.Z This would allow you to take the standard 18.54 sources and apollo-ize. Instead, I suggest that you get the complete apollo gnuemacs 18.54 sources from tut.cis.ohio-state.edu <128.146.8.60>. They are located in /pub/gnu/emacs/apollo I understand that Leonard Zubkoff is just about finished porting 18.55 to Apollo Domain/OS 10.1 and 10.2. I believe his address is zubkoff@lucid.com. (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ) Steve Albrecht - IntelliCorp, Inc. - Knowledge Systems Product Development ( ( "Opinions expressed here are my own, if anyone's, and not my employer's." ) ) DDS albrecht@intellicorp.com : COMPUSERVE 73657,1342 ( ( UUCP ...!sun!intellicorp.com!albrecht : public bbs (415)969-5643 ) ) or ...!sun!icmv!albrecht : "c"omment to sysop ( (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ------- From apollo-request@umix.cc.umich.edu Fri Oct 27 16:19:42 1989 Message-Id: <8910271755.AA19267@xuucp.ch.apollo.com> From: schickel_m@apollo.com Date: Fri, 27 Oct 89 13:19:27 EDT Subject: HP Unveils Plan for New PRISM CPU, System Enhancements for Apollo Series 10000 To: apollo@umix.cc.umich.edu FOR IMMEDIATE RELEASE HP UNVEILS PLANS FOR NEW PRISM CPU, SYSTEM ENHANCEMENTS FOR APOLLO SERIES 10000 PALO ALTO, Calif., October 25, 1989 - Hewlett-Packard Company, through its Apollo Systems Division, today unveiled a full program to increase the overall system performance of its Series 10000 personal supercomputer, including a new fully compatible RISC CPU that will double the system's processing power. Over the next year, every major component of the minisupercomputer-class, multiprocessing Series 10000 will receive a substantial upgrade: ~ a new PRISM CPU will double compute power, from 22 MIPS to 44 MIPS (12 MFLOPS) per processor; ~ parallelizing and vectorizing compilers will increase system performance by two to four times; ~ HP will make available a specialized software development environment for parallel programs and an interactive scientific software computation and visualization environment; ~ main memory capacity will be expanded by a factor of four; ~ disk capacity will be improved by a factor of six, and, ~ local-area-networking bandwidth will increase by a factor of 10. "The unveiling of this important program for the Apollo Series 10000 demonstrates HP's commitment to this advanced workstation, and, most importantly, to the current Series 10000 customers and third-party solutions suppliers who will be able to upgrade their systems while maintaining full compatibility," said David M. Perozek, general manager of HP's Apollo Systems Division. New PRISM CPU The new Series 10000 RISC CPU will maintain the existing PRISM instruction set so customers can run all Apollo Series 10000 applications without modification. In addition to a doubling of the integer, or Dhrystone, performance, the new CPU will provide increased floating point performance of up to 60 times that of a VAX 11/780, according to the company. Also, as a result of the new CPU, the system's data cache and instruction cache will increase in size from 64 Kbytes and 128 Kbytes, respectively, to 512 Kbytes each for significantly higher cache hit rates. The new PRISM CPU will be sourced from HP's Colorado Integrated Circuit Division and is scheduled for volume shipments in 1991. Application-specific-integrated-circuits (ASICs), including the bus interface and floating-point register file, will be implemented in one-micron gate arrays. Parallelizing, Vectorizing Compilers By offering fine-grain FORTRAN parallelizing and vectorizing compilers on the Series 10000, users can assign the system's multiple CPUs to a single compute-intensive task to speed up a solution by as much as four times. With the new compilers, programs can be automatically spread out across multiple CPUs for situations requiring faster time-to-completion. Parallel Programming, Scientific Computing Environments HP is reinforcing its commitment to distributed computing and multiprocessing by offering on the Series 10000, through SCIENTIFIC Computing Associates Inc., a portable, parallel programming environment called Lindar. Programs based on C-Linda, the version of Linda based in the C programming environment, provide a significant performance boost on numerical problems, database applications, graphics applications, and expert systems. C-Linda adds only six new operations to C. Using C-Linda, parallel programs are easy to write and understand. Linda programs can be moved without modification from one machine architecture to another, or to a workgroup on a local-area-network (LAN). Based on research at Yale University and developed by SCIENTIFIC, C-Linda also has a graphic visualization tool based on the industry-standard X Window Systemt, which can be used for debugging as well as for performance evaluation. Through SCIENTIFIC Computing Associates, Apollo also intends to make available to Series 10000 customers a software product called CLAMr - an interactive programming language and development environment designed to reduce the effort and time needed to perform computations. CLAM will also allow Series 10000 users to graphically display results for scientific and engineering problems. Memory Expansion Program As a result of the Series 10000's new memory expansion program, customers will be able to increase the system's main memory by up to four times over what is currently available - 512 Mbytes up from 128 Mbytes - using the emerging four-Mbit DRAMs (dynamic random access memory). Because the Series 10000's main memory is four-way interleaved, the system handles full-bus bandwidth in all memory configurations, eliminating the bottlenecks typical to traditional memory architectures. Series 10000 customers can immediately upgrade to 192 Mbytes of main memory. Disk Expansion Program A new disk subsytem program will allow Series 10000 customers to configure their systems with up to 18 Gbytes of high-performance mass storage, six times the amount of mass storage currently available. The higher capacity disk drives will support the largest, most complex applications. The drives will interface to the Series 10000 via the system's SCSI (small-computer-system-interface) protocol. FDDI Network HP is among the first workstation suppliers to announce a Fiber Distributed Data Interface (FDDI) network-controller board based on the American National Standards Institute's (ANSI) standard. FDDI, a high-speed data network, has the capability to support up to 200 Mbits per second - more than 10 times the speed of current commercial-networking products. The new controller board will be available initially on the Apollo Series 10000, the processing power of which will allow users to take full advantage of the FDDI LAN high-bandwidth. The upgrade to 192 Mbytes of main memory is available immediately. Linda and CLAM will be available from SCIENTIFIC Computer Associates Inc. later this year. The FDDI network controller board, 512-Mbyte memory expansion unit and parallelizing and vectorizing compilers are scheduled for delivery in mid-1990. The new, field upgradeable RISC CPU board and 18-Gbyte-disk subsystem are scheduled for volume shipments in 1991. The Series 10000 family includes the personal supercomputer and visualization system, designed for graphics-intensive applications. Both systems incorporate several workstation innovations, including multiprocessing capabilities, parallel instruction dispatch and execution, advanced compiler technology, a powerful RISC-based instruction set, and the capability to be configured with the IBM Token Ring network or Ethernet as native networks. Apollo, a division of Hewlett-Packard Company, is a leading manufacturer of network-based workstations and open computing products incorporating industry standards and technology innovations. Apollo offers a broad family of compatible workstations, ranging from desktop systems to the technologically-advanced Series 10000 personal supercomputer. Apollo provides users with the DomainOS operating system, which is based on and fully complies with AT&T's UNIXr system. Hewlett-Packard Company is an international manufacturer of measurements and computation products and systems recognized for excellence in quality and support. The company's products and services are used in industry, business, engineering, science, medicine and education in approximately 100 countries. Founded in 1939, the company is celebrating its 50th anniversary this year. It has 95,000 employees and had revenue of $9.8 billion in its 1988 fiscal year. # # # UNIX is a registered trademark of AT&T in the U.S.A. and other countries. X Window System is a product of the Massachusetts Institute of Technology. Linda and CLAM are registered trademarks of SCIENTIFIC Computing Associates, Inc. From apollo-request@umix.cc.umich.edu Fri Oct 27 19:52:22 1989 Date: 27 Oct 89 15:52:39 GMT From: lori%hacgate%usc.uucp@apple.com (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: Scanners on Apollo ? Message-Id: <5850@hacgate.UUCP> References: <8910110257.AA07489@umix.cc.umich.edu>, <753@prles2.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <753@prles2.UUCP> page@nvpna1.UUCP (Greg Pritchett) writes: >Does anyone know of any scanners which can be hooked up to Apollo >for scanning graphic images and also OCR/ICR( character recognition ? ) >I simply want files to be created using some simple interface ( nothing >fancy ). We bought a Datacopy scanner for our DN4500. The interface routine is nice-- all mouse-driven, and I just found out that our InterCAP (CAD system) software also includes some kind of a driver interface. We have only done limited testing with the imaging portion; we didn't need any character recognition, so I doubt we bought any such software. This was not a cheap scanner, and I know you are looking for a minimal setup, but maybe talking to these people will help inform you. They may also have other products which are at the lower end. Datacopy: 415-965-7900 I submit, however, that peripherals like scanners would probably be much cheaper if purchased for a PC of some sort. Character recognition software is reportedly in the public domain now. (I also have a friend who bought a scanner for his IBM PC clone for $300, complete with driver and recognition stuff.) It might be more cost effective to buy an old PC along with the scanner, and then just upload with a modem through an SIO line. If you investigate this, please post your findings to the net! ...lori From apollo-request@umix.cc.umich.edu Sat Oct 28 03:50:03 1989 Date: 27 Oct 89 22:23:26 GMT From: davidb%inmos%ukc%mcsun.uucp@uunet.uu.net (David Boreham) Organization: INMOS Limited, Bristol, UK. Subject: Problem with NFS2.0 and DNS (Mabe ?) Message-Id: <2703@ganymede.inmos.co.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'd be interested in hearing from anyone who is running NFS2.0 (SR10.1) AND using the DNS for host name lookup. I find that any client trying to mount an Apollo filesystem gets the cold shoulder. A message is put in the nfs log file to the effect that mountd could not verify the client's address. The curious thing is that the message actually says "cilent's address not in /etc/host". Now, /etc/host I suppose it's a typo for /etc/hosts, but the client sure is in /etc/hosts (and in an /etc/host I made just to be safe). I am running the DNS resolver though, and /etc/hosts should not be consulted after boot time. Any ideas ???? -- David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb Bristol, England | (us): uunet!inmos-c!davidb +44 454 616616 ex 543 | Internet : @col.hp.com:davidb@inmos-c From apollo-request@umix.cc.umich.edu Sat Oct 28 04:28:43 1989 Date: 23 Oct 89 23:27:16 GMT From: tvb%bugeater.UUCP%frame%vsi1.uucp@apple.com (Terry Bush) Organization: Frame Technology, 1010 Rincon Cir., San Jose, CA 95131 Subject: Re: Apollo NFS V2.0 Message-Id: <3601@frame.UUCP> References: <758@idacom.UUCP>, <239@ticipa.ti.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > From article <758@idacom.UUCP>, by danny@idacom.UUCP (Danny Wilson): > > > > To realize this, we run the NFS servers on a node one the ring _different_ > > from the gateway node to the Ethernet (which connects to some Suns and a > > Vax) > > I am assuming that you mean the your gateway node is not running as a > NFS server. Running the gateway node as a NFS server won't cause you > any problems. In fact it may be part of your problem. We had a problem > quite similar to this. We mounted files from our microvax to our > gateway node which had NFS running. Some of our nodes didn't have > NFS running, these nodes could see the NFS mounted files but could not > access them properly, they timed out trying to access them. > > Just because you have NFS running on some of your nodes doesn't > mean all your nodes can use the NFS mounted files. Those nodes that > don't have NFS installed probably won't work correctly. > > I suppect that if your gateway node isn't running NFS it may be > having trouble handling the NFS requests. > > I run NFS on all the nodes in my network and I don't have any NFS problems. This is not entirely true. Your problems may be one of the following: 1. TCP/IP is not configured such that nodes on one side of the gateway or the other are not aware of the other network. Run '/usr/ucb/netstat -r' to determine if the hosts know about the gateway. To solve this you can run an active router on the gateway node and passive routers on non-router nodes (On Apollos run '/etc/routed -q -h' for the passive routers.) -OR- Run '/etc/route' to add knowledge of the gateways on all nodes in question. 2. NFS type managers are not installed. To determine this, run '/com/ld -a ' (fill in ) on a node that is having trouble. If the file type should be 'nfs_gate' for the mount point and 'nfs_dir' or 'nfs_file' inside the tree. To fix this, install NFS on all hosts as a 'link' to another node. This will install the type server, etc. on each host, but will not install the files in /etc that take up so much disk space. I run NFS routinely on my Apollos and always have to rsh to the gateway, then to the remote host in order to run /etc/route so they all know about each other. Maybe other vendors than Apollo will supply the '-h' option to routed that makes it go away after the routing tables stablize. This is very nice of Apollo. Peace, Terry V. Bush The Veritable Bugeater From apollo-request@umix.cc.umich.edu Sat Oct 28 11:26:00 1989 Date: 28 Oct 89 01:14:32 GMT From: sllu%venera.isi.edu%usc%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Shih-Lien Lu) Organization: USC-Information Sciences Institute Subject: novice questions on apollo .... Message-Id: <10316@venera.isi.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have recently acguried ONE Mentor Graphic station (Apollo DN3500) with: ETHERNET AT AEGIS ONLY OPERATING SYSTEM We have SUNs, VAXes and HPs all on an internet using TCP/IP to communicate between them. I would like to put this Mentor Graphic station (Apollo) on the internet also. I am a novice in Aegis/Domain. Please answer the following questions: (1) Do I need extra hardware/software to put this Apollo on the existing internet? (2) If I cannot find "ftp", "telnet" .... in /com does it mean I do not have the software? Whereelse can I look? (3) The system comes with no /etc. Do I just create one and add files for TCP/IP purpose? Shih-Lien sllu@mosis.edu From apollo-request@umix.cc.umich.edu Sat Oct 28 11:27:03 1989 Date: 28 Oct 89 12:16:27 GMT From: davidb%inmos%ukc%mcsun.uucp@uunet.uu.net (David Boreham) Organization: INMOS Limited, Bristol, UK. Subject: Problem with NFS2.0 and DNS. Message-Id: <2705@ganymede.inmos.co.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Yesterday I posted this : ------------------------------------------ I'd be interested in hearing from anyone who is running NFS2.0 (SR10.1) AND using the DNS for host name lookup. I find that any client trying to mount an Apollo filesystem gets the cold shoulder. A message is put in the nfs log file to the effect that mountd could not verify the client's address. The curious thing is that the message actually says "cilent's address not in /etc/host". Now, /etc/host I suppose is a typo for /etc/hosts, but the client sure is in /etc/hosts (and in an /etc/host I made just to be safe). I am running the DNS resolver though, and /etc/hosts should not be consulted after boot time. Any ideas ???? ------------------------------------------- Well, after actually disabling DNS name resolving, surprise, surprise, NFS started working ! Now, I've noticed some strange behavior from the apollo DNS system before (like machine names in host.equiv sometimes needing to be the IP address before they will work). Does anyone have any experience of problems with the apollo DNS system in general ? [ I am running all my Apollo nodes as DNS slaves to various SUN servers, none of the Apollo's actually runs named. IP-based things all work pretty well, except NFS ] -- David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb Bristol, England | (us): uunet!inmos-c!davidb +44 454 616616 ex 543 | Internet : @col.hp.com:davidb@inmos-c From apollo-request@umix.cc.umich.edu Sun Oct 29 01:18:35 1989 Date: 29 Oct 89 04:10:59 GMT From: dma%beach.cis.ufl.edu%uflorida%mailrus%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (David Aharoni) Organization: UF CIS Department Subject: DPCC cards Message-Id: <21123@uflorida.cis.ufl.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We've recently replaced our DPCC cards with a new 386 board made by PC elevator. The reason for replacing the board was to take advantage of the faster processing speed of the 386 chip. As it turns out, the PC Elevator board is significantly slower than the DPCC card that runs the 286 chip. I have a DN3000 running sr9.7, Typically my node crashes about twice a week but i'm not sure if this is being caused by the PC elevetor card. I also noticed my node to be very slow since the card was installed. The dspst window shows that the PC elevator card is using 37.9% of the CPU just sitting idle. Any action in that window typically uses up 65% of the CPU, at one point while running a program that accesses many files it actually went to 103%. Has any one had any experience with these cards or have any idea why it is such a CPU hog. Our sys admin has no solution yet, if we don't come up with a fix we'll probably pull them out and put back the old DPCC cards. Thanks in advance, David Aharoni From apollo-request@umix.cc.umich.edu Mon Oct 30 01:18:50 1989 Date: 27 Oct 89 20:33:32 GMT From: danny%idacom%aunro%atha%philmtl.uucp@uunet.uu.net (Danny Wilson) Organization: IDACOM Electronics Ltd., Edmonton, Alta. Subject: Re: Mentor Graphics & DN2500 Message-Id: <777@idacom.UUCP> References: <574@stdc01.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <574@stdc01.UUCP>, walsh@stdc01.UUCP (Mike Walsh) writes: > > My second question, does anyone know whether or not Mentor is going to > support the new DN2500 ? Mentor [supposedly] support the DN2500 from SR10.2 onward. I guess the reason is that the 2500 requires a patch tape to add a new sau directory to run under the current SR10.1 (which is used by Mentor V7.0) tools -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta alberta!idacom!danny C A N A D A X.400 danny@idacom.cs.ubc.cdn From apollo-request@umix.cc.umich.edu Mon Oct 30 09:23:23 1989 Message-Id: <8910301348.AA05119@umix.cc.umich.edu> Date: Mon, 30 Oct 89 08:37:08 EST From: Scott Ferguson Subject: GPIB-driven peripheral boards To: APOLLO@UMIX.CC.UMICH.EDU Someone recently mentioned their PC Elevator board hogging CPU time while idling. I think I know why, and figured I'd post a message hoping that some peripheral vendors are listening. Some vendors write simple GPIB driver software, but don't use the pbu_$wait calls for getting interrupts. They run through a loop checking over and over again for their interrupts. This takes cpu time, and is pretty silly. I've seen the same problem with National Instruments IEEE-488 cards, and Mercury Systems Array processor cards. SO, if any vendors are listening, please check your software, because you might be doing more harm than good with your products. Scott Ferguson ferguson@erenj.bitnet Exxon Research & Engineering Annandale, NJ 08801 From apollo-request@umix.cc.umich.edu Mon Oct 30 13:20:18 1989 Date: 30 Oct 89 16:16:55 GMT From: dennis%Peanuts.uucp@nosc.mil (Dennis Cottel) Subject: Re: Apollo should use sendmail internally Message-Id: <1455@nosc.NOSC.MIL> References: <1547@novavax.UUCP>, <4676c05b.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: > The reason is that there's a fundamental problem with the "standard" > Unix mail model. Basically, I don't want to have to address mail I send > to internal users directly to the machine that user gets mail on. I > want to mail to "smith" not "smith@smiths-machine" or the like. > Various people have gotten around this problem in various ways: (1) > distribute aliases files to all machines (or use links and a distributed > file system to link to one or more "central" copies), (2) arrange that > all mail gets sent to a "smart" host which has an aliases file or the > like and disposes of the mail properly, (3) pretend that your network > is really one big timesharing system and use /bin/mail and trust that > it will be able to write to a central /usr/spool/mail directory on some > fileserver. Does each node then have an /etc/spool/mail directory and a sendmail daemon running? Otherwise case (2) and (3) can't spool up the mail if the central mail machine is down. A similar problem occurs for case (1) if you use links to find the alias file. [This is another good example of why the operating system should provide some kind of "redundant link".] And this still doesn't address the problem with file locking across nodes: touching your mail spool file from a node other than that where the spool directory lives may break sendmail, causing the mail to be returned to sender (or worse). Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis From apollo-request@umix.cc.umich.edu Mon Oct 30 15:33:51 1989 Date: Mon, 30 Oct 89 14:36:17 EST From: markg@caen.engin.umich.edu (Mark Giuffrida) Message-Id: <468ab95f3.0017b5e@caen.engin.umich.edu> To: apollo@umix.cc.umich.edu Subject: Re: Apollo should use sendmail internally Does each node then have an /etc/spool/mail directory and a sendmail daemon running? Otherwise case (2) and (3) can't spool up the mail if the central mail machine is down. A similar problem occurs for case (1) if you use links to find the alias file. [This is another good example of why the operating system should provide some kind of "redundant link".] And this still doesn't address the problem with file locking across nodes: touching your mail spool file from a node other than that where the spool directory lives may break sendmail, causing the mail to be returned to sender (or worse). Actually we at UofM(CAEN) link all our spool dirs to a central machine. Its six of one or half a dozen of another. Either the big one is down or some of the small ones are down. It teaches you to keep an eye on your primary server. This is actually the best scenario for a large Apollo ring. When the server is down, then mail trying to be delivered *should* be temporarily queued (i.e., /bin/mail returns a code that tells sendmail to "leave it queued"). The same for when the file is locked. Actually, we put in our own open which will wait up to 15 seconds for the mail file to unlock before returning the "leave it queued" return code to sendmail. The current behavior of Unix sendmail (to repeat an earlier msg) is for /bin/mail to balk at the locked file and return to sendmail which returns to it to the sender with "unknown mailer error" msg. /bin/mail presumes it can always connect to the mailbox which is wrong in an Apollo or NFS environment. Remember that queuing a msg because it cannot be delivered is not a bad thing. Presumably you run "/usr/lib/sendmail -q" from cron on every node every 30 or 60 minutes that will process any queued mail. This way, these temporary problems are just that, temporary. Mark Giuffrida Univ of Michigan markg@caen.engin.umich.edu From apollo-request@umix.cc.umich.edu Tue Oct 31 09:23:32 1989 Date: Tue, 31 Oct 89 09:59:21 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8910311459.AA12924@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: attaching external disk to DN2500 We have a couple of DN2500's on order which will be running SR10.2 I'm interested in attaching some generic SCSI external disks to the machines (some surplus Apple Macintosh drives, etc). Has anyone had any experience with attaching *any* sort of external disks to the DN2500? The sales literature is kind of confusing. In one place they state that you can have up to 7 SCSI devices attached to the machine, in another they state that the maximum disk configuration is a little over 1 Gb (2-200Mb internal and one 600 Mb external). What gives? How many external disks can I attach to a machine? Can I have only an external drive, or does the node have to have an internal disk before an external drive can be attached? Will a generic SCSI disk work? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) (with, as usual, more questions than answers) From apollo-request@umix.cc.umich.edu Tue Oct 31 13:19:31 1989 Date: 31 Oct 89 16:47:00 GMT From: mishkin%apollo.hp.com%apollo.uucp@eddie.mit.edu (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: Apollo should use sendmail internally Message-Id: <468f2a04.20b6d@apollo.HP.COM> References: <468ab95f3.0017b5e@caen.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <468ab95f3.0017b5e@caen.engin.umich.edu>, markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) writes: > The current behavior of Unix sendmail (to repeat an earlier msg) is for > /bin/mail to balk at the locked file and return to sendmail which returns to it > to the sender with "unknown mailer error" msg. /bin/mail presumes it can always > connect to the mailbox which is wrong in an Apollo or NFS environment. Note that there's a further problem with using /bin/mail over the network: If the network breaks in the middle of writing to the file in /usr/spool/mail, the contents of the file are going to be unpredictable. This could hopelessly damage the structure/format of the file. -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com From apollo-request@umix.cc.umich.edu Tue Oct 31 15:23:48 1989 Date: Tue, 31 Oct 89 14:56:12 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8910311956.AA13579@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: More SCSI questions Does anyone know which type of SCSI connector is on the back of the DN2500? I've seen at least 3 different types of connectors for this "standard" device interface: The "D" connector on the back of the Mac Plus, the edge connector (similar to a centronics printer connector) on the back of the 20MB external disk for the Mac Plus and on the back of the Western Digital controller in our DN3500, and a 50 pin "D" connector (pins in 3 rows) found on the back of a Sony optical disk! I just love standards, don't you? Anybody got a DN2500 in house that they can take a quick look at? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Tue Oct 31 15:24:13 1989 Message-Id: <8910311904.AA19549@unix.sri.com> Date: Tue, 31 Oct 89 10:56:15 PST From: ramu%tcipro.uucp@unix.sri.com (Ramu Iyer) To: apollo%umix.cc.umich.edu%sri-unix.uucp@unix.sri.com Subject: Running emacs in X I find that while running emacs within X-11 on a DN4500, I am unable to poll my mouse within my emacs shell. In such a situation, I have to use the keyboard keys like C-f, C-n, etc to advance forward or to the next lines. On the other hand, when I run emacs under Domain Windows, there are no such problems. Any ideas are welcome. Thanks in advance. --Ramu Iyer email: ramu%tcipro.uucp@unix.sri.com sri-unix!tcipro!ramu@uunet.uu.net (if the previous address bounces) From apollo-request@umix.cc.umich.edu Wed Nov 1 15:26:53 1989 Date: 1 Nov 89 17:41:51 GMT From: george%hyper.lap.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@handies.ucar.edu (George "Sir Lleb" Zipperlen) Organization: University of Pennsylvania, Language Analysis Project Subject: bsd sendmail and/or socket problem @sr9.7 Message-Id: <16245@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu /usr/lib/sendmail -bd has started dying on us when run in daemon mode. This makes it impossible to receive incoming internet mail, although local and outgoing mail work. There hasn't been any change in the configuration or alias files. There are no error messages in the syslogd log files, but using fmpd shows that the sendmail daemon is crashing. Curiously, two other programs, /bin/start_csh and /etc/run_rc, are sometimes crashing in the same way. This leads me to suspect a socket problem rather than anything specific to sendmail. Other internet services like telnet and ftp still work, as do heavy socket users like X11. Changing to SR10 is not an option at the moment. Has anyone else seen this problem? Any clues? Dump #31. Dump Status: 00120011: access violation (OS/fault handler) Dump Time: 1989/10/31.13:24 (EST) Proc2 UID: 468F8060.7000E2EB Prog UID: 43CA9B02.1000E2EB Prog Name: /bsd4.2/usr/lib/sendmail Fault Diagnostic Information Fault Status = 00120011: access violation (OS/fault handler) Access Addr = 0000000C IR = C001 Acc. Info = 0161 User Fault PC = 00008D4E D0-D3: 00000000 01270001 00000001 00000000 D4-D7: 00000001 00000000 00000001 00000000 A0-A3: 0001CB20 00000000 0001D328 031E2E2C A4-A7: 031482C4 00018478 031C74D8 031C74C0 Supervisor ECB = 00000000 Supervisor SR = 0000 Supervisor PC = 00000000 In routine "disconnect" line 949 Called from "main" line 552 Called from "UNIX_$MAIN" line 190 Called from "" line 31999 Called from "PM_$CALL" Called from "PGM_$LOAD_RUN" line 473 Dump #32. Dump Status: 00120011: access violation (OS/fault handler) Dump Time: 1989/10/31.13:24 (EST) Proc2 UID: 468F80B1.D000E2EB Prog UID: 38B1596E.F000E2EB Prog Name: /bsd4.2/etc/run_rc Fault Diagnostic Information Fault Status = 00120011: access violation (OS/fault handler) Access Addr = 0000000C IR = C001 Acc. Info = 0161 User Fault PC = 00008D4E D0-D3: 00000000 00000000 00000001 00000000 D4-D7: 00000001 00000000 00000001 00000000 A0-A3: 0001CB20 00000000 0001D328 031E2E2C A4-A7: 031702D8 00018478 031C7234 031C721C Supervisor ECB = 00000000 Supervisor SR = 0000 Supervisor PC = 00000000 In routine "disconnect" line 949 Called from "main" line 552 Called from "UNIX_$MAIN" line 190 Called from "" line 31999 Called from "PM_$CALL" Called from "PGM_$LOAD_RUN" line 473 Dump #36. Dump Status: 00120011: access violation (OS/fault handler) Dump Time: 1989/10/31.13:39 (EST) Proc2 UID: 468F8E19.9000E2EB Prog UID: 36BF787D.3000E2EB Prog Name: /bsd4.2/bin/start_csh Fault Diagnostic Information Fault Status = 00120011: access violation (OS/fault handler) Access Addr = 0000000C IR = C000 Acc. Info = 0161 User Fault PC = 00008D4E D0-D3: 00000000 01270001 00000001 00000000 D4-D7: 00000001 00000000 00000001 00000000 A0-A3: 0001CB20 00000000 0001D328 031E2E2C A4-A7: 031682D8 00018478 031C7168 031C7150 Supervisor ECB = 0000000 Supervisor SR = 0000 Supervisor PC = 00000000 In routine "disconnect" line 949 Called from "main" line 552 Called from "UNIX_$MAIN" line 190 Called from "" line 31999 Called from "PM_$CALL" Called from "PGM_$LOAD_RUN" line 473 George Zipperlen george@apollo.lap.upenn.edu george@hyper.lap.upenn.edu ...!{rutgers, uunet, mit-eddie, decwrl}!upenn.edu!apollo.lap!george Blatant plug for funky-music@apollo.lap.upenn.edu "Won't be no Static" -JB From apollo-request@umix.cc.umich.edu Wed Nov 1 19:20:09 1989 Date: 1 Nov 89 11:24:16 GMT From: sanders%mdcbbs.uucp@uunet.uu.net Organization: McDonnell Douglas M&E, Cypress CA Subject: Network License Server? Message-Id: <571.254ed260@mdcbbs.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are in the process of evaluating Appollo's Network Licensing System (NLS) and I am interested in any comments about it. Please send mail. We are are particularly interested in its use in a mixed platform network: Appollo, Sun, VAX/VMS, HP/UX. We have the sales material but how easy is it to implement and use in a real working environment? Thanks Sandy -- | Wayne E. Sanders Jr. | Voice: 714-952-5773 | Currently on contract to: | Domain: sandy@dev3f.mdcbbs.com | McDonnell Douglas M&E Co. | UUCP: uunet!mdcbbs!dev3f!sandy | MS K34-C694-300W | PSI: PSI%31060099980019::SANDY | 5701 Katella Ave. | | Cypress, CA 90630-5099 | We come in peace - shoot to kill! From apollo-request@umix.cc.umich.edu Wed Nov 1 23:55:30 1989 Date: 1 Nov 89 23:09:53 GMT From: rchrd%well.uucp@hplabs.hp.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: I can trash 10.1, but why does it happen?? Message-Id: <14403@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu An application program I am developing that runs on my DN3000 with DOMAIN 10.1 has twice now trashed the system. It somehow manages to destroy the pointers to the root directory, so that when the application exits and you type anything at the shell prompt, you get the frightening message: /bin/ls: Not a directory (when trying to do an ls command, say). All commands get similar messages, in all open shells on the screen, except commands that are internal to csh, such as cd or echo. Even trying to read a file from the DM command window (e.g. cv /tmp/mytext ) gets a OS server message that the directory does not exist. All is LOST! Trying to re-boot the system gets: Bad Root directory version number error E000D Now, keep in mind that this is a STAND-ALONE system, so only recourse is to RE-INSTALL the bloody operating system! ARE WE HAVING FUN YET !!! I ask anyone out there, does anyone have a clue how a "nice" C applications code that does I/O using standard C -library calls (no assembly routines!) could managed to wipe out the system in this manner. I suspect there is a hole in DOMAIN somewhere. But WHAT! Only other hints I can offer are: a) there were open filesat the time the application exited. b) the application did change directories before exiting, but these directories were far from root. e.g. the shell was in the directory: //berkeley/FORGE/examples/global/bmarks when the application was started up. ANY HELP GREATLY APPRECIATED. -- /s/ rchrd <=> Richard Friedman <=> rchrd@well rchrd@well.sf.ca.us | {apple,pacbell,hplabs,ucbvax}!well!rchrd [Pacific-Sierra Research / Berkeley CA] (415) 540-5216 (The usual disclaimers apply - I speak only for myself!) From apollo-request@umix.cc.umich.edu Thu Nov 2 01:20:33 1989 Date: 2 Nov 89 02:40:23 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%gem.mps.ohio-state.edu.uucp@ (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: More SCSI questions Message-Id: <21738@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Re: 'standard SCSI cable connectors and DN-2500' The connector is a 'Centronics-style' "D" connector. However, instead of using the 'standard' wire bales to physically secure it to the connector, Apollo chose to use machine screws. I guess it is more secure than the wire, but NOBODY ELSE USES THIS COMBINATION! Standards, eh? Michael Lampi MDL Corporation UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com From apollo-request@umix.cc.umich.edu Thu Nov 2 01:24:36 1989 Date: 2 Nov 89 02:40:18 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%gem.mps.ohio-state.edu.uucp@ (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: attaching external disk to DN2500 Message-Id: <21737@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The DN-2500 SCSI bus (like all SCSI-1 buses) supports as many as 7 SCSI devices. It is possible for each of these 7 devices to have a number of 'units'. For example, a SCSI 9-track tape controller can, conceivably, support more than a single tape transport by addressing units 0, 1,... but only occupy a single SCSI device 'slot'. The DN-2500 supports up to 2 disk drives internally, due to space and mounting limitations. These two drives must both be of the 3-1/2 inch variety. They use an internal cable to connect to the DN-2500 motherboard. Due to cable length limitations, one is more likely to run out of cable than to run out of device 'slots'. ('slots' are actually device numbers) Hence, if one wants up to 4.2 gigabytes (using the 760 meg unformatted 5-1/4 inch drives, for example), then one had better make the cable fit the SCSI-1 single-ended specifications. Note that this is TOTAL cable length, including that for internal drives. In terms of attaching brand-X devices, Apollo is releasing a version of GPIO that opens up the SCSI bus just like the AT bus in the higher-end machines. Note that this does NOT mean that any brand-X disk drive will be bootable or support an Apollo file system. The SCSI spec is not precise enough for one to write a single driver and have it work for all SCSI (say, disk) devices. There are tooo many important 'vendor-specific' commands that one needs to use to get reasonable performance from these devices. What does this mean? Well, you can try plugging in a disk and see if it works. Or, buy a drive from Apollo (a known quantity). Or give me a call and I'll see what I can do for you. Michael Lampi MDL Corporation (213) 782-7888 fax (213) 782-7927 or E-mail in care of the above address. UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com From apollo-request@umix.cc.umich.edu Thu Nov 2 01:27:10 1989 Date: 1 Nov 89 19:25:00 GMT From: howie%inmet.uucp@uunet.uu.net Subject: Re: DPCC cards Message-Id: <29900002@inmet> References: <21123@uflorida.cis.ufl.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am in charge of software development and technical support at Applied Reasoning Corporation, the company that produces the PC-ELEVATOR 386. I would like to invite Mr. Aharoni (and any other users that are not 100% satisfied) to contact us for assistance. One of our technical support people told me about a sign in a barber shop: "If you are happy with our work, please tell the world. If you are not happy, please tell us." Mr. Aharoni is not the only user who voiced such concerns when using some of our early software. Recent software updates have addressed these issues. We are constantly improving the performance of the PC-ELEVATOR 386, and we are constantly learning new facts about Apollo hardware and software. Please contact me at: VOICE: (617) 492-0700 FAX: (617) 492-7908 POST: 86A Sherman Street, Cambridge, MA 02140 (Please DO NOT try to contact me via usenet, as I am only a guest on this system, and do not check for messages very often). Howard Marshall Director of Software Engineering Applied Reasoning Corporation From apollo-request@umix.cc.umich.edu Thu Nov 2 07:23:24 1989 Date: 2 Nov 89 09:29:30 GMT From: mark%bruce%munnari.oz.au%uhccux.uucp@ames.arc.nasa.gov (Mark Goodwin) Organization: Monash Uni. Computer Science, Australia Subject: Re: I can trash 10.1, but why does it happen?? Message-Id: <1640@bruce.OZ> References: <14403@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <14403@well.UUCP>, by rchrd@well.UUCP (Richard Friedman): > An application program I am developing that runs on my > DN3000 with DOMAIN 10.1 has twice now trashed the system. > It somehow manages to destroy the pointers to the root directory, Add to this horrific story one of my own. My C program logs me out upon entry to a particular function! This happens when logged in on a pseudo tty on our DN580-T under SR9.7. Must have been stack overflow because I changed several mbytes of local storage (in the function) to static and the problem went away. The function was not recursive (by the way). All I can say is that the Apollo C compilers are extremly stack sensitive. Make sure * every function call passes exactly the same number of parameters as expected by the function * every parameter is exactly the same size as expected in the function. (i.e. you can not pass an int when a short is expected, etc.). * be careful not to declare too much local storage in a function, (especially for recursive functions). Add to the above the pascal calling convention to library routines (i.e. no need for ampersands when passing the address of a variable), and you have quite an "unexpected" development environment. Good for programming discipline, but often a real headache. -- Mark Goodwin, Programmer @ Monash Uni. Comp. Sci. From apollo-request@umix.cc.umich.edu Thu Nov 2 19:20:34 1989 Date: 2 Nov 89 21:24:10 GMT From: dvadura%watdragon%watmath.uucp@iuvax.cs.indiana.edu (Dennis Vadura) Organization: Computer Science Dept., University of Waterloo Subject: script doesn't work in bsd4.2 mode Message-Id: <17780@watdragon.waterloo.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu NODE: DN3500, BSD4.3 system, SR 10.1.1 Symptoms: Issue "script" command and all you get is -- Script started ...date... script ended ...date... and the next prompt from the invoking shell. Needless to say this is kind of useless. The same behaviour takes place when you log in from the network as when I do it in an X11 xterm window at the console. Has anyone seen this and know of a simple fix? I have the source for script but nothing obvious is popping up out of it. Any help appreciated. -thanks -dennis -- -------------------------------------------------------------------------------- The only happy people are Single MEN |Dennis UUCP,BITNET: dvadura@water and Married WOMEN. |Vadura EDU,CDN,CSNET: dvadura@waterloo ================================================================================ From apollo-request@umix.cc.umich.edu Thu Nov 2 19:25:16 1989 Date: 2 Nov 89 21:16:23 GMT From: dvadura%watdragon%watmath.uucp@iuvax.cs.indiana.edu (Dennis Vadura) Organization: Computer Science Dept., University of Waterloo Subject: Re: I can trash 10.1, but why does it happen?? Message-Id: <17779@watdragon.waterloo.edu> References: <14403@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <14403@well.UUCP> rchrd@well.UUCP (Richard Friedman) writes: +An application program I am developing that runs on my +DN3000 with DOMAIN 10.1 has twice now trashed the system. +It somehow manages to destroy the pointers to the root directory, +so that when the application exits and you type anything at the +shell prompt, you get the frightening message: + /bin/ls: Not a directory +(when trying to do an ls command, say). + +All commands get similar messages, in all open shells on the +screen, except commands that are internal to csh, such as cd +or echo. + +Even trying to read a file from the DM command window +(e.g. cv /tmp/mytext ) gets a OS server message that the directory +does not exist. + +All is LOST! + +Trying to re-boot the system gets: + Bad Root directory version number + error E000D + +Now, keep in mind that this is a STAND-ALONE system, so only recourse +is to RE-INSTALL the bloody operating system! I had a similar problem. Same thing, essentially a stand alone node, running 10.1.1. I had the disk upto 80% full or so, and was running A compile of gcc, as well as a couple of other compiles, and bang the world stopped. We could log in from other machines but could not execute any commands other than those that were built-in shell commands, everything else gave the same error as you indicate. Called apollo hotline, their suggestion was to invol the disk and reload the stuff. When I tried to reboot, it got past the reboot but it still did not execute any commands at the shell prompts. The box was hosed. Now the scary thing is this took place with a fairly full disk and lots going on which indicated to me there may be a problem with the virtual memory allocation when the node is busy and the disk is full. Anyway, eversince I re-installed the OS and made sure that half my 350 meg disk is empty at all times, I can load the thing down all I want and it runs fine. -dennis -- -------------------------------------------------------------------------------- The only happy people are Single MEN |Dennis UUCP,BITNET: dvadura@water and Married WOMEN. |Vadura EDU,CDN,CSNET: dvadura@waterloo ================================================================================ From apollo-request@umix.cc.umich.edu Fri Nov 3 03:19:58 1989 Date: 2 Nov 89 20:05:08 GMT From: danny%idacom%ncc%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Danny Wilson) Organization: IDACOM Electronics Ltd., Edmonton, Alta. Subject: Re: Mentor Graphics & DN2500 Message-Id: <783@idacom.UUCP> References: <574@stdc01.UUCP>, <1292@jura.tcom.stc.co.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1292@jura.tcom.stc.co.uk>, sm@tcom.stc.co.uk (Simon Marchant) writes: [...] > A long time ago I was a 'Mentor Graphics' System Administrator and > had cause to add menus to Neted. To do this it was necessary to > write in a special menu description language a file and compile > it with the Mentor Graphics "MISL" Compiler. MISL (Mentor Interactive Stimulus Language) really has nothing to do with defintion of menus. It is used to generate simulation log files (basically a list of events and signal combinations) to drive a circuit for simulation. That is, using a psuedo high-level language, you can define the driving forces on your circuit for simulation. MISL is used by QuickSim, the logic simulator, not in NETED (the schematic editor). BTW, among the mentor users out there, how many are actually using simulation? How do you like it? Can you find models? We have tried occasionally to get on the simulation bandwagon but have always gave up. The models were difficult to find and if we could find them they were _Very_ expensive. Also, the whole processed seemed just a little time consuming. Any comments? -- Danny Wilson danny@idacom.uucp IDACOM Electronics alberta!idacom!danny Edmonton, Alberta X.400 danny@idacom.cs.ubc.cdn C A N A D A Voice +1 403 462 4545 From apollo-request@umix.cc.umich.edu Fri Nov 3 17:21:05 1989 Date: 1 Nov 89 12:39:05 GMT From: moser%infbs%unido%mcsun.uucp@uunet.uu.net (Eduard Moser) Organization: TU Braunschweig,Informatik,West Germany Subject: Looking for SPICE2G.6 Message-Id: <1337@infbs.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are looking for SPICE 2G.6 for apollo (DN3000, DN3500, DN4500). Public domain would be best, but any companies selling it are also welcome. We are able to ftp from anywhere, but Europe and/or BITNET is preferred. I'm also interested in other SPICE 2?.? versions. J. Hannken-Illjes (moser@dbsinf6.bitnet moser@infbs) Institut fuer Theoretische Informatik Gauszstr. 11 / D-3300 Braunschweig / FRG From apollo-request@umix.cc.umich.edu Fri Nov 3 19:26:24 1989 Date: 1 Nov 89 11:40:44 GMT From: ye49%mrcu%hrc63%root44%stc%ukc%mcsun.uucp@uunet.uu.net (David Johnson) Organization: GEC-Marconi Research Centre, Great Baddow, UK Subject: TIFF to Apollo Bitmap convertor Message-Id: <244@mrcu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone out there have the a specification for the TIFF format, or utilities for converting it into Apollo bitmapped graphics Thanks in advance Dave Johnson Dave Johnson | uucp : ..!mcvax!ukc!mrca!ye49 GEC-Marconi Research Centre | OR : ye49@uk.co.gec-mrc Chelmsford | Tel +44 245 73331 x 3269 Essex CM2 8HN | Fax +44 245 75244 -- Dave Johnson | uucp : ..!mcvax!ukc!mrca!ye49 GEC-Marconi Research Centre | OR : ye49@uk.co.gec-mrc Chelmsford | Tel +44 245 73331 x 3269 Essex CM2 8HN | Fax +44 245 75244 From apollo-request@umix.cc.umich.edu Fri Nov 3 19:30:13 1989 Date: 3 Nov 89 17:04:00 GMT From: gaz%apollo.uucp@eddie.mit.edu (Gary Zaidenweber) Subject: Re: Calls to mbx_$get_conditional are dying. Message-Id: <469e4fa4.20b6d@apollo.HP.COM> References: <15448@bloom-beacon.MIT.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <15448@bloom-beacon.MIT.EDU>, by asherman@raven.ulowell.edu: > Is there anyone out there who uses mailboxes under 10.1 in C? Yes, I am using mbx_$get_conditional() successfully under SR10.1 in C. > The problem that I'm having is that mbx_$get_conditional is > exiting and not telling me what's wrong. This makes me a bit > unhappy, needless to say. > [... code removed ...] > > The output I get is: > > % test_io > Calling mbx_$get_conditional. > % > > This is confusing me badly. I want to call Apollo, but before I do, I want to > know that this is not just a simple mistake on my part. > > thanks. > > -AJS(Harmil) Please forgive me if this message is more pedantic than necessary. First of all, once the program exits, type 'tb -f' to see what happened in the process. If that doesn't work, get and print the pid in the program: extern int getpid(); int mypid; mypid = getpid(); printf ("process ID: %d\n", mypid); and then type 'tb -f '. You probably got a 'segment violation' or 'illegal access' or the like. here's the function prototype from /usr/include/apollo/mbx.h: /* * G E T _ C O N D - get a record from the mailbox if there is one */ extern void mbx_$get_conditional( void *&h, /* handle for the mailbox */ void *&bptr, /* pointer to buffer */ long &blen, /* max length of buffer */ void **rptr, /* pointer to data read */ long *rlen, /* amount of data read */ status_$t *st ); Notice that the handle is passed implicitly by reference. The type of the handle which you received from the mbx_$open() call is 'void *' already (as opposed to 'void') so your '&' on the handle parm is invalid. By the way, its not apparent from the code fragment you posted that you are including the mbx-header file. If not, do this: #include #include and let the compiler do the rest. Good luck. Gary Zaidenweber (508)256-6600 x6081 | You're only young Apollo Computer, a subsidiary of Hewlett Packard | once, but if you UUCP: {umix|decvax|mit-eddie}!apollo!gaz | do it right, ARPA: gaz@apollo.COM; gaz@apollo.HP.COM | once is enough! From apollo-request@umix.cc.umich.edu Fri Nov 3 21:17:44 1989 Date: 3 Nov 89 16:52:52 GMT From: apollo%ecf%me%jarvis.csri.toronto.edu%mailrus%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Vince Pugliese) Organization: Engineering Computing Facility, University of Toronto Subject: getting hold of usable C-Kermit running under 10.* Message-Id: <1989Nov3.165252.24965@ecf.utoronto.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu the subject heading pretty well sums up my request. an anonymous ftp address (complete with internet numbers) would be greatly appreciated. thanks vince apollo@ecf.toronto.edu From apollo-request@umix.cc.umich.edu Fri Nov 3 23:17:02 1989 Date: 3 Nov 89 04:39:33 GMT From: turner%dover%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Robert Turner) Organization: Motorola SPS, Mesa, AZ Subject: Security on Apollo systems Message-Id: <1945@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Would it be proper to discuss security issues on Apollo systems in this news group? If not, which other news group. Robert -- ----- Law of the Net: Triva begets triva tenfold. All opinions are. Robert Turner (602) 994-6837 ...!uunet!dover!turner or turner@dover.sps.mot.com From apollo-request@umix.cc.umich.edu Fri Nov 3 23:21:36 1989 Date: 3 Nov 89 20:18:02 GMT From: mikeh%ima%spdcc%snorkelwacker.uucp@tut.cis.ohio-state.edu (Mike Q. Hiller) Organization: Phar Lap Software Subject: pcnfsd on dn10000 with sr10 Message-Id: <4513@ima.ima.isc.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, I have a dn10000 with lots of disk space. I'd like to use it as an NFS server, but my client PC's can't mount it because it doesn't have a pcnfsd authentication service. pcnfsd.c won't build because the distribution doesn't include the rpc includes or libs. Has anyone out there run into this issue? Is there a solution short of porting the rpc libs myself? Thanks Mike Hiller mikeh@pharlap.com uunet!pharlap!mikeh From apollo-request@umix.cc.umich.edu Sat Nov 4 03:18:46 1989 Date: 4 Nov 89 05:43:56 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: Security on Apollo systems Message-Id: References: <1945@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I think it makes sense to discuss them here as long as you don't give the details on how to break in. If you want to do that, make sure you have a fix to post at the same time, but consider this as a last step. Also try discussing them with Apollo/HP first, they may already have a solution. I seem to remember seeing a newsgroup on security, if it exists, you may want to cross post there. -- Alan Bair SPS CAD Logic Simulation & Test Motorola, Inc. Austin, Texas ...!cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Sat Nov 4 15:28:39 1989 Date: Sat, 4 Nov 1989 19:37:13 MET From: Harald Hanche-Olsen To: apollo@umix.cc.umich.edu Cc: Mike Hiller Subject: Re: pcnfsd on dn10000 with sr10 Message-Id: Porting the rpc libs to the Apollo is a real snap, at least if you are running SR10.1 and bsd4.3 like we do. We found only two problems that had to be fixed: - We deleted line 398 of rpc/svc.c, which read as follows: int - and we changed line 219 of rpc/rpc_prot.c from case RPC_VERSMISMATCH: to case RPC_MISMATCH: other versions of sunrpc might have these typos fixed and others substituted in their place. We run pcnfsd both on a 3500 and a 10000 and it works fine both places. - Harald Hanche-Olsen Division of Mathematical Sciences hanche@imf.unit.no The Norwegian Institute of Technology hanche@norunit.bitnet N-7034 Trondheim-NTH NORWAY From apollo-request@umix.cc.umich.edu Sun Nov 5 01:18:55 1989 Date: 5 Nov 89 04:47:43 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: f77 -pg problems in sr10.1 Message-Id: <6121@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have a DN10000 running os 10.1.p, using BSD 4.3 as my environment. I have the 10.5(15) version of the fortran compiler, which was the one shipped with my system in September. When I try compiling code with the f77 -pg option (or -p) so that I can profile execution time with gprof, the compiler dies with a compiler error (stating "apollo specific fault". The apollo fortran crew couldn't duplicate the problem on their system. Has anybody else encountered this? The funny thing is that cc -pg works fine. R. T. Pierrehumbert University of Chicago, Geophysical Sciences. From apollo-request@umix.cc.umich.edu Sun Nov 5 01:21:20 1989 Date: 5 Nov 89 05:05:21 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: CAP on Apollo sr10.1 Message-Id: <6123@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I would like to get CAP (esp. lwsrv and aufs) running on my Apollo DN10000. Anybody have any experience with this? From apollo-request@umix.cc.umich.edu Sun Nov 5 01:23:20 1989 Date: 5 Nov 89 04:59:11 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: More f77 problems on DN10000 Message-Id: <6122@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Here are some more problems I am having with f77. I have a DN10000 running os 10.1.p, using BSD 4.3 as my environment. I have the 10.5(15) version of the fortran compiler, which was the one shipped with my system in September. First problem is huge executables. If I have, say, a 1000x1000 real array declared in a main program, this increases the size of the output of the binder (the executable) by 4megabytes! What's worse, local variables declared in subroutines do the same, additively. I have some 500 line fortran source code that turns into a 60 megabyte executable at the end. The .o files are normal size, though. Problem sets in at the binding stage. Apollo suggests using the -compress option, but this doesn't work. Anybody know what's going on? The second problem has to do with the optimizer not performing as advertised. It often doesn't substitute vector calls when it should, and it generates double precision code (like cc) for single precision variables. The following is the text of the problem report I sent to Apollo. Anybody have a workaround? All versions were compiled using f77 -O. f77 -W,"-opt 4" seems to behave the same. This version runs in 1.0 sec (=20 megaflops) program bench real*4 a(1000),b(1000),c(1000) real*4 temp1 do 1 i=1,1000 a(i)=1. b(i)=float(i) 1 c(i)=3. temp1=0. do 4 j=1,10000 c do 3 i=1,1000 c3 c(i)=a(i) + temp1*b(i) call vec_$mult_add(a,b,1000,temp1,c) 4 continue write(*,*) 'result is',temp1 end This version runs in 2.2 seconds: program bench real*4 a(1000),b(1000),c(1000) real*4 temp1 do 1 i=1,1000 a(i)=1. b(i)=float(i) 1 c(i)=3. temp1=0. do 4 j=1,10000 do 3 i=1,1000 3 c(i)=a(i) + temp1*b(i) c call vec_$mult_add(a,b,1000,temp1,c) 4 continue write(*,*) 'result is',temp1 end This version also runs in 2.2 seconds: program bench real*8 a(1000),b(1000),c(1000) real*8 temp1 do 1 i=1,1000 a(i)=1. b(i)=float(i) 1 c(i)=3. temp1=0. do 4 j=1,10000 do 3 i=1,1000 3 c(i)=a(i) + temp1*b(i) c call vec_$mult_add(a,b,1000,temp1,c) 4 continue write(*,*) 'result is',temp1 end ------------------------------------------------------------- Also, while we're at it, here are some dot product benchmarks: % more dotprod.f program dot real*4 a(1000),b(1000) real*4 temp do 1 i=1,1000 a(i)=1. 1 b(i)=2. c do 2 j=1,10000 temp=0. do 3 i=1,1000 3 temp=temp+a(i)*b(i) 2 continue write(*,*) "result is",temp end % !f f77 -W0,"-opt 4" dotprod.f -o dotprod dotprod.f: % !t time dotprod result is 2000.000 5.0u 0.0s 0:05 99% 0+0k 0+0io 0pf+0w (i.e. 4 megaflops) % more dotprod.f program dot real*4 a(1000),b(1000) real*4 temp do 1 i=1,1000 a(i)=1. 1 b(i)=2. c do 2 j=1,10000 temp=0. c do 3 i=1,1000 c3 temp=temp+a(i)*b(i) temp=vec_$dot(a,b,1000) 2 continue write(*,*) "result is",temp end % !f f77 -W0,"-opt 4" dotprod.f -o dotprod dotprod.f: **** Informational #929 on Line 9: Assignment eliminated, value never used: temp % !t time dotprod result is 2000.000 0.7u 0.0s 0:00 98% 0+0k 0+0io 1pf+0w (i.e. 28.6 megaflops) Perhaps the compiler is substituting double precision vector calls for the a(i)+temp*b(i) loop, but I don't think it is substituting any vector calls at all for the dot product. --Ray Pierrehumbert (rtp1@tank.uchicago.edu) From apollo-request@umix.cc.umich.edu Sun Nov 5 21:18:50 1989 Date: 5 Nov 89 17:48:49 GMT From: bhv%ddsw1%mcdchg.uucp@rutgers.edu (Bronis Vidugiris) Organization: ddsw1.MCS.COM Contributor, Mundelein, IL Subject: Re: I can trash 10.1, but why does it happen?? Message-Id: <1989Nov5.174849.7166@ddsw1.MCS.COM> References: <14403@well.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <14403@well.UUCP> rchrd@well.UUCP (Richard Friedman) writes: >An application program I am developing that runs on my >DN3000 with DOMAIN 10.1 has twice now trashed the system. >It somehow manages to destroy the pointers to the root directory, >so that when the application exits and you type anything at the >shell prompt, you get the frightening message: > /bin/ls: Not a directory >(when trying to do an ls command, say). > The problems I had of this general nature were on 9.7 rather than 10.1 - it turned out that I was overflowing the stack. However, I thought that this would be 'fixed' in 10.1. If you have the 'C' programming manual, I'd recommend checking it for stack size limits. I'm rather interested in the state of this serious OS limitation / bug. Under 9.7, interestingly enough, it turned out that remote processes would not (as far as I could tell) be affected by this bug. It's a good thing, too - imagine the havok that could be created by running a 'crash' program as a remote process, on somebody else's node. From apollo-request@umix.cc.umich.edu Tue Nov 7 01:57:46 1989 Date: 7 Nov 89 01:30:21 GMT From: jas%venera.isi.edu%usc%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Jeff Sullivan) Organization: USC-ISI Subject: Emacs for Apollo OS 9.7.5 Message-Id: <10432@venera.isi.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We just got an Apollo 3500, and are running only Aegis/DM on it. Can I get emacs to run on it? I ftp's it from prep.ai.mit.edu, but when I tied to run it, it said: Cannot open freeze file, running bare emacs... Warning: Lisp library (/gnuemacs/lisp) does not exist. emacs: cannot open termcap database file. Snappy replies always appreciated. -- -------------------------------------------------------------------------- Jeffrey A. Sullivan | Senior Systems Programmer jas@venera.isi.edu | Information Sciences Institute jas@isi.edu DELPHI: JSULLIVAN | University of Southern California From apollo-request@umix.cc.umich.edu Tue Nov 7 09:21:15 1989 Date: 6 Nov 89 17:51:13 GMT From: rchrd%well.uucp@hplabs.hp.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: Re: I can trash 10.1, but why does it happen?? Message-Id: <14446@well.UUCP> References: <14403@well.UUCP>, <1640@bruce.OZ> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Thanks to those who have reponded so far to my note about trashing 10.1 with a C application program. Once again it seems that stand-alone nodes are extremely prone to catastrophic failures. I would not recommend that anyone wanting a stand-alone UNIX workstation on their desk go out and buy an Apollo! I have not found the cause of the error yet, but am proceeding very cautiously. At some point I will try to recreate the problem while in the debugger, knowing full well that when I hit it it means a day's work to put everything back together again. The real question is, why doesnt Apollo have a disk-dump facility with a little bootstrap program so that I can save an image of my disk onto tape and reboot and not have to re-install OS everytime! -- /s/ rchrd <=> Richard Friedman <=> rchrd@well rchrd@well.sf.ca.us | {apple,pacbell,hplabs,ucbvax}!well!rchrd [Pacific-Sierra Research / Berkeley CA] (415) 540-5216 (The usual disclaimers apply - I speak only for myself!) From apollo-request@umix.cc.umich.edu Tue Nov 7 17:22:25 1989 Date: Tue, 7 Nov 89 16:06:51 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8911072106.AA09634@richter.mit.edu> To: apollo@umix.cc.umich.edu, rchrd%well.uucp@hplabs.hp.com Subject: Re: I can trash 10.1, but why does it happen?? Actually, it shouldn't be that hard to do ... the tape you boot the OS from after having trashed the disk is a simple rbak/wbak tape with a boot strapp block written to it. When you want to reboot the system, you type: DI C EX DOMAIN_OS and it loads the contents of the 1st backup file from the tape onto the disk and then starts the OS. I think you should be able to use the command: cpboot /sys -dev ct to copy the bootstrap file onto a tape and then use wbak -dev ct -f 1 -sysboot (or something like that) to backup your disk to the tape. I don't know if the bootstrap tape can span more than one physical volume, but if you simply copy the 1st file of the OS boot tape (and the bootstrape block) onto one tape and then use wbak to put the rest of the disk onto tape you should be ok. Simply use the bootstrape tape to load and start the OS, and then use rbak -dev ct -f 1 -du -force to read back the second tape you may need to use the -md option to avoid bashing the disk boot file). -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) ( I will admit that I have not tried this myself, since my disk hasn't been trashed -- yet) From apollo-request@umix.cc.umich.edu Tue Nov 7 19:17:46 1989 Message-Id: <8911072305.AA26806@unix.sri.com> Date: Tue, 7 Nov 89 14:47:43 PST From: ramu%tcipro.uucp@unix.sri.com (Ramu Iyer) To: apollo%umix.cc.umich.edu%sri-unix.uucp@unix.sri.com Subject: gcc (GNU C comiler) Has anyone ported the gcc to work on the Apollo under SR10.1? If so, please send me a message so that I may address my problem directly. Thanks in advance. --Ramu Email: ramu%tcipro.uucp@unix.sri.com (Internet) sri-unix!tcipro!ramu@uunet.uu.net (uucp via Internet) rutgers!sri-unix!tcipro!ramu (uucp) From apollo-request@umix.cc.umich.edu Wed Nov 8 13:36:57 1989 Date: 7 Nov 89 11:48:08 GMT From: sm%stc%stl%ukc%mcsun.uucp@uunet.uu.net (Simon Marchant) Organization: STC Telecomms, Harlow Technical Centre, Harlow Subject: Re: Mentor Graphics & DN2500 Message-Id: <1297@jura.tcom.stc.co.uk> References: <574@stdc01.UUCP>, <1292@jura.tcom.stc.co.uk>, <783@idacom.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I said it was a long time ago. I do however remember adding menus to neted using some kind of menu definition language that required compilation and adding to the neted startup files somewhere. Can anybody help with the name ? Sorry it's so vague but as I said, it was a looonnng time ago. From apollo-request@umix.cc.umich.edu Wed Nov 8 13:43:16 1989 Date: 7 Nov 89 19:07:19 GMT From: troym%amtfocus%mcdchg%mcdphx%asuvax.uucp@handies.ucar.edu (Troy Monaghen) Organization: Motorola Inc. GSG/AMT, Arlington Heights, Illinois Subject: Need sendmail (or other SMTP) for Apollo SR9.7 Message-Id: <227@amtfocus.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am in need of sendmail for an apollo running DOMAIN/IX SR9.7. Has anybody done the port? I have source for Sendmail 5.61 with Ida enhancements (that I have ported to a Motorola Delta series if anyone is interested). I know Apollo has sendmail for SR10, but the group that needs this is not ready to upgrade yet. Thanks in advance for any help. Troy -- Troy Monaghen, Motorola, Inc. chg.mcd.mot.com!amtfocus!troym General Systems Group - AMT "These are my own opinions and they may not reflect the opinions of Motorola, Inc." From apollo-request@umix.cc.umich.edu Thu Nov 9 03:21:25 1989 Date: 8 Nov 89 17:14:07 GMT From: srv%philabs%philmtl.uucp@uunet.uu.net (Sreeram Venkit) Organization: Philips Laboratories, Briarcliff Manor, NY Subject: Piced PMF to Postscript Message-Id: <67617@philabs.Philips.Com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am trying to convert a 'PicED MetaFile (PMF)' into a postscript file so that it can be printed on our available laser printer. The above PMF is an ascii file output from a Mentor Graphics software called PicED and is supposed to closely resemble postscript page description language. The file has to be preceded by a prologue that defines the PMF primitives in terms of postscript primitives. Has anybody done this? According to the PicED manual, the syntactic constructs, delimiters and escape sequences in PMF are identical to postscript. Given this how difficult would it be to write this prologue part? Any pointers, suggestions etc. will be greatly appreciated. I just happened to get involved in the above problem and normally don't read these newsgroups. So please send your replies to 'srv@philabs.philips.com' Thanks in advance. Sreeram (srv@philabs.philips.com) From apollo-request@umix.cc.umich.edu Thu Nov 9 03:23:14 1989 Date: 9 Nov 89 00:22:22 GMT From: gyp%ccadfa%csc%munnari.oz.au.uucp@uunet.uu.net (Patrick Tang Guan Yaw) Organization: Computer Centre, University College, UNSW, ADFA, Canberra, Australia Subject: vi in rlogin Message-Id: <633@ccadfa.adfa.oz.au> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have trouble getting vi to work properly under rlogin. I am running SR10.1 on a DN40000 node rlogin into a 10k node. The problem is that vi will display the file but does not allow you to move the cursor around, the cursor is at the bottom of the screen. I check the environment variables and everything seems to be ok, even stty tell me that it is at a correct speed. What have I done wrong? Thanks in advance. ---- Patrick Tang Guan Yaw, Phone : +61 62 68 8820 Dept. of Mathematics, EMAIL-ARPA/CSNET : gyp@ccadfa.cc.adfa.oz.au ADFA, Canberra, 2600. UUCP : ..!uunet!munnari!ccadfa.oz!gyp AUSTRALIA ACSnet : gyp@ccadfa.oz From apollo-request@umix.cc.umich.edu Thu Nov 9 07:19:02 1989 Date: 8 Nov 89 18:29:10 GMT From: srv%philabs%ttidca%quad1%srhqla%usc%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Sreeraman Venkitasubrahamanian) Organization: Philips Laboratories, Briarcliff Manor, NY Subject: PicED PMF to Postscript Message-Id: <67618@philabs.Philips.Com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am trying to convert a 'PicED MetaFile (PMF)' into a postscript file so that it can be printed on our available laser printer. The above PMF is an ascii file output from a Mentor Graphics software called PicED and is supposed to closely resemble postscript page description language. The file has to be preceded by a prologue that defines the PMF primitives in terms of postscript primitives. Has anybody done this? According to the PicED manual, "the syntactic constructs, delimiters and escape sequences in PMF are identical to postscript". Given this how difficult would it be to write this prologue part? The purpose is to print a mentor picture file on an unconnected laser printer. (We don't have the server for the Apollo). Is there is any other way of doing this? I know that the mentor software can output picture files in a format called TIF. Can this be converted to PS? Any pointers, suggestions etc. will be greatly appreciated. I just happened to get involved in the above problem and normally don't read these newsgroups. So please send your replies to 'srv@philabs.philips.com' Thanks in advance. Sreeram (srv@philabs.philips.com) From apollo-request@umix.cc.umich.edu Thu Nov 9 08:57:54 1989 Date: 6 Nov 89 15:51:00 GMT From: pcc%apollo.uucp@eddie.mit.edu (Peter Craine) Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA Subject: Re: script doesn't work in bsd4.2 mode Message-Id: <46ad248a.20b6d@apollo.HP.COM> References: <17780@watdragon.waterloo.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <17780@watdragon.waterloo.edu> dvadura@watdragon.waterloo.edu (Dennis Vadura) writes: >NODE: DN3500, BSD4.3 system, SR 10.1.1 > >Symptoms: Issue "script" command and all you get is -- > > Script started ...date... > script ended ...date... > > and the next prompt from the invoking shell. > Yep. There was a problem with pty's at sr10.1. fixed (i verified this, 'cause i entered the APR) at 10.2. Peter Craine, Cust Serv *I* don't want my opinions. Why would HPOLLO want them? From apollo-request@umix.cc.umich.edu Thu Nov 9 09:24:07 1989 Date: 7 Nov 89 18:11:07 GMT From: brianba%tekgvs%tekcrl%zephyr.ens.tek.com.uucp@uunet.uu.net (Brian Batson) Organization: Tektronix, Inc., Beaverton, OR. Subject: Anybody know what Apollo's upto here? Message-Id: <6312@tekgvs.LABS.TEK.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have recently acquired 5 Mentor Idea Stations. These are tied together over a token ring and have contact to the outside world via an ethernet bridge. MCG sold us Apollo's PCI (Personal Computer Interconnect) Host for the gateway machine but has left the purchase of the PCI Client SW for me to resolve with Apollo directly. It has been 4 months now and Apollo effectively refuses to sell the $495 package to me. On several occasions, they have requested that I give them my copy of the PCI Host. Sounds fishy and I am getting NOWHERE in dealing with Apollo. MCG just kinda doesn't really know what to do, kinda, maybe next week we'll help... Is this a SCAM or what? Anybody out there had similar dealings? I wonder if there isn't some deeper conflict going on between Mentor and Apollo or if the PCI package isn't really available. What's a poor boy to do? Brian Batson, speaking out in my own words, not those of my employer. -- Brian e. Batson Tektronix/T & M Group/MRI/DSP SPU UUCP: [uunet|ucbvax|decvax|ihnp4|hplabs]!tektronix!tekgvs!brianba ARPA: brianba%tekgvs.TEK.COM@RELAY.CS.NET CSNet: brianba@tekgvs.TEK.COM From apollo-request@umix.cc.umich.edu Thu Nov 9 09:27:49 1989 Date: 8 Nov 89 17:09:04 GMT From: oldfield%bnr-rsc%bigsur%bnr-fos%bnr-vpa%utzoo%utgpu%jarvis.csri.toronto.edu%mailrus.uucp@tut.cis (John Oldfield) Organization: Bell-Northern Research, Ottawa, Canada Subject: Background screen software Message-Id: <1349@bnr-rsc.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone have a solution to displaying a picture as a background screen on an Apollo running SR10? I have left small GIF pictures on a corner of my screen but this isn't a true background. Does anyone have s/w that traps background fills and substitutes a large picture? I would be interested in hearing how other people have tackled this problem and whether there is a true "hook" available in Domain for background display. Thanks, John Oldfield (oldfield@bnr-rsc) From apollo-request@umix.cc.umich.edu Thu Nov 9 09:41:03 1989 Date: 8 Nov 89 23:48:11 GMT From: rchrd%well.uucp@hplabs.hp.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: Re: I can trash 10.1, but why does it happen?? Message-Id: <14472@well.UUCP> References: <14403@well.UUCP>, <1989Nov5.174849.7166@ddsw1.MCS.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu It seems odd that overflowing the stack in a c routine would cause the // directory to be trashed... wouldnt stack problems just trash the process running the program but leave the rest of the system ok? The only possible thing that I can think of along these lines is that the program (under development and liable to dumb errors) called a routine with fewer (or more) than the number of arguments expected. Could such a thing bring down the whole system so that it required a re-install??? ouch. (Is APOLLO reading this?) -- /s/ rchrd <=> Richard Friedman <=> rchrd@well rchrd@well.sf.ca.us | {apple,pacbell,hplabs,ucbvax}!well!rchrd [Pacific-Sierra Research / Berkeley CA] (415) 540-5216 (The usual disclaimers apply - I speak only for myself!) From apollo-request@umix.cc.umich.edu Thu Nov 9 09:45:21 1989 Date: 7 Nov 89 21:35:13 GMT From: gyp%ccadfa%csc%munnari.oz.au.uucp@uunet.uu.net (patrick guan yaw tang) Organization: Computer Centre, University College, UNSW, ADFA, Canberra, Australia Subject: Performance Tools?? Message-Id: <618@ccadfa.adfa.oz.au> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am new to apollo machines. The department has a network of 14 nodes of which two are still under SR9.7, the rest are running SR10.1. The nodes are composed of a 10k, a DN580, a few 4000 and 3000. I am more used to operating under a true UNIX system (Sun and Pyramid). One of the problem I found is trying to benchmark machine performance. The tool dspst is not good enough as it only shows me the CPU usage. I like to know the page in/out activities, swapping, disk waits, network activities of a specify machines, something like vmstat in a true UNIX system (ps is not good enough either). So if you know of a tool that can supply my needs, I would be most appreciated if you could e-mail me the necessary information. Thanks in advance. ---- Patrick Tang Guan Yaw, Phone : +61 62 68 8820 Dept. of Mathematics, EMAIL-ARPA/CSNET : gyp@ccadfa.cc.adfa.oz.au ADFA, Canberra, 2600. UUCP : ..!uunet!munnari!ccadfa.oz!gyp AUSTRALIA ACSnet : gyp@ccadfa.oz From apollo-request@umix.cc.umich.edu Thu Nov 9 10:05:48 1989 Date: 8 Nov 89 18:22:59 GMT From: achille%cernvax%mcsun.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: bsd4.3 lpd bug ??? Message-Id: <1132@cernvax.UUCP> References: <8911072305.AA26806@unix.sri.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi there, we are trying to get lpd (bsd) running on two dn3500 to use them as servers for a couple of other Unix machines (SGI, Sun). I did it completely separately from one of my colleagues (who did the other dn3500) and we both came to the same point: 1) lbd is running 2) the server is running (tb shows it is in 'listen') 3) /dev/printer exists, is a pipe (AF_UNIX socket) and is locked (llkob shows it is in cowriters mode) 4) netstat -a shows that somebody (lpd) is listening on *.printer 5) lpr queues files and complains 'cannot start server' 6) lpc restart (or stop, start etc) always tells you 'cannot start server' (or cannot stop server etc.) Of course I checked the manual (admin bsd4.3), followed the suggestions and got nowhere. Same happened to my colleague. Configuration: bsd4.3, sr10.1, basic printcap file with a few mods to use different /com/prf options. One of the entries that do not work looks like: pawlp|line printer:\ :pc=/usr/apollo/bin/prf -banner off -text -npag -pr lw -headers off -s //geant -pre10:lp=/dev/null:\ :sd=/usr/spool/lpd/pawlp:if=/usr/lib/lpf:\ :af=/usr/adm/lpacct:lf=/usr/adm/lpd-errs:st=/usr/spool/lpd/pawlp/status:hl=true: Is there any reason why this setup refuses to work ? Am I forgetting something fundamental ? I looked on our Ultrix Vax and didn't spot anything different. Other people who've done that on site claim it just worked. Thank you, Achille Petrilli Cray and PWS operations P.s.: I've got the '-pre10' options on the prf line as the lpd host is sr10.1 but the apollo running the print queue isn't (sr9.7). From apollo-request@umix.cc.umich.edu Thu Nov 9 15:33:27 1989 Date: 9 Nov 89 18:04:26 GMT From: orand%kuhub.cc.ukans.edu%wuarchive%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (BRADY ORAND) Organization: University of Kansas Academic Computing Services Subject: Help with Apollo storage options. Message-Id: <17481@kuhub.cc.ukans.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I hope this is an easy question for someone out there to answer. We have a computer lab containing 16 Apollo DN4000 workstations. Four of these have Maxtor 348Meg drives on Opti 8 controller cards. Of these four, two of them have cartridge tape drives in them. We are trying to expand the storage capabilities of these machines. My goal is to: 1. Add 1.2 Meg floppy disk drives to four machines 2. Add two 700 Meg Hard drives 2. Possibly add 2 more cartridge tapes I want to be able to do this as economically as possible. When I ask Apollo about it, they tell me many things (some I even wanted to know) and show me big numbers. When I talk to third party sources, they tell me things I want to hear but I expected that since they have a vested interest in my business. What I want to know is: 1. Will the Opti 8 controller work with a 760 Meg Maxtor? 2. Can we add third party 1.2 Meg floppys to our Apollos? 2a. What kind of controllers do we need? 3. How feasible is it to add additional drives to the machines with controllers AND keep the ones we have? 3a. If it is not feasible, can we add drives to our workstations (as opposed to the servers) with a minimum of difficulty? 4. What cartridge tape drives are available for the 4000? (We currently have 40Meg drives using DC 300 XL/P tapes) 5. Who sells these products (other than Apollo)? Thanks a bunch for the help. I will be more than happy to summarize my findings on the net if there is enough interest. Brady... =========================================================================== Brady Orand - University of Kansas Computer Center Lawrence, Ks. 66045 ORAND@kuhub.cc.ukans.edu Work: (913) 864-0490 =========================================================================== From apollo-request@umix.cc.umich.edu Thu Nov 9 17:29:44 1989 From: van%tcipro.uucp@unix.sri.com Message-Id: <8911092006.AA20104@unix.sri.com> Date: Thu, 9 Nov 89 12:03:47 PST To: apollo%umix.cc.umich.edu%sri-unix.uucp@unix.sri.com Subject: [unix.sri.com!uunet.uu.net!gyp%ccadfa%csc%munnari.oz.au.uucp: vi in rlogin] > I have trouble getting vi to work properly under rlogin. > I am running SR10.1 on a DN40000 node rlogin into a 10k node. > > The problem is that vi will display the file but does > not allow you to move the cursor around, the cursor is > at the bottom of the screen. I check the environment > variables and everything seems to be ok, even stty > tell me that it is at a correct speed. What have I > done wrong? I've had simular problems with vi and emacs while using rlogin. These basic problems can be solved by invoking the vt100 emulator before doing an rlogin. Type 'vt100' to invoke the emulator. Unfortunately, sometimes upon exiting the editor (emacs in my case) the rlogin window will be dead (a problem that has been mentioned in past postings). I don't know if this will happen with vi or not. Hope this helps you out. --Van Henkle Thomson CSF, Inc./PRO Palo Alto, Ca van%tcipro.uucp@unix.sri.com From apollo-request@umix.cc.umich.edu Thu Nov 9 17:33:04 1989 Date: 8 Nov 89 22:43:05 GMT From: kdavis%grouch%nwnexus%sumax.uucp@beaver.cs.washington.edu (Karen Davis) Organization: Honeywell Inc., Marine Systems Division, Everett, WA Subject: 8mm tape systems Message-Id: <803@grouch.HYWLMSD.WA.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am currently investigating the various possibilites for 8mm tape systems on our Apollo network. I have talked to other Honeywell divisions and received differing opions as to the reliability of the Workstation Solutions' Exatape system. I would appreciate hearing from others who are using Workstation Solutions' Exatape, Apollo's Omnibak, or any other manufacturer's tape systems regarding their experiences good or bad. Karen Davis Apollo System Administrator Honewell MSD Everett, WA From apollo-request@umix.cc.umich.edu Thu Nov 9 19:20:10 1989 Date: 9 Nov 89 22:04:34 GMT From: gwh%typhoon.Berkeley.EDU%agate.uucp@apple.com (George William Herbert) Organization: ucb Subject: The CASE posting Message-Id: <1989Nov9.220434.2695@agate.berkeley.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu There is internet policy against advertising. I think that the positing may have been a violation... -george From apollo-request@umix.cc.umich.edu Thu Nov 9 19:32:23 1989 Date: 9 Nov 89 21:05:00 GMT From: dawson%apollo%hp-sdd.uucp@hplabs.hp.com (Keith Dawson) Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA Subject: Re: Background screen software Message-Id: <46bd533a.c4b0@apollo.HP.COM> References: <1349@bnr-rsc.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu There is no supported way to get a picture truly in the background (on the root rectangle) while the Display Manager owns the root. You can run Domain/X11 in the X-owns-root mode, however; now you can put any picture desired on the root rectangle. The MIT-supplied client program xsetroot lets you tile the root rectangle with any given color, pattern, or bitmap. This client is available with all versions of Domain/X11. A public-domain version of GIF for X11, called xgif, has an option whereby it draws a GIF image in the root rectangle and keeps it properly refreshed on exposures, etc. Here at Apollo we run a modified version of xsetroot that supports GIF format directly by command-line option, so it is the X server that keeps the root rectangle refreshed, not a client program -- much more efficient. -->Keith ____________________________________________________________ My opinions Keith Dawson Hewlett Packard Co. 508-256-0176 x5739 are my own. Graphics Technology Division / East 300 Apollo Dr. (CHR.03.DE) Chelmsford, MA 01824 USA My convictions Internet: dawson@apollo.hp.com are not for UUCP: {mit-eddie,yale,uw-beaver}!apollo!dawson public display. From apollo-request@umix.cc.umich.edu Thu Nov 9 21:21:39 1989 Date: Thu, 9 Nov 89 15:36:20 HST From: kent@humu.nosc.mil (Kent K. Kuriyama) Message-Id: <8911100136.AA05332@humu.nosc.mil> To: apollo@umix.cc.umich.edu Subject: Poor performance of SR10.1 on 590's We have recently installed 10.1 (AEGIS and BSD) on a DN590-T that was previously running 9.7. The system has 8MB of RAM and a 348 MB drive. The system's response to simple commands like 'ls' and 'cd' is exasperatingly slow at times. Apollo says they are aware of the problem but don't have a solution yet. The problem seems to be confined to DN570-590 series machines as our DN3500 has no problems with 10.1. Anybody else experience this same problem? Kent Kuriyama Voice (808) 257-1618 Naval Ocean Systems Center FAX (808) 257-5231 Hawaii Laboratory Box 997, Code 531 kent@nosc.mil Kailua, HI 96734 From apollo-request@umix.cc.umich.edu Fri Nov 10 05:19:42 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8911100928.AA00509@icaen.uiowa.edu> Date: Fri, 10 Nov 89 03:20:23 CST Subject: Re: Performance Tools?? To: gyp%ccadfa%csc%munnari.oz.au.uucp@uunet.uu.net, apollo@umix.cc.umich.edu WRT posting <618@ccadfa.adfa.oz.au>: > I like to know the page in/out activities, swapping, disk waits, > network activities of a specify machines, something like vmstat in > a true UNIX system (ps is not good enough either). "/com/pst -pa" will show you some paging info on a per-process basis. If you want "vmstat" though, there is an Apollo implementation of it under sr10.1. It's hidden in a funny place, look in "/systest/ssr_util" ( "/systest/ssr_util/vmstat" "/systest/ssr_util/vmstat.hlp" ). There are several other interesting tools in that directory, but be forewarned, they are unsupported and some of them can be dangerous if improperly used. Dave Funk From apollo-request@umix.cc.umich.edu Fri Nov 10 07:14:41 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8911101022.AA00512@icaen.uiowa.edu> Date: Fri, 10 Nov 89 03:36:38 CST Subject: Re: bsd4.3 lpd bug ??? To: achille%cernvax%mcsun.uucp@uunet.uu.net Cc: apollo@umix.cc.umich.edu WRT your posting <1132@cernvax.UUCP>: > we are trying to get lpd (bsd) running on two dn3500 to use them as servers for > a couple of other Unix machines (SGI, Sun). > I did it completely separately from one of my colleagues (who did the > other dn3500) and we both came to the same point: > 1) lbd is running By this did you mean that "/usr/lib/lpd" is running or did you mean that "/etc/ncs/llbd" is running? You need them BOTH for the bsd lpd printing system to work. The Apollo sr10.1 implementation of bsd "/usr/lib/lpd" uses NCS for server communications. Thus you must have "llbd" running on the node for "lpd" to register when it starts. > 2) the server is running (tb shows it is in 'listen') I did a traceback on my "llbd" & "lpd" and both of them were in a 'select'. Is this what you mean by 'listen'? # traceback of "lpd": $ tb 111 In routine system service "ec2_$wait" Called from "ec2_$wait_svc" line 164 Called from "select" line 170 Called from "main" line 285 Called from "unix_$main" line 114 Called from "_start" line 51 Called from "PM_$CALL" line 173 ... > 3) /dev/printer exists, is a pipe (AF_UNIX socket) and is > locked (llkob shows it is in cowriters mode) > 4) netstat -a shows that somebody (lpd) is listening on > *.printer These are as they should be for lpd printing to work. This looks OK. > 5) lpr queues files and complains 'cannot start server' > 6) lpc restart (or stop, start etc) always tells you > 'cannot start server' (or cannot stop server etc.) These sound like a communications (NCS) problem, "lpr" uses NCS to talk to "lpd". Use "/etc/ncs/lb_admin" to check the local location broker on the "lpd" node to see if it has registered. You should see something like: $ /etc/ncs/lb_admin lb_admin: set_broker local dds://ece2 lb_admin: lookup * * * ------------ object = * type = * interface = bsd4.3_lpd "BSD4.3 lpd" @ dds://ece2[241] ------------ One other possible unusual problem: the IP hostname must be the same as the DDS node name. IE "/etc/hostname" must give the same name as the name that the node's disk is cataloged with. If you use the standard Apollo supplied "rc" files then this will be the case. If you've modified the "rc.local" to register a different hostname at startup then you may have problems. This is because "lpd" registers with the "dds" NCS address family and "lpr" assumes that it can take the IP hostname to get the DDS hostname for socket address lookup. So the bottom line is: you need to be able to take the IP hostname as reported by "/etc/hostname" (on the "lpd" node) and have it work as a DDS name for that node ("//node-name"). I ran into this problem when setting up our printers as we use a 4 part internet domain name for our nodes. IE /etc/hostame = "ece2.icaen.uiowa.edu" on my lpd node so I had to register 2 names in "edns" for that node, "//ece2" "//ece2.icaen.uiowa.edu" to make the lpd stuff work. Until I figured that out, I had exactly the same problems that you have. Your "/etc/printcap" entry looks OK. Dave Funk BTW to make our nodes load the multi-component host name at boot time, I modified "rc.user" in the following way: 1) create a file "/etc/hosts.domain" with the domain name suffix in it (EG "icaen.uiowa.edu") and put a copy on all nodes. 2) catalog the node's disk with the first component of the hostname (as you would if you were just using simple names) 3) put the folllowing lines in "rc.local" before the start of "tcpd": # LOCAL modification: add ability to put domain name in hostname # if [ -f /etc/hostname -a -f /etc/hosts.domain ]; then my_host=`/etc/hostname`.`cat /etc/hosts.domain` /etc/hostname $my_host fi # From apollo-request@umix.cc.umich.edu Fri Nov 10 11:22:48 1989 Date: 10 Nov 89 15:38:31 GMT From: herky.cs.uiowa.edu%ns-mx.uucp@uunet.uu.net (Charlie McGuire,6 MLH,3352730,,) Subject: Re: bsd4.3 lpd bug ??? Message-Id: <173@ns-mx.uiowa.edu> References: <8911101022.AA00512@icaen.uiowa.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <8911101022.AA00512@icaen.uiowa.edu>, by dbfunk@ICAEN.UIOWA.EDU (David B Funk): Followup to lpd bug ... > WRT your posting <1132@cernvax.UUCP>: >> we are trying to get lpd (bsd) running on two dn3500 to use them as servers for >> a couple of other Unix machines (SGI, Sun). >> I did it completely separately from one of my colleagues (who did the >> other dn3500) and we both came to the same point: > . > >> 5) lpr queues files and complains 'cannot start server' >> 6) lpc restart (or stop, start etc) always tells you >> 'cannot start server' (or cannot stop server etc.) > These sound like a communications (NCS) problem, "lpr" uses NCS to > talk to "lpd". Use "/etc/ncs/lb_admin" to check the local location broker > on the "lpd" node to see if it has registered. . . . If you are trying to run only one lpd daemon on your network with linked spool directories, then you must also make sure the Domain "prmgr" is running on the same node as lpd. You must also create the file /usr/spool/lpd/servername that contains the hostid of the node running lpd. If you are using 4-level IP hostnames, then this is the name that should appear here. (see below) I run my network print services this way with only one lpd daemon running. All other nodes link to the entire /usr/spool tree on this one machine. NCS uses the hostid in the servername file to "wake up" the lpd daemon. > One other possible unusual problem: the IP hostname must be the same as > the DDS node name. IE "/etc/hostname" must give the same name as the name > that the node's disk is cataloged with. . . . This is true. I had the same problem and Dave helped me straighten it out. The BSD stuff is distinct from the "dds" stuff. > Your "/etc/printcap" entry looks OK. I agree. The lp=/dev/null: line is ok also. . . . > Dave Funk -------------------------------------- Charlie McGuire Systems Programmer Computer Science Dept. The University of Iowa E-Mail: mcguire@cs.uiowa.edu mcguire@math.uiowa.edu -------------------------------------- From apollo-request@umix.cc.umich.edu Fri Nov 10 12:18:00 1989 Date: 9 Nov 89 13:04:11 GMT From: sani%wmt%hp4nl%mcsun.uucp@uunet.uu.net (Sandor Nieuwenhuijs) Subject: CASE on Apollo hardware Message-Id: <388@wmt.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu ----------------------------------------------------------------- ANNOUNCEMENT ----------------------------------------------------------------- WESTMOUNT TECHNOLOGY, one of the leading CASE tool vendors announces the availability of its CASE products on the Apollo product lines. Major features are: - Complete generation of SQL and 4GL - Stores information in Ingres or Informix - Full X-windows (X11) graphical interface ----------------------------------------------------------------- DESCRIPTION ----------------------------------------------------------------- The modularity of the CASE workbenches offers you the ability to automate each development phase depending on your organization's requirements. Westmount's CASE products thus provide a growth path to a truly automated, integrated CASE development environ- ment. Since the end of 1988 Westmount offers three major CASE product lines: - ISEE/CASE - RTEE/CASE - TSEE/CASE ----------------------------------------------------------------- ISEE/CASE ----------------------------------------------------------------- ISEE/CASE is an integrated software development environment which supports the analysis, design, implementation, testing and maintenance of information systems. The generic version can gen- erate code for any Ansi SQL-based RDBMS. A special version of ISEE/CASE is ISEE/CASE-Ingres, which specializes in using the 4GL code generation for this well known RDBMS. ISEE/CASE fully sup- ports Yourdon/DeMarco, Jackson, Constantine and Chen Structured Analysis/Structured Design (SA/SD) methods. It includes: - ISEE/CASE-Analyst The Analyst workbench offers all the tools needed in the Analysis phase of the development of an information system, including: + Data Flow Editor + Data Structure Editor + Entity Relationship Editor - ISEE/CASE-Designer The Designer workbench offers all the tools needed in the Design phase of the development of an information system, including: + Structure Chart Editor + Entity Relationship Editor + Data Structure Editor + State Transition Editor - ISEE/CASE-Ingres-Programmer The ISEE/CASE-Ingres-Programmer environment establishes complete integration between Westmount's graphical Design workbench and the full INGRES fourth generation application development en- vironment. Using the ISEE/INGRES-Programmer together with INGRES database networking facilities, integrated system development is possible in a multi-user, distributed environment. Each of these workbenches may be used as a stand-alone environ- ment, dealing only with a single stage of the development process or together as one integrated environment. ----------------------------------------------------------------- TSEE/CASE ----------------------------------------------------------------- TSEE/CASE is an integrated software development environment which supports the analysis, design, implementation, testing and maintenance of technical systems, like CAD/CAM systems, operating system software and various tools. This type of development pro- cess, which may incorporate aspects also found in real-time sys- tems, requires special development methods and techniques. In the TSEE/CASE family there are three workbenches: - TSEE/CASE-Analyst The TSEE/Analyst workbench offers a comprehensive set of in- tegrated tools necessary for the structured analysis of technical systems applications. For building the Essential Model the fol- lowing editors are available: + Control Flow Editor + Data Structure Editor + Entity Relationship Editor + State Transition Editor - TSEE/CASE-Designer The TSEE/CASE-Designer workbench offers a comprehensive set of integrated tools necessary for the structured design of technical systems applications. For building the Implementation Model the following editors are available: + Data Structure Editor + Structure Chart Editor + Entity relationship Editor - TSEE/CASE-Programmer TSEE/CASE-Programmer provides a flexible programming support en- vironment which allows engineers to develop high-quality, multi- tasking technical applications. TSEE/CASE-Programmer allows the integration of cross-development tools and debuggers. Each of these workbenches may be used as a stand-alone environ- ment, dealing only with a single stage of the development process or together as one integrated environment. ----------------------------------------------------------------- RTEE/CASE ----------------------------------------------------------------- RTEE/CASE is an integrated software development environment which supports the analysis, design, implementation, testing and maintenance of real-time embedded systems. RTEE/CASE is the first CASE tool which supports a COMPLETE Ward/Mellor implementation. In the RTEE/CASE family there are four workbenches: - RTEE/CASE-Analyst The RTEE/Analyst workbench offers a comprehensive set of in- tegrated tools necessary for the structured analysis of real-time systems applications. For building the Essential Model the fol- lowing editors are available: + Control Flow Editor + Data Structure Editor + Entity Relationship Editor + State Transition Editor - RTEE/CASE-Designer The RTEE/CASE-Designer workbench offers a comprehensive set of integrated tools necessary for the structured design of real-time systems applications. For building the Implementation Model the following editors are available: + Data Structure Editor + Structure Chart Editor + Entity relationship Editor - RTEE/CASE-Programmer RTEE/CASE-Programmer provides a flexible programming support en- vironment which allows engineers to develop high-quality, multi- tasking real-time applications. RTEE/CASE-Programmer allows the integration of cross-development tools such as system builders, debuggers and system monitors as well as tools for downloading and generation of embedded systems. - RTEE/CASE-VRTX-Programmer RTEE/CASE-VRTX-Programmer provides a flexible programming support environment which allows engineers to develop high-quality, mul- titasking real-time applications dedicated to Ready System's VRTX32. RTEE/CASE-VRTX-Programmer consists of a integerated sys- tem builder (RTbuild), symbolic multi-tasking debugger (RTtask), system monitor (RTsystem) and virtual terminal connection (RTcon- nect), all dedicated to VRTX32. Each of these workbenches may be used as a stand-alone environ- ment, dealing only with a single stage of the development process or together as one integrated environment. ----------------------------------------------------------------- The Project Database ----------------------------------------------------------------- Integration of the workbenches is achieved by a common Project Database where all development information on a particular appli- cation is collected. This means that the information gathered in the analysis stage is directly available to the subsequent stages in the software development lifecycle. The Project Database (PDB) is built upon a standard relational database management system (Ingres). The PDB allows the integration of the work- benches and of the project-related information. The PDB is a single reference point where all information about a project is gathered. Information is only recorded once, ensuring the con- sistency and completeness of the data in the PDB. Users are always working with consistent and up-to-date informa- tion which saves time and increases their productivity. The analysis information gathered with the Analyst is directly avail- able for use with the Designer and the Programmer tools. Eventu- ally, the data in the PDB will contain a complete and consistent description of the required application. All the editors contain commands for storing diagrams and related data for the PDB and for retrieving definitions of the identifiers related to objects. >From the editors updates can be made of the PDB as well as view- ing the contents of the PDB. ----------------------------------------------------------------- The Desk ----------------------------------------------------------------- The desk is a window in which projects and systems will be displayed. The information which is displayed comes from cor- porate database and project database. Desk is the starting point for all development activities on a particular project. The user first selects a project to work on before activating one of the workbenches. At the Desk level projects and systems within projects are creat- ed and defined. Project-related organisational activities can be executed by the responsible Project Manager on three levels: Cor- porate, Project and User. For example, the project manager can restrict the permission to execute activities on a certain level of organisation to specific users for security purposes. ----------------------------------------------------------------- Multi-user ability ----------------------------------------------------------------- The CASE workbenches are most likely used by project teams con- sisting of multiple members. When working in project teams, data produced by one developer may be of importance for other team members. Very often a developer will want to use already exist- ing information sometimes even from sources outside the project. An essential requirement therefore is that members of a project team can at all times share all development information. The CASE workbenches allow handling of larger projects. Both the Project Database and the Corporate Database can be implemented on the da- tabase server of a network whereas the workbenches are running on graphical workstations. ----------------------------------------------------------------- The Graphical Editors ----------------------------------------------------------------- All the graphical editors support a stage of the development pro- cess which results in a set of diagrams. The user interfaces of the graphical editors provide a consistent and uniform look-and- feel, making them easy to use and helping to shorten learning time. As each editor uses a separate window, users may work simultaneously on the different type of editors. In this way dif- ferent aspects of a project can be displayed side by side on the screen. The graphical editors offer the possibility to draw and modify diagrams, to insert and change text and to check the resulting models for consistency and syntactical correctness. Anyone who is interested in more information on Westmount's CASE products can contact the corresponding product manager: Onno Schipperus (hp4nl!wmt!onsc) for ISEE/CASE or Sandor Nieuwenhuijs (hp4nl!wmt!sani) for RTEE/CASE and TSEE/CASE or contact us via normal mail: Westmount Technology B.V. attn. O. Schipperus/S. Nieuwenhuijs Poortweg 8 2612 PA DELFT The Netherlands telephone: INTL. (31) 15610815 fax : INTL. (31) 15565701 -- Sandor Nieuwenhuijs | E-mail: sani@wmt.uucp Westmount Technology B.V. | Phone: +31 15 610815 Poortweg 8, 2612 PA Delft | Fax: +31 15 565701 The Netherlands |---------------------------- From apollo-request@umix.cc.umich.edu Fri Nov 10 13:04:55 1989 Date: 9 Nov 89 21:18:00 GMT From: keil%apollo.uucp@EDDIE.MIT.EDU (Mark Keil) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: Piced PMF to Postscript Message-Id: <46bd5f27.20b6d@apollo.HP.COM> References: <67617@philabs.Philips.Com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <67617@philabs.Philips.Com> srv@philabs.philips.com (Sreeram Venkit) writes: > > I am trying to convert a 'PicED MetaFile (PMF)' into a postscript file > so that it can be printed on our available laser printer. The above PMF > is an ascii file output from a Mentor Graphics software called PicED > and is supposed to closely resemble postscript page description language. > The file has to be preceded by a prologue that defines the PMF primitives > in terms of postscript primitives. Has anybody done this? > > According to the PicED manual, the syntactic constructs, delimiters > and escape sequences in PMF are identical to postscript. Given this > how difficult would it be to write this prologue part? > > Any pointers, suggestions etc. will be greatly appreciated. I just happened > to get involved in the above problem and normally don't read these > newsgroups. So please send your replies to 'srv@philabs.philips.com' > > Thanks in advance. > > Sreeram > (srv@philabs.philips.com) I have not used PicED, but I have used neted, so what I suggest is based on outputting neted sheets to postscript. If you have & run the laser plot/printer server, set up another plot server process in offline postscript mode. Set it up to print to some fake device name. Then plot (or print) to the new pseudo device. The output will be to a file which will sit there. You can then look in that file, and get the prolog that is prepended to the output. That may well work right off. If nothing else, it should get you closer to what you want. Below is the config file (mpa.config) that I use for an A size pseudo printer. I call the printer mpa (for mentor pseudo A) To plot Neted sheets, I say something like: plot -pr mpa circut I then look for xpa.test.fcaa.0.userid.circut.sheet1 in /sys/print # MENTOR A size postscript print server config file DEVICE POSTSCRIPT INTERFACE OFFLINE PRINTER_NAME MPA FILE_BANNERS ON MODEL_NUMBER generic_ps PAPER letter OUTPUT_PREFIX xpa.test # Following parameters are applicable to 'language printer' files: BOTTOM_MARGIN 0 FORM_LENGTH 66 FORM_WIDTH 80 LEFT_MARGIN 0 PAGE_HEADERS OFF TOP_MARGIN 0 I hope that this helps, Mark Mark Keil Apollo Computer, Chelmsford MA 01824 +1 508-256-6600 x2495 keil@apollo.com / {decvax,mit-erl,yale}!apollo!keil From apollo-request@umix.cc.umich.edu Fri Nov 10 13:29:32 1989 Date: 9 Nov 89 19:41:16 GMT From: mort%dhump%marque%uwm.edu%wuarchive%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Mort d`Hump) Organization: Nubeat Communications, Milwaukee, WI Subject: Connecting a Terminal to DN3500 Message-Id: <489@dhump.lakesys.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am attempting to get a terminal going on a sio port on a DN3500 running SR10.1. I have two problems: 1) I can't get the terminal to talk at any faster than 1200bd. 2) When I try to use vi, the system responds with "I don't know enough about your terminal" & sends a bunch of escape sequences to the screen, then proceeds to log me out. The terminal is a Kemtron KT-7 & it does ansi. I have also used XTALK on a PC with the same results for both ansi & vt100. XTALK works fine with a dialup UNIX system I have an account on. TERM is set in /etc/ttys for the sio port. I have also set the TERM variable from the shell with the same results... What am I missing?? Wishing SR10.1 was *real* UNIX..... -- Marty Wiedmeyer mort@dhump.lakesys.COM From apollo-request@umix.cc.umich.edu Fri Nov 10 13:39:15 1989 Date: 10 Nov 89 12:56:19 GMT From: sani%wmt%hp4nl%mcsun.uucp@uunet.uu.net (Sandor Nieuwenhuijs) Subject: CASE, apology Message-Id: <392@wmt.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu After my posting of a news item in a few newsgroups, I have had a rather insulting reaction. It seems that the comp.sys.* newsgroups are not meant for commercial product announcements, although I have seen more than once that companies use it for this purpose. Maybe this reaction had to do with the first line: "WESTMOUNT TECHNOLOGY, one of the leading CASE tool vendors" which is probably not very modest. Maybe it was because of the length of the message, it seems that I should have posted a short message in the comp.sys.* newsgroups with a reference to comp.newprod. I'll remember that. We wanted to let specific users know about the availability of professional CASE tools on their platforms. According to a few reactions I already had, most users like to get this kind of information. If I offended anyone I am truly sorry. -- Sandor Nieuwenhuijs | E-mail: sani@wmt.uucp Westmount Technology B.V. | Phone: +31 15 610815 Poortweg 8, 2612 PA Delft | Fax: +31 15 565701 The Netherlands |---------------------------- From apollo-request@umix.cc.umich.edu Fri Nov 10 13:41:14 1989 Date: 10 Nov 89 01:17:19 GMT From: lori%hacgate%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%gem.mps.ohio-state.edu.uucp@tut.cis (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: CASE on Apollo hardware Message-Id: <6036@hacgate.UUCP> References: <388@wmt.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Um, try comp.newprod next time. You can put a tickler in comp.sys.apollo that says "look there," but you can't advertise here. This forum is strictly for criticising products. ;-) ...lori From apollo-request@umix.cc.umich.edu Fri Nov 10 17:20:27 1989 Date: 10 Nov 89 18:07:41 GMT From: lau%kings.wharton.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@handies.ucar.edu (Yan K. Lau) Organization: A Private Heaven Subject: HP Laserjet driver needed for SR10.1 Message-Id: <16746@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone have a driver source code for HP Laserjet printers connected to the SPE parallel port that runs under SR10.1? It seems that things have change much with the new prmgr. Any speculation on when Apollo will begin to support HP printers? Thanks much. Yan. )~ Yan K. Lau lau@kings.wharton.upenn.edu The Wharton School ~/~ 128.91.11.233 University of Pennsylvania /\ Darker grows the moon And shadows steal across the prison of my room From apollo-request@umix.cc.umich.edu Fri Nov 10 17:41:11 1989 Date: 9 Nov 89 19:28:50 GMT From: ray3rd%ssc-vax%fluke.uucp@beaver.cs.washington.edu (Ray E. Saddler III) Organization: Boeing Aerospace & Electronics, Seattle WA Subject: Re: bsd4.3 lpd bug ??? Message-Id: <2970@ssc-vax.UUCP> References: <8911072305.AA26806@unix.sri.com>, <1132@cernvax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1132@cernvax.UUCP>, achille@cernvax.UUCP (achille petrilli) says: ? ? [lead-in stuff deleted] ? ? 6) lpc restart (or stop, start etc) always tells you ? 'cannot start server' (or cannot stop server etc.) ? ? One of the entries that do not work looks like: ? ? pawlp|line printer:\ ? :pc=/usr/apollo/bin/prf -banner off -text -npag -pr lw -headers off -s //geant -pre10:lp=/dev/null:\ ^^^^^^^^^ Oooohhhh! I *do* believe this is your problem; since /com/prf spools out to /sys/print/spooler, and uses an sio port defined elsewhere, you're not required to specify an output device (lp=). SO, simply define 'lp like this: :lp=: I'll bet this'll work, it's happened to me before on Apollo, Sun & Cimlinc boxes. ? ? Thank you, ? Achille Petrilli ? Cray and PWS operations ? You're welcome, -- Ray E. Saddler III UseNet ___ ___ ___ ___ ___ CAD System/Network Admin uw-beaver!ssc-vax!ray3rd /__// //__ / /\ // _ P.O. Box 3999 m.s. 3R-05 PhoneNet /__//__//__ _/_ / //__/ Seattle, WA. 98124 USA +1 206-657-2824 Missile Systems Division From apollo-request@umix.cc.umich.edu Fri Nov 10 19:16:12 1989 Date: 10 Nov 89 15:00:57 GMT From: jaa%frank%philabs%philmtl.uucp@uunet.uu.net (Joseph M. Amato) Organization: Philips Laboratories, Briarcliff Manor, NY Subject: Re: Poor performance of SR10.1 on 590's Message-Id: <67798@philabs.Philips.Com> References: <8911100136.AA05332@humu.nosc.mil> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8911100136.AA05332@humu.nosc.mil> kent@HUMU.NOSC.MIL (Kent K. Kuriyama) writes: >We have recently installed 10.1 (AEGIS and BSD) on a DN590-T that >was previously running 9.7. The system has 8MB of RAM and a 348 >MB drive. The system's response to simple commands like 'ls' and >'cd' is exasperatingly slow at times. Apollo says they are aware >of the problem but don't have a solution yet. The problem seems >to be confined to DN570-590 series machines as our DN3500 has no >problems with 10.1. > > >Anybody else experience this same problem? And how. 570-T running very slow. Apollo or Mentor Graphics (I can't remember which) claims the 570-T machine is as fast if not faster than a 3000. DON'T YOU BELIEVE IT. Our 3000 has always been faster. (both run with 8Mb) Joe Amato jaa@philabs.philips.com | Some say "life is not worth living." | ...many have a wish to die. My company's views | I wonder, may differ | will they then say "death is not worth dying?" From apollo-request@umix.cc.umich.edu Sat Nov 11 15:18:53 1989 Date: Sat, 11 Nov 89 12:19:04 CST From: lray@civilgate.ce.uiuc.edu (Leland Ray) Message-Id: <8911111819.AA02201@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: getty problem at sr10.1 It all started when I moved the node to SR10.1. Until that time, it had been a well behaved DN4000. Connected to the node were two serial lines, both connecting to PCs in nearby offices. Several days after the node was converted, the owner began to complain. The node was slow, so she told me, and the disk was quickly filling up. Upon checking the node, I noticed that there was no free disk space, and both gettys were in an infinite loop. Rebooting the node recovered 70M in disk space. "Gee," said I, "this looks like a problem with the OS. Perhaps the 800 number could help me out." A call to the 800 number failed to resolve the problem. It seems nobody at Apollo had a problem with runaway gettys. The only possible suggestion was that I'd created the login_log file and that was growing without bounds. Of course, if it was a real file, rebooting the node would not recover that space -- I'd simply find a huge object on the disk I could delete. Well, if getty doesn't work, perhaps dropping back on the old way -- the SR9 way -- would solve the problem. siomonit came up easily, and did not destroy the cpu or the disk as did getty. However, it did create many processes called "level2" and fill up the process table, prohibiting any use of the node until reboot. So it seems I was stuck with getty. The next thing I did was to take advantage of the fact that my university is blessed with a Unix source license. I got the source to getty and spent a long time looking at it. I decided that the best way to tackle the problem would be to port the code to SR10.1 and use syslog calls to log significant program events. And this is what showed me the problem. It seems that the serial lines, for as yet unknown reasons, were flooding the line with large numbers of garbage characters. Most of them were ^? (Ascii 0xff) with a few o's (Ascii 0x7f) thrown in for good measure. What was happening was this: getty takes is the input of the login name only as many characters as are allowed, and after that, it terminates and passes the string to login even if the user never presses a return key. The Apollo serial drivers terminate the process silently after 255 characters (try holding down a repeating character while logged into an Apollo's serial line), which init faithfully notices and calls up another getty. The time spent in initializing the line, getting the environment, looking it up in gettytab, etc. while bogus characters are being dropped in the line takes up 99% of a DN4000. The fix I've made to my local copy of getty is the following: If the length of the login name exceeds the maxmimum number of permissible characters, drop all additional characters on the floor except the erase character, the kill character, and the EOF character. The loop of getty that reads in incoming characters and drops them takes up at most 2% of the DN4000's time. All told, here are my thoughts regarding this problem: 1. The Unix community (as this is a general Unix bug, and not an Apollo specific one) should modify more programs like getty to give debug output so these kind of problems can be tracked without having access to the source. 2. I've reported the serial line 256th character dropout problem to Apollo, and I'm told it will be "fixed in a future software release." 3. The problem with the process table filling up with level2's is a serious one, and should be fixed. I suspect this is incomplete process death, however, I don't know enough about it to precisely duplicate it. In addition, the DN10000 (SR10.1.p) also seems to accumulate level2's. -------------------------------------------------------------------------------- -- Just spendin' my days, Leland Ray Systems Administrator Soakin' in them cathode rays. UIUC - Dept. Civil Engineering (217) 333-3821 From apollo-request@umix.cc.umich.edu Sun Nov 12 07:13:32 1989 Date: 12 Nov 89 08:56:24 GMT From: jwright%atanasoff%sharkey%mailrus%hellgate.utah.edu%helios.ee.lbl.gov%agate.uucp@ucbvax.Berkeley (Jim Wright) Organization: Iowa State U. Computer Science Department, Ames, IA Subject: Re: getty problem at sr10.1 Message-Id: <1927@atanasoff.cs.iastate.edu> References: <8911111819.AA02201@civilgate.ce.uiuc.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu lray@CIVILGATE.CE.UIUC.EDU (Leland Ray) writes: | 1. The Unix community (as this is a general Unix bug, and not an Apollo | specific one) should modify more programs like getty to give debug output | so | these kind of problems can be tracked without having access to the source. Yeah, let's start by putting a debug mode into sendmail. -- Jim Wright jwright@atanasoff.cs.iastate.edu From apollo-request@umix.cc.umich.edu Sun Nov 12 11:16:57 1989 Date: 12 Nov 89 14:24:00 GMT From: oj%apollo.uucp@eddie.mit.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Performance Tools?? Message-Id: <46cb0390.20b6d@apollo.HP.COM> References: <8911100928.AA00509@icaen.uiowa.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8911100928.AA00509@icaen.uiowa.edu> dbfunk@ICAEN.UIOWA.EDU (David B Funk) writes: >... a funny place, look in "/systest/ssr_util"... >There are several other interesting tools in that directory... * To look at your system (hardware) error log, try /systest/ssr_util/lsyserr ... * As of sr10.1.p (DN10K) and/or sr10.2 (m68k and DN10K) try /systest/ssr_util/color_probe [-rgb] [-b] -rgb makes it show a true-color color map on VS systems -b makes it run in borrow mode. You can use the mouse to point to colors. If you press a mouse key, it'll flash the color you're pointing to. Left=red, middle=green, right=blue . * On the DN10000VS there's an "interactive mouse diagnostic" :-) /systest/ssr_util/bzone_vs Have fun. >but be forewarned, they are unsupported and some of them can be dangerous >if improperly used. I couldn't have said it better myself..... /Ollie Jones (speaking for myself, not for HP Apollo Systems Division) From apollo-request@umix.cc.umich.edu Sun Nov 12 17:31:10 1989 Date: Fri, 10 Nov 89 13:20:58 CST From: lray@civilgate.ce.uiuc.edu (Leland Ray) Message-Id: <8911101920.AA01798@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: getty problem at 10.1 It all started when I moved the node to SR10.1. Until that time, it had been a well behaved DN4000. Connected to the node were two serial lines, both connecting to PCs in nearby offices. Several days after the node was converted, the owner began to complain. The node was slow, so she told me, and the disk was quickly filling up. Upon checking the node, I noticed that there was no free disk space, and both gettys were in an infinite loop. Rebooting the node recovered 70M in disk space. "Gee," said I, "this looks like a problem with the OS. Perhaps the 800 number could help me out." A call to the 800 number failed to resolve the problem. It seems nobody at Apollo had a problem with runaway gettys. The only possible suggestion was that I'd created the login_log file and that was growing without bounds. Of course, if it was a real file, rebooting the node would not recover that space -- I'd simply find a huge object on the disk I could delete. Well, if getty doesn't work, perhaps dropping back on the old way -- the SR9 way -- would solve the problem. siomonit came up easily, and did not destroy the cpu or the disk as did getty. However, it did create many processes called "level2" and fill up the process table, prohibiting any use of the node until reboot. So it seems I was stuck with getty. The next thing I did was to take advantage of the fact that my university is blessed with a Unix source license. I got the source to getty and spent a long time looking at it. I decided that the best way to tackle the problem would be to port the code to SR10.1 and use syslog calls to log significant program events. And this is what showed me the problem. It seems that the serial lines, for as yet unknown reasons, were flooding the line with large numbers of garbage characters. Most of them were ^? (Ascii 0xff) with a few o's (Ascii 0x7f) thrown in for good measure. What was happening was this: getty takes is the input of the login name only as many characters as are allowed, and after that, it terminates and passes the string to login even if the user never presses a return key. The Apollo serial drivers terminate the process silently after 255 characters (try holding down a repeating character while logged into an Apollo's serial line), which init faithfully notices and calls up another getty. The time spent in initializing the line, getting the environment, looking it up in gettytab, etc. while bogus characters are being dropped in the line takes up 99% of a DN4000. The fix I've made to my local copy of getty is the following: If the length of the login name exceeds the maxmimum number of permissible characters, drop all additional characters on the floor except the erase character, the kill character, and the EOF character. The loop of getty that reads in incoming characters and drops them takes up at most 2% of the DN4000's time. All told, here are my thoughts regarding this problem: 1. The Unix community (as this is a general Unix bug, and not an Apollo specific one) should modify more programs like getty to give debug output so these kind of problems can be tracked without having access to the source. 2. I've reported the serial line 256th character dropout problem to Apollo, and I'm told it will be "fixed in a future software release." 3. The problem with the process table filling up with level2's is a serious one, and should be fixed. I suspect this is incomplete process death, however, I don't know enough about it to precisely duplicate it. In addition, the DN10000 (SR10.1.p) also seems to accumulate level2's. ---------------------------------------------------------------------------------- Just spendin' my days, Leland Ray Systems Administrator Soakin' in them cathode rays. UIUC - Dept. Civil Engineering (217) 333-3821 From apollo-request@umix.cc.umich.edu Sun Nov 12 21:18:28 1989 Date: 13 Nov 89 00:00:32 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%cs.utexas.edu.uucp@tut.cis. (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Background screen software Message-Id: <22165@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The new X-Window system as is available on the DN-2500 is capable of displaying a picture as the background image (rather than the stipple pattern or all white/black). Other than that, I do not know of any other method of doing what you wish. Michael Lampi Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Sun Nov 12 21:21:04 1989 Date: 13 Nov 89 00:00:38 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov.uucp@cs.ucla.edu (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Apollo performance tools Message-Id: <22166@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Have you tried the Apollo DPAT (Domain Performance Analysis Tools)? It is an additional cost item--contact your Apollo sales person for more info. Michael Lampi Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Sun Nov 12 21:25:22 1989 Date: 13 Nov 89 00:20:21 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%gem.mps.ohio-state.edu.uucp@ (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: Connecting a Terminal to DN3500 Message-Id: <22169@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Have you tried using the Aegis TCTL command (TCTL -line # -speed ) to set the speed? Yes, this isn't UNIX, but at least see if your SIO port is working. Also, have you determined if your terminal needs flow control (XON/XOFF)? You might want to set (Aegis, again) -INSYNC and -HOSTSYNC using the aforementioned TCTL command. Finally, are you using the 1-to-3 converter cable to separate the three SIO ports from the single DB-25 connector? Perhaps you are referring to the wrong SIO port in your Unix stuff. Anyway, who offers *real* UNIX, and what IS *real* Unix???!? Michael Lampi Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Mon Nov 13 05:30:35 1989 Date: 9 Nov 89 17:05:51 GMT From: news%calgary%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Network News Manager) Organization: U. of Calgary, Calgary, Ab. Subject: 3rd Party HardDrives for 2500 Message-Id: <2052@cs-spool.calgary.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu From: sharp@cpsc.ucalgary.ca (Maurice Sharp) Path: cpsc!sharp Sorry if this is repetative but... What 3rd party SCSI hard drives are KNOWN to work on the DN2500 ? I need one of at least 150 meg, preferably 340 meg. I will post a summary of replies. Thanx in Advance maurice E-MAIL : sharp@ksi.cpsc.UCalgary.CA EAN : sharp@calgary.CDN From apollo-request@umix.cc.umich.edu Mon Nov 13 11:23:18 1989 Date: 13 Nov 89 14:23:21 GMT From: apj9319%cec1%wuarchive%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Amol P Joshi) Organization: Washington University, St. Louis MO Subject: GNUemacs for 68X and SR10.1 - where can i get binary? Message-Id: <1989Nov13.142321.12724@cec1.wustl.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu a few days ago, i saw a posting requesting GNUemacs binary for SR10.1 on 68X machines. i haven't seen anything on that one again... may i request the author of the original article to post/mail if it can be copied from somewhere. otherwise, i can only think of getting the 18.54 apollo-update files from prep.ai.mit.edu thanx fellows. :amol From apollo-request@umix.cc.umich.edu Mon Nov 13 13:23:08 1989 Message-Id: <8911131342.AA05784@umix.cc.umich.edu> Date: Mon, 13 Nov 89 08:31:23 EST From: Scott Ferguson Subject: xgif To: APOLLO@UMIX.CC.UMICH.EDU Keith Dawson mentioned in a previous posting a public domain program called 'xgif' for working with GIF image files. I've asked a few times, but haven't received replies. Who's got xgif, and where can I get it? Can I get source with it? Of course, I haven't been up to my workstations yet this morning, and haven't checked to see if it's on the Domain/X11 distribution. Well, at least I now know the name of what I'm looking for, and that it exists. Now, if I could actually find it, I'd be very happy. Thanks and my first-born to whoever can help me, Scott Ferguson Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 srfergu@erenj.bitnet From apollo-request@umix.cc.umich.edu Mon Nov 13 15:19:32 1989 Date: 13 Nov 89 19:13:53 GMT From: rich@eddie.mit.edu (Richard Caloggero) Organization: MIT Subject: BASH on Apollo SR10(DN3xxx) Message-Id: <1989Nov13.191353.11059@eddie.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu What should TARGET in Makefile be for Apollo's DN3000/3500 hardware. I'm running SR10(BSD). -- -- Rich (rich@eddie.mit.edu). The circle is open, but unbroken. Merry meet, merry part, and merry meet again. From apollo-request@umix.cc.umich.edu Mon Nov 13 15:31:21 1989 Message-Id: <8911131949.AA29549@umix.cc.umich.edu> Date: 13 Nov 89 13:25:00 CST From: "DAVE ERSTAD" Subject: Strange Apollo Bug To: "apollo" Here's one I've never seen before. We have a piece of code which behaves differently on a DSP-160 than on other nodes using Pascal; SR9.7.0.4. I suspect a hardware problem, but am wondering if anyone has seen something like this. We've narrowed it down to a line like c := 1.0 In the expanded code listing, both the working machines and the non-working machines translate this to MOVE.L # 1.000000 , C(DB) However, on the 160 the actual object code is 2B7C3F8800000004 Whereas on other machines it is 2B7C3F8000000004 The extra bit set on the 160 means 'c' gets the value 1.06 rather than 1.00. We've seen the same thing with constants other than unity as well. Any thoughts? I've got another 160 I'm going to boot diskless off the first this afternoon; that should provide some clues. (the second 160 is at SR10 so can't be used for a direct verification until we boot it at 9.7). Whether that works or not, it's still a bit of a mystery to me that the constant is correctly in the code listing but wrong in the object code; you would think a hardware error bad enough to flip a bit like that would cause wider problems as well. Dave Erstad DERSTAD@cim-vax.honeywell.com Honeywell SSEC From apollo-request@umix.cc.umich.edu Mon Nov 13 19:25:11 1989 Date: 10 Nov 89 17:16:04 GMT From: sharp%ksi.cpsc.ucalgary.ca%calgary%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Maurice Sharp) Organization: Knowledge Science Lab, U. of Calgary, Calgary, Canada. Subject: Type of SCSI on the 2500 ? Message-Id: <2055@cs-spool.calgary.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone know the type of SCSI on the DN2500. Is it SCSI 1 or SCSI 2. Some people also call them SCSI and enhanced SCSI. thanx in advance maurice Maurice Sharp University of Calgary Computer Science Department 2500 University Drive N.W. sharp@ksi.cpsc.UCalgary.CA Calgary, Alberta, T2N 1N4 ...!alberta!calgary!sharp From apollo-request@umix.cc.umich.edu Mon Nov 13 21:14:49 1989 Date: 13 Nov 89 23:26:00 GMT From: kr%apollo.hp.com%apollo%hp-sdd.uucp@hplabs.hp.com (Keith Alan Rodwell) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: scripts and ptys... Message-Id: <46d1ef4e.20b6d@apollo.HP.COM> References: <46ad248a.20b6d@apollo.HP.COM>, <17780@watdragon.waterloo.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu FYI, there were some problems with ptys in general at 10.1. If you see problems, execute the following: % rm -f /dev/ttyp? /dev/ptyp? % /etc/crpty or from an AEGIS shell $ dlf /dev/ttyp?* /dev/ptyp?* $ /etc/crpty ------------------------------------------------------------------------ ------------------- ``This theory which is mine, is mine'' -- Ann Elk (Monty Python) Keith Alan Rodwell Apollo/HP Customer Support (508)-256-6600 X8415 From apollo-request@umix.cc.umich.edu Mon Nov 13 21:18:31 1989 Date: 13 Nov 89 23:32:00 GMT From: kr%apollo.hp.com%apollo%hp-sdd.uucp@hplabs.hp.com (Keith Alan Rodwell) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: vi in rlogin Message-Id: <46d1f4eb.20b6d@apollo.HP.COM> References: <633@ccadfa.adfa.oz.au> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <633@ccadfa.adfa.oz.au>, gyp@ccadfa.adfa.oz.au (Patrick Tang Guan Yaw) writes: > I have trouble getting vi to work properly under rlogin. > I am running SR10.1 on a DN40000 node rlogin into a 10k node. > > The problem is that vi will display the file but does > not allow you to move the cursor around, the cursor is > at the bottom of the screen. I check the environment > variables and everything seems to be ok, even stty > tell me that it is at a correct speed. What have I > done wrong? > If you are at the DM, you should be in vt100 window, you will need to have your shell environment variable set to vt100. That should take care of you. ------------------------------------------------------------------------ ------------------- ``This theory which is mine, is mine'' -- Ann Elk (Monty Python) Keith Alan Rodwell Apollo/HP Customer Support (508)-256-6600 X8415 From apollo-request@umix.cc.umich.edu Tue Nov 14 05:20:39 1989 Date: 14 Nov 89 07:24:18 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: GNUemacs for 68X and SR10.1 - where can i get binary? Message-Id: References: <1989Nov13.142321.12724@cec1.wustl.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Look on the UUCP site osu-cis for the Zubkoff(sp?) patches for Emacs on the Apollos. There are both source patches and prebuilt executables. They may also be at other sites. If you need more details, drop me a note. I am home now and don't have the exact information available. -- Alan Bair SPS CAD Logic Simulation & Test Motorola, Inc. Austin, Texas ...!cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Tue Nov 14 11:20:01 1989 Date: 11 Nov 89 17:03:01 GMT From: reb%quintro%tiamat.uucp@uunet.uu.net (Roger E. Benz) Organization: none Subject: Wanted DOS disk drivers (Repost) Message-Id: <1989Nov11.170301.14737@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Recently I posted a request for information about DOS disk drivers for the Apollo floppy. I received a message from someone asking for my mailing address. Coould that person please send me the information again. (I lost your mail message). Thanks, -- Roger E. Benz Glenayre/Quintron Phone = (217) 223-3211 One Quintron Way Quincy, IL UUCP: tiamat!quintro!reb@uunet or quintro!reb@lll-winken From apollo-request@umix.cc.umich.edu Tue Nov 14 15:22:45 1989 Date: 14 Nov 89 17:32:04 GMT From: tone%marque%uwm.edu%rpi%brutus.cs.uiuc.edu%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state. (Peter Tonellato) Organization: Marquette University - Milwaukee, Wisconsin Subject: SLIP on DN10000/3500 (OS 10.1) Message-Id: <9601@marque.mu.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Dear netlanders, We want to complete an internet connection to an internet site via a phone line and two telebit modems. We are running one DN10000 and several 3500's with 10.1 on a tolken ring. (currently sys5 and aegis loaded.) They are running sys5 (unix) on several ATT 3b15's. I have been told that if we can find a ported SLIP we can make the connection. I have also heard that someone posted several messages on this group concerning SLIP on the DN10000 (I didn't notice myself, no interest at the time :>) Can someone help me out? Thanks for the support, Peter J. Tonellato US Mail: Department of Mathematics, Statistics and Computer Science Marquette University Milwaukee, Wisconsin 53233 Voice: 414-224-5228 414-224-7573 Uucp: ...!{uwvax, attmail!glmndd}!marque!tone Bitnet: 6512TONELLAT@MUCSD Arpa: tone@marque.mu.edu From apollo-request@umix.cc.umich.edu Tue Nov 14 17:18:10 1989 Date: 14 Nov 89 20:17:24 GMT From: arane%me%jarvis.csri.toronto.edu%mailrus.uucp@tut.cis.ohio-state.edu (Raphael Arane) Organization: University of Toronto Subject: driver for Okidata printer Message-Id: <89Nov14.151734est.19157@me.utoronto.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello there, Does anybody have a driver for an Okidata Microline 393 dot matrix priter? I'm running DN3500, SR9.7.1 Thanx, Rafi Arane. From apollo-request@umix.cc.umich.edu Tue Nov 14 17:27:44 1989 Date: 14 Nov 89 20:29:08 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Unix Plot Message-Id: <6271@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Until I get X-windows, I'd like to use the Unix "plot" command for some low-level graphics. However, when I try to do a "plot -Tapollo.15.color" (or any other display description), it dies saying something about font initialization failing. When I do a plot -T4014 logged in from a remote Tektronix emulator, everything works fine. I'm running 10.1 on an Apollo DN10000. Also, under BSD4.3 is there any way to create a tektronix window for telnet (say, when I'm logging into a Cray somewhere?). Alternately, is there any way to display a tek command file in a window as graphics? Can the GPR calls be used without installing a full Aegis environment? When I try compiling the Fortran sample programs, the compile fails because it can't find the needed include files in /sys/ins (I don't even seem to have a /sys/ins directory). From apollo-request@umix.cc.umich.edu Tue Nov 14 19:17:03 1989 Date: 14 Nov 89 23:02:06 GMT From: lori%hacgate%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%samsung%shadooby%mailrus.uucp@tut.cis (Lori Barfield) Organization: Hughes Aircraft Company, El Segundo CA Subject: Another Sucka Makes His Debut Message-Id: <6094@hacgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Nobody's said this in a while (ever?)-- We really appreciate the input from you Chelmsford folks. Welcome to our net, Keith. ...lori Oh boy oh boy oh boy, more flame bait.... From apollo-request@umix.cc.umich.edu Wed Nov 15 05:13:10 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8911150927.AA00543@icaen.uiowa.edu> Date: Wed, 15 Nov 89 03:25:41 CST Subject: Re: SLIP on DN10000/3500 (OS 10.1) To: tone@marque.mu.edu, apollo@umix.cc.umich.edu For information on sr10.1 SLIP read the sr10.1 release notes, "/install/doc/apollo/os.v.10.1__notes", page 2-12. From apollo-request@umix.cc.umich.edu Wed Nov 15 09:21:59 1989 Date: Wed, 15 Nov 89 08:09:23 EST From: crh@apollo.eng.ohio-state.edu (Charlotte Hawley) Message-Id: <8911151309.AA01897@apollo.eng.ohio-state.edu> To: apollo@umix.cc.umich.edu, rtp1%tank.uucp@handies.ucar.edu Subject: Re: Unix Plot Regarding your problem with fonts, we had the same problem using plot (I presume you have 10.1). We found out there was a bug somewhere and the plot needs some Sys V stuff and I only had BSD. So the trick was to make sure the link sys5 and sys5.3 is o.k. and go into sys5 and link etc and usr to the bsd etc and user. Then plot worked o.k. From apollo-request@umix.cc.umich.edu Wed Nov 15 09:25:12 1989 Message-Id: <8911151351.AA07044@umix.cc.umich.edu> Date: Wed, 15 Nov 89 08:44:07 EST From: Scott Ferguson Subject: xgif To: APOLLO@UMIX.CC.UMICH.EDU Thanks everbody for the replies. I now have the xgif code, and I'll see if I can get it going. Scott Ferguson From apollo-request@umix.cc.umich.edu Wed Nov 15 15:49:45 1989 Date: 15 Nov 89 18:13:27 GMT From: achille%cernvax%mcsun.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: bsd4.3 lpd bug solved Message-Id: <1137@cernvax.UUCP> References: <8911101022.AA00512@icaen.uiowa.edu>, <173@ns-mx.uiowa.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I want to thank all people who helped me with this problem, both on the net and with e-mail. I tried to reply personally to each of you but many messages came back. Any way, here is the solution, just in case other people get the same trouble. The problem turned out to be related to the NCS hack Apollo introduced into lpd; for the beast to run, it is necessary that Domain name (//abc) is equal to Tcp name (abc). That's it. Unfortunately we cannot run in this configuration generally, so I had to hack up my machine, giving it another TCP/IP name. The configuration we are running now involves a Sun station that can queue both text and PS files to the Apollo LaserWriter just fine (well, read below :-) I still have a few problems (apollo's lpd logs an error for every remote file it receives from Sun, '/dev/wn0a: no such file or directory', but the job gets printed correctly, another problem comes I guess from Sun that keeps sending the banner page for PS files, even though sh=true, anyway these are details). The best of the whole story is that there is no doc anywhere and that the NCS hack is not described clearly with its implications and benefits (hardly any ???). Thanks again Achille Petrilli Cray & Personal Workstation Operations From apollo-request@umix.cc.umich.edu Wed Nov 15 17:21:44 1989 Date: 15 Nov 89 17:56:00 GMT From: rew%apollo%hp-sdd.uucp@hplabs.hpl.hp.com (Robert Wolters) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: re: SLIP at sr10.1 Message-Id: <46dad713.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > Peter writes: > > Dear netlanders, > > We want to complete an internet connection to an internet site via a > phone line and two telebit modems. We are running one DN10000 and > several 3500's with 10.1 on a tolken ring. (currently sys5 and aegis > loaded.) They are running sys5 (unix) on several ATT 3b15's. > > I have been told that if we can find a ported SLIP we can make the > connection. I have also heard that someone posted several messages > on this group concerning SLIP on the DN10000 (I didn't notice > myself, no interest at the time :>) Can someone help me out? I'm not sure what you mean by "ported" SLIP. At sr10.1 SLIP is a part of TCP/IP which we bundled with the OS. You already have it. However, before implementing it, I suggest you give us a call in the Response Center. Cheers, Rob Wolters CS Networking Support Apollo Systems Division, HP. rew@apollo.hp.com From apollo-request@umix.cc.umich.edu Wed Nov 15 19:13:42 1989 Date: 15 Nov 89 20:26:07 GMT From: daemon%imagen.uucp@ucbvax.Berkeley.EDU (Jeff Finger) Subject: SR10.1 BUG/MISFEATURE: typedefs Message-Id: <4756@imagen.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu ################################################################ Following is an example of a legal use of ANSI C function prototypes -- a typedef specifying a class of functions of identical type (including argument types). Unfortunately, this program cannot be compiled under SR10.1. Although Apollo's support of ANSI C is admittedly only partial, I believe that giving an error on the program below is either a serious bug or serious misfeature. At the worst, the compiler should give an incorrect warning message rather than claim a type mismatch. -- Jeff Finger -- jfinger@imagen.com jfinger@neon.stanford.edu ################################################################ % cat fred.c typedef short fred_fp( long ); extern fred_fp fred; extern void main( void ); short fred( nbytes ) long nbytes; { return( 37 ); } void main() { short x; x = fred( 43 ); } ##################################################################### # # Note that gcc 1.33 compiles it ok, but Apollo SR10.1 CC does not. # Apollo CC's handling of typedefs does not seem to have remembered # the formal parameter types. # ##################################################################### % gcc -ansi -Wall -c fred.c % cc -v -c fred.c -g-W0,-info 1 (0009) long nbytes; ******** Line 8 of "fred.c": [Error #258] Multiple declaration of "fred". (0017) x = fred( 43 ); ******** Line 17 of "fred.c": [Warning #078] Incompatible pointer and integer operands [x, fred] to the "=" operator. From apollo-request@umix.cc.umich.edu Wed Nov 15 19:20:03 1989 Date: 15 Nov 89 19:30:34 GMT From: clif%ticipa%ti-csl%pollux%attctc%texbell.uucp@rutgers.edu (Clif Harden) Organization: TI PAC Wafer Fab Systems, Dallas Subject: Need help with unix fork function Message-Id: <327@ticipa.ti.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In porting some unix software to our apollo system I have run into a problem using the unix fork function on our apollos. The node I am using is a DN3500, SR10.1, running Aegis, bsd4.3, and sys5.3. It has all the known needed patches installed. I have included a small test program that can be used to demonstrate the problem. I don't recommend that you run this program as the problem(s) caused can be very nasty. The program scenario is this. I start the program in a pad, the program then opens a new frame on the pad and clears it. The program then displays a list of numbers and waits for keyboard input. If a "q" key is pressed the program terminates properly with no problems. If a "e" key is pressed the program will execute a function that will fork a very simple child process. The child process executes properly and terminates. This is when things go belly up big time. When the child process terminates it clears the frame and causes all further messages to be displayed at the bottom of the screen. I can tell the parent process is still running because when I press the "q" key the input transcript pad returns to the bottom of the screen, but the parent process never totally terminates, you will never get the pad back into the DM mode. The only way to get rid of the process is to log out and blast processes. In some cases I have had it totally lock up a node to the point I had to press the reset switch. I think I know what is going on. Since the parent process and child process are duplicates I think they are sharing some task and display system pointers. When the child process terminates the pointers are changed or deleted leaving the parent process in limbo or worse with wrong pointers. In my discussions with the Apollo hot line about porting this software they recommend running this program in a VT100 emulator. However due to the sorry state of Apollo's VT100 emulator that is not possible, it causes more problems than it fixes and it destroys the usefullness of the program. The hot line on this problem has been of little help. My opinion is a UNIX program should be able to use the DM pads in any mode, not just with a VT100 emulator. Any help with this problem would be appreciated. Help from the Apollo/Hp personel who read this news group would be especially appreciated. The following is the example program. ***************** Start of program ************************** /* ** Name of Program -- fork_test ** */ #nolist #include #include #include #include #include #include #include #include #list #define DISPLAY_UNIT ((short)1) static void check_status(status_$t status) { long count; if (status_$ok != status.all) { error_$print(status); for( count = 0; count <100000000; count++); pgm_$exit(); } } execute(command,arg1,arg2,arg3,arg4) char *command,*arg1,*arg2,*arg3,*arg4; { int fderr,cpid,wait_stat; long err_pos,count; printf("Starting to do the fork\n\n"); for(count=0;count<1000000;count++); if ((cpid = fork()) == 0) if (execlp(command,command,arg1,arg2,arg3,arg4,NULL)) { printf("Cannot execute %s\n",command); return; } while (wait(&wait_stat) != cpid); printf("Exiting the excute routine\n\n"); for(count=0;count<1000000;count++); return(0); } int main(void) { pad_$window_list_t window_list, window_2list; pad_$window_desc_t window_one, window_two; ios_$id_t stream_one, stream_two, stream_three; ios_$id_t pane_stream; stream_$sk_t frame_seek_one; status_$t status; short window_no1, window_no2, window_no3, status_code; long buf_size, count; short pane_count; char buffer[1000],in_buffer[1000],stop,b; int a; char *data_string; /* Set the original positions of the number 1 window. */ window_one.top = 0; window_one.left = 50; window_one.width = 1100; window_one.height = 750; /* Set the original positions of the number 2 window. */ window_two.top = 0; window_two.left = 0; window_two.width = 40; window_two.height = 750; /* Create frame on a pad */ pad_$create_frame( ios_$stdout, (short)1, (short)25, &status ); check_status(status); /* Get value of window_no1 for next calls. */ pad_$inq_windows( ios_$stdout, /* Stream id */ window_list, /* Location, size of window */ (short)0, /* No need for position info */ &window_no1, /* Returns no of windows */ &status ); /* Status code */ check_status(status); pad_$raw( ios_$stdout,&status ); data_string = "1 \n2 \n3 \n4 \n5 \n6 \n7 \n8 \n9 \n10 \n11 \n12 \n13 \n14 \n"; buffer[0] = 0; strcat( buffer,data_string); data_string = "15 \n16 \n17 \n18 \n19 \n20 \n21 \n22 \n23 \n24 \n25 \n"; strcat( buffer,data_string); buf_size = strlen(buffer); ios_$put( ios_$stdout, ios_$cond_opt, buffer, buf_size, &status ); check_status(status); stop = 0; printf("Ready for keyboard input\n\n"); do { a = getchar(); switch (a) { case 81 : /* q or Q key */ case 113 : stop = 1; break; case 69 : /* e or E key */ case 101 : execute("/bin/chmod","645","//gollum/local/clif/c/s/tpath",NULL); break; default : printf(" %d ",a); stop = 0; break; } } while( stop == 0 ); pad_$cooked( ios_$stdout,&status ); frame_seek_one.offset = NULL; pad_$clear_frame( ios_$stdout, frame_seek_one, &status); /* Close streams before terminating program. */ pad_$delete_frame( ios_$stdout, &status); ios_$close(stream_two, &status); check_status(status); } ***************** End of program **************************** Have a nice day!! Clif Harden TI PAC Apollo Network Adminstrator Texas Instruments ARPA: clif@ticipa.ti.com PO Box 655012 M/S 3635 Dallas, TX 75265 From apollo-request@umix.cc.umich.edu Wed Nov 15 21:14:14 1989 Date: 15 Nov 89 21:39:13 GMT From: clifford%bnlux0.uucp@sbcs.sunysb.edu (Tom Clifford) Organization: Brookhaven National Lab Subject: HP laserjet2 print server for SR10 Message-Id: <1545@bnlux0.bnl.gov> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu : i Does anyone have a print server for the HP laserjet 2 that runs under SR10? clifford@bnlux0.bnl.gov From apollo-request@umix.cc.umich.edu Wed Nov 15 23:13:22 1989 Date: 15 Nov 89 22:21:41 GMT From: ianh%merlin%bruce%munnari.oz.au%samsung%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Ian Hoyle) Organization: none Subject: Colourprint 300 (colour Tektronix printer) Message-Id: <1338@merlin.bhpmrl.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone have any experience with the Colorprint 300 hardware/software combo ???? Is this an unmodified Tektronix 4693RGB ?? The scant info I have on the software indicates that it uses Aegis prsvr as the print server. Is there a more up to date version that uses lpd ?? Any problems under SR10.1 (or 10.2 when it *finally* arrives) ?? ian -- Ian Hoyle /\/\ Computer Systems Superintendent / / /\ BHP Melbourne Research Laboratories / / / \ 245 Wellington Rd, Mulgrave, 3170 / / / /\ \ AUSTRALIA \ \/ / / / \ / / / Phone : +61-3-560-7066 \/\/\/ ACSnet : ianh@merlin.bhpmrl.oz.au Internet: ianh%merlin.bhpmrl.oz.au@uunet.uu.net From apollo-request@umix.cc.umich.edu Wed Nov 15 23:16:45 1989 Date: 16 Nov 89 02:09:12 GMT From: lnz%lucid.com%polya%Teknowledge.COM.uucp@beaver.cs.washington.edu (Leonard N. Zubkoff) Organization: Lucid, Inc. Menlo Park, CA Subject: GNU Emacs 68020/68030 executables Message-Id: <2156@heavens-gate.lucid.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Subject: GNU Emacs 68020/68030 executables Newsgroups: comp.sys.apollo The SR10.1 executables available on labrea.stanford.edu and prep.ai.mit.edu (perhaps available elsewhere also) do indeed contain support for both 68020/68030 and PRISM nodes. The problem is that there is a bug in tar which causes it to restore the executables as object type COFF rather than CMPEXE asthey were created, thereby making the 68020/68030 portion of the compound executable unavailable. The fix is simple: just use /etc/obty to set the object types of the executables to cmpexe. The following csh script will do this: #! /bin/csh -f set executables = (emacs etc/test-distrib etc/etags etc/ctags etc/loadst \ etc/make-docfile etc/digest-doc etc/sorted-doc \ etc/movemail etc/cvtmail etc/fakemail etc/yow etc/env \ etc/server etc/emacsclient) foreach file ($executables) /etc/obty $file cmpexe end From apollo-request@umix.cc.umich.edu Wed Nov 15 23:50:46 1989 Date: 16 Nov 89 01:25:00 GMT From: kr%apollo.hp.com%apollo%hp-sdd.uucp@hplabs.hp.com (Keith Alan Rodwell) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: Sharing /usr/spool/mail Message-Id: <46dc6903.20b6d@apollo.HP.COM> References: <46dc33bb.20b6d@apollo.HP.COM>, <2614@unisoft.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <46dc33bb.20b6d@apollo.HP.COM>, kr@apollo.HP.COM (Keith Alan Rodwell) writes: > In article <2614@unisoft.UUCP>, cander@unisoft.UUCP (Charles Anderson) writes: > > Real simple question: can I share /usr/spool/mail between a bunch of > > machines on the Token Ring? All machines are running SR 10.1 with BSD > > ... > > Yes, there are a few gotcha's that you will need to pay attention > to. First, if you are uning sys5 /bin/mail it is possible to trample a > users mail file if several machines are writing to a given mail box at one > time (have seen this when nightly scripts went off and mailed all the results > at the same time to root). If you are running sendmail, you will probably > want to spend the effort to have all sendmail daemons point to just one. This > way you can prohibit more than one sendmail from trampling. If you have any > other questions, go ahead and give the 800 number a call... > Please understand, by the way, that none of these options are supported by Apollo/HP. And I have just gotten a call from R&D suggesting that this might have been misleading to state the problems. I have also been told that it is still possible to trample with only one writter sendmail running. This is due to the fact that mail may think it has read all of the mail, and flush the mail spool file. It is worth noting that this is also a problem with NFS. Not specific to the Apollo/HP platform, but rather an atribute of the base assumpts of current UNIX mailers. ------------------------------------------------------------------------ ------------------- ``This theory which is mine, is mine'' -- Ann Elk (Monty Python) Keith Alan Rodwell Apollo/HP Customer Support (508)-256-6600 X8415 From apollo-request@umix.cc.umich.edu Thu Nov 16 19:27:11 1989 Date: 15 Nov 89 23:42:13 GMT From: dat%harrier.ukc.ac.uk%ukc%mcsun.uucp@uunet.uu.net (D.A.Turner) Organization: Computing Lab, University of Kent at Canterbury, UK. Subject: Miranda release 2 Message-Id: <3145@harrier.ukc.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu *** ANNOUNCEMENT *** Miranda - Release Two Miranda is a lazy functional language with polymorphic strong typing and a simple but powerful module system. This is to inform anyone who may be interested to know that a major new release of the Miranda system is now available, incorporating a number of improvements - including parameterised modules, unbounded size integers, and local polymorphism, as well as a substantially faster implementation. It runs on a number of machines under UNIX, including Apollo workstations (under the Apollo port of Berkeley UNIX). If you wish to receive a longer piece of electronic mail telling you more about the Miranda system and how to obtain it, this can be requested from INTERNET: mira-request%ukc@nsfnet-relay.ac.uk UUCP: mcvax!ukc!mira-request JANET: mira-request@ukc.ac.uk From apollo-request@umix.cc.umich.edu Thu Nov 16 23:21:58 1989 Date: 17 Nov 89 02:22:29 GMT From: taylor%limbo.uucp@apple.com (Dave Taylor) Organization: Intuitive Systems, Mountain View, CA: +011 (415) 966-1151 Subject: Reviewer Wanted: "Network Computing Architecture" book Message-Id: <191@limbo.Intuitive.Com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Prentice Hall announced November 1 the publication of the definitive new book on Apollo's Network Computing Architecture in cooperation with Hewlett-Packard/Apollo Systems Division. We at (HP/Apollo) Workstation magazine (formerly "HP Design & Automation") are now seeking a qualified network software programmer to review the book for our publication. We seek someone not an HP or Apollo employee, probably, since it's difficult to be unbiased when it's your company (plus the point of the book is presumably to demo- nstrate to others what the scoop with NCA is, after all...). Your benefits for accepting this assignment include a brand new copy of the book (you can be the first on your block!), your name in print, and, perhaps most of all, a $$$ payment upon acceptance! If you're interested in reviewing this book, please drop me a note via electronic mail including a brief summary of your credentials, including, if possible, a list of previous publications or related work. Please check beforehand that it's cool with your employer if you review something for an HP/Apollo trade publication. For those of you interested in the book, but not perhaps interested in the review assignment itself, here's what I know about it: "Network Computing Architecture", Prentice Hall, Nov 1 1989. Authors: Lisa Zahn, Terrence Dineen, Paul Leach, Elizabeth Martin, Nathaniel Mishkin, Joseph Pato and Geoffrey Wyant, all Apollo NCA designers or tech writers. The series is called the "HP, Apollo Systems Division Series", and is co-produced by Prentice-Hall of New Jersey. Queued for later release in this series are two more titles; "Network Computing System Reference Manual", and, later in 1990, a tutorial on NCA for students and programmers unfamiliar with distributed computing. I am afraid that I do not have an ISBN number on the book or any indication of page count. You can glean this information, however, by contacting Prentice Hall directly at their customer service telephone number: (201) 767-5937. I look forward to hearing from you! -- Dave Taylor -- Unix Editor (HP/Apollo) Workstation [formerly HP Design & Automation] taylor@PCI.Intuitive.Com -- From apollo-request@umix.cc.umich.edu Thu Nov 16 23:53:24 1989 Date: 16 Nov 89 14:18:10 GMT From: gerten%uklirb%unido%mcsun.uucp@uunet.uu.net (Rainer Gerten) Organization: University of Kaiserslautern, W-Germany Subject: EPSON-Driver for DN3000 Message-Id: <7354@uklirb.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have connected over here a EPSON matrix-printer to a DN3000. We are looking for a printer-driver for this combination. Does somebody out there in networld has one or a similar one ? Please email. Rainer Gerten University of Kaiserslautern, Germany unido!gerten@uklirb.uucp From apollo-request@umix.cc.umich.edu Fri Nov 17 11:18:49 1989 Date: Fri, 17 Nov 89 09:27:20 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8911171427.AA13419@richter.mit.edu> To: apollo@umix.cc.umich.edu, gerten%uklirb%unido%mcsun.uucp@uunet.uu.net Subject: Re: EPSON-Driver for DN3000 There is an SR9 print server for an Epson printer connected via the SPE card's parallel port in the ADUS library. It should not take too much work to replace the SPE calls with SIO line calls. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Nov 17 11:26:31 1989 Date: 16 Nov 89 21:59:26 GMT From: kts%quintro%tiamat.uucp@uunet.uu.net (Kenneth T. Smelcer) Organization: none Subject: Domain/X11 question - Imake? Message-Id: <1989Nov16.215926.13423@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We've just picked up Domain/X11 for 10.1 and I've got a question about what's distributed with the package. I've been looking at some public-domain packages like xpic, and I've noticed they all seem to want to use a program called 'imake' to build the sources. From what I've been able to gather, 'imake' is supposed to be part of the X-window distribution from MIT, but I haven't been able to find it in the Domain/X11 stuff. Was I supposed to get imake with Domain/X11? If not, could someone send me the source or tell me where I could get it? Thanks! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet From apollo-request@umix.cc.umich.edu Fri Nov 17 20:14:28 1989 Date: 17 Nov 89 23:24:33 GMT From: sahayman@iuvax.cs.indiana.edu (Steve Hayman) Organization: Computer Science Department, Indiana University Subject: Writing standalone programs Message-Id: <29919@iuvax.cs.indiana.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu How feasible is it to write your own program to be executed instead of Domain/OS? I am wondering about writing a special standalone application that can be executed via "EX MYPROGRAM" or something, that will run without all the O/S overhead. I'd appreciate any pointers to any even vaguely relevant documentation. Where should I start reading? Or should I drop this idea right now? Send me mail and I'll summarize what I find out. Steve Hayman -- Steve Hayman Workstation Manager Computer Science Department Indiana U. sahayman@iuvax.cs.indiana.edu (812) 855-6984 From apollo-request@umix.cc.umich.edu Fri Nov 17 22:06:20 1989 Date: 10 Nov 89 21:48:59 GMT From: jch%hpfcdq%hpfcso.uucp@hplabs.hp.com (Jan Hardenbergh) Organization: Hewlett-Packard - Fort Collins, CO Subject: Re: Performance Tools?? Message-Id: <19710003@hpfcdq.HP.COM> References: <618@ccadfa.adfa.oz.au> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Re; Performance on Apollos If you are into perfromance monitoring you should definitly pick up DPAK. While these are not generic UNIX tools, they are a lot better than mon was last time I used it. But they are oriented torwards analyzing a particular program not the whole system. -Jan Hardenbergh - jch@apollo.hp.com - HP Graphics Technology Division From apollo-request@umix.cc.umich.edu Sat Nov 18 04:23:46 1989 Date: 16 Nov 89 16:31:07 GMT From: andrewn%syma%icdoc%ukc%mcsun.uucp@uunet.uu.net (Andrew D Nimmo) Organization: University of Sussex Subject: Database Generation Tools Wanted Message-Id: <1779@syma.sussex.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Our research group is currently looking for database creation tools, primarily for input into graphics applications. A structured text-based and/or graphics based system is considered suitable - welcome features would include PHIGS+ interfacing, C-like syntax, variable output format. The graphics applications are intended to cope with an extensive range of scene descriptions - polygons, splines, parameterised forms, patches, etc,. which the database tool would not need to know about. I would imagine that this type of tool has been done previously and would welcome any feedback. I would also like to hear of the suitability of using such tools as INGRES, AutoCAD, dBase, etc., with PHIGS+ as a intermediate processing step (for example) etc. Any public domain program (C for UNIX) would be considered by the group, and also commercial software (for Apollo DN3XXX/DN4XXX and DN10000 machines). Can anyone tell me where to obtain details of the PHIGS+ standard (perhaps in machine-readable form) or an address from where it may be purchased. Thanks, Andrew D. Nimmo -- | Andrew D. Nimmo, VLSI and Graphics Research Group, | | EAPS II, University of Sussex, Falmer, BRIGHTON, East Sussex, BN1 9QT | | TEL: +44 273 606755 x 2617 | | EMAIL: (JANET) andrewn@syma.sussex.ac.uk | (UUCP) ...mcsun!ukc!syma!andrewn | From apollo-request@umix.cc.umich.edu Sat Nov 18 07:24:00 1989 Date: 18 Nov 89 07:42:18 GMT From: abair%oakhill%cs.utexas.edu.uucp@think.com (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: XView porting to Apollo status? Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I read the article & reply about the status of XView and this reminded me that I need to get some information on porting it to the Apollo. I currently have the beta version running on a SUN3/60 OS3.5. As I recall, shortly after XView was available, there were some articles about Apollo porting problems. Since then I have seen nothing. Whats the current status of XView on the Apollo? I am mainly interested in SR10.1 with BSD4.3. Is SharedX from Apollo adequate to do the porting considering it is X11R2 based. Does XView depend on X11R3? -- Alan Bair SPS CAD Logic Simulation & Test Motorola, Inc. Austin, Texas ...!cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Sat Nov 18 09:21:10 1989 Date: 16 Nov 89 21:45:21 GMT From: dls%cci632%ritcsh%rit%rochester.uucp@louie.udel.edu (Darren Swartzendruber) Organization: CCI, Communications Systems Division, Rochester, NY Subject: The White Paper Message-Id: <31904@cci632.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am looking for a copy of the "The White Paper", also know as Apollo NCA and Sun ONC: A Comparison". _HP Design & Automation_ (Sept 1989) states that "Apollo had made the paper available to the industry-at-large." Can someone email to me as well as posting it. Thanks. Currently fighting the question:: What shall we buy: Sun or Apollo!?! -- Darren Swartzendruber CCCCCCCCCCC CCCCCCCCCCC IIIIIIIIII CC CC CC CC II II COMPUTER dls@cci632 CC CCC CC CC CCC CC IIII IIII CONSOLES, rochester!rit!cci632!dls CC CCCCCCC CC CCCCCCC IIII IIII INCORPORATED uunet!ccicpg!cci632!dls CC CCC CC CC CCC CC IIII IIII uunet!rlgvax!cci632!dls CC CC CC CC II II An STC Company rayssd!cci632!dls CCCCCCCCCCC CCCCCCCCCCC IIIIIIIIII From apollo-request@umix.cc.umich.edu Sat Nov 18 15:16:01 1989 Date: 18 Nov 89 18:00:23 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%gem.mps.ohio-state.edu.uucp@ (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: SCSI on the 2500 Message-Id: <22405@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The DN2500 SCSI conforms to the SCSI-1 standard, using the single-ended asynchronous transfer protocol. Typical transfer rates are as high as 1.5 megabytes per second. Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Sat Nov 18 15:28:07 1989 Date: 18 Nov 89 18:00:35 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%gem.mps.ohio-state.edu.uucp@ (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Tektronix emulation under BSD4.3 Message-Id: <22406@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The Danford TEK emulator can be used under BSD4.3 in the 'shell' mode to gain access through TCP-IP to other host systems. It is supported on all current Apollo systems, and emulates a complete 4014 (except for special point plot mode). (I should know--I wrote it! However, I am not certain that Danford still sells it--I no longer work there....) Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Sat Nov 18 23:21:18 1989 Date: 19 Nov 89 01:41:43 GMT From: ianh%merlin%bruce%munnari.oz.au%uhccux.uucp@ames.arc.nasa.gov (Ian Hoyle) Organization: none Subject: Using CAP to print files from Apollo node Message-Id: <1340@merlin.bhpmrl.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have just successfully built CAP (Columbia Appletalk Package) on my DN10000 so that I can (hopefully) direct printjobs to postscipt printers attached to our ethernet LAN using Apple localtalk protocols. Everything looks reasonable. atlook can see all of the printers and I used lwsrv to successfully send a print job. But ..... I want to spool the jobs using the Berkeley spooling system with the input and output filters papif and papof. If anyone has done this already, what should my printcap entry look like ??? Should I remove the pc= entry directing the printing system to use prf ?? What should be used instead? Any other hints at all :-) ? ian -- Ian Hoyle /\/\ Computer Systems Superintendent / / /\ BHP Melbourne Research Laboratories / / / \ 245 Wellington Rd, Mulgrave, 3170 / / / /\ \ AUSTRALIA \ \/ / / / \ / / / Phone : +61-3-560-7066 \/\/\/ ACSnet : ianh@merlin.bhpmrl.oz.au Internet: ianh%merlin.bhpmrl.oz.au@uunet.uu.net From apollo-request@umix.cc.umich.edu Sun Nov 19 21:28:26 1989 Date: 17 Nov 89 23:13:00 GMT From: conliffe%caen.engin.umich.edu%netnews.engin.umich.edu%shadooby%samsung.uucp@think.com (Darryl C. Conliffe) Organization: U of M Engineering, Ann Arbor, Mich. Subject: Rebind of SR9.7 object in SR10.n environment. Message-Id: <46e6018f.f088@beck.engin.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu A query ... An executable (lets call it enp) developed and maintained on an SR9.7 system currently executes in both SR9.7 and SR10.n (n > 0). The application originally allowed users to "taylor" the executable by binding object modules with the executable, resolving previously unresolved names. Routines that were undefined and thus unreachable became reachable if successfully compiled and bind'ed with the base executable. Now, hoever, in the mixed op sys environment, such tayloring is not possible if the user runs in SR 10. My question is: if a user uses the SR9.7 ftn compiler and bind, and if no other libraries need to be resolved, will a "good" executable be generated, even if the user IS RUNNING IN SR 10?? I think so, but don't know if there are some hideous "gotchas" out there, and need some verification before releasing this "solution" to a bunch of students trying to get homework assignments done! Thanks in advance for any insights. -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 ------------------- From apollo-request@umix.cc.umich.edu Mon Nov 20 01:43:36 1989 Date: 19 Nov 89 15:02:00 GMT From: oj%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: The X Window System on Domain/OS: Questions and Answers part 2 Message-Id: <46ee595d.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This posting covers X Window System questions from programmers. The previous posting covered user questions. A disclaimer: keeping the Q&A log and answering the questions has been a midnight project for myself and others. I take personal responsibility for errors in this material, and I hope anyone spotting an error will inform both me and comp.sys.apollo. Nothing in this posting should be interpreted as the "official" position of HP. Enjoy! Ollie Jones. Question: Does Xlib support anything like the external GPR bitmap file? Answer: Not really. It supports an ASCII representation for single-plane bitmaps. This ASCII representation is in a form that can be read/written by Xlib (XReadBitmapFile/XWriteBitmapFile) or #included in a C program. See /usr/X11/include/bitmaps/star for an example. Q: How do I use Apollo event counts with X, rather than the Berkeley select(2) call? A: (thanks to Joe Bowbeer) On SR10.2, look at /usr/X11/examples/x_and_gpr_input/x_and_gpr_input.c The gist of it is this: (1) retrieve the event count for the socket used by the X display connection: #define necs 2 /* or whatever number of event counts you want */ #define ix 0 /* or whatever index you want for X waits */ #define igpr 1 /* or whatever... */ Display *display; /* X display structure */ ec2_$ptr_t ec2_ptr[necs]; /* arrays for ec2_$wait */ unsigned long ec2_val[necs]; status_$t status; /* status code for sys calls */ ... ios_$get_ec( (ios_$id_t)ConnectionNumber(display), ios_$get_ec_key, &ec2_ptr[ix], &status); ec2_val[ix] = ec2_$read(*ec2_ptr[ix]); (2) initialize any other event counts you want in the event count arrays. For example: gpr_$get_ec(gpr_$input_ec, &ec2_ptr[igpr], &status); ec2_val[igpr] = ec2_$read(*ec2_ptr[igpr]); (3) in your main loop, use ec2_$wait to block, rather than XNextEvent or gpr_$event_wait: while (!quit) { XFlush(display); /* flush X display connection before blocking */ which = ec2_$wait (ec2_ptr, (ec2_$val_list_t)ec2_val, necs, &status); switch (--which) { /* decrement for 0-based indices */ case igpr: /* advance ec */ ec2_val[igpr] = ec2_$read(*ec2_ptr[igpr]) + 1; do { /* flush gpr events. gpr calls refresh entry here */ gpr_$cond_event_wait(&event, &button, &position, &status); if (event != gpr_$no_event) /* process the gpr event */ } while (!quit && (event != gpr_$no_event)); break; case ix: /* advance ec */ ec2_val[ix] = ec2_$read(*ec2_ptr[ix]) + 1; while (0 != XEventsQueued(display, QueuedAfterReading)) { XNextEvent(display, &event); /* process all queued X events */ } break; } /* end switch (--which) */ } /* end while (!quit) */ This uses plain-old event-count handling. You can use whatever event counts you wish for this; you're not limited to GPR and X event counts. Q: My application references include files that I can't seem to locate: #include #include #include A: These include files have to do with HP toolkits. You can find up-to- date copies of the Xw stuff via ftp on expo.lcs.mit.edu. The Xr stuff is from a library called Xrlib, colloquially known as Xray. You might consider switching to OSF/Motif. Q: Is there a way to draw vertical text in x? I want to label the vertical axis of a graph. A: Short answer: No. Long answer: There's an XV11R2 font called rot-s16 which has characters oriented going down the page. If you image each character with a separate Xlib call, each on its own baseline, you can label axes. Yuk, but functional. Q: Is there any easy way of converting a font charater to an X bitmap? A: This depends on what you mean by "X bitmap", and what you mean by "easy." You can make an X bitmap file with the client named "bitmap," and digitize the character's bits. This is easy from a coding point of view but quite hard work. You can use xfd to display all the characters in a font in an on-screen window. You can make a one-plane Pixmap and draw your character into it. Use XLoadQueryFont, then XTextExtents to find out the size of the character, then create the Pixmap, then draw the character into it. You could use XWriteBitmapFile to move the Pixmap into a bitmap file. If you wrote the code to do all this, it might be nice if you added it to the bitmap client. Q: In our new user interface, while the application is off performing some computation, it is not waiting for any X events. Therefore there appears to be no easy way to present the user with some sort of or button. A: Yes, this is a real problem with X-based applications. There's another reason why you might try to keep watching the event queue while your application is doing computations: some of them take a long time and the user might do things to incur exposure events while they're going on. They'd like it better if the refreshes came through correctly. Not all events you'll get are interrupts from the user. Here are some wild ideas on how maybe to manage this: (1) do nothing...probably unacceptable. (2) modify the long-running computations to somehow look for events. (3) Whenever you start one of these long-running computes, spawn off a little separate user interface process which merely displays an button, and if the user pushes it, sends a SIGTERM or something to the main application process. (4) Establish a signal handler and condition the X connection socket to generate a signal when any X event arrives. Code the signal handler to look ahead in the queue and figure out whether it's received something meaning abort, in which case longjmp somewhere to clean up. (5) Use a lightweight thread, created via the task_$create call. Be careful in this case as Xlib is not guaranteed reentrant. (6) Separate the UI process and the application's process. This is probably the most robust and elegant solution. It has upfront labor, but I suspect the investment will pay off handsomely in such areas as flexibility of the UI. Q: I get the message "XIO: Operation would block" from my X client program whenever I try to connect to the X server. A: You may be defining the variable errno in your program somewhere. This variable is reserved for use by the C runtime library in reporting exceptional conditions to callers. Xlib receives reports from the runtime library code to read and write sockets using errno, and if your program defines errno you may confuse Xlib. The best way to obtain access to errno in your program is to use this: #include If you must declare errno explicitly, do so with the following line only: extern int errno; Q: I'm having trouble porting my Xt-based application to Apollo workstations. It works fine on HP9000-300 series workstations and Sun 3 workstations, but I'm getting bad data back from subroutines which create widgets on the Apollos. A: Both the 9000-300 series workstations and the Suns use C compilers based on PCC. Machine registers in these compilers are allocated such that D0 is used both for intermediate storage in computations and for returning function results. So, if you leave out the "return" statement at the end of a function compiled by such a compiler, the caller can get lucky and receive the result of the last computational expression in the function. The Domain C compiler is far less likely to allocate registers this way. A good way to find this kind of programming mistake is to run lint. Q: I'm getting protocol errors from my X application after I use XDestroyWindow to eliminate one of my windows. A: If you have an event-accepting loop which responds to MotionNotify hints by doing XQueryPointer, you can get into trouble if you destroy the window, because there may be some pending motion events after the window's gone. What you need to do is clean out the event queue of those MotionNotify events right after issuing the XDestroyWindow request; this code will do the trick: XEvent foo; XDestroyWindow(dpy, w); XSync (dpy,0); while (XCheckWindowEvent ( dpy, ~(SubstructureNotifyMask|StructureNotifyMask), &foo )); The advantage of this code is that it will flush out input and Expose events, and leave window structure events (like, maybe, DeleteNotify and UnmapNotify) around for regular event processing to handle; thus other code can get notified of window destruction in due course if it cares. It's not as drastic as XSync ( dpy, 1); which blows away all waiting events for all windows. Notice this is a problem on all X workstations, not just apollos. Q: When trying to compile some code under sys5 I get the following errors: cc my.c /usr/X11/lib/libX11.a /usr/X11/lib/libXt.a -o my /usr/include/X11/Xos.h: 69: Can't find include file strings.h /usr/include/X11/Xos.h: 80: Can't find include file sys/file.h /usr/include/X11/Xos.h: 98: Can't find include file sys/time.h Define the symbol SYSV when compiling, and Xlib's includes will work properly. Use "-DSYSV" as follows: cc my.c -DSYSV /usr/X11/lib/libX11.a /usr/X11/lib/libXt.a -o my Q: When compiling an x program I get some undefined globals. cc -o xapp xapp.o -L/usr/lib/X11 -lX11 -lXt -lXaw undefined first referenced symbol in file XtDestroyGC /usr/lib/X11/libXaw.a XtGetGC /usr/lib/X11/libXaw.a ld warning: Output file xapp not executable What is wrong? Is there a way to dump the libXt.a to find out what are the globals defined? Like /com/bind -map ?? A: You are specifying the order of your libraries incorrectly. Try this: cc -o xapp xapp.o -L/usr/lib/X11 -lXaw -lXt -lX11 You can use /bin/nm (the Unix namelist command) to find out what symbols are defined in an object, archive, or shareable library: /bin/nm /usr/X11/lib/libXt.a | grep GC Q: Mouse motion events (after a button-down event) are not getting reported until after the button-up event. Why are the motion events being delayed? A: You are probably running "xev" or some other program which receives MotionNotify events from the server and printfs them to the standard output. Also, you're probably running this program from a DM pad. The problem is, the share-mode server acquires the GPR display lock while buttons are being held down, because of an X requirement that an active button grab be in effect while the button is held down. Your program receives the events at the correct time, and sends the output to the DM. The DM queues it up and doesn't output it until the user releases the button. Try running your program from an xterm rather than a DM pad. Q: I am trying to compile an X application which includes an "Atoms.h" header file. I can't find "Atoms.h". A: Atoms.h is an XV11R2 Xt intrinsics file. At XV11R3 it was renamed StringDefs.h, and Apollo supplies the XV11R3 intrinsics with SR10.2. Q: I have an X application that works fine in mono but fails to draw anything at all on a color node. I'm using the following code: fg = BlackPixel( dpy, DefaultScreen( dpy )); bg = WhitePixel( dpy, DefaultScreen( dpy ) ); GC = XCreateGC(dpy, w, 0, 0); XSetFunction(dpy, GC, GXxor); XSetForeground(dpy, GC, fg ); XSetBackground(dpy, GC, bg ); XSetPlaneMask( dpy, GC, AllPlanes ); A: You've got things set up wrong for exclusive-or drawing. Set the plane mask to fg xor bg, set fg to all ones, and set bg to zero. XSetFunction(dpy, GC, GXxor); XSetForeground(dpy, GC, AllPlanes ); XSetBackground(dpy, GC, 0 ); XSetPlaneMask( dpy, GC, fg^bg ); Alternatively, set the plane mask to fg xor bg and use GXinvert instead of GXxor: XSetFunction(dpy, GC, GXinvert); XSetForeground(dpy, GC, fg ); XSetBackground(dpy, GC, bg ); XSetPlaneMask( dpy, GC, fg^bg ); Notice that this applies to all X workstations, not just Apollos. Q: Is the source-code for any of the example programs from the O'Reilly documentation series available somewhere? A: It's in /usr/X11/src/oreilly.tar unless you told "config" not to install it. See /usr/X11/src/README for an explanation. Thanks to Kee Hinckley Rod Owen, Joe Bowbeer, Glen Valante, Craig Wolpert, John Brezak, Jim Glading, Mike Burati and Rob Stanzel for some of these answers. I take responsibility for any errors. From apollo-request@umix.cc.umich.edu Mon Nov 20 01:53:09 1989 Date: 19 Nov 89 14:03:00 GMT From: oj%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Domain/X11 question - Imake? Message-Id: <46ee2512.20b6d@apollo.HP.COM> References: <1989Nov16.215926.13423@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1989Nov16.215926.13423@quintro.uucp> kts@quintro.UUCP (Kenneth T. Smelcer) writes: >...Was I supposed to get imake with Domain/X11? If not, could someone send >me the source or tell me where I could get it? No, we didn't include imake (or makedepend) on the Domain/X11 kit, nor on the Domain/OS SR10.2 kit. So, I'm posting the SR10.2 m68k binaries here. The sources you can get by ordering a source kit from MIT, ADUS, or OSF. All of these source kits cost $1000.00 or less, I believe. Some places have source available by ftp as well. These binaries should work OK with SR10.1 as well... They're wholly unsupported, so please don't expect our Customer Service organization to answer questions about how they work. If you want DN10000 binaries, please let me know and I'll mail them. These bits are a bit tricky to unpack, and you need bsd4.3 installed. Here's how I suggest you unpack them: (1) cd /tmp (2) Put the bits in the file /tmp/imake.uue (3) /bsd4.3/usr/bin/uudecode 0`@`$()9`PBR&@00M<`%`P",NCUX`@'!D>H8.B" M3AD\=!(&PF=PKT$'K-CRA1C211TW=]*X"6L0$JG&C[L"*QLY(@@78>#0L8.P M;=>$U`R"C6LFX8B$0%R0"4,G3&<`H;V&!G"`B<$).`R2();0P,&UJ<7,F9,P MP-BNQ\L"!>1"SATR:3HC@(&(`\"+8?-FS)KR`13`ZZK?8`%F!G4@!'S@S2%'=!)Q$!=<$0D`@`N*B2=& M1`3$-5=$"#S81AIR\)0;`".X()ECQ#S](G`,`#RH@`4(;_[`#0BO_H"," MC.2(0",X),#(#0DT8F,"C-280",T*,#(#`HT(I/D/\0P^0\P3_(B)2Y(P$C+ MB__`X@0DEYW(A#L\`!"C$UXX40<(2)1X#SXIXD#`$OF(^]*0(`PETVDE" MGD*<4K/'[F)0,`-<\E,$.@#0*P`2>%1(=%?6.DNK5QX4#$&\;V"`A!1'!S!H MTNZ2X#08S+!1+;*N,(K)H=J,20(#^Y"3`X(<]8I-P\S`S`6C/@(`8G'C,)R*!*,#L^MQ!+(X`"FR`4:QP*Y2"B1"T(H'$&`E*DC@(8ZJ".'`FM_QY[ M$/5DJ`0J`0!Q>^Z_@V$.H\"X"T.D)`!!"S\&G>$#`Q(`T((9"#`P5Q)=+]U(@!`.1*Q`D%@``TB<)WJIBB$6ERQ%H67B#X"0`C(`P(807>X MMBEN(SJ$W!DI1P(W4,MR(Y"&L:8P+$6(,$3*`&`!"` M`1/PWNV:R53-9B@9@8$ MQU)[^E.(MH$`!C`@/,)`!$6!@0%!:`$$4`$9J`#2`-PV!=H\5@$`!Z, M?`8T#DS-74C8&1J5`(DS<``$$+C1YV+W@AAD*$L$8,%E19C9:B!@B@U@ZH18-K_&$,12FA$)\$@#->X(+Y MLA56>NT*.*@'`-3B@<)G$J$6%#67>8&8':@%Q(+1H*\!H!84+RC`=:F%N:L" M(\8S_AH!P(%CUNI+QB+,U@4I9P(DR%=M(C2#?0'Q!AP(81)P^`,P*GP.)2A/ M`E&>\C_.$:LL%0``KND'^YZ@A`J;XPS,$`(@(&#F+K>A`!`(,SB\BHM"^6\` M/`"#%1`F`!3H+4O)6[`?(G6S"J-,A&QH7V\#`(.Y5.O&LD*TOBK\T@LOJ@W) M>T$%W"4'?57`RR`(,R=8R@,HB;%EBRN=G03<5`._V0=>5F(_W.!@09P!"F@D M@8N,3#C0)7G);\"#$"21Y0K?P\IGP+*4C>WF`@`AS!1P<(7M@68UL_D?]FCV M'/G!#SKSV<][:P,`%`R`?I#"O@Y#0`JS-.Y^(8#38+#JN+T,!G?AP=->)C<_ ML&$VSZ$,L,HZAP]X$$D5T$P0)BB`QWK\&9ZBX*<1*X"7\>`:?GBB?83#0J'< MY0=%A8D.4@!$K"Z%CDBQ```@IL,+#+!Q$1)B9[!PQ3_H<(:(>YFB_.""O@C@ M+B'$K\)T`($1A`"##*$`"2A@``0H\,D`4.%^(/*E$7)A#+TQX.0*^,<_?(D# M$C!!@/.#.@C.8`^H)^`,\#"!$B`P@3-80.PI-+O5#:*`!TIA$<[3P"$GX&58 MV-8KBG`P("(,#R]C*;8B##R9!V\0;G@9&'\'@.+O&V%D>-GRB/_,Y!D/`%IX M&1J1WWR$0>%E;(1>\!%FA)?+FWG`HQX/7GY>ZR6/>C,H01!FT,&J>'"HDDLJ MTK6ZU8KBY65U#,I=#&"JO.@%+!YX>:L`V`<']"4`$#``$H3H\J);_AFM34N% M0VN#`1C@KD0](>D6*(04&-%/?ZCB]F<`@<>LCWWM=X7[7O&^P=;Z&3"`P*UD MP@?_0`-B1`[FI6J/TUYWQ"=",`B8(P6`HG@/%V'$4"@;`PU+IC?_)P6#<%]F MP`WQUH!3@W\`8'Y3T$X$L`8.``)2(`62``&\``#[LV80``:X``=2``SMI``, M@"M"8`9L4`OM<")E(`(],P3H<```,`O*,`86``(*4`6/``F(\`-E0B_`YQ66 MX%4&``(L!`"`(`-S`4&K%`3ET`BB57C!H`(Q@`4`H`FJ@#&R4`AL8(12`(,R MR()*)X-ZXX)"$`@24(-FP@13\X>!^`(!``99136]I0#NP@E>928P$'FB8#:E MQ@PPE2+%%4DF@%SP%'5>`#,"Q#T:808"($!'(W'B%U^SAPH[XX$"H`6*,#]< M4D"`@`3`$`W`@`!F04PF0(LP8HNXJ(N\"$X$($"\PP!ZES\\V#V(10!PD(@L M``)+L'9VAPA@@`]3@`BQL`QEX``0``%P)P]RQPY2@`A"<#`3<`7`X`X>=(O` M(%YQI3(F`@>:B(`[A%P(8P`:8$K&4#-0-7LZ,R[R!0>-1BVX&"L#$+E$S'`(C7BISD`<`^F0#(<,(^(4S@N,U-S4U-JI5,BI`LB9B?`0P!)')@Y@H<]EKN8@RKZ0Y^54-R91!( MH`?4XBZ8>#@&(0@!=1"!T$!4,#<'H74QDIQNZ`!$4"%=`0L*,2P`T`#\@)T! M``?;Z88%8#$'H9T)P9T!P`$!4#(&H74G8Q"#0)P`$(UG\Y[_D#;RN1\`P`+M M&9U:-QB$$$6PV9[8*9WT8!"$X`0&H0\!X%/X^0_\60@,"@#/R3@1FJ``4`BH M8!!<8*`9:A"&H`!=`0$!T%(1R@X&<0AD@0?M"772J:(`<`B>D!U>`:-:IZ&' MX`N28PG8"0#HB1`[:A"4\*`X.IT`@`AN"`!*<*(`*J$&@0@=&@"`<*(L))V\ M(7DB`@"^\*`'JG5`(WGRL!X.,#?Y9"9:IQ,`T`B^`0#V\*!7JG4``@".X"`` M8`I.FJ(&X0BNT!4>\*!/ZET`\`B:!`!,T)X*@J9("@D0"@,OJJD1!.4"<',:H(8:JE2JH&@:JKJJJRXJJL^JJG M"JNT.JNVFJJWVJJY*JNXVJNZZJN\^JO"&JS$&JO&6JO`>JQ+L:Q)$:H^(3>L M=!`O4`<&\@(2\@)C``?BV1D!P`4(,:W52@=M``8P*P$6[`&>[!'D:WBV0)) M("(M4`6'D0:]Q18"P`;Z))X!(`!Y@;`^['%,0!4D`3_6A=E,*YLP!H` MRQ`,*Z_6F@9B8*WU$0;K@J_JJAACP`9U0`;D44H*T01!L`1%T`,E0!Q`*[1& MD`1,,+1%"P!WL`(&,01AX`9N\`9!-P9R4`8J"P)V,:YO(`=A(`=YD#]IP`9E M``)%NZ4*(;54:[4@<`<'8A<@,`=T0`9O4`=TH+8`,`5I<`9N0+-H2P9Z:Q!) M<+1%D`1.,`1,4`5$4`0(401N8`<<\@9NT`9EX`9!9P=A"P*%&[2'F[B+V[AH M.P"[[B2[[F&[;IN[YR,)=4 MD#\IJS<+P;95*[UP<+FC*R(DFZ]F4+8KBQ`V6P8+;+8+X03S2Q[U2P?EZP9D M:[9Z^\`1W,`'D<`$\<$'4;0Z0!95,0P[=T``=X M*R(CP+,+[`9GN[M?0`6\"P5,$`1@G``B4+0B(,-9#,'CP;F@R[A%\`6[F[1+ M:\9H3*(C@+,ZR[.<:[A?',9C#,8V?!!\Z[>`"\7<6P1X\+H@,`9OP,>(?,-( M[+9W409C<,```,3Y,\1Z6\C(&[B)O,A7^\AG&\D&\:\_/,E!5\F7G+:9K,K! MR\2CN\G[JQA6G+='W+9!E[5A@)4TF[S3:\(&H<<[6Q!:/!X&<1A:?!!IX,00 MS,QFL!C/#`!EP`9ST,"7"QVET30(5D`B&(`"/ M\&4`$`A8/:9;+0CA(P$E4`(70`$CP`$54`%TO0$EH`$GL`(3,`$D(`$20`%B M'0!EC=8FF@%)"@!I@`&"$``2P`$1(-864-@&$P#QLM4F4->)4`&/0`"&'0#` MLM4Y,`&;3=DF>@.)?003@`$4,`$90`<:<`$GT-H3$`$VH`$1L`$BP`%BC0&F M'0!;D-BC;0$6H`&),-D%\-D%(=H30-R\[=O)7=EOD-A)4`2"D`(#(`C8L$H5 M4`."X`$:(0CO80$DT-I_'0$7,`*M30$9$`$C4`&M70(2@-[E70(@D`@E\-N/ ML=59$`$80`(9D`U`<`(CH-YB'0&_32M;C06),`&_'0R)O08%_@$4X`$8<`$2 M(-:<'=TF&AJB?0'&G0&_S0V)+0@2\``8<`44@-[-70&QG0(I<`$5L`%Q4`$9 M,`$Z4`(34`$@;@&7P-8`(-;YS>$"H"!KS0`'L.(8S@$U?N-*L.,3@`(8(.2F M+0".N]81D`!CC0$6<`$8P`$64`'R/0)+``X2<`*Y/=\1P-9.\-C^'0$WP`$7 M$`(A,`*/30,'7N7HL=5[8`@!P.4D0.&,`!"``X1D`(9;@@;;M@"`"!KC0`)H`@'D0&"P`)F4`$6$`$1 M$`*U/0<7(-8B4.7;<"H:L`$<,`$7T.I+D`*\_@@*8-@#D!9;O045X`&2;=H# M`-[\+>-YSN$NEMA6,*)A;0@(SN$"F-@'\`AVZA49>Q#Q8:?]V(*X1G80>^U8A!V^F7&H1Z. MH1!^(3[D'A]^I$\&00"RD//ZX!\4B1#5P'MP\`9L M0!]?,`;MWAHG7P=PX`,`0+=R0`9,#P!%(!!%7Q].:\[F2L)2H+5DP`3(G`;7 M/*YTD`>9;+93.P3:&KVW?/9:ZP9J#P=)X`9M_Z^O"P`*>_=S@`9O<`?X2QQ, M\`9G8`2L0;.&*OB$WQIL0#Y&H!AD(,)L+,%34`9T\`2:01Q!0`9D$/=!@+X` MD/EDD,\$T?F?I!AW+\]T,`;>!;>9,?5[W_=W+Q"*H=BH#``.?Q`%T`*Z#RSN MU!`#@`C2V0[Y/O`*(9UMJM2BT?M!DQMM(0`_H.^*NMT`Z@_QL!">80/*[P`. MTOPN`/W2*?WXZ0_08/T'@?W8V0``TOP>X/U:!_YHZ@]!^AH&(07*WP#$V?P. MP/[_`/XHH'7^4`GDKROX%.S$`*Q`K0@`V:!")("@X!EX`P'$6&Q!'^B_^.?_ M*A3R`P"!`3LM@#C4%@+`+=!_[L__<:^!ASVPDP+H4QWP$X!`A.#_*D``]!?* M#P%H@@.8!E8@@.H'^.[?'00':!`.@#4X@$K`!N*G?J`-`F``,`3*SP#DK@[( M`80@FNH'N"```H#$+&H&!IP[(8#_P5CK0(/@!Y4<`D,'`DP9N<$#$P0!@`93?`-AYGD$3N$$" M=0$G!'8:`$OP("0"-RCPOL-U4'X"P!X,O*(!`.+#]V.!)T)%[,&X M`F20'V2I"WARP),R&'A)(!2*`BDH`Y1?`!A8GD$'A$*T%@0@,H1!B!7_$`"0@&?P!CH! M5D`G\]`@S`",\1D,HD:BB`D1``P1W^`5TH)!H`X<$0#HG8.($7<">"B)\<(@ M`(N0>'(,PLD)B:W0($"MD/@A`,!<"(E.SR"HDI`8K0#`PPF)2N`@G("2V-1@ M4TDT@-PA),)!A5@2)T1<*(F""@!$D9!H20Q"""B)&VLGA,0S^`%*(F,";R$1 M"0:(DJ@>ODM)E`0'P>&%Q(&5'4IBC3((B"TD5@8_$A+CD$&X`"4Q2/7!D(CN M#((+#(DQJ`>61&%P$-)"2+2#MZ$D.H/>W2-#."?B\>BA/3!`3'R03BL,W#T9:09RUANX9F#2B;T!)I8FA]B3K$\][$T:R0.!N8*D M?#23:!),KLG+]2;G0-]"7F#2>=F%R`4F#X,[BY$W09,_<>#8R1#9*1]D:IJ2"K)(=4V5621G9);]DB/1[8_)?\2PFQAB@FMO4 M"!7A(H0$CN`10`+<'`DMX6Z*!)`F`VS`#'`),$$FT(0:0`-B@$BP`7U3)\"S MM\DX&Z?C?)R0,W+VA*8@@Z+"#1B9.D!#`0"HI16X0JC:`*8B:%@'G?,9<`48 M$$O],-`T`\O@&0,`$*S(12&PY`8%L-!P`2#`7@2 MO*:&`0:#95`-A4_^$3\'8!U`9^I,C@?A2P('%R`1Y[`')P# M=.@,:F`M!(#P>1`D50J86#K`-R($[U`KPL-X0)+CD\3%SYQG'5)`H7H(^XYZ MHLO[P!;>P/U()U!'`9B%!_$Q$T+^-!#H$2(D*M4Y(AY$A(!9%")UNDZ%D"%< MP(;HCA#A0T#+!NI(-!&+V"XQ8D;4"-&2(W9$C_@'/R)(#(E_4"2.Q)-8$DWB M240)&D$E8(25H!%80DMP"2\!)BH,/Q@390(SL8FVP0;,RPF!\/I`"4P%QX2RX*#""`(J`.I"(8T`9! MT)>(`24P`,Z`#BA(\P=&<($O(7C,@`18.-4GGU7":--3@$`8Q0"UR!H)#=2B M$6`$%J"C9(8`^!(/$&.X!!7X$I'"!`"!:U`,V,0M*`9C@`?%$XE'`*8`WI$' ME]0,L)RA407`@`DP`0O`$A2"#62;8LS;X!),X$OXI!J``ZR&`$@"U2`;#(/U M@P3Z%XSH&^;GE>I1`,`,T@7AL$=5@$O,T2T*".PHYDBF>E1C,14_FH@PP)-` M!TJ`Z4"4*H!:(`"7.*1;5)'Z@2=!#E8H-J4$9\`*+)SX!# M"6``M!2-+*J:V4N157),5@=B/R[KO+"L#R*S;E9HE(@$P&>5*_O`'M$5$M`B M%)`2-:JCPJSD&0)@5GQ`6EDX+H9J7!4:8"WP`)>(IP6#`IQ04&!5+4!QQ:I< M0HNB'B@@5Y\'X8`]S,*XP@@BH$^;*0]0,S"@P@`"`7!"]H,),0B@0%XS* M)8``).TIP(!+@`(DY!.9D!@(-P0`"'`)'O`E.JMK!03`91_4&\`24V@K$O!, M2I1+,`(X(`)$"R,``5`@&D15%Q$%[L8_(`00(\'LU_>*6&&$>X4$D:($X(JT M]$5OCR@E`504#"B`./H//BP)``0:U1V=((!;``_\B!F``EZT%'T8 MJ'68QA!J`1,(59X2I*L""[[I>_43#8@6/%DF$-,DAPB``[GA!:@2`H!:XFN8 M51128%@,`C#`#4(.%@@$8$`3"%EJ05NI13E0!`MG+O00`@0)1*R;=3089`H$ M@BD2`A:!'UFL_T!MU%C2T2*X!#LXH8Q@"$B#6!`-R,#^>#@>(`@`#1$`!N0! M7@).C]7T")P/BF`M"0-8H>0`!;2`?P`.5,"NY09"P!"$%0``"EJ`$=A_)*`+ M(0'.4C^@P"*``H@`"16.$Y`%IFVUY0>\@TU,@4'03)H.+5`",@<;W!2L"F*P M`9>``=U5E`J!<'M&]9!9:`%Z`PL,*"(P`I#`B0`#R``"?"4D``AZD#Q!`OZ6 M")P!+N!ODT"$$03^]@Y$&$O@;P6?0<`%_M8.1!AJX&]#GD'P!O[6##0=!N!O MG\`9Z+>XX@Q\DG^@!_H)'Z2O`H!A[3\E$`%*0UY*`NT`+;0`)K#_%@H7H`*( MP`3(#JYD`)J)"9`$VQ8$3(%PM#"@3@]`2VKI&&$C=W`"3`4!<+8+97H4`IPK M`HK`"!@+20`%8%D*X'(]0#,!`4!WSYH)"@!N]Y_+90!*X.$(`#-@`>B)`\*B M_X`%O-=-`0#P0?N!!SB7;_".LHL-2H,_$`=I=SU`#+=[33I/^X$&.+=4&-Z3 M8@SXKM_U!8OEI+2?;QMN_2XK2+RF@A>L'?#13`HO+PBZXH87[*$1\$G\@2,` M-$``T`#2:(H&P``,<+PGQ0[@7!8P%HS`YCTI:J"9L``)L%"4`.SU!UJ`;P`: M7!--S4_[00)8H!`,@9B+!E!`$4@!2>!$K)Q5P0LD*IU5%%`%TWB01<,E4(`L M'1?9USB`D.[[?2\)4M&^1V,`D%\Q:WX!S?8UJS#"^[+?/G%^Q6\C6K\^J?Z^ MWP6`?\&O_CT:/"/^EM];"R/`@1*8!&=`XTP`?XH'(NDA.04O8`'#"*IF?JI' M0!I!ZA=&5!#VJT+4KQY]4+!B`TC4`=!S?T]9I;.J"4:`E_G+)=H%)``#I`!A M``!^4',`34>#$13@S)X"+H%`P,3("$#_@!:($=GZ,D9JGC@:%(!+D!\0VT=S M"I=X-Q7XIZ``H1(`C.L'-@&*IBLHX2_A:!&`HXTL,!8(I",P@&".*8OE.>8G M3#@D0.!H(\:17<(A=L3J#T`#)O)96,5()YC%RHKY*Y)($EX!-*C`GV(!ZO,B M_`$_^!(HUJRBH)5.^(F/ARH!]K,3%P"J@$UR(G043GAJ= M^$O@)4:"B5/$\VL1+D!$8``6("(X`!(%`>^%!-04%!`Y6`!P+10Q9OH>``H# M7WBQ"N$3O'@LY+.!Y!.K!@\6Q>X`!/`#7KN73#$$00*I^%2PXN_RBF/Q+*[% MM_@P*1R6LXM%Q+\0$;^8QDR2?X`)NLMW*<2@`Q*0C&4L53:M3#'"DJ/#^H,: MPH0?TAM^KS[EM13BE^*#69-P>:P%%A[?$5OK)ZRJ!B"W&?@?H%MFBI9$AAC- MLW)5',"!?P!<:.QC13&+XZ8A%Q8$`A1M+``&90`N@0$Y(`+F0FBI+HC@''UD M,O!T@*H9L`$,X.',A5_B`B``]@`M-YD"0(`S``X8@(-0`78T)J.<5B)`;S(> M`@'XUB?+(#.@#:0`H+4&9LD,X`*G/$JBCE"--R1%"B0",&`*JC+I%0"3(!F0 M`$10`H*`P0`!"6!,$`#/H6D!,@[1Q'DBCLYC?`P$JH$PJ`7"().2(DXZ!08( M.>H>*_44*0)0K$?]`2[(3=6G#M,?3`)7-,1<>@`'+@BPT@A[M!TKF M"<0;X9R" M_0$W>*_L&10K9FS07=5`?#G/4X-1Z%<]R@_D@6:!$>78NUB59"&?_0$U&,#5 M0S8;&/R,+/P/?P8&A%@QT^-(\7!<*27T%NU9JK M[DX^M51K8XD:`+S!S@`#WF!5,Z8<;2:4!9V>U1\8&-QJ,T$$)LBO;J0?6!7L MC%>=HSF`"#A%@0`1R6IDO6#X`9O8&F:BLC*FNN-/7G4#\+OZ``S8`@8P"-") M&3`P4X`P'XHQXX$P`+GVF&:@1:1K.WTHYHQ8U0`BPQY/ZU-=F#4!MOX'3F!? MTVH+L*QWM=^E!`L%#9C8^'*L^?7&H`>OR-9TH0'0"P4%"K:^=B`2^8,U*@', M0':F:2_@X:@0+LMN8A>,T$LO6!(9:W5="96`Q\D@/=8?#)3.0F1W@)BD&Q``!$(V>Z$W6`"+H&R MVX=J*@)0V]4``%0`!F3`"S#:$H9J*VVF'3*>]L.AL^+&W)[LZWRULS:[J2-K M.V7[`R@PD4G-/W"LF0G5L(21BER4:'OQID9F"G`)-LV$XT6$&:P0&+:4:@^\ M,41!$>-A-'"@`9C<@6((8N2# M4@*$H.EX`/2M$4:%V3G@\1L$C!_&Q`#"@E<0U(3:4"/J4U%<6GB"2E!`0R=X MJQ<.`%ZX`J?770$:./#*PP<80"\4!L`(2O#;800,X,`!``9YJ#+(:P=6? MZH&7#0;(P?RH'U!'!,R=%6%W!H@4E1?0R!_4&V4D%+F^9EP_D':M!.(!5517\U,PR9`(` MA101%!@@Y."6RUC/`6LS$S^(1KG?<*`B+$G_CD;2NX!!]`I`W(3[`):DXMV("SEK(@(`Y4:*UMLO_!F3<_ MW%P0X&JSP0'VP3DOQ61$G7.))2^@N00>X+#AISYQ"3J`C!G'7U$3?6$V/*'0`@6HU1T M5@F!$$A"`.#I[Q.:$K`&H1#813%@I")4F#($JQ,9F/H(->H!@"$`!P;AIN,T MZ<2?#L']0``BX$?ESAGU[!'`CXI_*^I^#``28*8BE#&4/-COE/1Z1=4+%P'4 M4?9/2D,M@@]QH1J(=$+V`&`1H,4IV)["5(W`NP0`5@"G\%.4-@B/8"12@/\4H1K( M(]`)!X`'9/K_J!,$@"*P4A%J3D6"+"4-AKVB@O>2@!-(AA-E[Z$$D7**0(#? M5WH`0`DZE+QP^?W.(%0"CZ@#'KZBXD^58#D1`%B/$"J!;W1L0%_K^#M+T%L$ M@!_X4=L3`%!]@V`-YD:BNH0`X!(L)S!0\5^^0;@$N@`Y/*BOGY_\'29`C"X` M1"DJS2DY"U8`,`#;[>Y_>Z!P]Q&C0I!J9P&\D"I#X.\,`N"7&X)?1#$(="(% MX$(`D`*<_@!P@\._GE!5(5!TG0'R4_[$WT+&U$'8_*B*$)S"SV\Z.#\A\/F& MO_2CJD$`[QF_&S(.)R<`,$_03ZI27=V__;@_]^O^W<_[>[_O__W`/_@+_^%/ M_(M_[T\`2:QU%2T;AOS=EO*W9T7K!30MA=#\@\[S)U%%*_N7!W8&`*A8\!I> MJ?A[<8@Y,(UP%B^[9O@L"&`!(I`$I,`4&&3='WA-+TP9!L9`&[2U6"[K&T+`#[HM]$RH4?1\?][@?#3",#`,P;]"PBP$HD_DDS(!`!'A0Z@0 M;`%M0!/0!>@S9@OQ,@PF,9D2>7"YT`$D2G3`(A+&,/@@`J(?P'^J"#D549<`?X@N+!AH#!N`'QAQ[( M$]XQ/R%2&`QF,Y?+&)`&D`>I6`S#%GQX70'>]ZP8`(]!`-``I%=]7U9("1Q^ M"@!U1ZI4`KN1%%@6HBJ5P'5$%IJ%0M\`M0/F!W`ASU<9L`5B*H]`I0(`*(50S`E#PX0`6LP)@)4\ M?R"`Y#(Q:'^#S`ECMXQ)D"$9(!D.@Y0A!&,94B^SC&8XNK2#",$),H>B(0@P`K"&"(%[N!R^,\WA&T%$''YJ(JER"?1%/9M3[`?G>@E MD"J60'Q$PQ2'7L]Q.`>D`"M,"I,HOH2PS!9S).8L).('(R`Z!`J`]C<:+@0* M0$,C`(Z(X$MIE"E:@$C2:QAT^$F&3/("Q=@PS@J?F.3D?H??%%35"$V&35:3 MV)0`7LU7<^V0-69-K&@;K#4/P`+@YU0`*T`$0`?8.!>`"$`!W`$3@`8PYG`` MT@`0D`(0B\;B'4#I:`#LS07PZD@`.8`40`&<`"%`M!,KQB%KS0)P``0V\PUM MX^C4-B-`!!`%S#<20&,S`:0`,@!@$P$X.B&`"!`%'#>F#0`@#B0V-``&T.D@ M.`)`K%A&;34TP`;P+WH[L:):H]@T-EW-I$/H4`"]3BT`!H@`WF)ELP"-.@D` M:]/E`#;S8<5HHC@[`$`6P-80`!-`#E#7#`$K0)CS`@@"\4!V0TKT`&+-!?#; M#`&)31$PZPPY)T2L.+"L-0Z`E@-/"`)=@`(@"#P&)``'(`&$`%U-"$#HJ``4 MP*5#`8@`@,W1V->X-_.-L5@!"`(>@R"@280`,D!K$P'$`.!`"C`#>(T1``DP M`1B+4X"Q>"Z&`,X5!1#8(%P$@"`@5@@"+E`.,.@\``>`!J`W[HWV605P`F0` MR8[9:`$(-G[.;],*;35W@)<#XLP`,HZU6`%T`(,CI;/FS`,"@"``%WB,`<`3 MD-C<`!;`H?/;7`$EC@"PYC@VI0V'$P#X1FN-Z)@(-#:?3F43#FTU5X`AP`!< M.]G.9V.Q\#>K#>WXV^P!)0X"8`!$`%&C(&`!5(XJRM68`!P`@@!?X#;&-;!. M!!`$U#:U30@P`TP`(0#PB#EV*+"C["@"4(\6@"'0`&R/D0VV\]ND?3RCEC,^ M)8L3@#X@']X`%T`&T.-D`!I`8P,!<#D>P`<0`:``9TX)4`2(-2N`:;/M;#4) M0&<#",2*0=&HTP!L`(*``8`"0`,L`&.S`0B-Y@``(`AL``6`((#:P`&"0(>" M`]0`T"H+`M-`"F#I=P3:`<$D`,L!B(P%D`$>`OY@*P`%;@,>8Q0$`T<,C M,`#$BKM`8K,'H#H'@`D`#MA.%0`&(`8@7/V)#*!$#HP29`/0`$P`-P!ZH^;` MD);-!2`&[`""0`*0HV$X@L`!<`%L`&M.`B``=``\9`"@-&8`'X"_"-C4-G[C MU>@-((^GP000!0@"MX`2)`C0/YCC@-#EB`$2P"-P`'PV><%6DP8L`>D`%(`Y M;@=K30+0Z#PZ)T"8HP5T.C+`;_,)4#>.#FN#.89XHXX`(-:$``AC9:/@2)", MCB%0`+``$P`/@`-4`*Z-!N#HF``3@!40`1B-\XT5@.'@BQR.K+#H-`"[C@2P M`UPX[`T-8`'T->VC6$,"Y(O3S58CX5"3G:,AT`'DBW-0)YD`6``8@`8@`7P` M.L!J(P)X`2I`*ME->@#YXBJ0V)P`4PYR\QV$.[`1N=,2/8;G3KJS[E`+2<^[ M@_>0/))3*TR]$\"!W M"J)EF0U(0780>&(,>08Y@&7Y"QA!B"5$*0R-3QI*)@`&2I"QWWJB4<8`$8\S M!`V=`=(0-60-83!F`$JY#:T+:M,OF,UT0T,E2]GRD$.!P`0@G;AZ-(^XHZDD M)P1/;20`O$4"@"KP3X8!0H\G^`8ICW?AR)1(CZ'#11^<`>%2X6.QB$O/$`DC*)$PLH\ET5]R0@$+*B"= M]#ST$/&3$$@G_IORI'=@)PB`X\<6H`%U91Q@!.T\59"WT@')0N(0V!>AU$87 MD'CR!:DH'5`(4%=.1+705?`%&4">@3M05\83M9#3\P7Y$9Y!-V!95C^U4)F` MG1``\M-!P`Q8EJ[>!60`W9A(D&>P"UB6=M$%]%"Z$['?09`*6)9ED?($5[I" M!\$F8%F*&[70#W0(S60'P1U@67*8\L\`,(:HEK91`+`&P'N9@&!X$!P"[I`) MJ%&Z`+6EV7);YI;5T#746XJ4TPH&`USF*VO3<-E?KCS'91T0"&P`TDFATES" M1H_13;D>$"@"P+8B`/`!_Z03H","`'J`];)=6H/3T--#'[P!:\#4"'(`F:92YS^X#8%H_6(!TXIL4F/L.6ZEU MN)7(SY^3!&&978$,4%=2F1<0B5(%900=4+278;8_F!!#(06-6/Y!G,@60`!U MI6,($1D$%LL7=`D>!/A`74E*U$)KT!!#``>*F_[/5Q$$"@*<"#*F5 MPU&[24YCI!DA(FD!:J?5=@JZ"1FF+59S/T,4)9^Z6V!"=^5MZG`1!GAER9DI\ MYCCD9\8`,L_*&1]X!F\B:L1#:GW_9`*@L%PS=$!_5%8FF[.>A51K1IFADT&@ M47IM>.>;F7'RG7-FR?-W!I=L$[:BK5">3$_AV14@EPO`S(()$!`-!#-0Q810A0TZ`8,D4-D$'1&&"7N M4Q(]-4I(2)1V8D:?0=NT&7T&4=%G]!E8+,E/2,0DQ1,AT<0"7Y1$9PH`\!=U M!07`$&@0<$0%0)@"`.Q%[*>,TMAA1`4`?\+"P9^:4US$?AI/>@?\J72J12_G M0:`@<$0&P(_2`6!$!H!%!!9EA5`'5H.`RH5=$0+J$9V?".C-`P"(1EGAND-^ M9H4H3$:`@.(T\0$"*AG]$0SH/CD59865RFF`@'9&/@4"6A-5GUGA%U(",*"F MDU&$@#XU0Q$"VJ_\1%GA4K1^WGVCT$[4%20`0R`-&@`D`/+GE\$1)0#VYQ": M`.B?'&A^T*]01OS!4H2%>H4G*%[$$34`^V2\\(56*C=1&-@95:$-0$VT?7J% M7\@'ZA6"G[(B1Z0&/)[O9U>@!LQ[J='X=!6P1G+H#`0;R:$)4NTY/JU"MI$< MBOGE1G9HD:F$J@%]BEB`$:D!.P_Y]HCBB22*'/IT/@6/*(_RJ3RBA!%T](@N MEM31\8,09'VL$;?D+9%,%Z%]A%].A"K3>=0D:2WL$=2D$'A-I2A]!#1E3/G1 MQC2U]$?HI30B(4W> MZ-0D*'V=*A-^:0]J39>+^L:*SD.&DF(0*15)\VB:Y(S622$2GG2/SD-;TXTD M)<2UE.4MDM**;@$5/)'XDE1BC(5 M2%(IO]0@K2S`D1T:B1:<HENH&J")-D=V:"?:G7RB!P%<((HR-?:1 M*3J4"J,(07@T-8U+,I(K*AXEI1,IS#2+MJ6V*%QZ$.!'"M)3RHOJI0G!+QJ8 M6J7Y$BHZC(9,5^DQBA`DHQA@9"J93J:4:65JF5ZFF&EFJIENIIQI9^J9?J:@ 1:6@JFHZFI&EI:IJ>IJ@I``!@ ` end From apollo-request@umix.cc.umich.edu Mon Nov 20 01:59:27 1989 Date: 19 Nov 89 14:48:00 GMT From: oj%apollo%hp-sdd%ncr-sd%ncrlnk.uucp@uunet.uu.net (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: The X Window System on Domain/OS: Questions and Answers Message-Id: <46ee4d8f.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Domain/OS System Release 10.2 is finally shipping (for m68k node types; the DN10000 schedule runs a few weeks behind the m68k). As many of you know, HP/Apollo has bundled the X Window System(TM) with SR10.2. During the alpha and beta period for SR10.2, we had many internal users and a fairly large number of beta sites. In the X development group we kept a log of questions and answers about how to use it. I've edited that question-and-answer log and I'm posting it here to help newnews readers come up to speed with SR10.2 and X. This posting covers questions from users. The next posting will cover programming questions. A disclaimer: keeping the Q&A log and answering the questions has been a midnight project for myself and others. I take personal responsibility for errors in this material, and I hope anyone spotting an error will inform both me and comp.sys.apollo. Nothing in this posting should be interpreted as the "official" position of HP. Enjoy! Ollie Jones. Question: I am getting the following messages: 69> /usr/X11/bin/xterm reference to undefined global (process manager/loader) /usr/X11/bin/xterm Any ideas? What am I missing? Answer: If you're running Domain/X11 V1.1 on SR10.1, be sure that you've followed the installation instructions about adding a reference to x11lib to the file /etc/sys.conf. Alternatively, inlib /lib/x11lib before running xterm. Q: I get this error message when I run xterm or xclock: X Toolkit Error: Can't Open display: A: Make sure the DISPLAY environment variable is defined, and make sure your X server is running. On SR10.1 you have to do this manually (in some startup script). On SR10.2, the DISPLAY environment variable is set for you automatically in the appropriate one of the following node startup files: /sys/node_data/startup /sys/node_data/startup.19l /sys/node_data/startup.color /sys/node_data/startup.1280bw /sys/node_data/startup.1280color Beware; if you installed SR10.2 as an upgrade on a node which already had SR10.1 running on it the new startup files don't replace the old ones but rather get installed with the current date appended to the file name. If you don't have a DISPLAY environment variable, you (or your system adminstrator) may have to do some editing of startup files. Suppose you installed your SR10.2 upgrade on December 13th, and suppose you're using a DN3500F. Then you should edit /sys/node_data/startup.1280color so it includes the setting of the environment variable we added for SR10.2. In this example you would look in the SR10.2-installed file /sys/node_data/startup.1280color.12.13. Maybe your X server isn't running. In this case, on SR10.2, create an empty (zero-length) file named /etc/daemons/Xapollo and reboot the node. Notice that the zero-length file /etc/templates/daemons/Xapollo controls what happens with diskless nodes. Q: What exact lines do I need in my ~/user_data/startup_dm.1280.bw file? Are these what I need ? env display := ':0' export display /com/crf /etc/daemons/Xapollo A: You shouldn't need to do any of these things in your private startup file. Just once, you should create the zero-length file /etc/daemons/Xapollo, then reboot. The DISPLAY environment variable should be set up automatically in your node-wide startup script (but see the previous question and answer). Q: Well, I am really stuck. I can't seem to keep X up on my SR10.1 node today. Everytime I run xset (no matter which font is being set) I get a XIO error, broken pipe. % /usr/bin/X11/Xapollo -K ~/user_data/Xkey.config -D1 s+r- & % /usr/bin/X11/xclient & % xset fp /usr/lib/X11/fonts/75dpis/ & % Connection # 3 to server broken. XIO: Broken pipe Connection # 3 to server broken. XIO: Broken pipe A: Are you waiting for Xapollo to start before issuing the client commands? Sometimes Xapollo takes a while to start up. This is especially true if tcp/ip isn't working on your node: the X server attempts to initialize a TCP socket. Try sleep 60 or similar right after the Xapollo command. Also, notice that /usr/lib/X11/fonts/75dpis/ probably isn't a valid font path, and /usr/lib/X11/fonts/75dpi/ probably is. Q: My Xapollo server crashes sometimes. A: What's in the /sys/node_data/system_logs/X0msgs file? That's how we tell what the crash was. You can read this file with the UNIX(r) utility cat. Please file an APR when you see a server crash. Q: I'm running Xapollo SR10.2. Today, when I tried to run gnuemacs I got the error message emacs: X server unable to find requested font `fixed'. Does anyone know what I need to do to make X happy with my fonts? On related notes, I'm not terribly happy with the default behavior of Emacs- under-X; the font is so small as to be almost unreadable and the window- size is correspondingly tiny A: Try putting this line in your .Xdefaults file in your home directory. If you already use xrdb, don't forget to rerun it. This will give you a legible font in emacs. emacs*font: *-courier-bold-r-normal*-140-* Also, try issuing this command to allow your SR10.2 X server to use the fonts from both XV11R3 and XV11R2: % xset fp+ /usr/lib/X11/fonts/oldX11/ Q: I would like to start xclock from my startup_dm file. (Is there a better way to start xclock at login?) When I am logged in and give the following to the dm: cpo /bin/csh -c '/usr/X11/bin/xclock -display \:0 -u 60 -g 100x100+1178+0 &' the xclock seems to start just fine, but if I put the same line in my personal DM startup file , the xclock nevers starts up when I log in and doesn't give any error messages. What am I doing wrong? A: Many /bin/csh or /bin/sh users start X stuff from their .login or .profile files. This is a good way to do things for a couple of reasons: (1) it's a good idea to use xrdb to load resource info from your ~/.Xdefaults file. (2) Once you've loaded resource info, you don't have to say as much to the xclock command. For example, if you have these lines in your ~/.Xdefaults file, the position and update time of your xclock are automatic. xclock.*.mode: analog xclock.*.borderWidth: 3 xclock.*.update: 60 xclock.*.geometry: 40x40-1-50 #ifdef COLOR xclock.*.border: red xclock.*.background: turquoise xclock.*.foreground: black xclock.*.hands: red xclock.*.highlight: black #endif Q: I am having this strange bug with deleting windows. It seems somewhat connected to using X windows. When windows are resized, there are leftover parts of windows left around on the screen. A: We've seen this before, when running with an X window manager (like uwm, twm, or the like) and forgetting to tell the X server it owns the "root" or screen background window. To run an X window manager, you have to do three things: (1) say "wmgr -off" (to the DM command window.) (2) say /usr/X11/bin/xownroot -on (to some shell) (3) run the window manager, e.g. uwm & (to some shell) It sounds like you forgot step 2, which leaves nobody owning the root, which means that neither the DM nor X can clean up after windows which have gone away. Q: If I let the DM own root at startup, everything works fine, but if I have X own the root at startup and comment the "xownroot -on" out of my .login file, I don't get any rubberbanding when I resize or move windows and icons. A: Try changing your background to some other color, for example xsetroot -solid cornflowerblue Then see if you still don't get rubberbanding. Q: I am currently running sr10.2 on my color node and by using xgif I have been able to display images as my background display. Do you have anything like that that I could run on my mono node? A: Mono gif images can be converted to xbitmaps via giftopbm | pbmtoxbm > file.xbm and xsetroot can then be used to make them the background. Similarly the macpaint files can be viewed with xmac, or converted using macptopbm | pbmtoxbm Do a "man pbm" and "man fbm" (both in /usr/local/man) for more information about these publicly available programs. Use ftp to get them from expo.lcs.mit.edu. Q: I don't know how to make xgif get rid of previous root pictures: successive invocations cause refreshes to recapitulate all of the old images. A: You are probably running several different invocations of xgif. Kill all-but-one. Q: Does Xlib support anything analogous to the external GPR bitmap file? A: Not really. It supports an ASCII representation for single-plane bitmaps. This ASCII representation is in a form that can be read/written by Xlib (XReadBitmapFile/XWriteBitmapFile) or #included in a C program. See /usr/X11/include/bitmaps/star for an example. Q: I hate X. It's a stupid system, but now at SR10.2 Apollo forces me to run it on my node, wasting memory and a process slot. Do I have to go back to SR10.1 to get rid of X? A: No, you can stay with SR10.2 even if you don't want X running. To prevent the X server from starting automatically when you boot your node, either answer "no" to the relevant config question or customize your SR10.2 installation by deleting the following files (if they exist). Reboot your node after deleting the files. /etc/daemons/Xapollo /etc/templates/daemons/Xapollo These files have zero length and contain no useful information, so if you decide later that you wish to run the X server, you may recreate these files with zero length and reboot. Please be aware that an increasing number of software developers are committing to X, and that you may need to run the X server in the future to use their products. Q: Whenever I try to set the DISPLAY variable so I can draw on the color node in the next office, I get "Can't open display" as an error message. If I set it to just :0 for my own node everything is OK. These nodes all run TCP and have proper TCP addresses. A: You have to log in to the node in the next office and use the xhost command to allow your node to have access. For example, suppose your node is named //mine and the color node is named //color. Log in to //color and issue these two commands: /usr/X11/bin/xclient & /usr/X11/bin/xhost +mine Notice that you should invoke xclient to keep the X server on //color from resetting after the xhost command (whenever the X server detects that no client programs are attached to it it assumes the user has logged off and "resets," cleaning up all sorts of per-session data). Notice also that you don't use the node name's slashes in the xhost command. A permanent xhost entry can be created by editing the file /etc/X0hosts to include the appropriate host name. Q: We are trying to determine if we are able to set up X on an Apollo workstation and have the client process run on a Digital VAXStation (tm). A: Yes, network transparency is the entire point of X. You have to make sure your VAX is registered as a host in the /etc/hosts file on your Apollo node, and vice versa. See the answer to the previous question for information on how to authorize the VAX to connect to the Apollo display. Q: I tried out the Motif Window Manager on a 1280 x 1028 x 8 DM 4500 at sr10.2. The machine was started with the DM managing the root and X running in shared mode. I started up the mwm and turned DM window management off. In this configuration the MWM does not clear the display. A posted menu stays up. A moved window shows up in both locations. A: Here's a script you can use to start up mwm on a "vanilla" SR10.2 node. I suspect you didn't give the "xownroot -on" command. /com/xdmc "wmgr -off" # turn off dm's window manager capability xownroot -on # tell X it owns the root window xclient & # start up a dummy client to prevent server reset xrdb ~/.Xdefaults # load my ~/.Xdefaults file into the server mwm & # start mwm /usr/X11/bin/xmodmap /usr/lib/X11/keyboard/xmodmap.kb3sample [the mwm window manager isn't distributed with SR10.2, but rather with the Domain Motif distribution, which isn't out yet. -editor] Q: I seem to be having a problem when I set this in my .Xdefaults: mwm*iconBoxGeometry: =500x100+10+690 A: Holy Cow! You're asking for an icon box with enough room for 500 icons across by 100 icons down. That's big! Try mwm*iconBoxGeometry: 7x1+10+690 Q: The window manager is oue problem. We would like to use twm instead of uwm. But apollo has made undocumented modifications (no source code) to uwm and so the customer is not able to use both dm and x clients with twm simultaneously. A: If we have made changes to uwm, they're insignificant. uwm from the MIT tape should run fine on Domain/X11. The actual problem with using twm is that it's a reparenting window manager: it wraps windows in new "decoration" windows. This gives nice functionality. Unfortunately it also plays havoc with the Domain/X11 share mode. Only at sr10.2 and later does the share-mode Domain/X11 server work correctly with reparenting window managers. So, I suggest upgrading to sr10.2 as soon as it is available. If you can't upgrade to sr10.2 call Customer Service and explain your problem. They should be able to help you. Q: Why does my xterm take so much virtual memory, and why does it take so long to resize? A: You may have set your xterm saveLines to a large number, like 10000, in your ~/.Xdefaults file to emulate the DM's infinite transcript pads. If you do this, each time you make an xterm it allocates several megabytes of virtual memory complete with backing store (enough to hold 10000 of the longest lines you can have). Furthermore, when you resize the xterm, it reallocates the memory. Better to set xterm's saveLines property to a much small number, like 500 or 1000. Q: What's the "name" of the dm windows as far as mwm or twm is concerned? If I want the alarm server's little windows to pop up with no decoration, what do I put in my ~/.Xdefaults file? A: For the sr10.2 DM there isn't one stored in the X property. Therefore all DM windows will use no name or as mwm likes to put it, "*****". twm labels these windows "NoName." The only way to treat a DM window specially is to set the default window dressing to be what you want for the DM and individually tailor X apps. Or you can wait for the Grue DM. Q: Occasionally, I try to start up an xterm and get this message: xterm: no available ptys I'm not sure, but I think this is a lie; I have ptyp0 through ptypf and ttyp0 through ttypf, and I'm not running that many processes. Any hints? A: For some reason your pty(s) became trashed. The easiest way to solve the problem is recreate them. Use these commands, then reboot: rm /dev/pty* /dev/ttyp* /etc/mkdev /dev pty 16 GNU emacs is one program which appears to consume ptys. After several invocations of shells from with GNU emacs you may have to recreate the ptys. Q: How can I create a DM transcript pad with a shell running in it from within an xterm or other X program? /com/xdmc only works from within a DM pad. so I can't use a DM "cp" command. A: Use /usr/X11/bin/dmwin. This program serves as a wrapper from which any program that uses PAD calls on any of the standard streams may be run. dmwin creates a transcript/input pad pair on the screen of the local Display Manager, and then runs the program given to it with its standard streams connected to the new pads. It also makes sure the "TERM" environment variable is set to a reasonable value for a DM window. Q: If I've got two dm windows (started in my startx script) overlapping each other and they are controlled by mwm (with X as root), I can get the arrow keys to move from one window to another without catching on the window manager resize border. I'm using OSF/Motif 1.0 beta. A: The DM keeps track of its "locator" and its cursor position separately. The arrow keys move the locator, but not this cursor. So if you drive out of a window with an arrow key then hit a letter key, you get . But if you drive from one window to another, it just works (except the cursor doesn't follow along, but rather jumps when the locator arrives in the new window). We have a bug logged on this, but fixing it is deferred until the next major release. Q: I used to let the DM use colors 0 - 16 and lived with 240 colors for the color ramp (this was real easy to do with GPR). Now I want to do the same with X/Motif. Unfortunately, when I start up mwm, it allocates (by default) colors 3-6 and 16-22. I can cut down on a couple of colors that it grabs above index 15 (by making DM colors the same, so that it will *share* them in the 7 - 15 range), but not all of them. How can I get 240 contiguous colors in X and still use mwm? Will using xdm instead work (ie: are colors 7 - 15 available for mwm?)? A: Yes, before you start mwm issue the "mono" command to the DM. This will induce the DM to release some colors. Also, don't run any other motif stuff besides the window manager. Now, if you play around with the stuff in your ~/.Xdefaults file (to simplify the motif colors) you may get 240 consecutive colors 14-253 to play with. You'll probably be able to figure something out. Q: I understand that apollo has created a separate X library called xdl for performance reasons. My question is does this library work in share mode or is it X only functionality? A: We have improved X performance on sr10.2 by using native X graphics on selected devices. The code we use for this is the "X display library" or "xdl." Currently only monochrome devices (including the DN2500) have xdl drivers. These drivers cause the X server to run faster, and have no effect on GPR or the DM. Share-mode still works with these xdl drivers. If you use X on sr10.2 on the supported devices, then you are using the xdl drivers (but see the next question and answer). Stay tuned for news about support of color displays post-sr10.2. Q: My SR10.2 X server runs ridiculously slowly. Why? A: There are some installation and configuration problems which can cause an Xapollo server to run abnormally slowly. (1) If your node is monochrome, you may not have the x display type manager running due to an error in installation. To find out whether it's running, do this: a) ps axu to find out the Xapollo process id. b) /usr/apollo/bin/las on the Xapollo process id (list-address-space) Look for one of the following files to be mapped: /sys/mgrs.split/dtm_mono_big/xdl_trait /sys/mgrs.split/dtm_mono_small/xdl_trait /sys/mgrs.split/dtm_fm/xdl_trait If none of these files is mapped on your mono node, there's something wrong with your sr10.2 installation. (2) Make sure your X fonts are installed locally rather than through a soft link to another node. Network-access time for fonts can slow you down drastically. Q: How do X window managers deal with the three dm command lines at the bottom of the screen? Is there some way to tell mwm not to put decorations around these three windows? A: X window managers (mwm for example) deal poorly with those windows. You can specify that the default window decoration should be "none" but then that affects all DM windows, not just the command windows. If you wanted to do that with mwm, you'd put lines like the following in your xrdb file: Mwm*defaults.clientDecoration: none Mwm*xgetmail.clientDecoration: none Mwm*xprmon.clientDecoration: title Mwm*xperfmon.clientDecoration: title Mwm*xsysmon.clientDecoration: title Mwm*datebook.clientDecoration: all Many of us mwm users just leave the decorations on the command windows, but make the command windows smaller to accomodate the decorations, using the following entries in `node_data/startup.1280color . Notice that these same lines will work in `node_data/startup.1280bw , but that you'll need something else in the files for a 1024x800 display. (630,1001)dr;(1270,1013)cv /sys/dm/output (540,1001)dr;(620,1013)dr;(632,1010)cc;pb (0,1001)dr;(530,1013)cv /sys/dm/input Thanks to Kee Hinckley, Rod Owen, Joe Bowbeer, Glen Valante, Craig Wolpert, John Brezak, Jim Glading, Mike Burati and Rob Stanzel for some of these answers, and to many people for the questions. In article <46ee2512.20b6d@apollo.HP.COM> oj@apollo.hp.com writes: >In article <1989Nov16.215926.13423@quintro.uucp> kts@quintro.UUCP (Kenneth T. Smelcer) writes: >>...Was I supposed to get imake with Domain/X11? If not, could someone send >>me the source or tell me where I could get it? > >No, we didn't include imake (or makedepend) on the Domain/X11 kit, nor >on the Domain/OS SR10.2 kit. So, I'm posting the SR10.2 m68k binaries here. >The sources you can get by ordering a source kit from MIT, ADUS, or >OSF. All of these source kits cost $1000.00 or less, I believe. >Some places have source available by ftp as well. > >These binaries should work OK with SR10.1 as well... >They're wholly unsupported, so please don't expect our Customer Service >organization to answer questions about how they work. >If you want DN10000 binaries, please let me know and I'll mail them. > >These bits are a bit tricky to unpack, and you need bsd4.3 installed. >Here's how I suggest you unpack them: > >(1) cd /tmp >(2) Put the bits in the file /tmp/imake.uue >(3) /bsd4.3/usr/bin/uudecode (4) /bsd4.3/usr/ucb/uncompress imake.tar >(5) /bsd4.3/bin/tar xfv imake.tar >(6) /usr/apollo/bin/ts imake makedepend > Ver Name Time Stamp File Name > -------------------------------------------------------------- > c 1 crt0 1989/10/26 11:54:44 EST (Thu) imake > c 1 crt0 1989/10/26 11:57:02 EST (Thu) makedepend > >You'll get imake and makedepend. Move them to the local-software >directory of your choice (we put this sort of utility in /usr/local/bin). > >Have Fun. >Ollie Jones (speaking for myself, not for HP Apollo Systems Division) > >---------------cut right after this line-------------------- >begin 664 imake.tar.Z >M'YV0:=J$65,&@,&#"!,J7,BPH<.'$",B!$'QQHT:(`"`H`'#1HP;&2F"B$%# >M1DB1%&74@%&2(HT:,V+4D'$QILB9-&AHE,BSI\^?0(,*'4JTJ-&C2),JA1C@ >M$H`%)8[8J&:PA*6#.ED(>0`@`$()9`PBR&@00M<`%`P",NCUX`@'!D>H8.B" >M3AD\=!(&PF=PKT$'K-CRA1C211TW=]*X"6L0$JG&C[L"*QLY(@@78>#0L8.P >M;=>$U`R"C6LFX8B$0%R0"4,G3&<`H;V&!G"`B<$).`R2();0P,&UJ<7,F9,P >MP-BNQ\L"!>1"SATR:3HC@(&M@[>(`\"+8?-FS)KR`13`ZZK?8`%F!G4@!'S@S2%'=!)Q$!=<$0D`@`N*B2=& >M1`3$-5=$"#S81AIR\)0;`".X()ECQ#S](G`,`#RH@`4(;_[`#0BO_H"," >MC.2(0",X),#(#0DT8F,"C-280",T*,#(#`HT(I/D/\0P^0\P3_(B)2Y(P$C+ >MB__`X@0DEYW(A#L\`!"C$UXX40<(2)1X#SXIXD#`$OFM:P%P\\(`+Q#@V@"00/%$E@+`<"@)6#SQ0@L",.`:`9)$N@(0E;XH``2Q"'.& >M`2L@`0`&8&`PZ:FN-0!+I"\`X$0NGP&@*1"G,@J%:P(P`FL+K*XG"*PY(,=F >M&P)@@80;^^`SZV<&//$.``PLVRRO8/Q:*:-@+/OFLUY%.VVU;KS)*Q"1,LK& >MJAB`2ZVB)@!@A@/L,@K'I8XHRNZ@DPI`0;^6`E``&=("`($2E*IPA@-*M/*I >M&0P,&@8(D8)A*``&..,:`(R\(("[$H`@P)@@<'`/.FBJ6>(^]*0(`PETVDE" >MGD*<4K/'[F)0,`-<\E,$.@#0*P`2>%1(=%?6.DNK5QX4#$&\;V"`A!1'!S!H >MTNZ2X#08S+!1+;*N,(K)H=J,20(#^Y"3M$E"XJ\*O*_JM@AO_.)LFVR:B>`X(<]8I-P\S`S`6C/@(`8G'C,)R*!M/6NW#:>*,#L^MQ!+(X`"FR`4:QP*Y2"B1"T(H'$&`E*DC@(8ZJ".'`FM_QY[ >M$/5DJ`0J`0!Q>^Z_@V$.H\"X"T.D)`!!"S\&G>$#`Q(`T((9"#`P5Q)=+MG,A"PRL^BDZ]L3:1L@F!!&=0P(!!()BA@!`:N&\0,9&2@B+`@(XL#0`"THL? >M$&"!/0"<@0`J0`2;#`B"!#X!!`MLX`-+)0`$5.UH'UL:`&R@*`:LA2UG@,`+ >MR@0`0G@`A.ZR@=G,!(_0)2Y%C(O;W"(WN<)9C@&T,D@,D).DKPU`"09TU'J$ >M$+S7,>]U(@!`.1*Q`D%@``TB<)WJIBB$6ERQM1./TR(AJ,."NNH*.)B*`!$^\8Q2G2#P,`"`$0DA>%H67B#X"0`C(`P(807>X >MMBEN(SJ$W!DI1P(W4,MR(Y"&L:8P+$6M33`*KOD'%]A4,6RD$@#D"\`9V''+T@3`#"A0@BH%<#LJ4#$)E0*#+CB)!47, >MRX"2,."]NL(#1:U`"LD$Q2V)\TL9"',]Q3SFI\"@`08(XB`!>(,$3*`&`!"` >M`1/PWNV:RM!M2%`<=F$&A8$YL*-1,-;LF97RH`G_KM@T$9'[53-9B@9@8$ >MQU)[^E.(MH$`!C`@/,)`!$6!@0%!:`M#<]!'1[6-&*$$D`8%#`F:H51KF-\623MRB>$$4`$9J`#2`-PV!=H\5@$`!Z, >M?`8T#DS-74C8&1J5`(DS<``$$+C1YV+W@AAD*$L$8,%E19C9MBX/5?H9O3W#-/L*&AZZ`S&QP?2E@%0<`&@S6DCWDQQ$JRR8E2*)^+^C?58F` >MA"G(=EP$1*V+)HL$-`"``YAE*0W%"(X4\<"XII.DY.Y:28/A"0`46%:-W.6$ >M2"D!$&JP*@'(@-HY^L,;BG(7%>:B!@B@U@ZH18-K_&$,12FA$)\$@#->X(+Y >MLA56>NT*.*@'`-3B@<)G$J$6%#67>8&8':@%Q(+1H*\!H!84+RC`=:F%N:L" >M(\8S_AH!P(%CUNI+QB+,U@4I9P(DR%=M(C2#?0'Q!AP(81)P^`,P*GP.)2A/ >M`E&>\C_.$:LL%0``KND'^YZ@A`J;XPS,$`(@(&#F+K>A`!`(,SB\BHM"^6\` >M/`"#%1`F`!3H+4O)6[`?(G6S"J-,A&QH7V\#`(.Y5.O&LD*TOBK\T@LOJ@W) >M>T$%W"4'?57`RR`(,R=8R@,HB;%EBRN=G03<5`._V0=>5F(_W.!@09P!"F@D >M@8N,3#C0)7G);\"#$"21Y0K?P\IGP+*4C>WF`@`AS!1P<(7M@68UL_D?]FCV >M'/G!#SKSV<][:P,`%`R`?I#"O@Y#0`JS-.Y^(8#38+#JN+T,!G?AP=->)C<_ >ML&$VSZ$,L,HZAP]X$$D5T$P0)BB`QWK\&9ZBX*<1*X"7\>`:?GBB?83#0J'< >MY0=%A8D.4@!$K"Z%CDBQ```@IL,+#+!Q$1)B9[!PQ3_H<(:(>YFB_.""O@C@ >M+B'$K\)T`($1A`"##*$`"2A@``0H\,D`4.%^(/*E$7)A#+TQX.0*^,<_?(D# >M$C!!@/.#.@C.8`^H)^`,\#"!$B`P@3-80.PI-+O5#:*`!TIA$<[3P"$GX&58 >MV-8KBG`P("(,#R]C*;8B##R9!V\0;G@9&'\'@.+O&V%D>-GRB/_,Y!D/`%IX >M&1J1WWR$0>%E;(1>\!%FA)?+FWG`HQX/7GY>ZR6/>C,H01!FT,&J>'"HDDLJ >MTK6ZU8KBY65U#,I=#&"JO.@%+!YX>:L`V`<']"4`$#``$H3H\J);_AFM34N% >M0VN#`1C@KD0](>D6*(04&-%/?ZCB]F<`@<>LCWWM=X7[7O&^P=;Z&3"`P*UD >MP@?_0`-B1`[FI6J/TUYWQ"=",`B8(P6`HG@/%V'$4"@;`PU+IC?_)P6#<%]F >MP`WQUH!3@W\`8'Y3T$X$L`8.``)2(`62``&\``#[LV80``:X``=2``SMI``, >M@"M"8`9L4`OM<")E(`(],P3H<```,`O*,`86``(*4`6/``F(\`-E0B_`YQ66 >MX%4&``(L!`"`(`-S`4&K%`3ET`BB57C!H`(Q@`4`H`FJ@#&R4`AL8(12`(,R >MR()*)X-ZXX)"$`@24(-FP@13\X>!^`(!``99136]I0#NP@E>928P$'FB8#:E >MQ@PPE2+%%4DF@%SP%'5>`#,"Q#T:808"($!'(W'B%U^SAPH[XX$"H`6*,#]< >M4D"`@`3`$`W`@`!F04PF0(LP8HNXJ(N\"$X$($"\PP!ZES\\V#V(10!PD(@L >M``)+L'9VAPA@@`]3@`BQL`QEX``0``%P)P]RQPY2@`A"<#`3<`7`X`X>=(O` >M(%YQI3(F`@>:B(`[A%P(8P`:8$K&4#-0-7LZ,R[R!0>-1BVX&"LM-W)=X0*W8@`MQP'1X`XC62H&0`+I")"GL)'5TI$!X"ZNL#,U@Y-(H)/N0@N*LEC\F"4&4%NS >MAUM(:8_BAP:1UUK4\B)=>#M()860Y;:8)7YDY:`8#$@T`)=*),@,$/_@`9BI#AR,EAYM<'PBI'_B>$+E$S'`(C7BISD`<`^F0#(<,(^(4S@N,U-S4U-JI5,BI`LM90#(X!KW(`4B\U:8*3HN`P">B9B?`0P!)')@Y@H<]EKN8@RKZ0Y^54-R91!( >MH`?4XBZ8>#@&(0@!=1"!T$!4,#<'H74QDIQNZ`!$4"%=`0L*,2P`T`#\@)T! >M``?;Z88%8#$'H9T)P9T!P`$!4#(&H74G8Q"#0)P`$(UG\Y[_D#;RN1\`P`+M >M&9U:-QB$$$6PV9[8*9WT8!"$X`0&H0\!X%/X^0_\60@,"@#/R3@1FJ``4`BH >M8!!<8*`9:A"&H`!=`0$!T%(1R@X&<0AD@0?M"772J:(`<`B>D!U>`:-:IZ&' >MX`N28PG8"0#HB1`[:A"4\*`X.IT`@`AN"`!*<*(`*J$&@0@=&@"`<*(L))V\ >M(7DB`@"^\*`'JG5`(WGRL!X.,#?Y9"9:IQ,`T`B^`0#V\*!7JG4``@".X"`` >M8`I.FJ(&X0BNT!4>\*!/ZET`\`B:!`!,T)X*@J9("@D0"@,OJJM@1"0(*F.2BT1RI^0``D&P0">D1!.4"<',:H(8:JE2JH&@:JKJJJRXJJL^JJG >M"JNT.JNVFJJWVJJY*JNXVJNZZJN\^JO"&JS$&JO&6JO`>JQ+L:Q)$:H^(3>L >M=!`O4`<&\@(2\@)C``?BV1D!P`4(,:W52@=M``M$0!\`*YR4*[C2J_G&A`#40;KVJY+"@#I6A`,(3>8P*P$6[`&>[!'D:WBV0)) >M("(M4`6'D0:]Q18"P`;Z))X!(`!Y@;`^['%,0!4D`3_6A=E,*YLP!H` >MRQ`,*Z_6F@9B8*WU$0;K@J_JJAACP`9U0`;D44H*T01!L`1%T`,E0!Q`*[1& >MD`1,,+1%"P!WL`(&,01AX`9N\`9!-P9R4`8J"P)V,:YO(`=A(`=YD#]IP`9E >M``)%NZ4*(;54:[4@<`<'8A<@,`=T0`9O4`=TH+8`,`5I<`9N0+-H2P9Z:Q!) >M<+1%D`1.,`1,4`5$4`0(401N8`<<\@9NT`9EX`9!9P=A"P*%&[2'F[B+V[AH >M.PM\`9F``**81=R\+=L,+=T\+5A<`;ZRA"_&W3"2[R86P;'"[ATR[S..[BE^@8@ >MP+-S@+5IH!EI0+FA)@?Q%P:)9;US.;Q`V+RE*ZK>"[[B2[[F&[;IN[YR,)=4 >MD#\IJS<+P;95*[UP<+FC*R(DFZ]F4+8KBQ`V6P8+;+8+X03S2Q[U2P?EZP9D >M:[9Z^\`1W,`'D<`$\<$'4;0Z0!95,0M^Z^AEI7C^[P(@<-!9P9?NP9Z>P[=T``=X >M*R(CP+,+[`9GN[M?0`6\"P5,$`1@G``B4+0B(,-9#,'CP;F@R[A%\`6[F[1+ >M:\9H3*(C@+,ZR[.<:[A?',9C#,8V?!!\Z[>`"\7<6P1X\+H@,`9OP,>(?,-( >M[+9W409C<,```,3Y,\1Z6\C(&[B)O,A7^\AG&\D&\:\_/,E!5\F7G+:9K,K! >MR\2CN\G[JQA6G+='W+9!E[5A@)4TF[S3:\(&H<<[6Q!:/!X&<1A:?!!IX,00 >MS,QFL!C/#`!EP`9ST,"7"QVETM(1YM$+\C,+KQ"RE#0+ES\+487`=M<,(/[`)CP`)V,!(N,`,@@0,X4%HP\`(P@`,@ >M(`,PH`,GK0,S``,@H`8!`0**#`<@`*%K"\MP^[IGN[R8_,U)_,LS*[=0#`(! >M;1?V7!RP<1"YFY[+";(0$02F0P*HZA?,:3``H$J(,,,4T-5>30(5D`B&(`"/ >M\&4`$`A8/:9;+0CA(P$E4`(70`$CP`$54`%TO0$EH`$GL`(3,`$D(`$20`%B >M'0!EC=8FF@%)"@!I@`&"$``2P`$1(-864-@&$P#QLM4F4->)4`&/0`"&'0#` >MLM4Y,`&;3=DF>@.)?003@`$4,`$90`<:<`$GT-H3$`$VH`$1L`$BP`%BC0&F >M'0!;D-BC;0$6H`&),-D%\-D%(=H30-R\[=O)7=EOD-A)4`2"D`(#(`C8L$H5 >M4`."X`$:(0CO80$DT-I_'0$7,`*M30$9$`$C4`&M70(2@-[E70(@D`@E\-N/ >ML=59$`$80`(9D`U`<`(CH-YB'0&_32M;C06),`&_'0R)O08%_@$4X`$8<`$2 >M(-:<'=TF&AJB?0'&G0&_S0V)+0@2\``8<`44@-[-70&QG0(I<`$5L`%Q4`$9 >M,`$Z4`(34`$@;@&7P-8`(-;YS>$"H"!KS0`'L.(8S@$U?N-*L.,3@`(8(.2F >M+0".N]81D`!CC0$6<`$8P`$64`'R/0)+``X2<`*Y/=\1P-9.\-C^'0$WP`$7 >M$`(A,`*/30,'7N7HL=5[8`@!P.4D0.MG0$9(`$6(`>&,`!"``X1D`(9;@@;;M@"`"!KC0`)H`@'D0&"P`)F4`$6$`$1 >M$`*U/0<7(-8B4.7;<"H:L`$<,`$7T.I+D`*\_@@*8-@#D!9;O045X`&2;=H# >M`-[\+>-YSN$NEMA6,*)A;0@(SN$"F-@'\`AVZA49>Q#Q8:?]VM^JE?0+=AFQ=82P?4\:,+@0'2N0\,42'QP1#22>(*X1G80>^U8A!V^F7&H1Z. >MH1!^(3M(.\F+^\:;1#['@`^\+L#()VS`>[D'A]^I$\&00"RD//ZX!\4B1#5P'MP\`9L >M0!]?,`;MWAHG7P=PX`,`0+=R0`9,#P!%(!!%7Q].:\[F2L)2H+5DP`3(G`;7 >M/*YTD`>9;+93.P3:&KVW?/9:ZP9J#P=)X`9M_Z^O"P`*>_=S@`9O<`?X2QQ, >M\`9G8`2L0;.&*OB$WQIL0#Y&H!AD(,)L+,%34`9T\`2:01Q!0`9D$/=!@+X` >MD/EDD,\$T?F?I!AW+\]T,`;>!;>9,?5[W_=W+Q"*H=BH#``.?Q`%T`*Z#RSN >MU!`#@`C2V0[Y/O`*(9UMJM2BT?M!DQMM(0`_H.^*NMT`Z@_QL!">80/*[P`. >MTOPN`/W2*?WXZ0_08/T'@?W8V0``TOP>X/U:!_YHZ@]!^AH&(07*WP#$V?P. >MP/[_`/XHH'7^4`GDKROX%.S$`*Q`K0@`V:!")("@X!EX`P'$6&Q!'^B_^.?_ >M*A3R`P"!`3LM@#C4%@+`+=!_[L__<:^!ASVPDP+H4QWP$X!`A.#_*D``]!?* >M#P%H@@.8!E8@@.H'^.[?'00':!`.@#4X@$K`!N*G?J`-`F``,`3*SP#DK@[( >M`80@FNH'N"```H#M&>$+&H&!IP[(8#_P5CK0(/@!Y4<`D,'`DP9N<$#$P0!@`93?`-AYGD$3N$$" >M=0$G!'8:`$OP("0"-RCPOL-U4'X"P!X,O*(!`.+#]V.!)T)%[,&X >M`F20'V2I"WARP),R&'A)(!2*`BDH`Y1?`!A8GD$'A$*T%@M4-A/]F`4$7BAJN`AA\@`"6C!=@HHC^/V&81U]@+F0QFX7!)/#M2!,O`"VH#5 >M:F8DC^/AK;+U`AY8-RQ98Z`2L@4C4`?6@G3Z@0AAW/6^XQMAX50(;R"`U```:`$5``K,/XXH3W4#9_@$X`_)>0@,H1!B!7_$`"0@&?P!CH! >M5D`G\]`@S`",\1D,HD:BB`D1``P1W^`5TH)!H`X<$0#HG8.($7<">"B)\<(@ >M`(N0>'(,PLD)B:W0($"MD/@A`,!<"(E.SR"HDI`8K0#`PPF)2N`@G("2V-1@ >M4TDT@-PA),)!A5@2)T1<*(F""@!$D9!H20Q"""B)&VLGA,0S^`%*(F,";R$1 >M"0:(DJ@>ODM)E`0'P>&%Q(&5'4IBC3((B"TD5@8_$A+CD$&X`"4Q2/7!D(CN >M#((+#(DQJ`>61&%P$-)"2+2#MZ$D.H/>ML5*9AM__Q#:T2*%'$T2BK:T!J]P$'($*/1*0*`!3@:38D,:HWM9#*VQJJHJ49CAS`( >M#:`UM%PX9PG=$"%D1._HKH=8>W2-#."?B\>BA/3M"&\Q/0(``9D'"IA#.)`&(3#XQX001!3D0AB%\I$[5JV'X""^0/D2C@;RZ=&! >MC0<'S%Z(A'IFBSE.2(30#Q6D-7N&:X!#BLCC-0;&58@T`T"(6D7%_`B$YH`8 >MJ`/&T4(JA"(H'LW`+2L/)W)$ULAM91_I&41P$&;`W<5'\MQQ`I]>!`3'R03BL,W#T9:09RUANX9F#2B;T!)I8FA]B3K$\][$T:R0.!N8*D >M?#23:!),KLG+]2;G0-]"7F#2>=F%R`4F#X,[BY$WMWH4QV2;9))B<`W"`3M(!.XD0LN,:Z%I74D@"`'+`!L+"$&AD;V!<,;#]90-P >MP!)@066@H]D`%W`#4(`,F`$R(`40-"%0!*A`$``!8&P*!)1X1QU.I2-3E6:+ >M5;I*6"DK::6MQ`&Y$@!$+#SP!7J$F+0D7T!"(#WMB`:XXX+4EE_`#)#';PFS >MD-YZI`_A,%N6RR]@]=`EN10#2$\_OKVIIR[AY1=@D`3R7<;+,3`@"\(7^)%F >M()NUA@DQ!_+`'/@"W%$\T"UY,2(/`^HK"&V`!$"'.4`"BIXWBXC;*4#FK'D9 >M*@\"A!Q4&K-?%DC[N!`2I'S$E^6Q4S($"2DJ$4*%E(\7TCYJR.D&)CWD&P"1 >M]A'J92L3F3-'9(H$DPNA1MB;>09,_<>#8R1#9*1]D:IJ2"K)(=4V5621G9);]DB/1[8_)?\2PFQAB@FMO4 >M"!7A(H0$CN`10`+<'`DMX6Z*!)`F`VS`#'`),$$FT(0:0`-B@$BP`7U3)\"S >MM\DX&Z?C?)R0,W+VA*8@@Z+"#1B9.D!#`0"HI16X0JC:`*8B:%@'G?,9<`48 >M$$O],-`T`\O@&0,`$*S(12&PY`8%L-!P`2#`7@2 >MO*:&`0:#95`-A4_^$3\'8!U`9^I,C@?A2P('%R`1Y[`')P# >M=.@,:F`M!(#P>1`D50J86#K`-R($[U`KPL-X0)+CD\3%SYQG'5)`H7H(^XYZ >MHLO[P!;>P/U()U!'`9B%!_$Q$T+^-!#H$2(D*M4Y(AY$A(!9%")UNDZ%D"%< >MP(;HCA#A0T#+!NI(-!&+V"XQ8D;4"-&2(W9$C_@'/R)(#(E_4"2.Q)-8$DWB >M240)&D$E8(25H!%80DMP"2\!)BH,/Q@390(SL8FVP0;,RPM)H`0B"PP@ATH@3A$`.+/P@D9,*+>F!\/I`"4P%QX2RX*#""`(J`.I"(8T`9! >MT)>(`24P`,Z`#BA(\P=&<($O(7C,@`18.-4GGU7":--3@$`8Q0"UR!H)#=2B >M$6`$%J"C9(8`^!(/$&.X!!7X$I'"!`"!:U`,V,0M*`9C@`?%$XE'`*8`WI$' >ME]0,L)RA407`@`DP`0O`$A2"#62;8LS;X!),X$OXI!J``ZR&`$@"U2`;#(/U >M@P3Z%XSH&^;GE>I1`,`,T@7AL$=5@$O,T2T*".PHYDBF>E1C,14_FH@PP)-` >M!TJ`Z4"4*H!:(`"7.*1;5)'Z@2=!#E8H-J4$9\`*+)SXM8=K+C.D_0*;*%)%ZH#M*2O$9KW``T_2//CGSP4VORNHPI(@4"[`?4Y!&`6DP >M$J1XU)]V!6U0/<"``*@$R@`*`=%2$TOERCPH+W2%!K0(SW0$W,$\J"-#8`^] >M`+1D`;#'"Q`"$V`(N(.3P;`^*@A``('H#'@`4(5RS(#],`LK-2VA"GM0/90` >M_1``(B"CX@YLY`U$`#`0`I&@DGQ4(2``G$LZ?0$A(Y^A@25C!DI:5@T#@V;Q >MF`$2D,[M*C;(1C!5KIH"(0`ZW!# >M"6``M!2-+*J:V4N157),5@=B/R[KO+"L#R*S;E9HE(@$P&>5*_O`'M$5$M`B >M%)`2-:JCPJSD&0)@5GQ`6EDX+H9J7!4:8"WP`)>(IP6#`IQ04&!5+4!QQ:I< >M0HNB'B@@5Y\'X8`]S,*XP@@BH$^;*0]0,S"@P@`"`7!"]H,),0B@0%XS* >M)8``).TIP(!+@`(DY!.9D!@(-P0`"'`)'O`E.JMK!03`91_4&\`24V@K$O!, >M2I1+,`(X(`)$"R,``5`@&D15%Q$%[L8_(`00(\'LU_>*6&&$>X4$D:($X(JT >M]$5OCR@E`504#"B`./H//BP)``0:U1VM''94"L0AGN%H2$LA_0=((!;``_\B!F``EZT%'T8 >MJ'68QA!J`1,(59X2I*L""[[I>_43#8@6/%DF$-,DAPB``[GA!:@2`H!:XFN8 >M51128%@,`C#`#4(.%@@$8$`3"%EJ05NI13E0!`MG+O00`@0)1*R;=3089`H$ >M@BD2`A:!'UFL_T!MU%C2T2*X!#LXH8Q@"$B#6!`-R,#^>#@>(`@`#1$`!N0! >M7@).C]7T")P/BF`M"0-8H>0`!;2`?P`.5,"NY09"P!"$%0``"EJ`$=A_)*`+ >M(0'.4C^@P"*``H@`"16.$Y`%IFVUY0>\@TU,@4'03)H.+5`",@<;W!2L"F*P >M`9>``=U5E`J!<'M&]9!9:`%Z`PL,*"(P`I#`B0`#R``"?"4D``AZD#Q!`OZ6 >M")P!+N!ODT"$$03^]@Y$&$O@;P6?0<`%_M8.1!AJX&]#GD'P!O[6##0=!N!O >MG\`9Z+>XX@Q\DG^@!_H)'Z2O`H!A[3\E$`%*0UY*`NT`+;0`)K#_%@H7H`*( >MP`3(#JYD`)J)"9`$VQ8$3(%PM#"@3@]`2VKI&&$C=W`"3`4!<+8+97H4`IPK >M`HK`"!@+20`%8%D*X'(]0#,!`4!WSYH)"@!N]Y_+90!*X.$(`#-@`>B)`\*B >M_X`%O-=-`0#P0?N!!SB7;_".LHL-2H,_$`=I=SU`#+=[33I/^X$&.+=4&-Z3 >M8@SXKM_U!8OEI+2?;QMN_2XK2+RF@A>L'?#13`HO+PBZXH87[*$1\$G\@2,` >M-$``T`#2:(H&P``,<+PGQ0[@7!8P%HS`YCTI:J"9L``)L%"4`.SU!UJ`;P`: >M7!--S4_[00)8H!`,@9B+!E!`$4@!2>!$K)Q5P0LD*IU5%%`%TWB01<,E4(`L >M'1?9USB`D.[[?2\)4M&^1V,`D%\Q:WX!S?8UJS#"^[+?/G%^Q6\C6K\^J?Z^ >MWP6`?\&O_CT:/"/^EM];"R/`@1*8!&=`XTP`?XH'(NDA.04O8`'#"*IF?JI' >M0!I!ZA=&5!#VJT+4KQY]4+!B`TC4`=!S?T]9I;.J"4:`E_G+)=H%)``#I`!A >M``!^4',`34>#$13@S)X"+H%`P,3("$#_@!:($=GZ,D9JGC@:%(!+D!\0VT=S >M"I=X-Q7XIZ``H1(`C.L'-@&*IBLHX2_A:!&`HXTL,!8(I",P@&".*8OE.>8G >M3#@D0.!H(\:17<(A=L3J#T`#)O)96,5()YC%RHKY*Y)($EX!-*C`GV(!ZO,B >M_`$_^!(HUJRBH)5.^(F/ARH!]K,3%P"J@$UR(G043GAJ= >M^$O@)4:"B5/$\VL1+D!$8``6("(X`!(%`>^%!-04%!`Y6`!P+10Q9OH>``H# >M7WBQ"N$3O'@LY+.!Y!.K!@\6Q>X`!/`#7KN73#$$00*I^%2PXN_RBF/Q+*[% >MM_@P*1R6LXM%Q+\0$;^8QDR2?X`)NLMW*<2@`Q*0C&4L53:M3#'"DJ/#^H,: >MPH0?TAM^KS[EM13BE^*#69-P>:P%%A[?$5OK)ZRJ!B"W&?@?H%MFBI9$AAC- >MLW)5',"!?P!<:.QC13&+XZ8A%Q8$`A1M+``&90`N@0$Y(`+F0FBI+HC@''UD >M,O!T@*H9L`$,X.',A5_B`B``]@`M-YD"0(`S``X8@(-0`78T)J.<5B)`;S(> >M`@'XUB?+(#.@#:0`H+4&9LD,X`*G/$JBCE"--R1%"B0",&`*JC+I%0"3(!F0 >M`$10`H*`P0`!"6!,$`#/H6D!,@[1Q'DBCLYC?`P$JH$PJ`7"().2(DXZ!08( >M.>H>*_44*0)0K$?]`2[(3=6G#M>M,?3`)M#Z:QL_X`93!D`U`$8BXT``,VH#8#&G!0B'5S'>7-,1<>@`'+@BPT@A[M!TKF >M"<0;X9R" >M_0$W>*_L&10K9FS07=5`?#G/4X-1Z%<]R@_D@6:!$>78NUB59"&?_0$U&,#5 >M0S8;&/R,+/P/?P8&A%@QT^-(\7!<*27T%NU9JM!E0%G2T7Y"HQ^P-,M*&;J0"P`P$@/Z/H0HP,$"D8^+8#H$37&`%@A2L.+(C0 >M_H`8P.?J'#V8,'@5K[$"*.FD0LP+D#$)X`'WH&\$IPY3!5I$EAA`A1@7?(G! >M<2+$2`$1S3<6B:H./J%C(4#D2,)(H)'""#9`EU/S)Q$`5J!JV)DIX$I5DQX= >M`"@@N<8+*M!O&5,$(`/*`!H``1BP`S"&$\!W`B``L(,`$`5]RBE4!@%`!@0` >M(Q``H$`B"@"B8$I,B4@])K >M[DX^M51K8XD:`+S!S@`#WF!5,Z8<;2:4!9V>U1\8&-QJ,T$$)LBO;J0?6!7L >MC%>=HSF`"#A%@0`1R6IDO6#X`9O8&F:BLC*FNN-/7G4#\+OZ``S8`@8P"-") >M&3`P4X`P'XHQXX$P`+GVF&:@1:1K.WTHYHQ8U0`BPQY/ZU-=F#4!MOX'3F!? >MTVH+L*QWM=^E!`L%#9C8^'*L^?7&H`>OR-9TH0'0"P4%"K:^=B`2^8,U*@', >M0':F:2_@X:@0+LMN8A>,T$LO6!(9:W5="96`Q\D@/=8?#)3.M`N#JFJ&(C+&1H1J_FDN0`3!P8TBVN`&S>0F1W@)BD&Q``!$(V>Z$W6`"+H&R >MVX=J*@)0V]4``%0`!F3`"S#:$H9J*VVF'3*>]L.AL^+&W)[LZWRULS:[J2-K >M.V7[`R@PD4G-/W"LF0G5L(21BER4:'OQID9F"G`)-LV$XT6$&:P0&+:4:@^\ >M,41!MIEMTI^XH0KHGB!3`'(([GPF"@GT0ZHXZ\-9G0!PP:Y?K!T;0T(C=L40+#.M_ >MH`;X!=12(5X6TQS4I,V!%XH3J-ON@`7`E7;\6+_T#[BQ2K2FL!EO_%[0"G*Y >M.VP'[I0=@W!VX`',"#L&(0RT`1YD$/2`&SA&`\0=Z!TA<$=_;76)KHCTY%"` >M0L``Q.)2]B88MB9+`+@S?L@W6D)&[N"UL&P!@`->$>-A-'"@`9C<@6((8N2# >M4@*$H.EX`/2M$4:%V3G@\1L$C!_&Q`#"@E<0U(3:4"/J4U%<6GB"2E!`0R=X >MJQ<.`%ZX`J?770$:./#*PP<80"\4!L`(2O#;800,X,`!``9MG](3R.4":`&M`P:PP=7`X0``$CT!$7`$,,@12`<:8;2Z'1+@7>YJ#+(:P=6? >MZH&7#0;(P?RH'U!'!,R=%6%W!H@4E1?0R!_4&V4D%M@!-?+U%\BO\#`O+&[8=!\`$+XY!#<M2+OC9XQ@@?&NA06(=9ANH0L"L^7%OQ``J3P,6("7/5I-D9KQQV*D\(14TIQ$ >M;6V6Y0`/1,V``2-0`?*)5^``917\^%,@4$=7AY05XQZ@R#0@6_!D_\4$F#_Y >M3!8<9PZ$!?"..9@"#@,)"(&YP`$P[7L>+F^9EP_D':M!.(!5517\U,PR9`(` >MA101%!@@Y."6RUC/`6LS$S^(1KGMYP`1Z*)84$:YKAY0Z#<%#B@`:!"',$!$CQ7)W)':Z&K16W#-+WVOCA8"R`$% >MT)%/Q33HZ$[V5+`!"0"Y`8$):$\/_1PL`B$`"W(#`2G)IZ+-0O1$$`V"@:KM >M$HX8OM@"#4(`HL!!+^A0X*`7&3`@`2@Z?"$#7X.\PE)\3+_A+C%``H$@*!5U >M.7``@+@H)47A$GZW<=SJ6@]R8OX'\322`@+`QE.9$4]-`"`<#+@#^0S7O\0) >M&+'F?&VL*A.!:G#`!\VQMC9R0``F"@`N@!`@!!B`4!PF6#Z&N`0I&,`H``C@ >M@@9B!K1`+5@&;BM9.?$,.*RL^`HFMG342_EZYQ`GYZ<#V`&7$`&,.8`X`.\@%+()3`!/G[`U:67 >MLEA*4'Z5.8R`!,B8!UPF^KQI1S..[=MD&AQG60]@!H!`,?\,'D#-NI.2E%?4 >M-0WP281`"*Q2)(`+GNQ!SBMM5JU,#^<MMH+WJ00CD('VKNVX?22]UY#S<.;2*N$2Q``:$`)8``G<@`&@!:T``"@/&[`" >M!@00.,&BY<9$`*'28:P%/.`2B*#\WN=]\.)A!".8N[B""#P<MV%K$`RZQH,Q/-@CQ1$"T\`(D$!T@BF%R\5P"$%1WT8(+6.X9<`(_5MTLV[G0 >M`6;S>?<*`B+$G_CD;2NX!!]`I`W(3[`):DXMV("SEK(@(`Y4:*UMLO_!F3<_ >MW%P0X&JSP0'VP3DOQ61$G7.))2^@N00>X+#AISYQ"3J`C!G'7U$3?6$V/*M%*.2T[RS!C_*4Z4GZA``7,''0`@6HU1T >M5@F!$$A"`.#I[Q.:$K`&H1#813%@I")4F#($JQ,9F/H(->H!@"$`!P;AIN,T >MZ<2?#L']0``BX$?ESAGU[!'`CXI_*^I^#``28*8BE#&4/-COE/1Z1=4+%P'4 >M4?9/2D,M@@]QH1J(=$+V`&`1H,4IV)[MIS#%")PB)&`L7RK3&@1&,!C4@)>"5(W`NP0`5@"G\%.4-@B/8"12@/\4H1K( >M(]`)!X`'9/K_J!,$@"*P4A%J3D6"+"4-AKVB@O>2@!-(AA-E[Z$$D7**0(#? >M5WH`0`DZE+QP^?W.(%0"CZ@#'KZBXD^58#D1`%B/$"J!;W1L0%_K^#M+T%L$ >M@!_X4=L3`%!]@V`-YD:BNH0`X!(L)S!0\5^^0;@$N@`Y/*BOGY_\'29`C"X` >M1"DJS2DY"U8`,`#;[>Y_>Z!P]Q&C0I!J9P&\D"I#X.\,`N"7&X)?1#$(="(% >MX$(`D`*<_@!P@\._GE!5(5!TG0'R4_[$WT+&U$'8_*B*$)S"SV\Z.#\A\/F& >MO_2CJD$`[QF_&S(.)R<`,$_03ZI27=V__;@_]^O^W<_[>[_O__W`/_@+_^%/ >M_(M_[T\`2:QU%2T;AOS=EO*W9T7K!30MA=#\@\[S)U%%*_N7!W8&`*A8\!I> >MJ?A[<8@Y,(UP%B^[9O@L"&`!(I`$I,`4&&3='WA-+TP9!L9`&MA07H6!%X_PP!#4/,@"^SC#64M7`M"H8&0[G8?PO-Y\,&T#-CBX)A!Y0!\4L" >ML/P9?\R*5R`^-0#H07ZP'7@%+)-#$``D.8??`2!WD2J/0!]$^G4%)B"JT@BT >M39^/X]`"DBJ,`-U7`IZ`"Y_ZE/JQ@#@@QP#/W("HRB)0[/U],F`/N`@X`@@! >M$$BJ+`*=40S(`P:!%I$3.`+V@(J`V=052`&O7\C1%6@!@(`2N*)$@5U!`_#Z >M,4_MBT#@!HH'05(9H`98,O'1%,@"1G[,SP&`*XR`IL((N`0=`*_?`6#"'0`6RPB8 >M%XR`QMP!L!TM2PL8`RPA`4F`X,8$("Y%P%S2`KP(^M:!!X`.R3]\#[M`##X/MR!IP`PZ#FHK.<+:]/'5`J*2_OCD/#$"0&L`L(0."< >M`"/0G_2U*`;QQYJ$P9@O%^"W0JW,*P,@P$*BR#/@S)ZDP9PQM>[2U6"[K&T+`#[HM]$RH4?1\?][@?#3",#`,P;]"PBP$HD_DDS(!`!'A0Z@0 >M;`%M0!/0!>@S9@OQ,@PF,9D2>7"YT`$D2GM0-;RMU@NLXQ/3`(A+&,/@@`J(?P'^J"#D549<`?X@N+!AH#!N`'QAQ[( >M$]XQ/R%2&`QF,Y?+&)`&D`>I6`S#%GQX70'>]ZP8`(]!`-``I%=]7U9("1Q^ >M"@!U1ZI4`KN1%%@6HBJ5P'5$%IJ%0M\`M0/F!W`ASU<9L`5MI!;6A9(`6X1.'`",@%Y(JD0"D\$*2!>B*H]`I0(`*(50S`E#PX0`6LP)@)4\ >M?R"`Y#(Q:'^#S`ECMXQ)D"$9(!D.@Y0A!&,94B^SC&8XNK2#",$)M`$C^@0"A(?YW+,$!9HOMMC&1(0AP&*P!5M(?5R&^:&9TL\F!T"ARMAT4(>,H>B(0@P`K"&"(%[N!R^,\WAM'9XMOB%[B/W-AN7A"%#--#.SC$%@!M`LUTQ5"/\U3/I**@;_<8?O(7X8'^8Q >MPPM]:!\6B#2,AD@@PHMV`YNB""B?$@?EC##H!R(T!"#J%(;(!`L!OMB:AADL@=^H);S(YX_2T$.B(*H"N)`5:+ZE.ZW'WNCU!P]P$-'F!6R!=X!9Y* >M6"@W@!6.@ZN`JF`"&!)R<"$,ALB>&T%$''YJ(JER"?1%/9M3[`?G>@E >MD"J60'Q$PQ2'7L]Q.`>D`"M,"I,HOH2PS!9S).8L).('(R`Z!`J`]C<:+@0* >M0$,C`(Z(X$MIE"E:@$C2:QAT^$F&3/("Q=@PS@J?F.3D?H??%%35"$V&35:3 >MV)0`7LU7<^V0-69-K&@;K#4/P`+@YU0`*T`$0`?8.!>`"$`!W`$3@`8PYG`` >MT@`0D`(0B\;B'4#I:`#LS07PZD@`.8`40`&<`"%`M!,KQB%KS0)P``0V\PUM >MX^C4-B-`!!`%S#<20&,S`:0`,@!@$P$X.B&`"!`%'#>F#0`@#B0V-``&T.D@ >M.`)`K%A&;34TP`;P+WH[L:):H]@T-EW-I$/H4`"]3BT`!H@`WF)ELP"-.@D` >M:]/E`#;S8<5HHC@[`$`6P-80`!-`#E#7#`$K0)CS`@@"\4!V0TKT`&+-!?#; >M#`&)31$PZPPY)T2L.+"L-0Z`E@-/"`)=@`(@"#P&)``'(`&$`%U-"$#HJ``4 >MP*5#`8@`@,W1V->X-_.-L5@!"`(>@R"@280`,D!K$P'$`.!`"C`#>(T1``DP >M`1B+4X"Q>"Z&`,X5!1#8(%P$@"`@5@@"+E`.,.@\``>`!J`W[HWV605P`F0` >MR8[9:`$(-G[.;],*;35W@)<#XLP`,HZU6`%T`(,CI;/FS`,"@"``%WB,`<`3 >MD-C<`!;`H?/;7`$EC@"PYC@VI0V'$P#X1FN-Z)@(-#:?3F43#FTU5X`AP`!< >M.]G.9V.Q\#>K#>WXV^P!)0X"8`!$`%&C(&`!5(XJRM68`!P`@@!?X#;&-;!. >M!!`$U#:U30@P`TP`(0#PB#EV*+"C["@"4(\6@"'0`&R/D0VV\]ND?3RCEC,^ >M)8L3@#X@']X`%T`&T.-D`!I`8P,!<#D>P`<0`:``9TX)4`2(-2N`:;/M;#4) >M0&<#",2*0=&HTP!L`(*``8`"0`,L`&.S`0B-Y@``(`AL``6`((#:P`&"0(>" >M`M%D">]0`T"H+`M-`"F#I=P3:`<$D`,L!B(P%D`$>`OY@*P`%;@,>8Q0$`T<,C >M,`#$BKM`8K,'H#H'@`D`#MA.%0`&(`8@7/V)#*!$#HP29`/0`$P`-P!ZH^;` >MD);-!2`&[`""0`*0HV$X@L`!<`%L`&M.`B``=``\9`"@-&8`'X"_"-C4-G[C >MU>@-((^GP000!0@"MX`2)`C0/YCC@-#EB`$2P"-P`'PV><%6DP8L`>D`%(`Y >M;@=K30+0Z#PZ)T"8HP5T.C+`;_,)4#>.#FN#.89XHXX`(-:$``AC9:/@2)", >MCB%0`+``$P`/@`-4`*Z-!N#HF``3@!40`1B-\XT5@.'@BQR.K+#H-`"[C@2P >M`UPX[`T-8`'T->VC6$,"Y(O3S58CX5"3G:,AT`'DBW-0)YD`6``8@`8@`7P` >M.L!J(P)X`2I`*ME->@#YXBJ0V)P`4PYR\QV$.[`1N=,2/8;G3KJS[E`+2<^[ >M@_>M/!//QD.Y7#P9CX'`\:0L2"'((_)D0RE/24,LK3SB4%?P\M0!,8_6,?/@/+#1 >M`M2^L06%"E)%\+@`_Z06@+/(2U.+8L,I(C3_DMG#Q?1.D"+/HM@,!WE`&X`E >MB@?AD-ACM]0M5LM2.54"`%F+-30!?@%3Y57Y4]X+L(M0F506!(T0.@$#2"<5 >M)4*P4"X$T@D26`N50CF/=N(9;`-DT#TE!2U&A]"^Z!GH`G7E4Z,\E7$LS_US >M$(@"=25J4PL90]B)`&`,##R&0%TY$EU`9QO!4Z-X!G8`&>0/))3*TR]$\"!W >M"J)EF0U(0780>&(,>08Y@&7Y"QA!B"5$*0R-3QI*)@`&2I"QWWJB4<8`$8\S >M!`V=`=(0-60-83!F`$JY#:T+:M,OF,UT0T,E2]GRD$.!P`0@G;AZ-(^XHZDD >M)P1/;20`O$4"@"KP3X8!0H\G^`8MH*0'SD>ICW?AR)1(CZ'#11^<`>%2X6.QB$O/$`DC*)$PLH\ET5]R0@$+*B"= >M]#ST$/&3$$@G_IORI'=@)PB`X\<6H`%U91Q@!.T\59"WT@')0N(0V!>AU$87 >MD'CR!:DH'5`(4%=.1+705?`%&4">@3M05\83M9#3\P7Y$9Y!-V!95C^U4)F` >MG1``\M-!P`Q8EJ[>!60`W9A(D&>P"UB6=M$%]%"Z$['?09`*6)9ED?($5[I" >M!\$F8%F*&[70#W0(S60'P1U@67*8\L\`,(:HEK91`+`&P'N9@&!X$!P"[I`) >MJ%&Z`+6EV7);YI;5T#746XJ4TPH&`USF*VO3<-E?KCS'91T0"&P`TDFATES" >M1H_13;D>$"@"P+8B`/`!_Z03H","`'J`];)=6H/3T--#'[P!:\#4MD1@'0C#]D@,!&THPCJ*'-%02!_>"'(`F:92YS^X#8%H_6(!TXIL4F/L.6ZEU >MN)7(SY^3!&&978$,4%=2F1<0B5(%900=4+278;8_F!!#(06-6/Y!G,@60`!U >MI6,($1D$%LL7=`D>!/A`74E*U$)KT!M""A`#-!!4%"Z$Z;.7#D!84+^0"H@!6TWB669>!#``>*F_[/5Q$$"@*<"#*F5 >MPU&[2MA&<*EXO!"Y!J-HCM49\9"*P`T@DT,&B*0V:-,ID5L@5-3;?R3[8`J(_J4Y]T >M"-5A':!J_H=?0*9D:HZ58(;F\W/B@3?GJ[D00`+220.A4+:4MN8_D/;50CI! >M8ID(&0100%T9&.6:<`%X,B!X!C%`7=D=#CREP8^2<`(`Z\^QN?\DF[W0!43B >M#)P>4YCI!DA(FD!:J?5=@JZ"1FF+59S/T,4)9^Z6V!"=^5MZG`1!GAER9DI\ >MYCCD9\8`,L_*&1]X!F\B:L1#:GW_9`*@L%PS=$!_5%8FF[.>A51K1IFADT&@ >M47IM>.>;F7'RG7-FR?-W!I=L$[:BK5">3$_AV14@EPO`M\)#D,`]!2/50T(`/Z4/\T$'0>S(()$!`-!#-0Q810A0TZ`8,D4-D$'1&&"7N >M4Q(]-4I(2)1V8D:?0=NT&7T&4=%G]!E8+,E/2,0DQ1,AT<0"7Y1$9PH`\!=U >M!07`$&@0<$0%0)@"`.Q%[*>,TMAA1`4`?\+"P9^:4US$?AI/>@?\J72J12_G >M0:`@<$0&P(_2`6!$!H!%!!9EA5`'5H.`RH5=$0+J$9V?".C-`P"(1EGAND-^ >M9H4H3$:`@.(T\0$"*AG]$0SH/CD59865RFF`@'9&/@4"6A-5GUGA%U(",*"F >MDU&$@#XU0Q$"VJ_\1%GA4K1^WGVCT$[4%20`0R`-&@`D`/+GE\$1)0#VYQ": >M`.B?'&A^T*]01OS!4H2%>H4G*%[$$34`^V2\\(56*C=1&-@95:$-0$VT?7J% >M7\@'ZA6"G[(B1Z0&/)[O9U>@!LQ[J='X=!6P1G+H#`0;R:$)4NTY/JU"MI$< >MBOGE1G9HD:F$J@%]BEB`$:D!.P_Y]HCBB22*'/IT/@6/*(_RJ3RBA!%T](@N >MEM31\8,09'VL$;?D+9%,%Z%]A%].A"K3>=0D:2WL$=2D$'A-I2A]!#1E3/G1 >MQC2U]$M)4DD$L\D'J%(?%*2Q!KT24I2UJ2*JC[6$`PX-2U-#Z=\="3)2>?HI30B(4W> >MZ-0D*'V=*A-^:0]J39>+^L:*SD.&DF(0*15)\VB:Y(S622$2GG2/SD-;TXTD >M)M/2(MI$I,2]72?UDO;4NL0;<2UE.4MDM**;@$5/)'XDE1BC(5 >M2%(IO]0@K2S`D1T:B1:<HENH&J")-D=V:"?:G7RB!P%<((HR-?:1 >M*3J4"J,(07@T-8U+,I(K*AXEI1,IS#2+MJ6V*%QZ$.!'"M)3RHOJI0G!+QJ8 >M6J7Y$BHZC(9,5^DQBA`DHQA@9"J93J:4:65JF5ZFF&EFJIENIIQI9^J9?J:@ >1:6@JFHZFI&EI:IJ>IJ@I``!@ >` >end From apollo-request@umix.cc.umich.edu Mon Nov 20 16:18:06 1989 Message-Id: <8911201827.AA23361@umix.cc.umich.edu> Date: 20 Nov 89 12:20:00 CST From: "DAVE ERSTAD" Subject: SR10 equivalent of '.'? To: "apollo" Back when Apollo's were JLRA (Just Like Real Aegis, something you can't buy anymore) '.' was a pathname qualifier which said 'This is a fully qualified pathname; start at the current wd to find it', with the same sorts of meanings as a pathname starting with '/' (This is a fully qualified pathname; start at the node entry directory to find it). This is one of those forlorn hopes, but is there an SR10 equivalent? Please note that './' is NOT the same thing. The current implementation of './' treats the . as a leaf name; thus, this pathname is not considered fully qualified (I'm not sure what the right technical term other than "fully qualified" is - if there's a better way to convey the concept, let me know). Thus, the behavior is very different in certain cases. For example, if I type the command ./program and program does not exist (for example, if some other operation has failed), Aegis will now execute ~/com/./program if it exists (~/com/./program == ~/com/program). I don't particularily care for that behavior. Also, in JLRA the command '.program' (and './program', when it became available) would execute program the working directory regardless of CSRs; since '.' is a leaf name rather than a special character this no longer happens. My suspicion is that I'm out of luck; but there's always hope. Dave Erstad DERSTAD@cim-vax.honeywell.com Honeywell SSEC From apollo-request@umix.cc.umich.edu Tue Nov 21 04:31:29 1989 Date: 21 Nov 89 07:03:36 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: X Window System: Q/A - Thanks Message-Id: References: <46ee595d.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Just wanted to let you know I and probably lots of others really appreicated the information you posted. In just glancing through the 2 parts I saw answers to at least 3 problems I have run into. I was encouraged to hear that the X merge into SR10.2 is ready. I had thought it would be another year before it would be ready. It looked like this release is based on X11R3, let me know if that is wrong. There was also mention on Motif, will that be provided too? If not, are there any problems building it on the SR10.1 or 10.2 X? You may not want to answer this, but I have to ask. Are there any reasons to keep Sun's XView from porting to the Apollo or maybe it has already been done. Again, thanks for the X information. -- Alan Bair SPS CAD Logic Simulation & Test Motorola, Inc. Austin, Texas ...!cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Wed Nov 22 03:50:49 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8911220821.AA00632@icaen.uiowa.edu> Date: Wed, 22 Nov 89 01:36:17 CST Subject: Re: Rebind of SR9.7 object in SR10.n environment. To: apollo@umix.cc.umich.edu, conliffe@caen.engin.umich.edu WRT posting <46e6018f.f088@beck.engin.umich.edu>: > An executable (lets call it enp) developed and > maintained on an SR9.7 system currently executes > in both SR9.7 and SR10.n (n > 0). > ... > My question is: > if a user uses the SR9.7 ftn compiler and bind, > and if no other libraries need to be resolved, > will a "good" executable be generated, even if > the user IS RUNNING IN SR 10?? Yes, it can be done; Yes, there are a few "gotchas". We have several packages that do things like this, most commonly it is used in simulation programs. A user interface will collect parameters and then create a Fortran subroutine with them, compile and bind it with a simulation engine, and run the whole mess. Boeing's Easy5w is one example of this. You have to use the sr9.7 version of ftn & bind, of course. To facilitate this, we've installed sr9.7_compatibility versions on the sr10 machines and they end up named ftn_sr9.7 & bind_sr9.7, on the sr9.7 machines, we just create links in /com named ftn_sr9.7 & bind_sr9.7 that point to ftn & bind. Then in the shell scripts we only need to refer to ftn_sr9.7 & bind_sr9.7 and they will work regardless of machine OS type. "gotchas": 1) No imbedded uppercase path names allowed. Fortran programmers are notorious for using the CAPS LOCK key. If you have a sr9.7 program that has these, you may be lucky and be able to find them and zap it with db to convert the text to lower case. In worst case you may need to wrap the program in a shell script with the DOWNCASE crutch set to true. 2) Some unreleased system calls broke between sr9.7 & sr10. User programs weren't supposed to use these, but if they did, then they're dead. 3) There are some potential compatability problems with Fortran unformatted data files created by sr9.7 programs and those run on newer systems. 4) There is a problem (bug ?) with sr9.7 Fortran programs trying to open "unstruct" type text files for formatted sequential reads that causes them to crash. As "unstruct" is the default text file type under sr10, this can be a real problem. There may be a patch out for it. 5) Disk space can be a problem. Under sr9.7 a programmer could dimension a huge array to hold worst case size data, and if the user only actually used a small part of it, it would run with minimal disk space requirements. I saw one program that had 256 Mbytes worth of working arrays, but the typical case that our students ran only needed 4 Mbytes. Under sr10 you need to have all the disk space free up-front or the program won't even start. Dave Funk From apollo-request@umix.cc.umich.edu Wed Nov 22 13:27:21 1989 Date: 22 Nov 89 18:26:21 GMT From: murphy%hao.uucp@handies.ucar.edu (Graham Murphy) Organization: Dept. of Pure Mathematics/Univ. of Sydney Subject: DM editor as a process Message-Id: <5431@ncar.ucar.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu [ The following item is posted on behalf of a friend in Australia whose news articles have been disappearing in transit and who feels he has been yelling himself hoarse with nobody able to hear ... please reply directly to him at the address below, or post a follow-up if of general interest. ] Is there a way of using the DM editor from within a process, for example, in place of EDITOR=/ucb/bin/vi for editing from within mail, etc? Note that xdmc ce filename is *not* suitable, because the xdmc command returns immediately instead of waiting for you to exit from the edit pad. I seem to remember this question being asked in the bad old days of SR9, and there being no known answer. Have things improved with SR10? Maybe some sort of trick with "crpad -i" would do it, but I haven't been able to work one out. Note that this would also be useful for when you are logged in as yourself but su'd to someone else in a window: you could edit their files via the DM editor even though you yourself do not have access. Thanks in advance for any suggestions. -- Jim Richardson Department of Pure Mathematics, University of Sydney, NSW 2006, Australia Internet: jimr@summer.su.oz.au ACSNET: jimr@summer.su.oz UUCP: ...!uunet!munnari!summer.su.oz.au!jimr From apollo-request@umix.cc.umich.edu Wed Nov 22 14:04:38 1989 Date: 22 Nov 89 17:15:50 GMT From: georgec%marque%uwm.edu%cs.utexas.edu.uucp@tut.cis.ohio-state.edu Organization: Marquette University - Milwaukee, Wisconsin Subject: IEEE floating point Message-Id: <9611@marque.mu.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu 1. I am told that the Apollo 3500 and 4500 machines support the IEEE floating point standard. Can anyone confirm that and provide more details? 2. If the answer is, "Yes," can anyone tell me how the IEEE capabilities can be accessed from Fortran or C? 3. My specific interest is interval analysis, which uses the directed rounding. Does anyone know of a library of interval arithmetic routines written for the Apollo's? Thanks in advance. George Corliss, Marquette University georgec@marque.mu.edu ... uwvax!marque!georgec (414) 288-6599 From apollo-request@umix.cc.umich.edu Wed Nov 22 15:20:40 1989 Date: Wed, 22 Nov 89 12:27:29 CST From: rackow@antares.mcs.anl.gov Message-Id: <8911221827.AA02928@skeeve.mcs.anl.gov> To: apollo@umix.cc.umich.edu, info-alliant@antares.mcs.anl.gov, krowitz@richter.mcs.anl.gov Subject: Re: LAPACK anyone? The person to check with would be dongarra@ornl.gov it may also be in the netlib archives at netlib@ornl.gov From apollo-request@umix.cc.umich.edu Wed Nov 22 15:41:44 1989 Date: 22 Nov 89 18:47:33 GMT From: cander%unisoft.uucp@ucbvax.Berkeley.EDU (Charles Anderson) Subject: Sendmail dumps core on Apollo Message-Id: <2639@unisoft.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Configuration: Sendmail 5.51 on an Apollo DN 4500 running SR10.1 (bsd4.3). Problem: When receiving mail from UUCP, via rmail, the sendmail process dies with an invalid, non-null pointer. Other items: If I give rmail a simple, local mail message, it gets delivered fine with the hostname "somewhere" prependend to the user name on the From: line. If I give rmail a copy of a UUCP mail message (one stolen from the outgoing UUCP queue), the message gets delivered, but the host name on the From: and From lines gets garbaged (non-printable characters). I have this running correctly on another Apollo node. The sendmail executable is identical (acording to cmp(1)) and I've even run them with the same configuration files. There are no old .fc files lying around to confuse sendmail. rmail and sendmail have resonable modes. For apollo people, tb says the process is dying in main() at line 370; the PC is 0x8a76; the IR is 0x8001; the faulting address is the same as A2 which is 0x2f757372; Any clues? Any other tests that might be useful? -- Charles. {sun, amdahl, ucbvax, pyramid, uunet}!unisoft!cander From apollo-request@umix.cc.umich.edu Wed Nov 22 17:23:43 1989 Date: Wed, 22 Nov 89 15:52:31 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8911222052.AA22950@richter.mit.edu> To: apollo@umix.cc.umich.edu, georgec%marque%uwm.edu%cs.utexas.edu.uucp@tut.cis.ohio-state.edu Subject: Re: IEEE floating point The Apollo DN3000/4000, DN2500/3500/4500, DN560/570/580/590, DN330, and DSP90 all use the Motorola 68881/68882 floating point chips. These chips allegedly conform to the IEEE standard. The functions you want can probably be found in the fpp library (floating point package). See /sys/ins/fpp.ins{.c, .pas, .ftn} and/or The Domain/OS Call Reference Manual (vol 2). -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Nov 22 18:23:53 1989 Date: Wed, 22 Nov 89 13:31:30 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8911221831.AA22671@richter.mit.edu> To: apollo@umix.cc.umich.edu, info-alliant@MCS.ANL.GOV Subject: LAPACK anyone? Does anyone have a copy of the new LAPACK math library (LAPACK is the successor to Linpack and Eispack, designed to reduced memory fetches and to take advantage of parallel and parallel-vector architectures). I heard a test version had been released, and I'm looking for a copy of it to port to our Apollos. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Nov 22 19:15:20 1989 Date: Wed, 22 Nov 89 16:23:36 EST From: crh@apollo.eng.ohio-state.edu (Charlotte Hawley) Message-Id: <8911222123.AA00557@apollo.eng.ohio-state.edu> To: apollo@umix.cc.umich.edu Subject: routing problem I have a single DN2500 (with the 10.2.a OS) in a network of DN4500's, DN3500's, and 1 DN10000 with 10.1 (Unix BSD). I have set an internet number using the rtsvc command and everything is working fine except the DN2500 which I just installed. I set the DN2500 up and set the rtsvc in the rc startup file just like in the rest of my system. The DN2500 comes up with a new and different network number completely different from mine. I have deleted all the hint files, rebooted everything on the network, and even disconnected the the DN2500 from the network - but it always comes up with this strange number. I have called Apollo, their response was that there must be some other Apollo router on the network. This is not true since I have checked with the other system administrators. Does anybody have any ideas? I may have to just leave this DN2500 on it's own. Maybe some of you more experienced Apollo pros can hellllllppppp - Thanks. From apollo-request@umix.cc.umich.edu Thu Nov 23 15:21:25 1989 Date: 23 Nov 89 12:48:37 GMT From: achille%cernvax%mcsun.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Re: DM editor as a process Message-Id: <1149@cernvax.UUCP> References: <5431@ncar.ucar.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, I wrote a program some times ago that does what you want, I called it dmed and use it to replace vi in mail (we all have the same ideas it seems :-). This is not particularly difficult. About using it when you're su'd, sorry, no way. As the program calls pad_$xxxx, the editor is still owned by DM and the person logged into the DM. I would be interested to know if Apollo has any plan to make this work. If you want a copy send me mail (only works at sr10 and later). Achille Petrilli Cray & PWS Operations From apollo-request@umix.cc.umich.edu Fri Nov 24 21:16:14 1989 Date: 24 Nov 89 19:59:31 GMT From: sridhar%usceast%ncrcae%ncrlnk.uucp@uunet.uu.net (M. A. Sridhar) Organization: University of South Carolina, Columbia Subject: "screen" for Apollo's? Message-Id: <2972@usceast.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu A while ago there was some discussion in this newsgroup about a program called `screen,' which could handle multiple vt100 terminal windows on one line. Has anyone successfully implemented this program on an Apollo? I ftp'ed a copy of it from isy.liu.se (130.236.1.3), but failed to get it to work on my Apollo workstation (a DN3000 running SR10.1). The program works fine on our Vax 780 under BSD4.3, but quits with a peculiar error when I compile and run it on the Apollo: bind: I/O error. If someone has a working version of this program available, could you please make it available to me? Thanks in advance. Sridhar -- M. A. Sridhar | Department of Computer Science | ncr-sd!ncrcae ! usceast!sridhar (USENET) University of South Carolina | sridhar@cs.scarolina.edu (CSNET) Columbia, SC 29208 | (803) 777-2427 (Ma Bell) From apollo-request@umix.cc.umich.edu Fri Nov 24 21:21:50 1989 Date: 24 Nov 89 13:06:30 GMT From: janick%bnr%bnrgate%bigsur%bnr-fos%bnr-vpa%utzoo%yunexus%ists%jarvis.csri.toronto.edu%mailrus% (Janick Bergeron) Organization: bnr Subject: Re: DM editor as a process (Source Code included) Message-Id: <109@crk56.bnr.com> References: <5431@ncar.ucar.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <5431@ncar.ucar.edu> jimr@summer.su.oz.au (Jim Richardson) writes: > >Is there a way of using the DM editor from within a process, for example, >in place of EDITOR=/ucb/bin/vi for editing from within mail, etc? > >Note that > > xdmc ce filename > >is *not* suitable, because the xdmc command returns immediately instead of >waiting for you to exit from the edit pad. > Here is a small C program (I called it dmvi) that will pop-up an edit pad and wait for it to be close before exiting. I use it with rn (I am writing this with it) and its perfect. I am running SR10 so I don't know if it'll work under SR9. Usage: dmvi [-w] [-l #] fname -w : Do not wait for window to close -l : Goto specified line number ---------8<------8<-------8<------ Cut here ----8<------8<------ #include #include #include #include #include /***************************************************************************\ ** ** ** Function name: getopt() ** ** Author: Henry Spencer, UofT ** ** Coding date: 84/04/28 ** ** ** ** Description: ** ** ** ** Parses argv[] for arguments. ** ** Works with Whitesmith's C compiler. ** ** ** ** Inputs - The number of arguments ** ** - The base address of the array of arguments ** ** - A string listing the valid options (':' indicates an ** ** argument to the preceding option is required, a ';' ** ** indicates an argument to the preceding option is optional) ** ** ** ** Outputs - Returns the next option character, ** ** '?' for non '-' arguments ** ** or ':' when there is no more arguments. ** ** ** ** Side Effects + The argument to an option is pointed to by 'optarg' ** ** ** ***************************************************************************** ** ** ** REVISION HISTORY: ** ** ** ** DATE NAME DESCRIPTION ** ** YY/MM/DD ------------------ ------------------------------------ ** ** 88/10/20 Janick Bergeron Returns '?' on unamed arguments ** ** returns '!' on unknown options ** ** and 'EOF' only when exhausted. ** ** 88/11/18 Janick Bergeron Return ':' when no more arguments ** ** 89/08/11 Janick Bergeron Optional optarg when ';' in optstring ** ** ** \***************************************************************************/ char * optarg; /* Global argument pointer. */ char getopt( argc, argv, optstring) int argc; char ** argv; char * optstring; { register int c; register char * place; extern char * index(); static int optind = 0; static char * scan = NULL; optarg = NULL; if ( scan == NULL || *scan == '\0') { if ( optind == 0 ) optind++; if ( optind >= argc ) return ':'; optarg = place = argv[ optind++ ]; if ( place[ 0 ] != '-' || place[ 1 ] == '\0' ) return '?'; if ( place[ 1 ] == '-' && place[ 2 ] == '\0' ) return '?'; scan = place + 1; } c = *scan++; place = index( optstring, c ); if ( place == NULL || c == ':' || c == ';' ) { (void) fprintf( stderr, "%s: unknown option %c\n", argv[ 0 ], c ); scan = NULL; return '!'; } if ( *++place == ':' ) { if ( *scan != '\0') { optarg = scan; scan = NULL; } else { if ( optind >= argc ) { (void) fprintf( stderr, "%s: %c requires an argument\n", argv[ 0 ], c ); return '!'; } optarg = argv[ optind ]; optind++; } } else if ( *place == ';' ) { if ( *scan != '\0' ) { optarg = scan; scan = NULL; } else { if ( optind >= argc || *argv[ optind ] == '-' ) optarg = NULL; else { optarg = argv[ optind ]; optind++; } } } return c; } int main( int argc, char ** argv ) { char opt; char * fname = NULL; char * lineno = NULL; char * p; int wait = 1; int usage = 0; pad_$window_desc_t window; ios_$id_t stream; status_$t status; while( ( opt = getopt( argc, argv, "l:w" ) ) != ':' ) { switch ( opt ) { case 'l': if ( lineno != NULL ) { fprintf( stderr, "%s: Option -l : only one line number can be specified.\n", argv[ 0 ] ); usage = 1; } else { for( p = optarg; *p != '\0'; p++ ) { if ( !isdigit( *p ) ) { fprintf( stderr, "%s: Option -l : Invalid character '%c'.\n", argv[ 0 ], *p ); usage = 1; break; } } if ( *p == '\0' ) lineno = optarg; } break; case 'w': wait = 0; break; case '?': if ( fname != NULL ) { fprintf( stderr, "%s: Only one file to edit can be specified.\n", argv[ 0 ] ); usage = 1; } else fname = optarg; break; default: usage = 1; break; } } if ( fname == NULL ) { fprintf( stderr, "%s: No file to edit were specified.\n", argv[ 0 ] ); usage = 1; } if ( usage ) { fprintf( stderr, "Usage: %s [-l lineno] [-w] fname\n", argv[ 0 ] ); exit( -1 ); } /* Create the window in the next DM default region */ window.width = window.height = 0; pad_$create_window( fname, strlen( fname ), pad_$edit, 1, window, &stream, &status ); if ( lineno != NULL ) { pad_$dm_cmd( stream, lineno, strlen( lineno ), &status ); } if ( wait ) pad_$edit_wait( stream, &status ); exit( 0 ); } -- Janick Bergeron Bell-Northern Research (613) 763-5457 janick@crk56.bnr.ca -- Janick Bergeron Bell-Northern Research (613) 763-5457 janick@crk56.bnr.ca From apollo-request@umix.cc.umich.edu Sun Nov 26 15:23:16 1989 Date: 26 Nov 89 09:36:33 GMT From: achille%cernvax%mcsun.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Re: The White Paper Message-Id: <1154@cernvax.UUCP> References: <31904@cci632.UUCP>, <46f42a6a.20b6d@apollo.HP.COM>, <14983@joshua.athertn.Atherton.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <14983@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes: >We are talking about Apollo/HP's white paper comparing Apollo's Networking >system and Sun's Networking system. The version of the paper which I have >is dated Jan. 1988. If a new version has come out since then, my comments >would be out of date. > ....... >0. The paper is out of date by two years at least. Many things have chagned > since it was written. > >1. The paper is marketing propaganda with a thin veneer of technical knowledge. > >2. Never use the paper's arguments in a debate with someone who understands > Sun's RPC: you'll be cut to shreads. The facts about Sun's RPC are often > out of date or inaccurate, the facts about Apollo's RPC are often > technically acurate, but totally misleading. > >Joshua Levy joshua@atherton.com home:(415)968-3718 > {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822 Hi, I'm in no way an RPC expert, I just tried to use both Apollo's NCS and Sun's RPC just for a couple of examples and just to find out their applicability to our environment. I found NCS a much more finished product (but I'm no expert :-). May be is just matter of doc style or whatever else, I don't know. What strikes me, is that there is NO justified technical argument in Joshua's posting. Point 0) refers to a paper dated Jan. 1988, almost 2 years old, point 1) is irrelevant (Sun RPC doc could be taken exactly like this, as marketing propaganda, just like any vendor's doc and report), point 2) is just subjective. I would like to see technical comments, even if they are long, I'm interested and would really love to see them. Please post, I believe there is interest in these sort of things. I'm not working for Sun or Apollo nor I have any interest in them. Thank you, Achille Petrilli Cray & PWS operations From apollo-request@umix.cc.umich.edu Mon Nov 27 09:35:25 1989 Date: 27 Nov 89 09:26:32 GMT From: jimr%extro%metro%basser%munnari.oz.au%samsung%gem.mps.ohio-state.edu.uucp@tut.cis.ohio-state. (Jim Richardson) Organization: Uni Computing Service, Uni of Sydney, Australia Subject: Problems with mail: pager, aliases Message-Id: <865@extro.ucc.su.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu [] We are having two annoying problems with BSD mail at SR10.1. (A) The PAGER option of /bsd4.3/usr/ucb/mail does not work. If within mail one says & set crt=6 & set PAGER=/bin/cat then tries to read a mail item of more than 6 lines, one gets the error messages csh: Permission denied (stream manager/IOS) error: operation attempted on unopened stream (the second message appears only if APOLLO_STATUS is set in the environment). My login shell *is* csh. However, the "csh: Permission denied" message is the same even if I run mail from sh, or if I redefine the environment variable SHELL to be /bin/sh. Of course, I would really like to use crpad or something better rather than cat, but it doesn't seem to make any difference what PAGER program one asks for. (This was APRed on 22 August as 23FBB4A4, but the Sydney office seems to have lost it; I have resubmitted it but maybe the net will provide a quick answer.) (B) How do you get sendmail to accept two or more usernames as the value of an alias? I tried putting the line postmaster: root, jimr in the aliases file, then running newaliases. If I then send mail to postmaster, using /usr/ucb/mail with "set verbose" on, I see the following: postmaster... aliased to root, jimr root... Connecting to .local... root... Sent and that's all: it know about the dual alias, but doesn't send to jimr. What's more, it doesn't simply send to the FIRST username: if the alias is postmaster: jimr, root it STILL sends to root but not jimr! Thanks in advance for any help on these problems. (Thanks also to all who replied to my request for a program to run the DM editor from a process. I will post a summary shortly.) -- Jim Richardson Department of Pure Mathematics, University of Sydney, NSW 2006, Australia ACSNET: jimr@summer.su.oz Internet: jimr%summer.su.oz.au UUCP: ...!uunet!munnari!summer.su.oz!jimr "What do you mean by busting in here like a walrus and gumming up our wedding?" -- D. Runyon From apollo-request@umix.cc.umich.edu Mon Nov 27 15:35:57 1989 Date: 27 Nov 89 18:14:55 GMT From: lau%kings.wharton.upenn.edu%netnews.upenn.edu%eecae%tank.uucp@handies.ucar.edu (Yan K. Lau) Organization: A Private Heaven Subject: Need help with BSD4.3 printing through parallel port... Message-Id: <17339@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Has anyone been able to get lpr printing to work with the parallel port on the Apollo SPE board? I've setup /etc/printcap with /dev/pio. Lpr queues jobs but nothing gets printed. The jobs just sit in the queue. Lpd is running. I'm trying to hook up a HP Laserjet if this makes a difference. Any ideas? Yan. )~ Yan K. Lau lau@kings.wharton.upenn.edu The Wharton School ~/~ 128.91.11.233 University of Pennsylvania /\ Darker grows the moon And shadows steal across the prison of my room From apollo-request@umix.cc.umich.edu Mon Nov 27 19:29:29 1989 Date: 27 Nov 89 22:09:18 GMT From: razdan%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Anshuman Razdan) Organization: Motorola Inc., Austin, Texas Subject: use of postscript on Imagen Printers Message-Id: <2665@monarch.oakhill.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is there any body who has written postscript interpreters for apollo's imagen printers. If yes would you mind sharing info about them or sharing source. I have a horde of users on my back that want my software on apollo. Thanx a lot From apollo-request@umix.cc.umich.edu Mon Nov 27 21:26:01 1989 Date: 28 Nov 89 00:30:03 GMT From: andrews%sdipl%usage%basser%munnari.oz.au%samsung%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Andrew Schonberger) Organization: Software Developments Int'l Subject: Re: DM editor as a process (Source Code included) Message-Id: <176@sdipl.oz> References: <5431@ncar.ucar.edu>, <109@crk56.bnr.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <109@crk56.bnr.com> janick@crk56.bnr.ca writes: >Here is a small C program (I called it dmvi) that will pop-up an edit pad >and wait for it to be close before exiting. > >I use it with rn (I am writing this with it) and its perfect. >I am running SR10 so I don't know if it'll work under SR9. I wrote a similar program, and it is really nice to set the VISUAL variable and then use it from rn or mail. The only difference from 'dmvi' is the use of return code. When editing a new letter, my mailer (mailx) is testing the return code from the editor. If the editor ended abnormally, the mailer does not replace the old message. This is usefull, since I can change my mind while editing, and after pressing the ABORT key I still have the original version. As another small difference, my editor returns abnormally if it could not open the file. Also, I took some extra care to have the pad closed when the program ends. On the other hand, there are no options recognized. I append the source for this editor. I'm using the same variable names as in the 'dmvi' posted before, so people can compose their own flavour. Andrew Schonberger -these are only my private opinions- Software Developments Int'l ACSNET: andrews@sdipl.sdi.oz 845 Pacific Hwy, NSW 2067 UUNET:..!uunet!munnari!sdipl.sdi.oz.au!andrews Australia +61-(2)-411-7200 INTERNET: andrews@sdipl.sdi.oz.au or munnari!sdipl.sdi.oz.au!andrews@uunet.uu.net ---------------------- cut here ---------------------------------- /* Apollo file editor (Andrew Schonberger) Does not use the parent's window. Thus it is more general than "xdmc cv filename". Use this program as: cred filename */ #include #include #include #include #include #include pad_$window_desc_t window; ios_$id_t stream_id; status_$t status; int main (int argc, char *argv[], char *envp[]) { if (argc!=2) { fprintf(stderr, "usage: cred filename\n"); exit(2); }; pad_$create_window ( argv[1] , strlen (argv[1]) , pad_$edit , 1 , window , &stream_id , &status ); if (status_$ok != status.all) { fprintf (stderr, "could not open: %s\n" , argv[1]) ; exit(1); } pad_$set_auto_close (stream_id, 1, true, &status); pad_$edit_wait (stream_id, &status); if (status_$ok != status.all) { fprintf (stderr, "editing aborted on %s\n", argv[1]); ios_$close (stream_id, &status); exit(2); } ios_$close (stream_id, &status); exit(0); } From apollo-request@umix.cc.umich.edu Tue Nov 28 11:25:19 1989 Date: 28 Nov 89 14:45:21 GMT From: brigman%stdc01%rti.uucp@mcnc.org (James Brigman) Organization: Star Technologies, Graphicon Products Division (RTP, N.C) Subject: Adding Centronics Port to DN3000 Message-Id: <580@stdc01.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Can you add a plain-jane serial-parallel PC-bus card to a DN3000 with a reasonable expectation of functionality? What kind of drivers would I need? Will the Context Corporation's Postscript Laser Print Server drive such a port? thanks for any and all info. James Brigman Star Technologies ...!uunet!rti!stdc01!brigman From apollo-request@umix.cc.umich.edu Tue Nov 28 15:28:15 1989 Date: 28 Nov 89 15:30:08 GMT From: collins%nvpna1%prles2%prle%phigate%hp4nl%mcsun.uucp@uunet.uu.net (Donal O Coileain) Organization: Philips Research Labs (Nat Lab), Eindhoven, The Netherlands. Subject: Unix remote dump and restore Message-Id: <792@prles2.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone know if apollo ever plan to support the standard (?) remote dump and remote restore (rdump and rrestore)? I ask because under sr10.1 there is a manual page for rmt (remote magtape protocol module), but no executable, and rmt is a key element when using rdump and rrestore. Donal O Coileain. email - collins@apolloway.prl.philips.nl or collins%nvpna1.prl.philips.nl@uunet.uu.nl -----------------o------------------ SERI - collins:nlwaya01 or COLLINS:NVPNASA From apollo-request@umix.cc.umich.edu Tue Nov 28 15:34:06 1989 Date: Mon, 3 Oct 94 01:37:15 CDT From: lray@civilgate.ce.uiuc.edu (Leland Ray) Message-Id: <9410030637.AA00190@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: Apollo X question We are involved in porting an X client to the Apollos. As I am new to X, I find myself at a loss to deal with the following situation. According to my understanding, the X that is shipped with SR10.2 is a hybrid between releases 2 and 3. Further, I've been told that many release 3 clients run without problems on the Apollos. Which release 3 features has Apollo NOT implemented, and how can I tell if the program in question uses these features? (Yeah, I know about compiling and running things to tell if they work, but I like to do my work in parallel). Thanks in advance for the responses. Leland Ray UIUC - CE Dept. (217) 333 - 3821 From apollo-request@umix.cc.umich.edu Tue Nov 28 17:33:02 1989 Date: 28 Nov 89 19:40:18 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc.uucp@ucsd.edu (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: Adding Centronics Port to DN3000 Message-Id: <22839@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The Apollo SPE (Serial Parallel Expansion) board was, originally, a bottom of the line serial/parallel board to provide just such functionality. However, it had insufficient buffering and/or intelligence so that the DN-xx00 would, typically, spend most of its time servicing interrupts from the SPE when simply printing a file. The 'new' SPE has fairly deep FIFO buffers so as to reduce the number of interrupts per character processed without loss of data on input. Anyway, yes you can add such a board to a DN-3000. The driver would be pretty simple, and you would have all the overhead problems that the Apollo SPE had. One 'gotcha' is that you would probably have to write an extensible streams type manager so that the Context printer server would know how to talk to your board. Examples of such things are available with the Apollo Open Systems Toolkit software package. Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Wed Nov 29 07:42:06 1989 Date: 28 Nov 89 14:52:00 GMT From: mishkin%apollo.hp.com%apollo.uucp@beaver.cs.washington.edu (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: The White Paper Message-Id: <471b93ba.20b6d@apollo.HP.COM> References: <14983@joshua.athertn.Atherton.COM>, <31904@cci632.UUCP>, <46f42a6a.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <14983@joshua.athertn.Atherton.COM>, joshua@athertn.Atherton.COM (Flame Bait) writes: > Had you actually written any Sun RPC programs at the time you wrote the paper? > I got the impression that the author of the White Paper had not actually used > Sun RPCs. I've (a) read all the available documentation, (b) looked closely at several programs (including Sun's samples), (c) tried to write some simple programs, and (d) read the Sun RPC source code. Based on all of that, plus my native intelligence, I think I'm competent to comment. > >Second, I take personal responsibility for > >the content. This is NOT some official pronouncement of HP. > > Too late for that. The copy I got about 10 months ago from Apollo has > Apollo's name all over it, and does not have your name on it at all. > It was an "official pronouncement" of Apollo then :-). I'm afraid I don't have 100% control over what the marketing folks do. I accept your criticism though. > 0. The paper is out of date by two years at least. Many things have chagned > since it was written. Well, first of all, as you've said, *you're* comments might be out of date. In fact they are, since the paper I just distributed is different from the 1/88 version. Given the way the world works, it's just not possible to (a) always update these things as frequently as everyone would like, and (b) purge all existing old copies of documents to make sure no one gets the wrong impression. This is why I put dates on the paper (at least I started doing that some time ago). Give me a break. > 1. The paper is marketing propaganda with a thin veneer of technical knowledge. Remarkable. I wrote the paper. I consider myself to be solely technically oriented. I believe I have a pretty good understanding of all the technical issues. > 2. Never use the paper's arguments in a debate with someone who understands > Sun's RPC: you'll be cut to shreads. The facts about Sun's RPC are often > out of date or inaccurate, the facts about Apollo's RPC are often > technically acurate, but totally misleading. Let's have a list of the parts that are out of date or inaccurate. Based on my best recollections of the various versions of the paper and of Sun RPC, the areas of old versions of the paper that might be out of date relate to RPCGEN. I think at the time of the first version of the paper, there wasn't an RPCGEN at all. Later there was an RPCGEN, but it generated only server stubs, not client stubs. Last I looked, RPCGEN did both stubs, but still allowed only for procedures that take one input parameter and return outputs as function values. Recently, Sun/Novell/Netwise made an announcement that said that the Netwise RPC TOOL stub generator would generate stubs that talk to the Sun RPC runtime. As far as I know, this is not available to the general public, if it's even available at all. (Note that the Netwise interface language is significantly different from Sun's [RPCL]. So much for compatibility.) > If you make a feature by feature comparison, Apollo's networking system > has more features than Sun's. Glad to hear we agree on at least one thing :-) > But, if you want simplicity and ease of > use, then Sun's is the winner. Of course I disagree. I'll happily let the world decide whether in fact for a broad class of applications Sun RPC is either simpler or easier to use. I don't think it's simpler to have to understand when to use UDP and when to use TCP. I don't think it's simpler to have to know whether my input or output parameters are larger than 8K. I don't think it's easier to use when I can only pass one parameter as input thereby requiring me to manually write code to assign my "logical" input parameters into fields of a struct before making a remote call. I don't think it's easier to use when I have to remember when I do and when I don't have to explicitly free storage that the stubs have malloc'd for me under the covers. > For example, Apollo's RPC forces you to use their beefed up UDP transport > protocol. Sun's RPC allows you to use UDP or TCP as a transport protocols, > your choise. See above. > Apollo makes it very difficult to use any interface > language except NIDL. Sun provides RPCGEN, but also makes it easy to > roll your own interface language, if you want to. Apollo makes it very > difficult to use any data representation except their's (NDR). Sun makes > it easy to replace their representation (XDR), if you want to. Sure. And I don't like C, but since the 68000 instruction set is public, I can write a compiler for my own language. What's the point? Most people don't want to write compilers; they want to get their jobs done. They want to be supplied with a competent set of tools; they don't want to reinvent the world. In any case, both Sun RPC and NCS have runtime libraries that export routines used by the stubs. I don't see that either system has any particular advantage in making any happier the small percentage of people who want to design their own interface definition language and implement a compiler for it. > The know this is an emotional issue, but lets face it. Sun's RPC source > code has been freely distributable for three or four years. Apollo's > source is still not freely distributable. Apollo uses a proprietary, > private communications protocol. Sun uses public protocols when possible, > and publishes their protocols, when they are forced to create their own. Both Sun RPC and NCS run (can run) on top of UDP/IP. However, they're both "private communication protocols". The Sun RPC spec doesn't just say "use UDP/IP". It says "use UDP/IP in the following way". That's a protocol. NCS does the same thing. Admittedly, the NCS protocol is more complicated, but that's because it does more things. In any case, the specification for both protocols are public and published. (The book "Network Computing Architecture" just published by Prentice-Hall contains the complete specifications of the NCS RPC protocols.) As far as availability of source code, sure, Sun gives theirs away and we charge for ours. I'll let the market decide whether what we have to offer is worth the price. (Also, I'll be interested to see whether Sun gives away the source the the Netwise RPC TOOL compiler, which they claim is the future of Sun RPC.) -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com From apollo-request@umix.cc.umich.edu Wed Nov 29 08:53:54 1989 Date: 28 Nov 89 14:52:00 GMT From: mishkin%apollo.hp.com%apollo.uucp@beaver.cs.washington.edu (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: The White Paper Message-Id: <471b93ba.20b6d@apollo.HP.COM> References: <14983@joshua.athertn.Atherton.COM>, <31904@cci632.UUCP>, <46f42a6a.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <14983@joshua.athertn.Atherton.COM>, joshua@athertn.Atherton.COM (Flame Bait) writes: > Had you actually written any Sun RPC programs at the time you wrote the paper? > I got the impression that the author of the White Paper had not actually used > Sun RPCs. I've (a) read all the available documentation, (b) looked closely at several programs (including Sun's samples), (c) tried to write some simple programs, and (d) read the Sun RPC source code. Based on all of that, plus my native intelligence, I think I'm competent to comment. > >Second, I take personal responsibility for > >the content. This is NOT some official pronouncement of HP. > > Too late for that. The copy I got about 10 months ago from Apollo has > Apollo's name all over it, and does not have your name on it at all. > It was an "official pronouncement" of Apollo then :-). I'm afraid I don't have 100% control over what the marketing folks do. I accept your criticism though. > 0. The paper is out of date by two years at least. Many things have chagned > since it was written. Well, first of all, as you've said, *you're* comments might be out of date. In fact they are, since the paper I just distributed is different from the 1/88 version. Given the way the world works, it's just not possible to (a) always update these things as frequently as everyone would like, and (b) purge all existing old copies of documents to make sure no one gets the wrong impression. This is why I put dates on the paper (at least I started doing that some time ago). Give me a break. > 1. The paper is marketing propaganda with a thin veneer of technical knowledge. Remarkable. I wrote the paper. I consider myself to be solely technically oriented. I believe I have a pretty good understanding of all the technical issues. > 2. Never use the paper's arguments in a debate with someone who understands > Sun's RPC: you'll be cut to shreads. The facts about Sun's RPC are often > out of date or inaccurate, the facts about Apollo's RPC are often > technically acurate, but totally misleading. Let's have a list of the parts that are out of date or inaccurate. Based on my best recollections of the various versions of the paper and of Sun RPC, the areas of old versions of the paper that might be out of date relate to RPCGEN. I think at the time of the first version of the paper, there wasn't an RPCGEN at all. Later there was an RPCGEN, but it generated only server stubs, not client stubs. Last I looked, RPCGEN did both stubs, but still allowed only for procedures that take one input parameter and return outputs as function values. Recently, Sun/Novell/Netwise made an announcement that said that the Netwise RPC TOOL stub generator would generate stubs that talk to the Sun RPC runtime. As far as I know, this is not available to the general public, if it's even available at all. (Note that the Netwise interface language is significantly different from Sun's [RPCL]. So much for compatibility.) > If you make a feature by feature comparison, Apollo's networking system > has more features than Sun's. Glad to hear we agree on at least one thing :-) > But, if you want simplicity and ease of > use, then Sun's is the winner. Of course I disagree. I'll happily let the world decide whether in fact for a broad class of applications Sun RPC is either simpler or easier to use. I don't think it's simpler to have to understand when to use UDP and when to use TCP. I don't think it's simpler to have to know whether my input or output parameters are larger than 8K. I don't think it's easier to use when I can only pass one parameter as input thereby requiring me to manually write code to assign my "logical" input parameters into fields of a struct before making a remote call. I don't think it's easier to use when I have to remember when I do and when I don't have to explicitly free storage that the stubs have malloc'd for me under the covers. > For example, Apollo's RPC forces you to use their beefed up UDP transport > protocol. Sun's RPC allows you to use UDP or TCP as a transport protocols, > your choise. See above. > Apollo makes it very difficult to use any interface > language except NIDL. Sun provides RPCGEN, but also makes it easy to > roll your own interface language, if you want to. Apollo makes it very > difficult to use any data representation except their's (NDR). Sun makes > it easy to replace their representation (XDR), if you want to. Sure. And I don't like C, but since the 68000 instruction set is public, I can write a compiler for my own language. What's the point? Most people don't want to write compilers; they want to get their jobs done. They want to be supplied with a competent set of tools; they don't want to reinvent the world. In any case, both Sun RPC and NCS have runtime libraries that export routines used by the stubs. I don't see that either system has any particular advantage in making any happier the small percentage of people who want to design their own interface definition language and implement a compiler for it. > The know this is an emotional issue, but lets face it. Sun's RPC source > code has been freely distributable for three or four years. Apollo's > source is still not freely distributable. Apollo uses a proprietary, > private communications protocol. Sun uses public protocols when possible, > and publishes their protocols, when they are forced to create their own. Both Sun RPC and NCS run (can run) on top of UDP/IP. However, they're both "private communication protocols". The Sun RPC spec doesn't just say "use UDP/IP". It says "use UDP/IP in the following way". That's a protocol. NCS does the same thing. Admittedly, the NCS protocol is more complicated, but that's because it does more things. In any case, the specification for both protocols are public and published. (The book "Network Computing Architecture" just published by Prentice-Hall contains the complete specifications of the NCS RPC protocols.) As far as availability of source code, sure, Sun gives theirs away and we charge for ours. I'll let the market decide whether what we have to offer is worth the price. (Also, I'll be interested to see whether Sun gives away the source the the Netwise RPC TOOL compiler, which they claim is the future of Sun RPC.) -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com From apollo-request@umix.cc.umich.edu Wed Nov 29 13:07:20 1989 Date: 29 Nov 89 16:45:55 GMT From: zeleznik%cs.utah.edu%hellgate.utah.edu%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Mike Zeleznik) Organization: University of Utah CS Dept Subject: Re: DM editor as a process Message-Id: <1989Nov29.094555.24366@hellgate.utah.edu> References: <5431@ncar.ucar.edu>, <1149@cernvax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1149@cernvax.UUCP> achille@cernvax.UUCP (achille petrilli) writes: >Hi, I wrote a program some times ago that does what you want, I called >it dmed and use it to replace vi in mail (we all have the same ideas it >seems :-). This is not particularly difficult. > >About using it when you're su'd, sorry, no way. As the program calls >pad_$xxxx, the editor is still owned by DM and the person logged into >the DM. We got around this problem of DM owning the editor in the past with a small shell script wrapped around the "dmed" program. The script simply copied the desired file into /tmp with world write access, and edited it there. On exit, it moved the original file to a .bak version (thus keeping original ACLs), copied the /tmp file back to the original location, and then set the ACLs on this new file from the .bak file. It also had lots of checks to make sure you didn't lose things on abort or error. **** Obviously this is NOT secure **** but it does serve the purpose if security of that sort is not a primary issue. Mike Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617 From apollo-request@umix.cc.umich.edu Wed Nov 29 13:07:50 1989 Date: 29 Nov 89 17:22:29 GMT From: rtp1%tank%accuvax.nwu.edu%mailrus%cs.utexas.edu%usc.uucp@ucsd.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: kermit Message-Id: <6466@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I would like to get kermit running on my DN10000. I am running BSD4.3 under Domain. Where can I get the kermit source and makefiles? Has anybody done a port to Domain (if needed?). From apollo-request@umix.cc.umich.edu Thu Nov 30 04:52:36 1989 Date: 30 Nov 89 03:32:42 GMT From: kerr%tron%umbc3%haven%aplcen%samsung%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Dave Kerr) Organization: Westinghouse Electric Corporation Subject: Re: Problems with mail: pager, aliases Message-Id: <462@tron.UUCP> References: <865@extro.ucc.su.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <865@extro.ucc.su.oz> jimr@extro.ucc.su.oz (Jim Richardson) writes: >[] >We are having two annoying problems with BSD mail at SR10.1. > >(A) The PAGER option of /bsd4.3/usr/ucb/mail does not work. If within mail >one says > [ ...text deleted I'm not at a node to try this out ] >(B) How do you get sendmail to accept two or more usernames as the value of >an alias? I tried putting the line > >postmaster: root, jimr > >in the aliases file, then running newaliases. If I then send mail to >postmaster, using /usr/ucb/mail with "set verbose" on, I see the following: [.. text deleted ] This one I can answer. There's an option in sendmail to include the sender in an alias expansion that includes himself. Set option "m" it in your sendmail.cf file. -- Dave Kerr (301) 765-4453 kerr%tron.UUCP@umbc3.UMBC.EDU from an Internet site kerr@tron.UUCP from a smart uucp mailer From apollo-request@umix.cc.umich.edu Thu Nov 30 11:21:44 1989 Date: Thu, 30 Nov 89 10:32:41 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8911301532.AA01677@richter.mit.edu> To: apollo@umix.cc.umich.edu, idurand%geocub%inria%mcsun%sunic%luth%eru.uucp@bloom-beacon.mit.edu Subject: Re: APOLLO.gmf format You can write a relatively simple Fortran program on your Apollo to solve this problem. Use the GMF_$ calls to open the bitmap file and copy it into a GPR bitmap. Then use the GPR_$READ_PIXELS call to read the pixel values into a memory array and use the standard Fortran (or C) I/O calls to write the array out in whatever format you like. I've got a simple Fortran program that does this for GPR bitmaps which I've included below. Just change the code that reads in the GPR bitmap to use GMF calls. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) ===================================cut here========================= {***************************************************************************** ***** ***** ***** GPRDUMP.PAS ***** ***** ***** ***** Program to read GPR bitmap files and dump the color map and ***** ***** the contents of the bitmap into a unformatted binary data ***** ***** file which can be read by a Fortran program. ***** ***** ***** ***** Version 2 ***** ***** David M. Krowitz September 9, 1988. ***** ***** ***** ***** Copyright (c) 1988 ***** ***** David M. Krowitz ***** ***** Massachusetts Institute of Technology ***** ***** Department of Earth, Atmospheric, and Planetary Sciences ***** ***************************************************************************** } PROGRAM GPR_DUMP; %NOLIST; %INCLUDE '/sys/ins/base.ins.pas'; %INCLUDE '/sys/ins/error.ins.pas'; %INCLUDE '/sys/ins/gpr.ins.pas'; %INCLUDE '/sys/ins/ios.ins.pas'; %INCLUDE '/sys/ins/pgm.ins.pas'; %INCLUDE '/sys/ins/type_uids.ins.pas'; %LIST; CONST {Program version number - should be same as in file header above} version_number = 2; TYPE byte = 0..255; color_map_entry = PACKED RECORD unused: byte; red: byte; green: byte; blue: byte; END; VAR infile: ARRAY[1..80] OF CHAR; infile_len: PINTEGER; outfile: ARRAY[1..80] OF CHAR; outfile_len: PINTEGER; out: IOS_$ID_T; hi_plane: GPR_$PLANE_T; bitmap: GPR_$BITMAP_DESC_T; window: GPR_$WINDOW_T; file_bm: GPR_$BITMAP_DESC_T; { Bitmap descriptor for GPR bitmap file } file_cm: GPR_$COLOR_VECTOR_T; { Color map for the GPR bitmap file } attribs: GPR_$ATTRIBUTE_DESC_T; version: GPR_$VERSION_T; header: GPR_$BMF_GROUP_HEADER_ARRAY_T; groups: INTEGER; created: BOOLEAN; i,j: LINTEGER; { Counters } pixel_size: PINTEGER; { Size of bitmap pixels (1 to 8, or 24) } pixels_24: ARRAY[1..4096] OF GPR_$PIXEL_VALUE_T; { Pixel values read from bitmap } pixels_8: PACKED ARRAY[1..4096] OF CHAR; { 8-bit pixels from bitmap } source: GPR_$WINDOW_T; { Window from which pixels are being read } status: STATUS_$T; BEGIN {Type initial greetings to user.} WRITELN ('This is GPRDUMP Version ',version_number:-1,'.'); WRITELN; {Get the names of the input and output files.} IF (PGM_$GET_ARG (1, infile, status, SIZEOF(infile)) <> 0) THEN BEGIN infile_len := PGM_$GET_ARG (1, infile, status, SIZEOF(infile)); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - argument 1 exists, but bad status? ****'); PGM_$EXIT; END; END ELSE BEGIN WRITE ('Enter name of GPR bitmap file for input: '); READLN (infile); infile_len := SIZEOF(infile); END; IF (PGM_$GET_ARG (2, outfile, status, SIZEOF(outfile)) <> 0) THEN BEGIN outfile_len := PGM_$GET_ARG (2, outfile, status, SIZEOF(outfile)); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - argument 2 exists, but bad status? ****'); PGM_$EXIT; END; END ELSE BEGIN WRITE ('Enter name of unformatted binary file for output: '); READLN (outfile); outfile_len := SIZEOF(outfile); END; { Initialize the GPR library with a 1x1 dummy bitmap in main memory } WITH window.window_size DO BEGIN x_size := 1; y_size := 1; END; GPR_$INIT (gpr_$no_display, 0, window.window_size, 0, bitmap, status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not initialize GPR library ****'); ERROR_$PRINT (status); PGM_$EXIT; END; { Open the output file } IOS_$CREATE (outfile, outfile_len, RECORDS_$UID, IOS_$RECREATE_MODE, [IOS_$WRITE_OPT], out, status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not open output file ****'); ERROR_$PRINT (status); PGM_$EXIT; END; { Get the GPR bitmap into memory along with it's color map } GPR_$ALLOCATE_ATTRIBUTE_BLOCK (attribs, status); GPR_$OPEN_BITMAP_FILE (GPR_$WRITE, infile, infile_len, version, window.window_size, groups, header, attribs, file_bm, created, status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not open GPR bitmap file ****'); ERROR_$PRINT (status); PGM_$EXIT; END; GPR_$INQ_BITMAP_FILE_COLOR_MAP (file_bm, 0, 256, file_cm, status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not read color map for bitmap file ****'); ERROR_$PRINT (STATUS); PGM_$EXIT; END; { Set the current bitmap to be the GPR bitmap file } GPR_$SET_BITMAP (file_bm, status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not make bitmap file the current bitmap ****'); ERROR_$PRINT (STATUS); PGM_$EXIT; END; { Calculate pixel size from the number of bitmap sections and the per-section pixel size } pixel_size := header[0].n_sects*header[0].pixel_size; { Output the size of the bitmap } WRITELN ('Bitmap size is: ', window.window_size.x_size:-1, ' by ', window.window_size.y_size:-1); WRITELN ('Pixel size is: ', pixel_size:-1); IOS_$PUT (out, [IOS_$PARTIAL_RECORD_OPT], window.window_size, SIZEOF(window.window_size), status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not write bitmap size to output file header record ****'); ERROR_$PRINT (STATUS); PGM_$EXIT; END; IOS_$PUT (out, [], pixel_size, SIZEOF(pixel_size), status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not write pixel size to output file header record ****'); ERROR_$PRINT (STATUS); PGM_$EXIT; END; { Output the color map entries if the bitmap is a psuedo-color (1 to 8 planes) bitmap } IF (pixel_size <= 8) THEN BEGIN for i := 0 to 255 do writeln (file_cm[i]); IOS_$PUT (out, [], file_cm, SIZEOF(file_cm), status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not write GPR color map to output file ****'); ERROR_$PRINT (STATUS); PGM_$EXIT; END; END; { Write out the bitmap, one line per record } source.window_size.x_size := window.window_size.x_size; source.window_size.y_size := 1; source.window_base.x_coord := window.window_base.x_coord; source.window_base.y_coord := window.window_base.y_coord; FOR i := 1 TO window.window_size.y_size DO BEGIN GPR_$READ_PIXELS (source, pixels_24, status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not read GPR pixel values for line ',i:-1,' ****'); ERROR_$PRINT (STATUS); PGM_$EXIT; END; FOR j := 1 TO source.window_size.x_size DO BEGIN pixels_8[j] := CHR(pixels_24[j]); IF (pixels_24[j] > 255) THEN WRITELN ('Warning - pixel value greater than 8-bits'); END; IOS_$PUT (out, [], pixels_8, source.window_size.x_size, status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not write pixel values into output file for line ',i:-1,' ****'); ERROR_$PRINT (STATUS); PGM_$EXIT; END; source.window_base.y_coord := source.window_base.y_coord+1; END; { Close up the output file and cleanup } IOS_$CLOSE (out, status); IF (status.all <> STATUS_$OK) THEN BEGIN WRITELN ('**** GPRDUMP: Error - could not close output file ****'); ERROR_$PRINT (STATUS); PGM_$EXIT; END; END. From apollo-request@umix.cc.umich.edu Thu Nov 30 13:17:35 1989 Date: 29 Nov 89 18:28:25 GMT From: andrew%hpqtdla%hpsqf%hpcuhb%hp-ses.uucp@hplabs.hp.com (Andrew Mackenzie) Organization: HP, Queensferry Telecomms (UK) Subject: Polygon Mesh in 3-D ????? Message-Id: <8330001@hpqtdla.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I was wondering if anybody out there has a graphics program (or some source code in 'C' ideally !!) that could be used to draw a 3-D polygon mesh on a HP9000 300 series workstation (using Starbase or X11 ??) , given a set of points in 3-D space. Any special effects; such as shading it, light sources, viewing from different point in space etc would be great !!! Any help to do this would be greatly appreciated !!!!!!!!!!!! Either reply here or E-mail me at andrew@hpqtdlb From apollo-request@umix.cc.umich.edu Thu Nov 30 13:31:30 1989 Date: 30 Nov 89 08:39:16 GMT From: idurand%geocub%inria%mcsun%sunic%luth%eru.uucp@bloom-beacon.mit.edu (Irene Durand) Organization: Greco, Bordeaux, France. Subject: APOLLO.gmf format Message-Id: <1515@geocub.greco-prog.fr> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Here is a description of the problem I would like to solve : I am using a scanner DATACOPY 734 on an APOLLO station under AEGIS (Unix like) with the CONTEXT software from MENTOR GRAPHICS. I would like to display the pictures from the scanner on my PC screen . The scanner is able to save the pictures in the APOLLO.gmf format (Graphic Map File). Once I have transferred this binary file to my PC, the problem is that I don't get the format description of this file. Has somebody got the same problem? Where could I get this format? Thank you..... From apollo-request@umix.cc.umich.edu Thu Nov 30 15:19:16 1989 Message-Id: <8911301912.AA21932@umix.cc.umich.edu> Date: Thu, 30 Nov 89 13:59:08 EST From: Scott Ferguson Subject: Graphics terminal emulation To: APOLLO@UMIX.CC.UMICH.EDU I have a colleague who logs into a Cray, and wants to run a CA-DISSPLA application on his DN4500. He'll need some form of graphics terminal emulation, and he's logging in through an Ethernet, so the terminal emulator can't be directly tied to a serial port. Can anyone recommend an affordable graphics terminal emulation package (preferably better than Tektronix-like things) that runs under the DM and over an Ethernet? Or would it just be cheaper to put CA-DISSPLA on his machine? Personally, I think it would be better to create X applications for the Cray, but that's someone else's job. Thanks a bunch, Scott Ferguson Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 srfergu@erenj.bitnet -Always bark at a dog. From apollo-request@umix.cc.umich.edu Thu Nov 30 19:16:06 1989 Date: 30 Nov 89 22:10:34 GMT From: mathys%dover%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Yves Mathys) Organization: Motorola SPS, Mesa, AZ Subject: troff format on Apollo/Imagen Message-Id: <1961@dover.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu How can I print a troff document on an Imagen printer on Apollo. On SUN/Apple-laser I use the comment : troff -t docname | lpr -t The -t option is documented on Apollo, but if you look the /etc/printcap file, lpr is just a front end to /com/prf which doesn't support the -t option. Any ideas From apollo-request@umix.cc.umich.edu Thu Nov 30 19:20:20 1989 Date: 30 Nov 89 21:14:28 GMT From: shull%kings.wharton.upenn.edu%netnews.upenn.edu%eecae%cps3xx%tank%ux1.cso.uiuc.edu%uwm.edu% (Christopher E. Shull) Organization: Decision Sciences, Wharton School, U of Pennsylvania Subject: FDDI users/planner perspectives wanted for student project... Message-Id: <17522@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu FDDI users/planner perspectives wanted for student project. If you are a FDDI users or planner, a classmate of mine would like to talk to you about your use or plans. Please e-mail me your name, and telephone number, and I will pass them on to him. Thanks in advance! -Chris Christopher E. Shull shull@scrolls.wharton.upenn.edu "Damn the torpedoes! Full speed ahead!" Admiral Farragut, USN, 1801-1870 From apollo-request@umix.cc.umich.edu Thu Nov 30 19:29:59 1989 Date: 30 Nov 89 03:19:32 GMT From: jaeger%madnix%nicmad%astroatc.uucp@speedy.wisc.edu (Jay Jaeger) Organization: State of WI, Dept. of Transportation Subject: Re: Adding Centronics Port to DN3000 Message-Id: <975@madnix.UUCP> References: <580@stdc01.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <580@stdc01.UUCP> brigman@stdc01.UUCP (James Brigman) writes: >Can you add a plain-jane serial-parallel PC-bus card to a DN3000 >with a reasonable expectation of functionality? What kind of >drivers would I need? Will the Context Corporation's Postscript >Laser Print Server drive such a port? We at WI DOT tried parallel ports, and /dev/pio seems to be being asked too much of - interrupt drive PC parallel ports don't seem to work very well. The Apollo SPE card comes with the appropriate drivers. If you want serial, your DN3000 has one built in (I think), and can be addressed as /dev/sio1 (or, if you buy special cable, 3 ports, adding /dev/sio2 and /dev/sio3). Hope this helped. (We GAVE UP on parallel ports...) Jay R. Jaeger State of WI, Department of Transportation madnix!jaeger (for now...) From apollo-request@umix.cc.umich.edu Thu Nov 30 19:34:06 1989 Date: 30 Nov 89 03:11:38 GMT From: jaeger%madnix%nicmad%astroatc.uucp@speedy.wisc.edu (Jay Jaeger) Organization: State of WI, Dept. of Transportation Subject: Re: Need help with BSD4.3 printing through parallel port... Message-Id: <974@madnix.UUCP> References: <17339@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <17339@netnews.upenn.edu> lau@kings.wharton.upenn.edu (Yan K. Lau) writes: > >Has anyone been able to get lpr printing to work with the >parallel port on the Apollo SPE board? I've setup /etc/printcap >with /dev/pio. Lpr queues jobs but nothing gets printed. The >jobs just sit in the queue. Lpd is running. I'm trying to hook >up a HP Laserjet if this makes a difference. Any ideas? > > We at WI DOT also had tons of trouble trying to make parallel printers work under SR9.7. We finally gave up. I think there are some very basic problems involving parallel ports, interrupts and Apollo device drivers (in the kernel, not the ones that are really just filters that Apollo sometimes calls "drivers"). Basically, I think that /dev/pio is being asked to do an impossible task - PC parallel ports do not do well being interrupt driven - one look at all the trouble the MINIX folks have had in that area should convincie you. Very best of luck. (Sorry I don't have a signature line yet, I am: Jay R. Jaeger State of Wisconsin, Dept. of Transportation email (for now): madnix!jaeger (I HOPE) ----------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Thu Nov 30 21:20:51 1989 Date: 30 Nov 89 13:54:00 GMT From: oj%apollo.uucp@beaver.cs.washington.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: using X on sr10.2 Message-Id: <47256e8e.20b6d@apollo.HP.COM> References: <46ee595d.20b6d@apollo.HP.COM>, Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article Alan Bair wrote: >In just glancing through the 2 parts I saw >answers to at least 3 problems I have run into. Would you consider posting your questions (and answers, if you have them)? I figure everybody's going through the same learning curve with Domain/X, so we may as well share information. >I was encouraged to hear that the X merge into SR10.2 is ready. Me too. It seemed like it was taking forever to get done. Vacation time.... >It looked like this release is based on X11R3, let me know if that is wrong. That's correct. Actually, the client code (including libraries) is almost completely vanilla XV11R3. The server is "based on" the MIT XV11R2 server but has had many XV11R3 bugfixes and features added. Xlib is set up as a shareable library, and /usr/lib/libX11.a (which actually lives at /usr/X11/lib/isp_m68k/libX11.a , and is found via an intricate little nest of links which allows our two isps--m68k and Prism--to coexist) is a stub. This makes application executables a bunch smaller. The real Xlib bits are at /lib/x11lib . >There was also mention on Motif, will that be provided too? OSF/Motif isn't bundled with XV11R3. It is due to ship soon as a layered product. It has been released from R&D and is in the process of software manufacturing. >If not, are there any problems building it on the SR10.1 or 10.2 X? OSF/Motif was easy to build (on SR10.2, I didn't try it on SR10.1). We used the 1989.1 compilers, and we incorporated some late bug fixes from our new colleagues at HP Corvallis into our binaries. >You may not want to answer this, but I have to ask. I don't mind answering questions about competitive products, as long as you don't mind remembering that I don't know much about them, and definitely can't make any commitments about them. >Are there any reasons to keep Sun's XView from porting to the Apollo There shouldn't be. If there are problems with our product which prevent any compliant X client code from running, we'd very much like to hear about them. >...maybe it has already been done. I don't know. Does anybody out there in netland? /Ollie Jones (speaking for myself not necessarily for HP Apollo Systems Division) From apollo-request@umix.cc.umich.edu Fri Dec 1 04:15:48 1989 Date: 1 Dec 89 05:08:50 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: Unix remote dump and restore Message-Id: References: <792@prles2.UUCP>, <2661@unisoft.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am currently running a PD rmt library on our SR10.1 nodes, DN4000 & DN10000. With the new versions of wbak/rbak there is a option to write stdout and read stdin. I have combinded these options with a little cat-like routine using the rmt library to dump 8mm tapes on our Suns from the Apollo. I explained the complete system about a month ago in this newsgroup. -- Alan Bair SPS CAD Logic Simulation & Test Motorola, Inc. Austin, Texas ...!cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Fri Dec 1 04:30:47 1989 Date: 1 Dec 89 05:00:05 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Re: using X on sr10.2 Message-Id: References: <46ee595d.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The questions/answers I was refering to were in the previous X posting. I don't recall exactly which ones they were, but if anyone has some problems I would recommend they read through those postings. Concerning building Motif and XView, I expect to try this shortly on our DN4000, SR10.1 & Shared-X. I will let you know about any problems and fixes I run into. Its looking like this group is becomming a better source for Apollo X questions then comp.windows.x. -- Alan Bair SPS CAD Logic Simulation & Test Motorola, Inc. Austin, Texas ...!cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Fri Dec 1 05:20:48 1989 Date: 1 Dec 89 19:42:29 GMT From: andrews%sdipl%usage%basser%munnari.oz.au.uucp@uunet.uu.net (Andrew Schonberger) Organization: sdi Subject: Re: X11R3 - When ? Message-Id: <178@sdipl.oz> References: <1951@cs-spool.calgary.UUCP>, <4671c36f.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I wrote and posted this a month ago, but a local gateway was not forwarding comp.sys.apollo In article <4671c36f.20b6d@apollo.HP.COM> dawson@apollo.HP.COM (Keith Dawson) writes: >At SR10.2, Domain/X11 (the "share-mode" server) v1.2 will be bundled >with base software. This is an R3 server in all the ways that matter. >All supplied clients are the R3 versions, as are all the libraries >(libXt, libX11, libXaw, ...). Did anyone think about makeing these libraries 'installed' ones? I thought about doing it myself, but there are some signs suggesting it's not a trivial task. First, the Domain/OS Programming Environment manual has a warning: Do not confuse INSTALLED LIBRARIES with LIBRARY FILES. Installed libraries are simply object files that are put into workstation's or process's address space. Library files are ... collections of object files. Second, the manpages for 'cc' and 'ld' shortly describe options like: -W0,-pic (for position-independent-code) -A loadhigh (load at higher addresses) -A allmarks (make all sections public) Fine, so an installed library must be a SINGLE object file and must be created carefully. I'd rather like to have this done by Apollo, just as they did with the C library. I assume it's worth doing, not only for the basic libX11, but also for libXt and libXaw. Just watch the increase in size when a compiled object module (using widgets) gets linked with these libraries. When a workstation runs X-windows, there are always a few clients active, and much of their code consists of common widget and Xlib modules. Having a single copy of the library code would reduce memory requirements and make updates/patches more easy to install. Andrew Schonberger -my opinions are private only- Software Developments Int'l INTERNET: andrews@sdipl.sdi.oz.au 845 Pacific Hwy, NSW 2067 or munnari!sdipl.sdi.oz.au!andrews@uunet.uu.net Australia +61-(2)-411-7200 UUNET: ..uunet!munnari!sdipl.sdi.oz.au!andrews ACSNET: andrews@sdipl.sdi.oz From apollo-request@umix.cc.umich.edu Fri Dec 1 05:21:22 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8912010659.AA00706@icaen.uiowa.edu> Date: Fri, 1 Dec 89 00:40:55 CST Subject: Re: Need help with BSD4.3 printing through parallel port... To: apollo@umix.cc.umich.edu In article <17339@netnews.upenn.edu> lau@kings.wharton.upenn.edu (Yan K. Lau) writes: > >Has anyone been able to get lpr printing to work with the >parallel port on the Apollo SPE board? I've setup /etc/printcap >with /dev/pio. Lpr queues jobs but nothing gets printed. The >jobs just sit in the queue. Lpd is running. I'm trying to hook >up a HP Laserjet if this makes a difference. Any ideas? > You should be able to use Lpd to drive your printer if you can hook it to the serial port. I'm not sure that it'll be worth the bother to connect it to the parallel port. Yes SPE does provide a streams interface to the parallel port, but you may also need to use a special "spe_$pio_set_mode" call to configure the handshake options. This is OK within a new program that you're writing, but an existing program like Lpd doesn't know about this suff. It may not even be worth it from a speed stand point. I took one of my prsvr HP LaserJet drivers and converted it from sio to pio output as a test. I found that the SPE parallel I/O was about 20% faster than the serial line at 9600 baud, and about 80% slower than the serial line at 19200 baud. there was also lots more cpu overhead on the node when driving the pio port. This was under sr9.7 with SPE v1.3, I've not tried it under sr10.x. Dave Funk From apollo-request@umix.cc.umich.edu Fri Dec 1 11:24:53 1989 Date: Fri, 1 Dec 89 09:29:47 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912011429.AA03847@richter.mit.edu> To: apollo@umix.cc.umich.edu, jaeger%madnix%nicmad%astroatc.uucp@speedy.wisc.edu Subject: Re: Adding Centronics Port to DN3000 To clear up a few things ... A IBM-PC/XT compatible parallel printer port is fairly easy to add to a DN3xxx/4xxx. The Apollo Serial/Parallel Expansion card (the SPE) has such a port built into it. If your print-server supports the SPE card, it will also work with the XT card -- they are hardware compatible. The driver software for the SPE may be another matter. You *definitely* don't want to drive the XT card (or the SPE) with interrupts turned on. Processing an interrupt for every single character sent will severely degraded the performance of the CPU. You want to use programmed I/O which (although it sits in a loop eating up CPU time waiting for the printer to accept the next character) will not degrade the performance of the other processes on the node. If I/O performance is a big issue, get the Ikon 10092 or 10097 parallel printer boards with DMA capability. The DN3000 only has a single serial port. The special cable adaptor which gives 3 serial ports works only on the DN3500, the DN4000, the DN4500, and the new DN2500. Adding extra serial lines via an add-in board is a pain. The software is much more complicated than for the parallel port. You'd be better off with one of the supported products from someone like Danford, Workstation Solutions, et-al. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Dec 1 11:25:24 1989 Date: Fri, 1 Dec 89 09:39:11 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912011439.AA03867@richter.mit.edu> To: dbfunk@icaen.uiowa.edu Subject: Re: Need help with BSD4.3 printing through parallel port... Cc: apollo@umix.cc.umich.edu I've written GPIO drivers for the IBM-PC/XT parallel card (which is hardware compatible with the SPE parallel port) and the Ikon 10092/10097. I run the XT card using programmed I/O and get roughly 60,000 characters per second through it to our Shinko color printers (running on a DN3000, on a DN3500 the rate goes up to roughly 100,000 bytes/sec). It seems like the SPE driver must be trying to use interrupt driven I/O -- which is a *very* bad idea with a character-at-a-time device. I will be looking into doing a streams manager interface for these GPIO drivers so that the parallel port can be simply referred to a /dev/lpt in the print-server config file ala Michael Lampi's suggestion. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Dec 1 17:40:47 1989 Date: 1 Dec 89 21:22:32 GMT From: dvadura%watdragon%watserv1%utgpu%jarvis.csri.toronto.edu%cs.utexas.edu.uucp@tut.cis.ohio-state. (Dennis Vadura) Organization: Computer Science Dept., University of Waterloo Subject: Problem copying a cartrige tape Message-Id: <18890@watdragon.waterloo.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have a sr97 Maple 4.2 tape and I want to copy it... (on DN3500 running 10.1) so I perform the following..., >/systest/ssr_util/cptape -r test -dev ct >calypso.root[39]% ls -l >total 31825 >-rwxr--r-- 1 root 10792960 Nov 2 15:25 maple42.sr10 >-rwxr--r-- 1 root 10831360 Nov 2 16:35 maple42.sr97 >-rwx------ 1 root 10831360 Dec 1 15:39 test and when I do the rbak I get the error... >calypso.root[40]% rbak -index -from test -all | more >Starting index: > > >** Tape i/o error -- DATA LOST. > > >** UID in block header does not match those read from earlier blocks. >correct uid = 4D41504C.45202020, uid read = 40C8C80D.80018A2C, block 11 >?(rbak) (next_block) Fatal error. similar errors occurr if I copy the file to tape using cptape, and then try the rbak from tape. Anybody have any ideas? What does the UID mismatch mean? I couldn't find it any of the manuals that I have. -thanks -dennis -- -------------------------------------------------------------------------------- Another rescue ruined by the total |Dennis UUCP,BITNET: dvadura@water lack of danger. |Vadura EDU,CDN,CSNET: dvadura@waterloo ================================================================================ From apollo-request@umix.cc.umich.edu Fri Dec 1 21:19:01 1989 Date: 1 Dec 89 23:45:17 GMT From: chen%digital%dover%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Jinfu Chen) Organization: Motorola, Inc. Logic IC Div, Mesa, AZ Subject: Re: using X on sr10.2 Message-Id: <472c86a7.81da@digital.sps.mot.com> References: <46ee595d.20b6d@apollo.HP.COM>, , <47256e8e.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <47256e8e.20b6d@apollo.HP.COM> oj@apollo.hp.com (Ollie Jones) writes: >OSF/Motif isn't bundled with XV11R3. It is due to ship soon >as a layered product. It has been released from R&D and >is in the process of software manufacturing. Could someone (probably marketing) from HP/Apollo tell us more about OSF/Motif support on SR10.2? I'd like to find out which Motif part is in the standard release and which is not (e.g. mwm included with SR10.2 like uwm? ). Also what is Open Dialog's rule in terms of supporting Motif? Suppose I'm going to write a Motif compliant program on Apollo at SR10.2, what kind of products should I buy from Apollo? The X support on SR10.2 is very encouraging, keep on the good work. From apollo-request@umix.cc.umich.edu Sat Dec 2 07:17:30 1989 Date: 2 Dec 89 02:41:15 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov.uucp@ames.arc.nasa.gov (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: Adding Centronics Port to DN3000 Message-Id: <22939@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu An alternative would be to purchase a serial-to-parallel converter (roughly $80 to $120, depending on buffering and other options). Just plug it into a standard serial port and direct the print server to that port. Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Sat Dec 2 07:18:47 1989 Date: 2 Dec 89 02:40:46 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov.uucp@ames.arc.nasa.gov (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: APOLLO.gmf format Message-Id: <22938@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The Apollo Graphics Map File format (GMF) is a binary streams file. There are 4 kinds of records: header records, scanline group records, scanline data records and end-of-bitmap records. Each occurrence of a header record means the beginning of a separate bitmap. The file must have a header record as the first record in the file. Following the header record of a bitmap is a series of scanline group records and scanline data records intermixed. At the end of a bitmap is an end-of-bitmap record. The header record has the following 16-bit fields: 0001 means 'this is a header record' 0001 version number of this file format x x dimension of bitmap in bits y y dimension of bitmap in bits bpi resolution of data in bits per inch, to whatever degree of accuracy is feasibe. (0 means each bit is one dot regardless of dot size of the output device.) The scanline group record has the following fields, both 16-bit: 0002 means "this is a scanline group record" n number of scanline records following A scanline group record signals that the following n records are not to be interpreted as anything but binary data for the bitmap (scanline data records). A scanline data record consists of bits of data for one scanline. Each record is a simple string of bytes, with the frirst byte in a record being the leftmost of the scanline and the first bit in a byte being the leftmost of the byte. Records that do not contain enough bits to equal the x dimension are to be interpreted as padded on the right with zero bits. Records exceeding the x dimension of the bitmap are truncated at the xth bit. If the end-of-bitmap record is encountered before the expected number of scanlines (y dimension) is read, the remaining scanlines are assumed to contain zeroes. Extra scanlines are ignored. One bits are to be printed in black, zero bits are to be printed in white. The end-of-bitmap record has the following format: 0003 means "this is an end-of-bitmap record" -------The above was copied from a memo from Apollo a long time ago.... Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Sat Dec 2 21:18:36 1989 Date: 3 Dec 89 00:28:55 GMT From: troy%usage%basser%munnari.oz.au%samsung%zaphod.mps.ohio-state.edu%mr_plod.cbme.unsw.oz@tut. (Troy Rollo) Subject: Re: DM editor as a process (Source Code included) Message-Id: <508@usage.csd.unsw.oz> References: <109@crk56.bnr.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <109@crk56.bnr.com>, by janick@crk56.bnr.ca (Janick Bergeron): janick> pad_$dm_cmd( stream, lineno, strlen( lineno ), &status ); janick> } janick> if ( wait ) pad_$edit_wait( stream, &status ); janick> exit( 0 ); janick> } It is more effiient to use pad_$create_window. There is one thing to be careful about with this sort of setup - the edit_wait function sometimes returns before the file has been unlocked and made available to other programs. Sometimes the process will return before the file is unlocked too, resulting in a file which cannot be reopened by the calling process. This can be cured by placeing a sleep(2) in front of the exit(0). ___________________________________________________________ troy@mr_plod.cbme.unsw.oz.au Make our greenies useful! The Resident Fascist Put them in the army! From apollo-request@umix.cc.umich.edu Sun Dec 3 03:21:29 1989 Date: 3 Dec 89 06:08:52 GMT From: troy%usage%basser%munnari.oz.au%samsung%zaphod.mps.ohio-state.edu%mr_plod.cbme.unsw.oz@tut. (Troy Rollo) Subject: Re: DM editor as a process Message-Id: <509@usage.csd.unsw.oz> References: <1989Nov29.094555.24366@hellgate.utah.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <1989Nov29.094555.24366@hellgate.utah.edu>, by zeleznik@cs.utah.edu (Mike Zeleznik): zeleznik> We got around this problem of DM owning the editor in the past with a zeleznik> small shell script wrapped around the "dmed" program. zeleznik> The script simply copied the desired file into /tmp with world write zeleznik> access, and edited it there. On exit, it moved the original file to a .bak zeleznik> version (thus keeping original ACLs), copied the /tmp file back to the zeleznik> original location, and then set the ACLs on this new file from the .bak zeleznik> file. It also had lots of checks to make sure you didn't lose things on zeleznik> abort or error. zeleznik> **** Obviously this is NOT secure **** but it does serve the purpose if zeleznik> security of that sort is not a primary issue. It could be made to be secure with a slight modification. If each user has their own group ID, the editor could change the group owner of the temp file to the owner of the DM process. Apollo have kindly created an extra ID which can be used for similar things, the organization ID, so there's really no excuse for leaving a security hole like that. Of course it gets better - with extended ACLs you can simply grant access to the user who owns the display to the file in question... with: chacl user.%.%=rw file and remove with: chacl user.%.%= file ___________________________________________________________ troy@mr_plod.cbme.unsw.oz.au Make our greenies useful! The Resident Fascist Put them in the army! From apollo-request@umix.cc.umich.edu Mon Dec 4 01:21:54 1989 Date: 4 Dec 89 05:15:06 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: kermit Message-Id: <6534@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Following various suggestions I received on getting Kermit running on my DN10000 running BSD 4.3 under SR10.1, I got the apollo-kermit distribution from labrea.stanford.edu. I can't get it to work. It builds fine on the 10000, using "make bsd", and I get the C-kermit prompt, and the response to help queries, etc. looks OK. It won't transfer files though. When I tell it to Receive, I get the prompt to escape back to local mode and send the file, but when I do this on my Mac using Kermit under Versaterm pro, nothing happens. The file transfer never gets initiated. Same happens with Send. The Macintosh kermit I am using works fine with the C-kermit built on tank (an ELXSI running BSD 4.x), and the comm settings revealed by "show" on tank are the same as for my apollo-kermit, except that the maximum packet length on apollo kermit is listed as 32768 for send or receive (vs 1024 and 2048 on tank). Any idea of what is going on? It seems like somehow the DN10000 is never getting the message from my Mac kermit that the file transfer is ready to go. Has anybody successfully used this kermit on a DN10000 under 10.1? From apollo-request@umix.cc.umich.edu Mon Dec 4 15:50:30 1989 Date: 4 Dec 89 17:02:11 GMT From: hedman%cernvax%mcsun.uucp@uunet.uu.net (fredrik hedman) Organization: CERN, Geneva, Switzerland Subject: Using the Apollo INLIB feature with X11 Message-Id: <1170@cernvax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Notes on how to use the X libraries through the INLIB facility. =============================================================== I have been using the Apollo inlib facilities with the X11, Xaw and Xt libraries under 9.7 AEGIS( bsd and sys5 installed); the version of X is the version which Apollo calls: Apollo Domain/X11. Statistics on the size given by 'ls -l': Without INLIB With INLIB 254398 xboxes 2986 xboxes 230798 xbuttonbox 3060 xbuttonbox 226176 xcommand 1756 xcommand 221088 xhw 1264 xhw 50164 xhw0 3106 xhw0 54736 xhw1 4058 xhw1 221038 xhw3 1224 xhw3 221258 xlabel 1466 xlabel 224062 xscroll 2338 xscroll 230764 xsensitive 3036 xsensitive 297952 xtext 2270 xtext 340218 xwidgets 4542 xwidgets Average of the ratio AFTER/BELOW = 0.0192712 or in other words the size of the code is decreased by approximately 98%... There are to things which has to be done to be able to use this facility: 1) produce a file which can be used by the /com/bind -inlib facility, and 2) change makefiles when making applications. Can anyone explain the undefined global below? Well in any case I hope this will help. Any improvements of the Makefile would be welcome. Enjoy ! Fredrik Hedman SPS-LEP Accelerator Computer Control CERN SWITZERLAND 1) INLIB: ( Put these lines into a C-shell script ) ---- BEGIN CUT HERE ----- # # Written by Fredrik Hedman # SPS-LEP Accelerator Computer Control # CERN # SWITZERLAND # # The script does produce a lot of output, but in the # end Undefined Globals: # # XGrabKey First referenced in 2.inlib # # # The time to run the script is about 10 minutes. # # MARK use only lowercase letters in filenames and directories! # 9.7 AEGIS feature... # Make subdirectories for this operation echo Making directories... mkdir ~/inlibs test_inlib cd test_inlib mkdir x11_inlib xaw_inlib xt_inlib # Extract binaries from the respective libraries # and /com/bind them into one big file. # I choose to go from the highest level and down; # see 'DOMAIN binder librarian reference Multilevel binding'. # echo Inlibing Xaw cd xaw_inlib ar x /usr/lib/X11/libXaw.a /com/bind -allmark -exactcase -systype any *.*.bin -binary ../1.inlib echo Xaw was inlibed echo Inlibing Xt cd ../xt_inlib ar x /usr/lib/X11/libXt.a /com/bind -allmark -exactcase -systype any *.*.bin -binary ../2.inlib echo Xt was inlibed echo Inlibing X11 cd ../x11_inlib ar x /usr/lib/X11/libX11.a /com/bind -allmark -exactcase -systype any *.*.bin -binary ../3.inlib echo X11 was inlibed cd .. echo Inlibing Xaw,Xt and X11 into x_inlib /com/bind -allmark -exactcase -systype any *.inlib -binary ~/inlibs/x_inlib echo ~/inlibs/x_inlib has been made ls -l ~/inlibs/x_inlib # Clean up cd .. echo Cleaning up ! /bin/rm -rf test_inlib echo DONE ---- END CUT HERE ----- 2) MAKEFILE ---- BEGIN CUT HERE ----- # Written by Fredrik Hedman # SPS-LEP Accelerator Computer Control # CERN # SWITZERLAND # # Description: A sample makefile which will compile the Xaw # examples using the INLIB feature. The file # ~/inlibs/x_inlib is manufactured in # the script above. # # MARK: The version of the shell should be running bsd when # make is done. # # There will be undefined globals due to the inlib utility... # # The AEGIS command BIND does not # recognize big letters. More precisely, # when mixing AEGIS and UNIX do not use # file names with big letters! # # For more information See manpages of /bin/cc /com/cc, # /com/bind and /com/inlib. CFLAGS = -Ox -c -W0,-NDB,-NMAP,-MGBL,-STD, # x_inlib contains libXaw.a libXt.a libX11.a # This should really be in something like /usr/lib/x11 ( lower case ! ) # but I do not have the rights to put it there. XINLIB = ~/inlibs/x_inlib # My programs may use libraries which have been made in sys5, that is # why I use -SYSTYPE sys5. COMBINDFLAGS = -SYSTYPE sys5 -EXACTCASE -INLIB $(XINLIB) # These are the Xaw examples .... OBJS = xcommand.o hw.o hw1.o xboxes.o xbuttonbox.o xcommand.o\ xhw.o xhw0.o xhw1.o xhw3.o xlabel.o xscroll.o xsensitive.o xtext.o\ xwidgets.o .c.o: cc $(CFLAGS) $< /com/bind $(COMBINDFLAGS) $@ -BINARY $* size $* all: $(OBJS) clean: /bin/rm *.o ---- END CUT HERE ----- From apollo-request@umix.cc.umich.edu Mon Dec 4 19:38:44 1989 Date: 4 Dec 89 20:45:43 GMT From: ief%geocub%inria%mcsun.uucp@uunet.uu.net (Alain Merigot) Organization: Universite Paris Sud Subject: Using the same IP class C adress with a domain-ring and an ethernet Message-Id: <1531@geocub.greco-prog.fr> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu My site has for a short time an internet class C adress. We have a small (15 machines) domain-ring, and an equal number of others computers on an ethernet. Presently (sr10) all the machines communicate without problems with tcp ip. We have 2 different domains, and an apollo gateway. Now, we must renumber all the machines, with respect to our class C adress. My problem is : how can i use the same class C adress with a domain ring and a plain ethernet ? I am not a tcp/ip expert and the documentation did not seem to be very helful (at least to me !). Could somebody give me some hints ? Many thanks in advance, A. Merigot Institut d'Electronique Fondamentale Universite Paris Sud 91405 Orsay Cedex France ...uunet!mcvax!inria!iefups!am am%iefups@lri.lri.fr From apollo-request@umix.cc.umich.edu Mon Dec 4 21:52:00 1989 Message-Id: <8912050203.AA04971@umix.cc.umich.edu> Date: Tue, 5 Dec 89 09:53 H From: Subject: Toshiba Printer Driver for SR10.1 To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK Re: Toshiba (P1351) Printer Driver for SR10.1 A friend of mine is looking for the printer driver. Could someone who has the source help to mail it to me please? Thanx very much. --AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Mon Dec 4 21:57:30 1989 Date: 5 Dec 89 00:44:00 GMT From: dawson%apollo%hp-sdd%ucsdhub.uucp@ucsd.edu (Keith Dawson) Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA Subject: Re: using X on sr10.2 Message-Id: <473bd26d.20b6d@apollo.HP.COM> References: , <47256e8e.20b6d@apollo.HP.COM>, Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article abair@turbinia.oakhill.uucp (Alan Bair) writes: >Its looking like this group is becomming a better source for Apollo X questions >then comp.windows.x. So it should be. Though we all try, the X developers at Apollo have no easier time keeping up with comp.windows.x than you do! I venture to say we all read comp.sys.apollo though, as do lots of folks at Apollo (and outside) who have been developing applications on Domain/X11 for 1+ years. So there should be plenty of help in this newsgroup for X questions specific and generic, novice and xpert. -->Keith ____________________________________________________________ My opinions Keith Dawson Hewlett Packard Co. 508-256-0176 x5739 are my own. Graphics Technology Division / East 300 Apollo Dr. (CHR.03.DE) Chelmsford, MA 01824 USA My convictions Internet: dawson@apollo.hp.com are not for UUCP: {mit-eddie,yale,uw-beaver}!apollo!dawson public display. From apollo-request@umix.cc.umich.edu Tue Dec 5 01:38:03 1989 Date: 5 Dec 89 05:35:09 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: kermit Message-Id: <6561@tank.uchicago.edu> References: <6534@tank.uchicago.edu>, <6560@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu There is still a curious anomaly regarding my fix of my kermit problem. Namely, when I built kermit on tank (a bsd4.3 ELXSI), and accessed it through the SAME incorrectly set terminal server, it worked just fine. Now is that weird or what? From apollo-request@umix.cc.umich.edu Tue Dec 5 01:40:37 1989 Date: 5 Dec 89 05:08:06 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: kermit Message-Id: <6560@tank.uchicago.edu> References: <6534@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <6534@tank.uchicago.edu>, rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) writes: > Following various suggestions I received on getting Kermit running on > my DN10000 running BSD 4.3 under SR10.1, I got the apollo-kermit > distribution from labrea.stanford.edu. I can't get it to work. It > builds fine on the 10000, using "make bsd", and I get the C-kermit > prompt, and the response to help queries, etc. looks OK. It won't > transfer files though. When I tell it to Receive, I get the prompt > to escape back to local mode and send the file, but when I do this > on my Mac using Kermit under Versaterm pro, nothing happens. The > (etc.) After reading the .bwr file, and some experimentation, I found that the problem was that I was dialling in to my Apollo through a tcp/ip based terminal-access system that assumed 7 data bits, even parity. Kermit couldn't put this in "raw mode" since it is out of its control. The .bwr file suggests some scary hacking with telnetd, but fortunately, this system allows you to reset the parity and data bits even if you use telnet. I suppose rlogin -8 would also work. Once I did this, everything worked fine. From apollo-request@umix.cc.umich.edu Tue Dec 5 03:41:50 1989 Date: 4 Dec 89 23:20:18 GMT From: lampi%pnet02%gryphon%hacgate%usc%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: Problem copying a cartrige tape Message-Id: <23078@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > What does the UID mismatch mean? [text deleted] Each block written by WBAK to a tape contains header information in addition to the data being backed up. There is a UID created for the backup set which is written in a section of this header info portion, which RBAK uses to verify that the data it is reading is good, and not a part of something that it doesn't know about. Sounds like you may have skipped a block, missed an end-of-file marker, or the original tape is bad. Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Tue Dec 5 05:17:58 1989 Date: 4 Dec 89 19:13:59 GMT From: news%calgary%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Network News Manager) Organization: Knowledge Science Lab, U. of Calgary, Calgary, Canada. Subject: Re: The White Paper Message-Id: <2197@cs-spool.calgary.UUCP> References: <31904@cci632.UUCP>, <46f42a6a.20b6d@apollo.HP.COM>, <14983@joshua.athertn.Atherton.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu From: sharp@cpsc.ucalgary.ca (Maurice Sharp) Path: cpsc!sharp I have also used both systems (NCS and Suns RPC), and thus have my own comments on the following ... In article <14983@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes: >Too late for that. The copy I got about 10 months ago from Apollo has >Apollo's name all over it, and does not have your name on it at all. >It was an "official pronouncement" of Apollo then :-). Not surprising. They have to do something about Suns blatant rumour spreading techniques (Mr. Sun says Sure WE are UNIX now..., NFS for file sharing, much better than Apollos) >0. The paper is out of date by two years at least. Many things have chagned > since it was written. On both sides. Apollo for the better as well. >1. The paper is marketing propaganda with a thin veneer of technical knowledge Actually, Apollo NCS IS faster than the Suns. I have the source, compiled NCS and NIDL on the Suns, and it WORKED first time. NO bugs (unlike NFS for machine X). Not only that, it took 3 Sun 4 file servers to equal the speed of 6 DN3000's for the Mandel demo. >2. Never use the paper's arguments in a debate with someone who understands > Sun's RPC: you'll be cut to shreads. The facts about Sun's RPC are often > out of date or inaccurate, the facts about Apollo's RPC are often > technically acurate, but totally misleading. Totally agree with you there. >There are two ways to compare Sun's and Apollo's networking systems, >technically and intuitively. Technically would take many pages to handle in >detail, but here is a quick inituitive comparison: > >Apollo's networking system is like VMS's file system; Sun's networking system >is like UNIX's file system. More accurate to say Apollo is like Multics. > VMS is a file system of features. It directly supports all kinds of > special purpose files, it has record based files and stream based files, > all kinds of files. UNIX only has one kind of file, but it is flexible > and easy to use. VMS has features; UNIX has simplicity. Nonsense. The Apollo system is Object Oriented. I would agree with a higher learning curve to master it. However, it is MUCH more flexible and MUCH easier to use. (A file type to mount Vaxes at the root level in abouth 2 weeks, including learning time) > If you make a feature by feature comparison, Apollo's networking system > has more features than Sun's. But, if you want simplicity and ease of > use, then Sun's is the winner. I disagree, see above... >Apollo's RPC is like PASCAL; Sun's RPC is like C. NIDL lets you do Pascal OR C. You are confusing the interface with the implementation. Yes, the Apollo NCS is written in Pascal, but then so is the OS. And not standard Pascal, but one with many C like extensions. The Sun version is C to the core. > Since it was designed as a teaching language, PASCAL forces you to write > programs the way the designer wanted programs written. C is a language > designed to to what the programmer wants, right or wrong. PASCAL says > "this is the best way to do things", C says "here is a flexible language, > do what you want". NCS is a can be used with C including a C interface definition. Are you sure you used it ? > For example, Apollo's RPC forces you to use their beefed up UDP transport > protocol. Sun's RPC allows you to use UDP or TCP as a transport protocols, > your choise. Apollo makes it very difficult to use any interface > language except NIDL. Sun provides RPCGEN, but also makes it easy to > roll your own interface language, if you want to. Apollo makes it very > difficult to use any data representation except their's (NDR). Sun makes > it easy to replace their representation (XDR), if you want to. NCS does that because the machines are TRANSPARENT. Try interfacing with an IBM using Sun. Yech, write your own. For NCS, if it exists on the machine, use NIDL and all is OK :-) >Finally, Sun's RPC system has always been an open system; Apollo's is just >now opening up (and even now, is opening in a marketing/buzzword sense of >the word). > > The know this is an emotional issue, but lets face it. Sun's RPC source > code has been freely distributable for three or four years. Apollo's > source is still not freely distributable. Apollo uses a proprietary, > private communications protocol. Sun uses public protocols when possible, > and publishes their protocols, when they are forced to create their own. Apollo now publishes all their stuff. And they currently use 2 protocols (TCP, and Domain) with others to follow. Sun ??? I do not work for Apollo, nor for Sun. I have used both. And just as a final note, RPC is NOT a good way of distributed processing anyway. If they were smart, they would offer Message passing, or even Linda, or maybee all of them :-) maurice Maurice Sharp MSc. Student University of Calgary Computer Science Department 2500 University Drive N.W. sharp@ksi.cpsc.UCalgary.CA Calgary, Alberta, T2N 1N4 ...!alberta!calgary!sharp From apollo-request@umix.cc.umich.edu Tue Dec 5 07:18:41 1989 Date: 4 Dec 89 14:19:27 GMT From: davidb%braf%inmos%ukc%mcsun.uucp@uunet.uu.net (David Boreham) Organization: none Subject: Re: Problem copying a cartrige tape Message-Id: <3204@ganymede.inmos.co.uk> References: <18890@watdragon.waterloo.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This is apparently a bug in cptape. Mabe someone from HP/Apollo could fill in the details. we have this problem all the time getting tapes from Mentor, who copy Apollo RAI tapes for us. David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb Bristol, England | (us): uunet!inmos.com!davidb +44 454 616616 ex 547 | Internet: davidb@inmos.com From apollo-request@umix.cc.umich.edu Tue Dec 5 11:18:25 1989 Date: 5 Dec 89 14:11:54 GMT From: speyer%joy%cadillac%milano%cs.utexas.edu%usc%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state (Bruce Speyer) Organization: MCC CAD Program, Austin, TX Subject: Re: The White Paper Message-Id: <4564@cadillac.CAD.MCC.COM> References: <46f42a6a.20b6d@apollo.HP.COM>, <14983@joshua.athertn.Atherton.COM>, <2197@cs-spool.calgary.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Bruce Speyer / MCC CAD Program WORK: [512] 338-3668 3500 W. Balcones Center Dr., Austin, TX. 78759 ARPA: speyer@mcc.com From apollo-request@umix.cc.umich.edu Tue Dec 5 11:21:54 1989 Date: 5 Dec 89 14:15:39 GMT From: speyer%joy%cadillac%milano%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Bruce Speyer) Organization: MCC CAD Program, Austin, TX Subject: Re: The White Paper Message-Id: <4565@cadillac.CAD.MCC.COM> References: <46f42a6a.20b6d@apollo.HP.COM>, <14983@joshua.athertn.Atherton.COM>, <2197@cs-spool.calgary.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2197@cs-spool.calgary.UUCP> sharp@ksi.cpsc.ucalgary.ca.UUCP (Maurice Sharp) writes: >>Apollo's RPC is like PASCAL; Sun's RPC is like C. > > NIDL lets you do Pascal OR C. You are confusing the interface >with the implementation. Yes, the Apollo NCS is written in Pascal, >but then so is the OS. And not standard Pascal, but one with many C >like extensions. The Sun version is C to the core. > > NCS is a can be used with C including a C interface definition. >Are you sure you used it ? > >Maurice Sharp MSc. Student NCS and the suite of associated tools that are produced by Apollo are totally implemented in C code. (How else would it be portable?) All coding at Apollo has been in C or C++ for the last three years except that which is tied to Pascal for historical reasons. Bruce Speyer / MCC CAD Program WORK: [512] 338-3668 3500 W. Balcones Center Dr., Austin, TX. 78759 ARPA: speyer@mcc.com From apollo-request@umix.cc.umich.edu Tue Dec 5 17:21:25 1989 Date: 5 Dec 89 20:02:00 GMT From: bowbeer%apollo.uucp@EDDIE.MIT.EDU (Joe Bowbeer) Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA Subject: Re: Using the Apollo INLIB feature with X11 Message-Id: <473fdd42.20b6d@apollo.HP.COM> References: <1170@cernvax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1170@cernvax.UUCP> hedman@cernvax.UUCP (fredrik hedman) writes: > >Notes on how to use the X libraries through the INLIB facility. >=============================================================== > >I have been using the Apollo inlib facilities with the X11, Xaw >and Xt libraries under 9.7 AEGIS( bsd and sys5 installed); the >version of X is the version which Apollo calls: Apollo Domain/X11. > Thanks for the info about using inlib with the sr9.7 Domain/X11. That's version 1.0, by the way. You might be interested to know that in the two following releases, version 1.1(sr10.1) and version 1.2(sr10.2), the inlib-ing of libX11 is done automatically and does not require any makefile changes. Version 1.2 also provides inlib-able versions of the various other x libs. However, since these other x interfaces were/are still in flux, the inlib-ing is not done automatically; simple makefile changes are required if you want the other x libs dynamically loaded instead of bound-in. -------------------------------------------------------------------------------- | Joe Bowbeer Apollo Computer A Subsidiary of Hewlett-Packard (508) 256-6600 | | Internet: bowbeer@apollo.com UUCP: {attunix,decvax,mit-eddie}!apollo!bowbeer | -------------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Tue Dec 5 21:16:37 1989 Date: 5 Dec 89 23:18:42 GMT From: kerr%tron%umbc3%haven.uucp@ames.arc.nasa.gov (Dave Kerr) Organization: Westinghouse Electric Corporation Subject: Re: Using the same IP class C adress with a domain-ring and an ethernet Message-Id: <464@tron.UUCP> References: <1531@geocub.greco-prog.fr> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1531@geocub.greco-prog.fr> am%iefups@inria.inria.fr writes: > > My site has for a short time an internet class C adress. We have a >small (15 machines) domain-ring, and an equal number of others computers >on an ethernet. Presently (sr10) all the machines communicate without problems >with tcp ip. We have 2 different domains, and an apollo gateway. > Now, we must renumber all the machines, with respect to our class C >adress. My problem is : how can i use the same class C adress with a domain >ring and a plain ethernet ? I am not a tcp/ip expert and the documentation >did not seem to be very helful (at least to me !). Could somebody >give me some hints ? You have to have your domain ring be one network and the ethernet be another network Your apollo gateway can run /etc/routed to route between the two networks. These networks can be subnets, where you divide the host portion of your class C address into a network and host portion. This is done with the mask option to /etc/ifconfig. Alternatively you could get another class C address for the token ring. -- Dave Kerr (301) 765-4453 kerr%tron.UUCP@umbc3.UMBC.EDU from an Internet site kerr@tron.UUCP from a smart uucp mailer From apollo-request@umix.cc.umich.edu Tue Dec 5 21:24:30 1989 Date: 5 Dec 89 23:36:00 GMT From: oj%apollo.uucp@eddie.mit.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Installable libraries for X runtime (was Re: X11R3 - When ?) Message-Id: <47409cb4.20b6d@apollo.HP.COM> References: <1951@cs-spool.calgary.UUCP>, <4671c36f.20b6d@apollo.HP.COM>, <178@sdipl.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <178@sdipl.oz> andrews@sdipl.sdi.oz.au (Andrew Schonberger) writes: >In article <4671c36f.20b6d@apollo.HP.COM> dawson@apollo.HP.COM (Keith Dawson) >writes: > >At SR10.2, Domain/X11 (the "share-mode" server) v1.2 will be bundled > >with base software. This is an R3 server in all the ways that matter. > >All supplied clients are the R3 versions, as are all the libraries > >(libXt, libX11, libXaw, ...). > >Did anyone think about making these libraries 'installed' ones? Yes, at SR10.2 you will find these files on your node, for the XV11R3 Xlib, XV11R3 Xt intrinsics, and XV11R3 X Athena Widgets: /lib/x11lib /lib/xtlib /lib/xawlib If you purchase OSF/Motif for Domain/OS (NOT bundled with SR10.2), you'll also get these for the Motif widgets and OSF version of the Intrinsics (trivia question: how many distinct binary-incompatible versions of the Xt Intrinsics exist?): /lib/xmlib1.0 /lib/xtlib1.0 /usr/lib/libX11.a is a stub, so everybody gets to use /lib/x11lib. In other words, calls like XOpenDisplay and XDrawLines are available to all Domain/OS programs (but don't get paged in unless needed). If you want to use the installable libraries for XV11R3 Xt it's best to include the following option when you issue a "cc" command for C compilation: cc -W0,-inlib,/lib/xtlib This informs the compiler that you want it to refer to the named installable library. The "inlib" instruction gets placed in the COFF file emitted by the compiler, and then the loader "ld" uses it to resolve symbols. Finally, when you run the program, the library gets installed for you. All programs running Xt on the same node wind up sharing the same xtlib pages in memory. Notice that "ld" lets you specify the inlib as well, using "-A inlib,/lib/xtlib" , but it's better to let the compiler know because the compiler can tell the difference between programs and data, whereas the loader can't. Beware: saying "-A inlib,/lib/xtlib" in the CC command passes it to the loader; you have to use the -W0 form. If you want to use the installable libraries for XV11R3 xaw, include the following option when you call for C compilation: cc -W0,-inlib,/lib/xawlib The same goes for our Domain/OS OSF/Motif kit, except you say -W0,-inlib,/lib/xmlib1.0 to get the OSF/Motif widgets and the OSF version of Xt intrinsics. xawlib itself knows to use xtlib, and xmlib1.0 knows to use xtlib1.0 . If you want to know, for a given object or executable, what libraries it requires to run, say /usr/apollo/bin/coffdump -Ai filename The clients we shipped with SR10.2 were compiled and loaded with shareable libraries where possible. For example: % coffdump -Ai /usr/X11/bin/xterm /lib/xawlib /lib/xtlib ***INLIB INFORMATION*** Res1 Res2 Res3 Offset Name /usr/X11/bin/xterm: 0 0 0 236 /lib/xtlib 0 0 0 247 /lib/xawlib /lib/xawlib: 0 0 0 2308 /lib/xtlib /lib/xtlib: >I thought about doing it myself, but there are some signs suggesting it's >not a trivial task. It's not totally impossible either; remember there are (1) "inlib"able libraries, like /lib/xawlib and /lib/xtlib (2) automatically inlib'ed libraries, like /lib/x11lib . (3) global libraries, like /lib/syslib.881 and /lib/gprlib . The global libraries are the hard ones, because the loading of statically initialized data is very strange (not to say almost impossible.) >I'd rather like to have this done by Apollo, just as >they did with the C library. Righto! Get SR10.2! /Ollie Jones (speaking for myself, not necessarily for HP Apollo Systems Division) From apollo-request@umix.cc.umich.edu Tue Dec 5 21:25:41 1989 Date: 5 Dec 89 11:11:45 GMT From: ccsmm%gdt%dcl-cs%ukc%mcsun.uucp@uunet.uu.net (Martin Maclaren) Organization: University of Bath, England Subject: locking node 0 Message-Id: <1989Dec5.111145.14231@gdt.bath.ac.uk> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu One of our DN3000 (node id B072) shows the following with a "llkob -r" ----------------------------------------------------------------------------- Home Locking Use Constraint Node Node Pathname R nR_xor_1W B072 0 / R nR_xor_1W B0D8 B072 //anaphe/sys5/etc/passwd.map 2 remote files locked. ----------------------------------------------------------------------------- When doing a "shut", it sometimes carshes with an stcode 8008000D (volume not properly mounted or assigned (OS/disk manager)), and a salvol doesn't fix it. It has 70Mb H/D, 5 1/4" floppy drive, and SPE. Anyone seen this before, or know what is happening? - The machine works ok, so it doesn't seem to be a problem, just odd. Could it be the floppy? Martin From apollo-request@umix.cc.umich.edu Tue Dec 5 23:14:39 1989 Date: 6 Dec 89 00:11:54 GMT From: lori%hacgate%usc%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Lori Barfield) Organization: Hughes Aircraft Company, El Segundo CA Subject: Handy Aegis Script Message-Id: <6354@hacgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Now that I'm a sysadmin on Unix systems instead of an Aegis net, I'm not sure what to do with those oh-so-handy shellscripts I used to depend on. Before I throw them out forever, thought I'd throw one on the net and see if anyone is interested in spending bandwidth on sharing Aegis scripts in this forum. All of my Aegis stuff was written on SR9; better ways may exist now. This script searches a dir for a string, ignoring .bin and .bak files, defaulting to current dir. ---------------------------------- cut here --------------------------------- ############################################################################## # TITLE : pat # # ARG 1 : (required, prompted with omission) pattern to find in non-.BAK # # ASCII files in current directory # # ARG 2 : (optional) directory to search # # ARG 3 : (optional) std FPAT list option (such as -LF or -LM) # # METHOD: scans current (or given) dir for non-.BAK ASCII files, calls FPAT # # AUTHOR: Lori Barfield # # REV. : 3-31-89 # ############################################################################## # # *** set up shell # eon # # *** variables # frag := ''; files := ''; file := ''; junk := ''; listop := ''; ch1 := ''; line := ''; # # *** parameters # if eqs ^1 then read -p 'Enter fragment: ' frag else frag := ^1 endif if eqs ^2 then files := './?*' else files := "^2/?*" endif if eqs ^3 then listop := '-lm' else listop := ^3 endif # # *** execution # /com/ld ^files -nhd -c -lf -ab | /com/fpat -x '.bak' 'bin' | @ while readln line do for ch1 in ^line by char exit endfor # sift out mailboxes and whatever if ((^ch1 <> ' ')) then args ^line | read junk file /com/fpat ^listop -l -i -rmf 20 ^file -p ^frag endif enddo From apollo-request@umix.cc.umich.edu Tue Dec 5 23:18:52 1989 Date: 6 Dec 89 00:27:10 GMT From: lori%hacgate%usc%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: Handy Aegis Script Message-Id: <6355@hacgate.UUCP> References: <6354@hacgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <6354@hacgate.UUCP> lori@hacgate.UUCP (Lori Barfield) writes: >All of my Aegis stuff was written on SR9; better ways may exist now. Here's another that I get asked for sometimes, my version of "phone" for DMs. It takes advantage of an ASCII registry file to convert human names to user ids-- very simple to edit that out if you don't have one. Works on user ids, node numbers, or their fragments. Handy for putting a large message window on a DM with no one currently logged in. (alarm_servers are usually set up only when a user is logged on a node.) ------------------------------------ cut here ------------------------------- # "talk" # creates input-echo pad on display manager currently in use by given person # 1 arg: user name (human or logon) or fragment of same --OR-- # '-n nodenumber' # eon # # "constants" # registry := '/tss/com/registry_list' # # variables # logonID := ''; node_spec := ''; node := ''; num_matches := 0; talk_to_node := false; # # # get argument: user name fragment or node id # if eqs ^1 then /com/args '' 'You forgot to supply recipient. Assuming root.' '' recpnt := 'root' else if eqs ^1 '-n' then node := ^2 talk_to_node := true else recpnt := ^1 endif endif endif # # # talk directly to node # # count node matches; handle errors # if ((^talk_to_node)) then /com/lcnode -b -id | /com/fpat -i -c -rm 2 ^node | read num_matches if ((^num_matches < 1)) then /com/args '' 'No matching node number found in ring.' '' else if ((^num_matches > 1)) then /com/args '' 'Node number fragment not unique in ring.' '' else /com/lcnode -b -id | /com/fpat -i ^node | read node /com/crp /com/crpad -on ^node -me endif endif # # # talk to given user # # count user name matches; handle errors # else /com/fpat -i -c -rm 2 ^registry -p ^recpnt | read num_matches if ((^num_matches < 1)) then /com/args '' 'Recipient name fragment not found in user registry.' '' else if ((^num_matches > 1)) then /com/args '' 'Recipient name fragment not unique in user registry.' '' else # # have logon name; find node logged in to; handle error # /com/fpat -i ^registry -p ^recpnt | read logonID node_spec := ^"/com/lusr | /com/fpat ^logonID"-'*** diskless'-^logonID if eqs ((^node_spec)) then /com/args '' 'Recipient not logged in to a Display Manager.' '' else for node in ^node_spec by word; exit; endfor # 1st word is node /com/crp /com/crpad -on ^node -me endif endif endif endif From apollo-request@umix.cc.umich.edu Wed Dec 6 01:17:15 1989 Date: 5 Dec 89 15:25:19 GMT From: dvadura%watdragon%watserv1%utgpu%attcan.uucp@uunet.uu.net (Dennis Vadura) Organization: Computer Science Dept., University of Waterloo Subject: Re: Problem copying a cartrige tape Message-Id: <19011@watdragon.waterloo.edu> References: <23078@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <23078@gryphon.COM> lampi@pnet02.gryphon.com (Michael Lampi) writes: >> What does the UID mismatch mean? [text deleted] > >Sounds like you may have skipped a block, missed an end-of-file marker, or the >original tape is bad. Hmm, I've since successfully restored from the original tape its entire contents using rbak. Now I can probably create a new tape by using wbak but this seems a bit awkward. Why do I get an error when when I copy the tape image to a file and then try to perform an rbak from the tape image I have on disk. This is the fundamental problem that I do not understand. It was my understanding that when you use /systest/ssr_util/cptape, that what you get on disk is an *EXACT* image of the contents of the tape, if I then take that file and try an rbak from it from disk, or if I copy it to a new tape and then try the rbak from the tape it fails with the previously posted errors. -thanks -dennis -- -------------------------------------------------------------------------------- Another rescue ruined by the total |Dennis UUCP,BITNET: dvadura@water lack of danger. |Vadura EDU,CDN,CSNET: dvadura@waterloo ================================================================================ From apollo-request@umix.cc.umich.edu Wed Dec 6 01:18:21 1989 Date: 6 Dec 89 04:31:48 GMT From: rtp1%tank%accuvax.nwu.edu%mailrus.uucp@tut.cis.ohio-state.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: kermit Message-Id: <6586@tank.uchicago.edu> References: <6534@tank.uchicago.edu>, <6560@tank.uchicago.edu>, <6561@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <6561@tank.uchicago.edu>, rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) writes: > There is still a curious anomaly regarding my fix of my kermit > problem. Namely, when I built kermit on tank (a bsd4.3 ELXSI), > and accessed it through the SAME incorrectly set terminal server, > it worked just fine. Now is that weird or what? This must look mysterious, but what happened was that my report of my kermit fix got bounced by the mailer. The text of the original message follows: After reading the .bwr file, and some experimentation, I found that the problem was that I was dialling in to my Apollo through a tcp/ip based terminal-access system that assumed 7 data bits, even parity. Kermit couldn't put this in "raw mode" since it is out of its control. The .bwr file suggests some scary hacking with telnetd, but fortunately, this system allows you to reset the parity and data bits even if you use telnet. I suppose rlogin -8 would also work. Once I did this, everything worked fine. Actually, just setting parity, stopbits and 8bits wasn't enough. I also had to specify "term download" to this telnet-based system, which must have something to do with the way carriage returns and line feeds are handled. 1 From apollo-request@umix.cc.umich.edu Wed Dec 6 03:15:55 1989 Date: 6 Dec 89 04:35:28 GMT From: joshua%athertn%pyramid%nsc.uucp@decwrl.dec.com (Flame Bait) Organization: Atherton Technology, Sunnyvale, CA Subject: Re: The White Paper Message-Id: <15101@joshua.athertn.Atherton.COM> References: <31904@cci632.UUCP>, <46f42a6a.20b6d@apollo.HP.COM>, <471b93ba.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu % = Achille Petrilli # = Nat Mishkin > = Joshua Levy (me) % I would like to see technical comments, even if they are long, I'm % interested and would really love to see them. Please post, I believe there % is interest in these sort of things. The quickest summary is: there isn't that big a difference. Apollo, Netwise, and Sun all make good RPC systems which will solve almost all of the problems you need solved. This discussion is about which is "better", a hard to define idea when it comes to RPCs. The RPC systems are different, however, which provides lots of stuff to talk about. Unfortunately, I do not have the time to write a good technical comparison of RPC protocols (except speed and reliablity, which I already have written). I'm sorry. I know how valuable one would be. Instead, I'll reply to the technical parts of Nat's posting. % I found NCS a much more finished product (but I'm no expert :-). % May be is just matter of doc style or whatever else, I don't know. I can see how you felt that way, and I do not disagree. In a sense I see Apollo's RPC as one tool, while I see Sun's RPC as several cooperating tools. This gives Apollo the finish you talk about; Sun's architecture gives it greater flexiblity. > If you make a feature by feature comparison, Apollo's networking system > has more features than Sun's. Some of these features include: quit propagation, where if the server routine fails this is echoed back to the client; no time out operation, where you do not need to specifiy a maximum server time out; and a better name service. # I don't think it's simpler to have to understand when to use # UDP and when to use TCP. I don't think it's simpler to have to know # whether my input or output parameters are larger than 8K. In a sense, you're correct; whenever you force someone to do things one way, you save them the hassle of making a choice. I'd rather have choices and easy to use defaults, if I do not really care. # I don't think # it's easier to use when I can only pass one parameter as input thereby # requiring me to manually write code to assign my "logical" input parameters # into fields of a struct before making a remote call. This is a non-issue, at least in my mind. Both Sun and Apollo allow you to pass as many arguments as you want, they use slightly different syntax, but it is no big deal. We can argue about syntax forever, but why bother. # I don't think it's easier to use when I have to remember when I do and when # I don't have to explicitly free storage that the stubs have malloc'd for # me under the covers. Then you'll be happy to know that both Sun and Apollo will free storage automatically for you. (Look at the dealloc action for XDR. I must admit that I've never used this feature myself, but it looks like it does exactly what you want. > Apollo makes it very difficult to use any interface > language except NIDL. Sun provides RPCGEN, but also makes it easy to > roll your own interface language, if you want to. Apollo makes it very > difficult to use any data representation except their's (NDR). Sun makes > it easy to replace their representation (XDR), if you want to. # Sure. And I don't like C, but since the 68000 instruction set is public, # I can write a compiler for my own language. What's the point? Most # people don't want to write compilers; they want to get their jobs done. Using your compiler analogy: C is simple. I understand how to write a compiler for it. Even though I never will, the fact that I could is very important. It shows that the language is understandable. The fact that I could write an XDR compiler shows how easy and straight forward the language is. The fact that I can not for NDR shows the problem; that NDR is compilcated. # They [RPC users] want to be supplied with a competent set of tools; they # don't want to reinvent the world. This is very true, and why I like Sun RPC. It is a collection of useful tools which you can combine to solve many problems. Apollo's RPC is more like a single tool, which also solves many problems. But you can not tailor it to your particular problem (by choosing a transport layer, or a data encoding, or ...) like you can with Sun. # As far as availability of source code, sure, Sun gives theirs away and # we charge for ours. I'll let the market decide whether what we have to # offer is worth the price. # I'll happily let the world decide whether in fact # for a broad class of applications Sun RPC is either simpler or easier # to use. Besides source code availability, there is also "plain old" availablity. Take a company which makes a product for IBM RT, DEC ULTIRX, Suns, Apollos, and HPs, and wants to expand to VMS and IBM PCs. Sun RPC is available on all these platforms; Apollo's RPC is not. (The ringer is the IBM RT, which does not yet have Apollo RPC, as far as I can tell.) The bottom line is that every new UNIX machine coming out now has Sun RPC as part of its standard software bundle. Most of them have Apollo RPC also, but the difference between all and most is important. Since everyone must use NFS (like it or not) everyone has Sun's RPC. If you want to pay $25,000 you can get Apollo's RPC also. Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822 From apollo-request@umix.cc.umich.edu Wed Dec 6 07:14:12 1989 Date: 6 Dec 89 05:53:31 GMT From: joshua%athertn%pyramid%prls%mips%bridge2%jarthur%brutus.cs.uiuc.edu%zaphod.mps.ohio-state.edu% (Flame Bait) Organization: Atherton Technology, Sunnyvale, CA Subject: Re: The White Paper Message-Id: <15103@joshua.athertn.Atherton.COM> References: <46f42a6a.20b6d@apollo.HP.COM>, <14983@joshua.athertn.Atherton.COM>, <2197@cs-spool.calgary.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > = Maurice Sharp from sharp@ksi.cpsc.ucalgary.ca >> = my eariler posting Maurice ended with this note, which I think is imporant and often overlooked, so I'm putting it in front: > And just as a final note, RPC is NOT a good way of distributed processing > anyway. If they were smart, they would offer Message passing, or even > Linda, or maybee all of them :-) I look at RPC as a sort of temporary kludge, which should go away in three to ten years. Right now programmers, compilers, designers, and everything else is set up for sequential execution on one machine. RPC alows us to have sequential execution on several machine, one at a time. Current programmers, designers, testers, compilers, etc. are all very comfortable with that, but it is a waste of hardware. As people and programs become more comfortable with distributed systems, things like Messages and Linda should replace RPC. > Actually, Apollo NCS IS faster than the Suns. I have the source, >compiled NCS and NIDL on the Suns, and it WORKED first time. NO bugs >(unlike NFS for machine X). Not only that, it took 3 Sun 4 file >servers to equal the speed of 6 DN3000's for the Mandel demo. I'm not comparing hardware or distributed file systems, just RPC protocols. I didn't now anyone used the file system part of NCS. I thought even Apollo used Sun's NFS. Your last sentence seems to say that Sun's are twice as fast as Apollos, so I'm sure you did not mean it :-) I assume that "faster" refers to installation time, not run time speed. The current Apollo RPC system is 4 TIMES slower than Sun RPC system for 8K packets, which happens to be the size my application uses. That is using Sun/TCP (for reliablity as good or better than Apollo). If I use Sun/UDP, it is 8 times faster than Apollo, but not as reliable. Note to Nat: I know that Apollo is coming out with version 1.5 "Real Soon Now", but it is still in beta test and you can not buy it, so I'm still giving out speeds for version 1.1. > Nonsense. The Apollo system is Object Oriented. I would agree > with a higher learning curve to master it. However, it is MUCH more > flexible and MUCH easier to use. I assume you are refering to Apollos distributed file system, not their RPC system. If you are refering to their RPC system you are wrong. Object Oriented means three things: data encapsulation, inheritence, and polymorphism. Many OO people seem to think you need all three, but I think that inheritence and one other qualifies a system as OO. Apollo RPC has only data encapsulation, not inheritence or polymorphism. By that definition Sun RPC is "Object Oriented" also. I refer to this as "buzzword object oriented", you give your routines object oriented names like (object$_method for example) and a consistent naming scheme, (UUIDs for example), and claim your system is "object oriented". I like Apollo's routine naming system. UUIDs (with their location broker) is one of Apollo's best features, much better Sun's counter part, but they do make make the system object oriented. >>Apollo's RPC is like PASCAL; Sun's RPC is like C. > > NIDL lets you do Pascal OR C. You are confusing the interface >with the implementation. I'm sorry; I must not have been clear. I meant that PASCAL and Apollo's RPC were paternalistic ("father knows best"), while C and Sun's RPC were not ("I'll do what I'm told, even if I do not like it"). I do not want to talk about interface langauge syntax (everyone has their own favorite), but I will say one sentence: I thought that both NIDL's PASCAL syntax and its C syntax looked like PASCAL, and were almost identical. This is personal taste, however, just look at example code from all three to see which one you like better, RPCGEN, NIDL(C), or NIDL(PASCAL). >> For example, Apollo's RPC forces you to use their beefed up UDP transport >> protocol. Sun's RPC allows you to use UDP or TCP as a transport protocols, >> your choise. > NCS does that because the machines are TRANSPARENT. Try >interfacing with an IBM using Sun. Yech, write your own. For NCS, if >it exists on the machine, use NIDL and all is OK :-) Which IBMs are you talking about? I use NFS on an IBM RT everyday, and I'm sure it is available for IBM PCs and mainframes as well. I think your facts are wrong or out of date, or maybe you are refering to on specific IBM machine which is not supported (AS/400?). Transparency is nice, but look at the price: It forces Apollo RPC to use the same transport protocol, even when the machine supports several. So on a UNIX machine I must use their protocol, even though my application could never run on an IBM mainframe, for example. But Apollo RPC will not support more protocols because the IBM mainframe can not. (By the way, I'm not convinced that Apollo forces one transport protocol for transparency. I think you could have several transport protocols, and still have transparency. The RPC system would use a default protocol if your requested protocol was not available to a given machine. Nat, what's the word on this?) Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822 From apollo-request@umix.cc.umich.edu Wed Dec 6 13:39:33 1989 Date: 6 Dec 89 16:03:14 GMT From: dennis%Peanuts.uucp@nosc.mil (Dennis Cottel) Subject: lcnode bug (was Handy Aegis Script) Message-Id: <1565@nosc.NOSC.MIL> References: <6354@hacgate.UUCP>, <6355@hacgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Warning: Apollo complaint follows. lori@hacgate.UUCP (Lori Barfield) sends us a nifty shell script including some constructions like: > /com/lcnode -b -id | /com/fpat -i -c -rm 2 ^node | read num_matches The trouble with this is that if you have an Apollo internet--for instance, several rings connected via Ethernet--commands like lcnode and lusr display only information for the local subnet. There is no option on them to display all the connected nodes in the Apollo internetwork. This means that when you go to an internetwork, suddenly all the shell scripts in which you used tricks like the above to find all the nodes, or update all the disks in the network, don't work anymore and have to be modified. And changed again when you add another subnet. Some of the nice network transparency that is Apollo's strength has been taken away. I complained about this to the Apollo hotline, as well as submitted an APR. Apollo's response was essentially, "That's the way it works." Nuts. Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis From apollo-request@umix.cc.umich.edu Wed Dec 6 14:38:31 1989 Message-Id: <8912061643.AA12779@umix.cc.umich.edu> Date: 6 Dec 89 10:26:00 CST From: "DAVE ERSTAD" Subject: Re: The White Paper To: "apollo" > > Actually, Apollo NCS IS faster than the Suns. I have the source, > >compiled NCS and NIDL on the Suns, and it WORKED first time. NO bugs > >(unlike NFS for machine X). Not only that, it took 3 Sun 4 file > >servers to equal the speed of 6 DN3000's for the Mandel demo. > > I'm not comparing hardware or distributed file systems, just RPC protocols. > I didn't now anyone used the file system part of NCS. I thought even > Apollo used Sun's NFS. Your last sentence seems to say that Sun's are > twice as fast as Apollos, so I'm sure you did not mean it :-) I'm sure Joshua meant exactly what he said. The DN3000 is (was) an entry level machine. The equivalent can be purchased today for under $5000. The Sun 4 is a much bigger, more expensive machine. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Wed Dec 6 15:30:56 1989 Date: 6 Dec 89 16:22:54 GMT From: hedman%cernvax%mcsun.uucp@uunet.uu.net (fredrik hedman) Organization: CERN, Geneva, Switzerland Subject: Problem using Xaw scrollbar widget. Message-Id: <1186@cernvax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi ! I would like to use the Xaw scrollbar to implement a valuator. However, when I try to read the 'final' value directly from the scrollbar widget instance using the routine XtGetValues() I always get back 0.0. ( See GetFinalValue routine below ) Is this normal ? If so, why is the value 0.0 and if not why does XtGetValues not work? The version which I'm using is Apollo Domain/X11 which is somewhere between X11.R2 and X11.R3. I'm running on an DN3000 under 9.7. Please answer to me by e-mail and I'll post a summary. Thanks in advance. Fredrik Hedman Below is sample program using Xaw widgets which will clarify the problem. ------ BEGIN CUT HERE ----- #ifndef lint static char rcsid[] = "$Header: xscroll.c,v 1.6 88/02/14 15:13:11 rws Exp $"; #endif lint #include #include #include #include #include #include #include /* Command line options table. Only resources are entered here...there is a pass over the remaining options after XtParseCommand is let loose. */ static XrmOptionDescRec options[] = { {"-label", "label", XrmoptionSepArg, NULL}, {"-horiz", "scrollbar.orientation", XrmoptionNoArg, "horizontal"} }; char *ProgramName; /* * Report the syntax for calling xcommand */ Syntax() { fprintf( stderr, "Usage: %s\n", ProgramName ); } void Thumbed(w, closure, top) Widget w; caddr_t closure; float top; { printf( "thumbed to %f%%\n", 1.0 - top ); } void Scrolled(w, closure, call_data) Widget w; caddr_t closure; /* Not used */ int call_data; /* Not used*/ { /* Do nothing */ } void GetFinalValue(widget, closure, callData) Widget widget; caddr_t closure; /* Scrollbar widget */ caddr_t callData; /* Not Used */ { Arg arg[1]; float top = 0.5; /* This seems to mean XtNtop is really = 0.0 Why do I not get the value which Thumbed gives me? */ printf("Top before: %.2f ", top); XtSetArg(arg[0],XtNtop,(XtArgVal)&top); XtGetValues((Widget)closure, arg, ONE); printf("Top after: %.2f\n", top); } void main(argc, argv) unsigned int argc; char **argv; { Widget top, form, bar, com; Arg arglist[10]; Cardinal i; ProgramName = argv[0]; top = XtInitialize(NULL,"Demo",options,XtNumber(options),&argc,argv); if (argc != 1) Syntax (); form = XtCreateManagedWidget("form",formWidgetClass,top,NULL,NULL); i = ZERO; XtSetArg(arglist[0],XtNlength,(XtArgVal)200); ++i; bar = XtCreateManagedWidget( "scrollbar", scrollbarWidgetClass, form, arglist, i ); XtAddCallback(bar,XtNscrollProc,Scrolled,NULL); XtAddCallback(bar,XtNthumbProc,Thumbed,NULL); XtScrollBarSetThumb( bar, 0.5, 1.0 ); i = ZERO; XtSetArg(arglist[0],XtNfromHoriz,bar); ++i; com = XtCreateManagedWidget("Get Value",commandWidgetClass,form, arglist, i ); XtAddCallback(com,XtNcallback,GetFinalValue,(caddr_t)bar); XtRealizeWidget(top); XtMainLoop(); } ------ END CUT HERE ----- From apollo-request@umix.cc.umich.edu Wed Dec 6 17:47:18 1989 Date: 6 Dec 89 14:09:00 GMT From: mishkin%apollo.hp.com%apollo.uucp@eddie.mit.edu (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: The White Paper Message-Id: <4743a967.20b6d@apollo.HP.COM> References: <31904@cci632.UUCP>, <46f42a6a.20b6d@apollo.HP.COM>, <14983@joshua.athertn.Atherton.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <2197@cs-spool.calgary.UUCP>, news@calgary.UUCP (Network News Manager) writes: > From: sharp@cpsc.ucalgary.ca (Maurice Sharp) > >Apollo's networking system is like VMS's file system; Sun's networking system > >is like UNIX's file system. > > More accurate to say Apollo is like Multics. Ah, the truth will out! > NIDL lets you do Pascal OR C. You are confusing the interface > with the implementation. Yes, the Apollo NCS is written in Pascal, > but then so is the OS. And not standard Pascal, but one with many C > like extensions. The Sun version is C to the core. THE NCS IMPLEMENTATION IS WRITTEN IN PORTABLE C AND HAS BEEN MADE TO RUN ON MACHINE FROM CRAYS TO PC'S. I put that in all caps because I just couldn't bear to have straightjacketed myself to the requirement of maximum portability and then have people think otherwise. Just want to make it clear. NIDL supports two input languages: one that looks like (ANSI) C and one that looks like Pascal. The non-Unix parts of DOMAIN/OS are written largely in Pascal. > Apollo now publishes all their stuff. And they currently use 2 > protocols (TCP, and Domain) with others to follow. Sun ??? Small correction: NCS runs on top of UDP, not TCP. From apollo-request@umix.cc.umich.edu Wed Dec 6 18:54:20 1989 Date: Wed, 6 Dec 89 14:18:11 CST From: lray@civilgate.ce.uiuc.edu (Leland Ray) Message-Id: <8912062018.AA09605@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: Node 0 locking a directory Ahh, the infamous node 0 lock. The short answer: get rid of the lock using /com/ulkob. It will do it regardless of the node ID locking the object. The long answer: say a user has locked a file called /meat/steak. Then the user decides to change the name of the directory from /meat to /food. So, the user, while locking steak, changes the directory using chn (or mv). The next time he tries to create a file in /food, he will be very depressed, for the node will appear to hang for a while and do nothing. Well, if you view the lock table from the offending machine, you will see a directory locked by node 0. This used to happen all the time at SR9. I just tried it at SR10 and it no longer happens, so I would wager that this is fixed. Just spendin' my days, Leland Ray Systems Administrator Soakin' in them cathode rays. UIUC - Dept. Civil Engineering (217) 333-3821 From apollo-request@umix.cc.umich.edu Wed Dec 6 19:22:31 1989 Date: Wed, 6 Dec 89 17:30:08 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912062230.AA10665@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: beta test sites wanted I have nearly completed an SR10 print server for the HP Paintjet color inkjet printer. I am looking for sites that would be interested in testing the software and giving me feedback on bugs/features/misfeatures. I will be using this driver as a prototype for writing several other drivers (HP Paintjet XL, Deskjet, Deskjet+, Shinko CHC series, etc) so I am looking for feedback on general print server features in addition to specific complaints about the Paintjet. If you are interested in testing this software, drop me a line (email) or call me at (617) 253-6180. The beta-test release should be ready in a week or two. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Dec 6 19:32:44 1989 Message-Id: <8912062227.AA00850@umix.cc.umich.edu> Date: 6 Dec 89 17:15:00 EST From: "Jeffery Hojnicki" Subject: RE: lcnode bug (was Handy Aegis Script) To: "apollo" Dennis Cottel writes: >lori@hacgate.UUCP (Lori Barfield) sends us a nifty shell script including >some constructions like: > >> /com/lcnode -b -id | /com/fpat -i -c -rm 2 ^node | read num_matches > >The trouble with this is that if you have an Apollo internet--for >instance, several rings connected via Ethernet--commands like lcnode >and lusr display only information for the local subnet. There is no >option on them to display all the connected nodes in the Apollo >internetwork. > >This means that when you go to an internetwork, suddenly all the shell >scripts in which you used tricks like the above to find all the nodes, >or update all the disks in the network, don't work anymore and have to >be modified. And changed again when you add another subnet. Some of >the nice network transparency that is Apollo's strength has been >taken away. Although this is true for some applications, the instance sited is easily fixed with the lcnet command. Use lcnet to get a listing of the connected networks and then do an lcnode on each network. A script to do just that follows. Jeff Hojnicki -- My opinions are not those of NASA NASA LeRC JSHOJ@earth.lerc.nasa.gov Some of the lines in my scripts are not always the most elegant, but they usually get the job done. --------------------CUT HERE------------------------------------------------ #!/com/sh eon # Get connected net id's NETS := ^"lcnet -c | chpat '{????????}?*' '@1'" # substitute appropriate options on lcnode command # .aaaa is needed on the from node spec, but any hex code will do for NET in ^NETS by word args "^NET" | read -type string THISNET lcnode -b -id -from ^THISNET.aaaa endfor From apollo-request@umix.cc.umich.edu Thu Dec 7 15:36:18 1989 Date: 7 Dec 89 16:21:00 GMT From: mishkin%apollo.hp.com%apollo.uucp@eddie.mit.edu (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: The White Paper Message-Id: <47492647.20b6d@apollo.HP.COM> References: <31904@cci632.UUCP>, <46f42a6a.20b6d@apollo.HP.COM>, <471b93ba.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <15101@joshua.athertn.Atherton.COM>, joshua@athertn.Atherton.COM (Flame Bait) writes: > % = Achille Petrilli > # = Nat Mishkin > > = Joshua Levy (me) > > # I don't think > # it's easier to use when I can only pass one parameter as input thereby > # requiring me to manually write code to assign my "logical" input parameters > # into fields of a struct before making a remote call. > > This is a non-issue, at least in my mind. Both Sun and Apollo allow you to > pass as many arguments as you want, they use slightly different syntax, but > it is no big deal. We can argue about syntax forever, but why bother. OK, I'll grant you the right to like what you like, but I just want to make it clear to all our readers what we're talking about. Suppose I want to define and call some procedure (say "proc1") that takes 3 input params and returns 2 output params. With Sun RPC you have to do (something like): struct proc1s_ins { int in1; char in2; float in3; }; struct proc1s_outs { short out1; double out2; } proc1s_outs proc1(proc1s_ins); You have to make up a struct for each unique combination of input and output parameters used in your interface. In NCS you just do: void proc1( int [in] in1, char [in] in2, float [in] in3, short [out] *out1, double [out] *out2 ); Sure it's "just syntax", but I think it matters. > Using your compiler analogy: C is simple. I understand how to write > a compiler for it. Even though I never will, the fact that I could is > very important. It shows that the language is understandable. The fact > that I could write an XDR compiler shows how easy and straight forward > the language is. The fact that I can not for NDR shows the problem; that > NDR is compilcated. First, you write a compiler for NIDL, not NDR. Second, I guess I don't understand what you're trying to say. Simplicity is not the only metric of the utility of a language. The "language" (instruction set) of most RISC systems is simple, that doesn't mean I want to program in it. > Besides source code availability, there is also "plain old" availablity. > Take a company which makes a product for IBM RT, DEC ULTIRX, Suns, Apollos, > and HPs, and wants to expand to VMS and IBM PCs. Sun RPC is available on > all these platforms; Apollo's RPC is not. (The ringer is the IBM RT, which > does not yet have Apollo RPC, as far as I can tell.) The bottom line is > that every new UNIX machine coming out now has Sun RPC as part of its > standard software bundle. Most of them have Apollo RPC also, but the > difference between all and most is important. You can get NCS in binary form from Apollo for Ultrix, Sun, Apollos, VMS, and MS/DOS. IBM has licensed NCS from Apollo. We'll have to see what they ship. DEC and Apollo (HP) have announced that the two companies are doing joint work on NCS. I won't argue that Sun RPC is probably being shipped in binary form by more vendors today than NCS. But let's recall that this discussion started as one of technical merits. I can only hope that the technical merits will eventually change the availability situation. > Since everyone must use NFS (like it or not) everyone has Sun's RPC. > If you want to pay $25,000 you can get Apollo's RPC also. The $25K number is completely out of context. That's the price of the NIDL compiler source. The NCS runtime library source sells for something like $1000. (The source to both is available for essentially nothing to universities.) I think the binary forms of both the compiler and the runtime are around $500-1000 each. -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com From apollo-request@umix.cc.umich.edu Thu Dec 7 19:22:10 1989 Date: Thu, 7 Dec 89 16:33:09 CST From: lray@civilgate.ce.uiuc.edu (Leland Ray) Message-Id: <8912072233.AA00235@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: NCS source I think, if Apollo wants this RPC to be a standard, that they should not charge for the source. Consider the facts: X windows is a standard because the source code is given away, not that X is the best or most logical system available. Unix is everywhere, not because Unix is the best, logical, or whatever but because the source was at one time given away. C'mon Apollo, take the lead, and let us all out here in user-land port this to every machine we can get our hands on! Just spendin' my days, Leland Ray Systems Administrator Soakin' in them cathode rays. UIUC - Dept. Civil Engineering (217) 333-3821 From apollo-request@umix.cc.umich.edu Thu Dec 7 19:36:04 1989 Date: 7 Dec 89 22:07:29 GMT From: rchrd%well.uucp@apple.com (Richard Friedman) Organization: RCHRD 2855 Telegraph #415 Berkeley CA 94705 Subject: Re: kermit Message-Id: <14862@well.UUCP> References: <6534@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu check that the assumed parity is thesame between the two systems over kermit. I have had problems like this when dialing into a system where the server was set for no parity and the dialin was set with even. They could never get talking. -- /s/ rchrd <=> Richard Friedman <=> rchrd@well rchrd@well.sf.ca.us | {apple,pacbell,hplabs,ucbvax}!well!rchrd [Pacific-Sierra Research / Berkeley CA] (415) 540-5216 (The usual disclaimers apply - I speak only for myself!) From apollo-request@umix.cc.umich.edu Thu Dec 7 23:24:41 1989 Date: 8 Dec 89 02:41:22 GMT From: rtp1%tank%ux1.cso.uiuc.edu%brutus.cs.uiuc.edu%zaphod.mps.ohio-state.edu%pacific.mps. (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Why is Domain OS so big? Message-Id: <6627@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I bought my DN10000 with the 300megabyte drive, figuring that this would do me for a long time, until I managed to set up some optical secondary storage, or until the price of big, fast disks came down. Allright, so I am used to my various Macintosh setups, where I have labored for years without filling up my 80 meg of disk storage. Thought if I ever got 300 meg, I'da died an gone to heaven. Well, nobody expects Unix to be as compact as the Mac os, which after all doesn't do as much as Unix (though in some ways it does a lot more. Wish I had that 256K toolbox in rom on the 10000!). But Domain OS is a real disk hog. I installed BSD_medium, and found that the OS files take up an amount pushing 150 megabytes (even after deleting the games directory)--and yes, I did install using hard links. With the "medium" installation you don't even really get all the Unix you need, e.g. you don't get support for Unix "plot" under DM. And now I find that with 10.2, in order to get the X developer tools, I will need to do a "large" installation. This means I will really need to spring mucho $$$ to get an expensive Apollo 700MB disk to stay in business. Now, I don't want to get into the tired "apollo vs. sun" thing. I've had enough with the interminable and unproductive "mac vs ibm" thing (but alright, since you asked, since you twisted my arm, yes the mac is better than ibm and apollo is generally better than Sun, except that the sparcstation is a great little machine at a great price and I wish Apollo had a PrismStation, but no let's not start a thread on this, it was just because I heard you insisting to know ...:)). But the fact is people have Sun 3/50's with 70MB scsi disks running SunOS as stand-alone systems (i.e. no links to file servers anywhere), and still have room left over for their data files. I think it is probably easier for me to get more disk space than to hack around with custom installations (I am the prime user and sysadmin all in one of this 10000, and tend to think of it as a kind of expensive personal computer). For me, I like minst just fine. But is there some intrinsic reason why the OS on the DN10000 has to be so big? What am I getting for all that space? It is a real nuisance, because not only do you need more disk space, but you have to spend time backing it all up. Does anybody have any bright ideas as to what I could delete to free up significant amounts of space? What is all that stuff in the sau10 directory for? Is all of it really ] needed? What is really needed is a minst script tailored for an installation such as mine, which is strictly a single-node operation. Something that gives you what you need without all the fluff. Failing that, Apollo ought to offer a cheaper line of 700MB drives. I'd much rather be spending $13000 for a second processor than for another disk drive. From apollo-request@umix.cc.umich.edu Fri Dec 8 02:35:37 1989 Date: 7 Dec 89 17:57:54 GMT From: cricket%hp-ses.uucp@hplabs.hp.com (Jiminy Cricket) Organization: Integrated Office Systems, Palo Alto Subject: Re: The White Paper Message-Id: <3960004@hp-ses.SDE.HP.COM> References: <31904@cci632.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu % = Achille Petrilli # = Nat Mishkin > = Joshua Levy > Apollo makes it very difficult to use any data representation except > their's (NDR). Sun makes it easy to replace their representation (XDR), > if you want to. # Sure. And I don't like C, but since the 68000 instruction set is public, # I can write a compiler for my own language. What's the point? Most # people don't want to write compilers; they want to get their jobs done. Using your compiler analogy: C is simple. I understand how to write a compiler for it. Even though I never will, the fact that I could is very important. It shows that the language is understandable. The fact that I could write an XDR compiler shows how easy and straight forward the language is. The fact that I can not for NDR shows the problem; that NDR is compilcated. Whoa. What? I think you'd better take some time to qualify your terms. To say that because it's easy to write a compiler for a language makes it "easy and straightforward" (for a programmer, anyway) is ludicrous. To my mind, more abstraction brings with it both an "easier and [more] straighforward" programming paradigm, but often at the cost of greater compiler or interpreter complexity - just the reverse of your claim. C is "simple"? I beg to differ. C, to many folks, is a nasty, grubby language. Smalltalk, on the other hand, is based on a clear, consistent paradigm. But try writing a Smalltalk compiler. cricket Hewlett-Packard Corporate cricket@winnie.corp.hp.com Palo Alto, California cricket From apollo-request@umix.cc.umich.edu Fri Dec 8 10:16:07 1989 Message-Id: <8912081338.AA04820@umix.cc.umich.edu> Date: Fri, 08 Dec 89 08:27:39 EST From: Scott Ferguson Subject: lusr/who deficiency (sequel to lcnode/lcnet) To: APOLLO@UMIX.CC.UMICH.EDU I also would like to see added to the Aegis lusr and Unix who commands the following. Although I'm at 9.7, and I'm still not a complete UNIX wiz, so this may be there, and I haven't read my man pages. On other Unix systems, the 'who' command gives information about people who are logged in via telnet, getty, etc. However, lusr does no such thing, and I'm not aware of the 'who' command being able to do so over the entire network. If I'm wrong about this, please correct me. And what about the Aegis siomonitor stuff? Scott Ferguson Exxon Research & Engineering Annandale, NJ 08801 Always bark at a dog. From apollo-request@umix.cc.umich.edu Fri Dec 8 11:17:14 1989 Date: Fri, 8 Dec 89 09:15:15 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912081415.AA12414@richter.mit.edu> To: rtp1%tank%ux1.cso.uiuc.edu%brutus.cs.uiuc.edu%zaphod.mps.ohio-state.edu%pacific.mps. Subject: Re: Why is Domain OS so big? Cc: apollo@umix.cc.umich.edu Hmm ... something doesn't sound right here ... I've loaded the "large" installation of Aegis plus BSD onto my DN560 with a 150MB disk. Granted, there was only 6MB left after booting and starting *all* the servers (rgyd, llbd, glbd, sendmail, tcpd, and 3 or 4 of my own). This was for SR10.2, including the X windows load with hard links. I can think of the following things to check: 1) MINST seems to load all of the M68K sau directories from the tape into the /install directory even though I only asked for one or two of the /sau directories. It may be doing something similar for the DN10000. 2) While helping someone else here at MIT who has a DN10000 load software, I noticed that the /sau10 directory contains a couple of subdirectories full of microcode and diagnostic code. A lot of the code is for the 40 and 80 plane graphics subsystem. One or the other set (or both, if you have the regular 8-plane graphics system) can be removed from the system. 3) When we loaded SR10.1p onto this person's DN10K, not everything that was supposed to be hard linked actually got linked. Some of the stuff was, in fact, copies rather than links. I don't remember which directories were involved, off hand, but you might poke around your system. We loaded both Aegis and BSD onto his system (with a 350MB disk like yours) and had 180MB left over. If your just loading BSD, you should have more like 200MB left. 4) Remember that under SR10.1p, every process running on the system takes up 5MB of disk space for virtual memory for the stack (0.5MB on M68K machines). If you have 10 servers running, which is not unusual, you have 50MB of disk space tied up for stack space. SR10.2 fixes this. Stack space is allocated dynamically as it is used. Elminating the extra /sau directories from my DN560 saved me about 20-25MB. If I remember correctly, the 40/80 plane graphics code and diagnostics were about 10 or 20MB, and the stuff that failed to get hard linked was another 20MB or so. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Dec 8 13:21:11 1989 Date: 8 Dec 89 15:15:00 GMT From: oj%apollo.uucp@eddie.mit.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: using X on sr10.2 Message-Id: <474df33b.20b6d@apollo.HP.COM> References: , <47256e8e.20b6d@apollo.HP.COM>, <472c86a7.81da@digital.sps.mot.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <472c86a7.81da@digital.sps.mot.com> chen@digital.sps.MOT.COM (Jinfu Chen) writes: >I'd like to find out which Motif part is in the standard release and >which is not (e.g. mwm included with SR10.2 like uwm? ). No OSF/Motif software is bundled with SR10.2, not the header files, not the man pages, not the .a files, not the libraries, and not the window manager. You can order an OSF/Motif binary kit containing all the things I mentioned, precompiled, for either kind of CPU (Motorola 68k or Prism). If it doesn't start shipping today, it starts shipping Monday. This kit is suitable for application developers (or end users). You can also buy a source kit directly from OSF and compile it yourself (but you'll miss out on a few bug fixes). It's not hard to compile; if I were betting my company on the efficient development of OSF/Xt/Motif applications I'd buy the source kit AND the vendor-furnished binaries. >Also what is Open Dialog's rule in terms of supporting Motif? Open Dialogue V2.0 (the Apollo version) was committed to replication last Tuesday, so it should hit the streets in January. It contains a set of "classes" (Open Dialogue jargon with roughly the same meaning as "widget") which let you use it to make a human interface with the Appearance and Behavior (we're not supposed to say L**k and F**l) given in the OSF/Motif Style Guide. Open Dialogue V2.0 for Sun 3 and Sun 4 (SunOS 4), as well as the C++ source kit, get committed to replication today (shortly after I quit fooling around with netnews :-), and also should hit the streets in January. It'll be out for HP9000-3xx HPUX machines shortly as well, and various third parties have ported it to other machines and OSs. >Suppose I'm going to write a Motif compliant program on >Apollo at SR10.2, what kind of products should I buy from Apollo? Either OSF/Motif or Open Dialogue should meet your needs. Both let you develop portable applications, as well as applications specifically for Domain/OS. /Ollie Jones (speaking for myself, not necessarily for HP Apollo Systems Division) From apollo-request@umix.cc.umich.edu Fri Dec 8 13:35:13 1989 Message-Id: <8912081808.AA16463@umix.cc.umich.edu> Date: 8 Dec 89 12:58:00 EST From: "Jeffery Hojnicki" Subject: Re: lusr/who deficiency To: "apollo" Regarding the message from Scott Ferguson >On other Unix systems, the 'who' command gives information about people >who are logged in via telnet, getty, etc. However, lusr does no such thing, >and I'm not aware of the 'who' command being able to do so over the entire >network. If I'm wrong about this, please correct me. And what about the >Aegis siomonitor stuff? I don't know about 'who' since I almost exclusively use AEGIS, but you can get the telnet processes by using the '-allp' option on the lusr command. Unfortunately, this lists all processes including server processes and every user process on every node. These can be filtered relatively easily though to list only the display manager and telnet processes. Jeff Hojnicki My opinions are not those of NASA NASA LeRC JSHOJ@earth.lerc.nasa.gov From apollo-request@umix.cc.umich.edu Fri Dec 8 15:22:47 1989 Date: 8 Dec 89 18:11:28 GMT From: joshua%athertn%pyramid.uucp@hplabs.hp.com (Flame Bait) Organization: Atherton Technology, Sunnyvale, CA Subject: Re: The White Paper Message-Id: <15131@joshua.athertn.Atherton.COM> References: <31904@cci632.UUCP>, <3960004@hp-ses.SDE.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I said: | C is simple. I understand how to write a compiler for it. Even though I | never will, the fact that I could is very important. It shows that the | language is understandable. cricket@hp-ses.SDE.HP.COM (Jiminy Cricket) replies: > Whoa. What? I think you'd better take some time to qualify your terms. To > say that because it's easy to write a compiler for a language makes it "easy > and straightforward" (for a programmer, anyway) is ludicrous. I was describing a rule of thumb, not causality. I'm sorry if it sounded that way. I was thinking of ALGOL type languages. Take these as examples: C, PASCAL, ADA, ALGOL-68, PL/I. Those languages that are easy to write a compiler for are easy to understand, and the reverse is also true. This rule tends to break down for non ALGOL type languages like LISP, PROLOG, SMALLTALK, and database languages. > To my mind, more abstraction brings with it both an "easier and [more] > straighforward" programming paradigm, but often at the cost of greater > compiler or interpreter complexity This is a good rule of thumb also, but it is not perfect either. > C, to many folks, is a nasty, grubby language. Surely we can find something more interesting to talk about then "my language is better than your language". Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822 From apollo-request@umix.cc.umich.edu Fri Dec 8 17:29:58 1989 Date: 8 Dec 89 20:21:08 GMT From: conrad%tlc%motcsd.uucp@apple.com (Conrad Dost) Organization: Total Logic Corp., San Jose, Ca. Subject: NFS Message-Id: <104@tlc.tlc.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone know where to get NFS for apollos ? -- - Conrad Dost, Total Logic Corp. 12 South 1st Street, #808, San Jose, CA 95113 USA, (408)295-1792 conrad@tlc.com, {apple!motcsd | key | uunet!loki}!tlc!conrad From apollo-request@umix.cc.umich.edu Fri Dec 8 19:16:10 1989 Date: 8 Dec 89 22:35:59 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: NFS Message-Id: <6653@tank.uchicago.edu> References: <104@tlc.tlc.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu NFS can be obtained directly from Apollo. Call Apollo Direct, or your sales rep. Mine cost about $100 some dollars, and I installed it using minst in about 15 minutes. Worked perfectly the first time. It has been trouble free, so I didn't order the pricey $50/mont support/update service From apollo-request@umix.cc.umich.edu Fri Dec 8 21:13:04 1989 Date: 8 Dec 89 23:06:41 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Can you have a library like a cmpexe? Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have a DN4000 and a DN10000. To provide programs for our own use and for our customers to run on any type of machine, we have started building cmpexe with xar. This allows us to have only one program directory for both machine types. For code developement, we have built up several libraries of usefull functions. Currently we have to keep two different copies for the two machine types and make sure the correct one is used during binding. To make life easier, is it possible to have a library of object files with both machine types included like with a cmpexe? If not, is there some easy way to make the library selection more automatic, maybe use the ISP variable? -- Alan Bair SPS CAD Logic Simulation & Test Motorola, Inc. Austin, Texas ...!cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Fri Dec 8 23:12:39 1989 Date: 9 Dec 89 00:36:30 GMT From: joeche%auto-trol%ico.uucp@handies.ucar.edu (Joe Chen) Organization: Auto-trol Technology, Denver Subject: Wanted: Optical Disks information/experiences on Sun/Dec/Apollo Message-Id: <487@auto-trol.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Help! I am looking for Sun/Dec/Apollo Optical Disk solutions to our customers' data storage needs. I remember that there were discussions of optical disks in the net, but I have not been able to locate them again. Could those netters be so kind as to repost them in the net? Or they may directly e-mail them to me? I would like to know the names of venders who sell both erasable and WROM optical disks (HW&SW), and (hopefully) support Sun/Dec/Apollo platforms. I am also interested in comments/experiences/suggestions about products of some well known venders (i.e. Genesis, Maxtor, Alphatronix, US Design, Pinnacle, Computer Upgrades, and etc.) from a user's point of view. Any related information/suggestions will be greatly appriated. Thanks in advance. Joe Chen Auto-trol Technology Corporation 12500 N Washington Street Denver, Colorado 80241 Tel: (303)-252-2135 UUCP: joeche@auto-tro.uucp From apollo-request@umix.cc.umich.edu Sat Dec 9 17:19:49 1989 Date: 9 Dec 89 21:21:00 GMT From: vinoski%apollo.uucp@eddie.mit.edu (Stephen Vinoski) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Why is Domain OS so big? Message-Id: <4754401e.20b6d@apollo.HP.COM> References: <6627@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <6627@tank.uchicago.edu> rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) writes: > Does anybody have any bright ideas as to >what I could delete to free up significant amounts of space? What >is all that stuff in the sau10 directory for? Is all of it really ] >needed? Most of the files in the /sau10 directory and subdirectories have to do with diagnostics. Apollo machines usually only have diagnostics which run under the Diagnostic EXecutive (DEX), but due to the enormous complexity of testing a machine like the DN10000, we chose to use scan testing techniques to provide high fault coverage and good fault isolation. Scan tests execute quickly, but require large amounts of input data and expected output data. Most of the files in the /sau10/scan directory are scan test data files which are used by the scan diagnostic executive (called the SCAn Test MANager, or SCATMAN) to test the machine. These data files are highly compressed but some of them are still pretty large. One good way to free up some disk space on a DN10000 which does not have Visualization System graphics (an X-Bus graphics board) installed would be to delete the /sau10/scan/graphics directory - that will give you ~10 megabytes back. HOWEVER, I strongly suggest that you avoid deleting any of the OTHER /sau10/scan subdirectories /sau10/scan/cpu /sau10/scan/memory /sau10/scan/utility if your DN10000 is a stand-alone system; without them, SCATMAN will be unable to test and diagnose the machine. Note that the DEX diagnostics were designed to be run only after the SCATMAN tests pass, since those diagnostics require hardware which is verified by SCATMAN. If you have multiple DN10000's on a network, only one of them really needs to have the SCATMAN and DEX diagnostics installed, and the rest can be tested by booting the diagnostics from the disk on that node. Of course, as soon as you purchase and install the X-Bus graphics board, you will have to reinstall that /sau10/scan/graphics directory... ;-) Hope this helps. -steve | Steve Vinoski | Hewlett-Packard Apollo Div. | ARPA: vinoski@apollo.com | | (508)256-6600 x5904 | Chelmsford, MA 01824 | UUCP: ...!apollo!vinoski | | "My second wife isn't even born yet." | From apollo-request@umix.cc.umich.edu Sat Dec 9 17:19:49 1989 Date: 9 Dec 89 19:24:52 GMT From: chen%digital%dover%mcdphx%asuvax%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Jinfu Chen) Organization: Motorola, Inc. Logic IC Div, Mesa, AZ Subject: Re: lusr/who deficiency Message-Id: <4753d980.81da@digital.sps.mot.com> References: <8912081808.AA16463@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I don't remember if how 'who' behave at SR9.7 but in SR10 and above, there's a switch, '-a', for 'who' to list users on the local network. Check the man page to see if it's the same in SR9.7 (probably does, if my memory is right). While on the similar subject, I read something about HP/Apollo's support of Aegis shell and commands will go away in about two years. Could someone from HP/Apollo confirm/deny this? From apollo-request@umix.cc.umich.edu Sun Dec 10 11:15:45 1989 Date: Sun, 10 Dec 1989 16:02:59 MET From: Harald Hanche-Olsen To: Subject: PRISM Fortran compiler causes trashing! Message-Id: This is a short tale about a long FORTRAN compilation on the DN10000. I was to compile a FORTRAN program with a total of 120K lines split up into 37 files. Since our machine has only 8MB of memory and compiling is known to load it down severely, I set it up to start compiling at 1am. Next morning I got in to the office sort of late and found that the compilation was still running, and students were complaining loudly about the sluggishness of the machine. So I killed it, and restarted it the following night. History repeated itself next morning, which got me to thinking. By now, I had compiled 87K lines, which had taken 29.5 hours of elapsed time and a total of 5 million page faults! "All right", I thought, "maybe the compiler tries to compile all subroutines in one file simultaneously, thereby filling up a lot of memory and causing page trashing. In other words, maybe it helps to split the files into single subroutine pieces?" To test my hypothesis, I took a representative FORTRAN file of 2850 lines and split it up into little files using `fsplit'. I got 19 files with sizes ranging from 22 lines to 280 lines. Compiling them all and timing with the `time' command, I got the answer 289.3u 20.4s 14:51 34% 0+0k 1014+0io 30083pf+0w For those who don't know `time' output format, this means 289 seconds user time, 20 seconds system time (i.e., spent in the kernel), almost 15 minutes elapsed time, and 30000 page faults. Compare this with the result of trying to compile the whole file in one shot. After tying up the machine for over two hours, I decided the most merciful thing to do was to kill it, yielding this result: 267.2u 271.5s 2:17:10 6% 0+0k 7043+0io 441500pf+0w That is, 9 times as much elapsed time, 14 times as many page faults! Needless to say, I decided to split up the rest of the input files and compile them all separately. Thus, the remaining 32K lines took a total of 2 hours elapsed time and 300000 page faults. That is 266 lines per (elapsed) minute, compared to 67 lines/minute for the first part of the compilation! Not quite the same performance ratio as in the test case, but still quite a difference. Technical detail: We are running under SR10.1.p. Our Fortran compiler is version 10.5.p. As I said, we have 8M of memory. (We will upgrade to 32M soon). Conclusion: Split your files before compiling! Rhetoric question: What do those compiler writers at HP/apollo think they're doing? Writing for machines with a minimum of 128M of memory? - Harald Hanche-Olsen Division of Mathematical Sciences hanche@imf.unit.no The Norwegian Institute of Technology hanche@norunit.bitnet N-7034 Trondheim-NTH NORWAY From apollo-request@umix.cc.umich.edu Sun Dec 10 21:14:26 1989 Date: 10 Dec 89 23:32:02 GMT From: gyp%ccadfa%usage%basser%munnari.oz.au%samsung%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state (Patrick Tang Guan Yaw) Organization: Computer Centre, University College, UNSW, ADFA, Canberra, Australia Subject: Changing Maximum Transmission Unit (Mtu) Message-Id: <800@ccadfa.adfa.oz.au> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis dr0 1268 131.236.0 phi.ma.adfa. 5648 0 2785 0 0 sl0 1000 131.236.0 maadfa-slip. 8010 0 5956 0 0 lo0* 9216 127.0.0 localhost 0 0 0 0 0 The above is taken from netstat -i, I am concerned with the second interface sl0. Note that the Mtu is 1000, I wonder whether that can be changed to 1006?? And how?? Thanks in advance. ---- Patrick Tang Guan Yaw, Phone : +61 62 68 8820 Dept. of Mathematics, EMAIL-ARPA/CSNET : gyp@ccadfa.cc.adfa.oz.au ADFA, Canberra, 2600. UUCP : ..!uunet!munnari!ccadfa.oz!gyp AUSTRALIA ACSnet : gyp@ccadfa.oz From apollo-request@umix.cc.umich.edu Sun Dec 10 21:18:39 1989 Date: 11 Dec 89 00:24:20 GMT From: ross%cancol%ccadfa%usage%basser%munnari.oz.au%samsung%usc%zaphod.mps.ohio-state.edu%pacific.mps (Ross Johnson) Organization: Info. Sciences, Canberra Coll. of Adv. Ed. Subject: Re: Why is Domain OS so big? Message-Id: <267@cancol.oz> References: <8912081415.AA12414@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8912081415.AA12414@richter.mit.edu>, krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: > Hmm ... something doesn't sound right here ... I've loaded the "large" > 3) When we loaded SR10.1p onto this person's DN10K, not everything > that was supposed to be hard linked actually got linked. Some of > the stuff was, in fact, copies rather than links. I don't remember > which directories were involved, off hand, but you might poke > around your system. We loaded both Aegis and BSD onto his system > This happened to me too (SR10.1p). I think it was most of /bsd4.3/usr/bin. Our 10000 originally came preloaded, but has since been invol'ed and reloaded off tape. I mention that because I asked the local Apollo engineer to check his 10000 which he found was ok. I presume his came preloaded too. > 4) Remember that under SR10.1p, every process running on the system > takes up 5MB of disk space for virtual memory for the stack > (0.5MB on M68K machines). If you have 10 servers running, which > ???? Unless 'df' is lying to me ('du' does!), each process only?! grabs 500k (SR10.1p) - same as for the m68k machines. That is, as a minimum. +----------------------+---+ | Ross Johnson |:-)| ACSnet: ross@cancol.oz.au | Info. Sciences & Eng.|___| ARPA: ross%cancol.oz.au@uunet.uu.net | University of Canberra | UUCP: {uunet,ukc}!munnari!cancol.oz.au!ross | P.O. Box 1 | CSNET: ross%cancol.oz@australia | Belconnen A.C.T. 2616 | JANET: ross%au.oz.cancol@EAN-RELAY | AUSTRALIA | BITNET: ross%cancol.oz.au@relay.cs.net +--------------------------+ From apollo-request@umix.cc.umich.edu Sun Dec 10 23:35:37 1989 Date: 7 Dec 89 20:14:40 GMT From: dennis%Peanuts.uucp@nosc.mil (Dennis Cottel) Subject: Re: lcnode bug Message-Id: <1573@nosc.NOSC.MIL> References: <8912062227.AA00850@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu After I said: > ... commands like lcnode > and lusr display only information for the local subnet. ... jshoj@EARTH.LERC.NASA.GOV ("Jeffery Hojnicki") writes: > ... the instance sited is > easily fixed with the lcnet command. Use lcnet to get a listing of the > connected networks and then do an lcnode on each network. A script to do > just that follows. Granted. My point, though, is that you shouldn't *have* to write shell scripts to do these kinds of things; basic system support tools should be supplied as part of the system. Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis From apollo-request@umix.cc.umich.edu Mon Dec 11 09:15:14 1989 Message-Id: <8912111343.AA03128@umix.cc.umich.edu> Date: 11 Dec 89 07:15:00 CST From: "DAVE ERSTAD" Subject: Memory allocation bug To: "apollo" After spending my weekend glued to the tube, I finally found the reason some of our applications grind to a thrashing halt. Near as I can tell, there is a bug (?) in memory allocation at SR10 which causes a node to thrash violently even if the application very clearly should not thrash. For example, I wrote a program which allocated (via a Pascal NEW) memory in 1Kbyte chunks. Each time it allocated a chunk, the program touched each memory location in the chunk. At SR9.7 on a DN4000 with 16 MB Ram, and 80 MB free disk, I was able to allocate 40 MB of memory without much problem. There was paging to disk, but no more than I expected. At SR 10.1.1 on a DN4000 with 32 MB Ram, and 160 MB free disk, at arouund 16 MB of allocated memory the allocation process began thrashing badly. I was unable in over an hour to get more than 20 MB allocated (The SR9 version of the program was completely done in less than 5 minutes) There is no way 16 MB of data should thrash a 32 MB node! Aside from anything else, each data item is only touched once and should be paged to disk (never to be paged back) when needed - and this is what we say on 9.7. From a DPAT we did, the problem appears to be in the memory allocation routines. I can post the sample program if anyone is interested, but I've got a couple of question. 1) Hasn't anyone else seen this? (Incidentally, we verified the same behavior on the DN10000 - This could easily account for the FORTRAN compilation cited by Hanche-Olsen if the FORTRAN compiler does a lot of dynamic memory allocation for symbol tables or whatever). 2) Does anyone know what's broken? Is Apollo aware of this problem? 3) How do I work around this without re-writing zillions of lines of code? Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Mon Dec 11 14:09:23 1989 Date: Mon, 11 Dec 89 11:51:34 EST From: pha@caen.engin.umich.edu (Paul H. Anderson) Message-Id: <475d5f510.000f088@caen.engin.umich.edu> To: apollo@umix.cc.umich.edu, hanche@imf.unit.no Subject: Re: PRISM Fortran compiler causes trashing! Compiles that go on to no end due to page faults can be fixed by splitting files up, as you mentioned, or by reducing the level of optimization, which is a very memory intensive process. For example, if you have 10000 lines of code compiling at max optimization leve, it will be doing an awful lot of global optimization, in attempts to remove redunant code, reuse common code, etc. Addiing memory is a good solution, and should take care of most of the problem. Paul Anderson CAEN From apollo-request@umix.cc.umich.edu Mon Dec 11 14:16:39 1989 Message-Id: <8912111825.AA06689@umix.cc.umich.edu> Date: 11 Dec 89 11:38:00 CST From: "DAVE ERSTAD" Subject: Re: Memory allocation bug To: "apollo" wescott@lnic5.hprc.uh.edu writes: > I think the problem you are encountering is a known one. > Although I was not around at SR 9.7, I understand that > the allocation of virtual memory was quite different > than the UNIX-like scheme employed at SR 10. As you may > know, a code running at SR 10 opens a paging file > immediately at run time, while SR 9 only opens this upon > demand. This does not mean that the SR 10 node pages > immediately...but you know what I mean. Anyhow, there > has been alot of confusion and disgust voiced from SR 9 > users that wrote their codes to fit the O/S characteristics. Yes, that is an area of concern; however, it is a different issue. The fact that I touch (assign a value into) each memory location once removes any differences due to this effect (Since at SR9 I am demanding each page). In any case, this should not cause thrashing, just a uniform increase in disk accesses. BTW, I was one of the gripers about this change from SR9 since I did have to rewrite some code and wasn't happy about it. I found there is a patch on the November patch tape that sounds suspiciously like this problem but only applies to SAU2, 3, and 5 machines. I haven't gotten any word back from the Apollo hotline yet. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Mon Dec 11 18:18:42 1989 Date: 11 Dec 89 19:50:33 GMT From: lori%hacgate%usc%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: Why is Domain OS so big? Message-Id: <6414@hacgate.UUCP> References: <8912081415.AA12414@richter.mit.edu>, <267@cancol.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Discussing OS disk hogging, David Krowitz writes: >> 4) Remember that under SR10.1p, every process running on the system >> takes up 5MB of disk space for virtual memory for the stack >> (0.5MB on M68K machines). [...] In article <267@cancol.oz> ross@cancol.oz (Ross Johnson) writes: >Unless 'df' is lying to me ('du' does!), each process only?! grabs 500k >(SR10.1p) - same as for the m68k machines. That is, as a minimum. I remember hearing that firing up a diskless node under SR10 soaks up 6MB of disk, a lot of it for swap. Perhaps this is related. It certainly is a problem, although not exclusive to the 10k. ...lori (an SR10 wanna-be anyway) From apollo-request@umix.cc.umich.edu Mon Dec 11 18:20:48 1989 Date: 11 Dec 89 19:17:58 GMT From: lori%hacgate%usc%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Lori Barfield) Organization: Hughes Aircraft Company, El Segundo CA Subject: Re: Handy Aegis Scripts Message-Id: <6413@hacgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu No one yelled "stop!" so here's another: One of the problems with Aegis (9.7 at least) is that links going nowhere collect on your disk over the ages until things get really messy. Here is a simple script to list and check every link for a given dir. I used it like "ck_link //newton..." to periodically clean up an entire disk. By default, it will check just the links in the working directory-- an option I used to verify a link or set of links I had just created. ---------------------------------- cut here ------------------------------ # CK_LINK # checks link resolution names for existence # needed because crl command doesn't warn if unresolvable # 1 opt arg- pathname to check (CL processing available) # NOTE: to check all dirs at and below a given level, use 'TOPDIR...' # NOTE: for large checks, redirect output to a file and search on 'ERROR' # default-- check all links in current dir # eon # if eqs ^1 then path := '.' else path := ^1 endif found := false args '' # /com/ld -lt -ll -c ^path | @ while read link resolution do if existf ((^resolution - '"' - '"')) then args " @"^link@" points to ^resolution" else args "ERROR: no resolution ^resolution for link @"^link@"" endif if ((not ^found)) then found := true endif enddo # if ((^found)) then args '' "Link check completed." '' else args 'No links found.' endif From apollo-request@umix.cc.umich.edu Mon Dec 11 20:08:52 1989 From: tpfabian@nasamail.nasa.gov (THEODORE FABIAN) Date: Sat, 9 Dec 89 18:04 PST Message-Id: To: Subject: RE: Re: lusr/who deficiency X-Lines: 42 > I don't remember if how 'who' behave at > SR9.7 but in SR10 and above, there's > a switch, '-a', for 'who' to list users > on the local network. Check the man > page to see if it's the same in SR9.7 > (probably does, if my memory is right). > > While on the similar subject, I read > something about HP/Apollo's support of > Aegis shell and commands will go away > in about two years. Could someone from > HP/Apollo confirm/deny this? while I'm not a representative of HP/APOLLO, I'd like to respond.. At the ADUS Conference this past fall in New Orleans, we asked that very question to which Apollo responded emphatically that they'll continue to support AEGIS into the indefinite future.. I certainly hope this is the case.. -my opinions are my own and do not reflect those of my employer. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Thanks, * * * * Ted Fabian * * * * NASA Lewis Research Center * * Cleveland, Ohio * * * * phone: 216-433-6307 * * FTS: 297-6307 * * * * email: tpfabian@nasamail.nasa.gov * * tfabian@earth.lerc.nasa.gov * * tfabian@csd.lerc.nasa.gov * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From apollo-request@umix.cc.umich.edu Mon Dec 11 20:12:37 1989 Date: 11 Dec 89 21:39:00 GMT From: perry%apollo%hp-sdd%ucsdhub.uucp@ucsd.edu (Jim Perry) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: The White Paper Message-Id: <475e5faf.20b6d@apollo.HP.COM> References: <31904@cci632.UUCP>, <3960004@hp-ses.SDE.HP.COM>, <15131@joshua.athertn.Atherton.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >> C, to many folks, is a nasty, grubby language. > >Surely we can find something more interesting to talk about then "my >language is better than your language". This is the perfect capper for a nasty, grubby debate about "my RPC system is better than your RPC system" :-) - Jim Perry perry@apollo.hp.com HP/Apollo, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter. From apollo-request@umix.cc.umich.edu Mon Dec 11 20:19:07 1989 Date: 11 Dec 89 23:59:10 GMT From: gwh%typhoon.Berkeley.EDU%agate.uucp@ucbvax.Berkeley.EDU (George William Herbert) Organization: ucb Subject: A funny posting... Message-Id: <1989Dec11.235910.14984@agate.berkeley.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This appeared on one of our local newsgroups here at berkeley [we have an all-apollo cluster]: >From: [deleted]@UCBVAX.BERKELEY.EDU >Subject: The Math functions Library >Message-ID: <11876@shuriken.berkeley.edu> >Date: 7 Dec 89 12:35:30 GMT >Sender: daemon@ucbvax.BERKELEY.EDU >Distribution: ucb >Lines: 9 > > > A bug has been discovered in the Apollo math functions. More a > accurately, in double precision mode there is some inaccuracy regarding > the number four. > This is being patched by redefining four, so please add > #include > in all appropriate code. It will be fixed in 10.2 We believe it to have been faked... even so, I think you all may enjoy it. **************************************************************************** George William Herbert | UCB Naval Architecture [On schedule? at UCB? Yes!] ---------------------------------------------------------------------------- gwh@ocf.berkeley.edu ||||||||| "And What if I Don't?" "Then, You Die, gwh@soda.berkeley.edu ||||||||||||||| the Girl dies, Everybody Dies..." maniac@garnet.berkeley.edu |||||||||||||||||||||||||||||||||||| -Heavy Metal From apollo-request@umix.cc.umich.edu Mon Dec 11 22:06:36 1989 Message-Id: <8912120119.AA22888@umix.cc.umich.edu> Date: 11 Dec 89 14:28:00 CST From: "DAVE ERSTAD" Subject: Re: memory allocation bug To: "apollo" I've received a request for the test program which demonstrates the alleged memory allocation bug in SR10.1 The program is given below, along with some results. The point at which SR10 breaks down appears to be somewhat variable, and I haven't tried to find out what causes that variability. It always breaks, though. We've verified this at SR10.1, SR10.1.1, and SR10.1.p. BTW, the results below are with -opt 0 to prevent anything from being optimized away. SR9.7.0.4 SR10.1.1 DN4000 16.0 MB memory DN4500 32.0 MB memory 170MB disk 380 MB FA disk Alloc speed - alloc 1 7.4 Alloc speed - alloc 1 1.5 Alloc speed - alloc 2 12.8 Alloc speed - alloc 2 2.5 Alloc speed - alloc 3 10.3 Alloc speed - alloc 3 3.4 Alloc speed - alloc 4 9.8 Alloc speed - alloc 4 3.0 Alloc speed - alloc 5 7.4 Alloc speed - alloc 5 3.0 Alloc speed - alloc 6 7.4 Alloc speed - alloc 6 3.4 Alloc speed - alloc 7 8.4 Alloc speed - alloc 7 3.9 Alloc speed - alloc 8 10.8 Alloc speed - alloc 8 4.4 Alloc speed - alloc 9 9.8 Alloc speed - alloc 9 4.4 Alloc speed - alloc 10 7.9 Alloc speed - alloc 10 5.4 Alloc speed - alloc 11 10.8 Alloc speed - alloc 11 51.7 Alloc speed - alloc 12 10.3 ( The next one is > 600 - I killed it ) Alloc speed - alloc 13 8.4 Alloc speed - alloc 14 12.3 Alloc speed - alloc 15 9.4 Alloc speed - alloc 16 9.8 Alloc speed - alloc 17 9.8 Alloc speed - alloc 18 8.4 Alloc speed - alloc 19 8.9 Alloc speed - alloc 20 8.9 Dave Erstad DERSTAD@cim-vax.honeywell.com -------------------------------------------------------------------- program test; %nolist; %include '/sys/ins/base.ins.pas'; %include '/sys/ins/cal.ins.pas'; %list; type onek = array[1..256] of integer32; const size = 2000 { kb}; max_alloc = 20; var ar : array[1..size] of ^onek; num_alloc : integer; (*************************************************************) (* *) (* Real_seconds Function Integer32 *) (* *) (* Determines the number of real-time seconds since *) (* midnight. *) (* *) (*************************************************************) function real_seconds : integer32; var temp_rec : cal_$timedate_rec_t; begin (* real_seconds *) cal_$decode_local_time(temp_rec); with temp_rec do real_seconds := hour * 3600+minute*60+second; end (* real_seconds *); (*************************************************************) (* *) (* Alloc Procedure *) (* *) (* Allocate (size) items, each about 1k byte. Touch *) (* each data time. *) (* *) (*************************************************************) procedure alloc; var i, j, r1, r2 : integer32; begin r1 := real_seconds; for i := 1 to size do begin new(ar[i]); for j := 1 to 256 do ar[i]^[j] := 0; end; r2 := real_seconds; writeln('Alloc speed - alloc ', num_alloc:2, 1000*(r2 - r1) / size:8:1); end; begin for num_alloc := 1 to max_alloc do alloc; end. ------------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Tue Dec 12 02:09:53 1989 Date: 12 Dec 89 04:37:29 GMT From: rtp1%tank%ux1.cso.uiuc.edu%uwm.edu%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: Why is Domain OS so big? Message-Id: <6679@tank.uchicago.edu> References: <8912081415.AA12414@richter.mit.edu>, <267@cancol.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have received many interesting comments on this, and provide a digestion of some of the more critical ones: (1) My size estimates seem large. This is true. I did a crude estimate originally, based on df, and came up with the almost 150mb figure. I did a better estimate by taking a du, and subtracting the "install" directory and my "users" directory,which is where all our own stuff resides (except for Kermit, C and Fortran compilers). Result is 120MB, not 150. (2) The stuff in sau10 is sophisticated scan diagnostics, which is large by its very nature. Well, at least it's nice to know what I'm getting. Certainly, I'm all for good hardware diagnostics. Downtime, and MyTime are a lot more expensive than disk space (3) You could free up some space in sau10 by eliminating the scan/graphics diagnostics for 40 and 80 plane controllers, if you don't have them. The rest of the stuff is really needed. (4) Comparing the Sun 3/50's with Prism was apples and oranges. Point well taken, Indeed, the 3/50's were running an old Sun OS, and if they ever upgrade, they'll be in trouble. Further, object code for RISC architectures like Prism is always larger than for CISC architectures. Asking around, I have found that the OS for Sun 4's, Sparcs, and for SG Iris's are not much smaller than 10.1p So, all seems to be right with the world-- except I wish disk space were cheaper. Seems we are perhaps beset by the "creeping featurism" that the Unix gods used to inveigh against. I do wonder sometime about just what has happened to Unix. I need my DN10000, and I need my MacII's, but the fact is that the 1MB operating system on the MacII does about 80% of what an OS ought to, and am not a little disconcerted that getting the remaining 20% takes 119MB. This, of course, is not an Apollo-Specific comment. From apollo-request@umix.cc.umich.edu Tue Dec 12 02:12:47 1989 Date: 12 Dec 89 03:02:00 GMT From: howie%inmet.uucp@uunet.uu.net Subject: usenet from an Apollo -- how? Message-Id: <29900005@inmet> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am composing and posting this note on a non-Apollo system where I temporarily have a guest account. I would like to be able to use mail and notes on our in-house Apollo systems, but so far I have found only deadends. Our systems are DN3010 and DN3500 running SR9.7 with BSD; the closest I have come is an Apollo SE who told me it was easy on SR10, but he had never even used SR9. He had also never heard of notes, and I don't think he was using phone/modem connections. Are any of you reading these notes on Apollos running SR9.7? If so, can you help me find out what software, hardware, and documentation I need to get access to usenet from an Apollo? Also, if the answer is that we have to use SR10, this may finally be the reason that we have to take the plunge. [temporarily]: inmet!howie VOICE: (617) 492-0700 FAX: (617) 492-7908 POST: 86A Sherman Street, Cambridge, MA 02140 Howard Marshall Applied Reasoning Corporation From apollo-request@umix.cc.umich.edu Tue Dec 12 04:05:45 1989 From: tpfabian@nasamail.nasa.gov (THEODORE FABIAN) Date: Mon, 11 Dec 89 21:50 PST Message-Id: To: Subject: re: lusr et. al. X-Lines: 43 > I don't remember if how 'who' behave at > SR9.7 but in SR10 and above, there's > a switch, '-a', for 'who' to list users > on the local network. Check the man > page to see if it's the same in SR9.7 > (probably does, if my memory is right). > > While on the similar subject, I read > something about HP/Apollo's support of > Aegis shell and commands will go away > in about two years. Could someone from > HP/Apollo confirm/deny this? while I'm not a representative of HP/APOLLO, I'd like to respond.. At the ADUS Conference this past fall in New Orleans, we asked that very question to which Apollo responded emphatically that they'll continue to support AEGIS into the indefinite future.. I certainly hope this is the case.. -my opinions are my own and do not reflect those of my employer. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Thanks, * * * * Ted Fabian * * * * NASA Lewis Research Center * * Cleveland, Ohio * * * * phone: 216-433-6307 * * FTS: 297-6307 * * * * email: tpfabian@nasamail.nasa.gov * * tfabian@earth.lerc.nasa.gov * * tfabian@csd.lerc.nasa.gov * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From apollo-request@umix.cc.umich.edu Tue Dec 12 09:15:00 1989 Message-Id: <8912121342.AA03192@umix.cc.umich.edu> To: tcp-ip@nic.ddn.mil, ietf@isi.edu To: NeWS-makers@brillig.umd.edu To: NFS@tmc.edu To: apollo@umix.cc.umich.edu To: SUN-SPOTS@rice.edu To: XPERT@athena.mit.edu Subject: IETF Activities Date: Tue, 12 Dec 89 08:32:49 -0500 From: Craig Partridge Hi folks: This note is being sent around to let you know that the Internet Engineering Task Force plans to start work within the next week on developing Internet standards for network graphics and distributed file systems. People interested in participating in or monitoring these activities should join the IETF mailing list (ietf-request@isi.edu). I should hasten to emphasize that we currently *expect* that this process will be a matter of reviewing the various current candidate protocols and recommending which ones are suitable for Internet-wide use. (Of course if none of the protocols are deemed suitable, then development work may be required.) Craig Partridge IETF Area Director, Host-Based and User Services PS: For those of you not familiar with the IETF: The IETF is charged with near-term engineering of the Internet. This activity includes advising the Internet Activities Board of protocols that might be suitable for standardization in the TCP-IP protocol suite. From apollo-request@umix.cc.umich.edu Tue Dec 12 11:16:23 1989 Date: Tue, 12 Dec 89 09:13:59 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912121413.AA16566@richter.mit.edu> To: lori%hacgate%usc%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu Subject: Re: Why is Domain OS so big? Cc: apollo@umix.cc.umich.edu Yeah, firing up a diskless node would start about 6 or 7 processes on the diskless node. Under SR10.1, each process had 500Kb of stack space plus whatever else they used in the way of common storage, static arrays, and the like. It's better under SR10.2. The stack space allocation is done differently. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Tue Dec 12 19:14:46 1989 Date: Tue, 12 Dec 89 16:15:08 CST From: richard@pemrac.space.swri.edu (Richard Murphy) Message-Id: <8912122215.AA09082@pemrac.space.swri.edu> To: apollo@umix.cc.umich.edu Subject: Apollo DN4000 question I use a DN4000 running O/S rev. SR10.1 and I have this problem: Periodically the "network transmit" light on the front of the system comes on and stays on for about 30-45 secs. I have no token ring, only Ethernet, yet a network monitor shows nothing coming from my system. It also slows down on whatever I happen to be running. Has anyone ever experienced this problem? The network functions normally when I rlogin or ftp..... R. Murphy richard@pemrac.space.swri.edu From apollo-request@umix.cc.umich.edu Tue Dec 12 23:17:49 1989 Date: 12 Dec 89 19:23:33 GMT From: conrad%tlc%motcsd%csibtfr%excelan%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Conrad Dost) Organization: Total Logic Corp., San Jose, Ca. Subject: GUARD FAULT ? Message-Id: <923@tlc.tlc.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anyone know what a GUARD FAULT is ?. I got it in a deeply recursive routine on an DN-4000, SR 0.1, bsd4.2. The same program runs ok on a SUN. -- - Conrad Dost, Total Logic Corp. 12 South 1st Street, #808, San Jose, CA 95113 USA, (408)295-1792 conrad@tlc.com, {apple!motcsd | key | uunet!loki}!tlc!conrad From apollo-request@umix.cc.umich.edu Tue Dec 12 23:22:25 1989 Date: 12 Dec 89 22:12:07 GMT From: lori%hacgate%usc%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Lori Barfield) Organization: Hughes Aircraft Company, El Segundo CA Subject: Ada 2.0 Install bug Message-Id: <6432@hacgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Sorry to waste bandwidth if this is old news. For those of us still stuck at SR9.7, the install binary for the Ada compiler (best version compatible w/9.7 *is* 2.0) has a glitch. ada and a.make won't work! After running the install, you need to modify the DTMs in these dirs: /usr/apollo/ada/apollolib/.objects /usr/apollo/ada/apollolib/.nets /usr/apollo/ada/apollolib/.objects /usr/apollo/ada/apollolib/.nets Under Unix, use touch * in each dir. If you don't trust touch, here is my Aegis script: abtsev -w /com/wd /usr/apollo/ada/standard /com/cpt :.nets :.nets2 /com/chn :.nets :.nets.orig /com/chn :.nets2 :.nets /com/cpt :.objects :.objects2 /com/chn :.objects :.objects.orig /com/chn :.objects2 :.objects /com/dlt :.nets.orig, :.objects.orig /com/wd /usr/apollo/ada/apollolib /com/cpt :.nets :.nets2 /com/chn :.nets :.nets.orig /com/chn :.nets2 :.nets /com/cpt :.objects :.objects2 /com/chn :.objects :.objects.orig /com/chn :.objects2 :.objects /com/dlt :.nets.orig, :.objects.orig ...lori From apollo-request@umix.cc.umich.edu Wed Dec 13 00:40:04 1989 Date: 12 Dec 89 20:35:06 GMT From: lori%hacgate%usc%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Lori Barfield) Organization: Hughes Aircraft Company, El Segundo CA Subject: review of _Digital_Review_ review of DN2500 Message-Id: <6427@hacgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Look in _Digital_Review_ for a complete benchmark analysis of the DN2500. I agree with their summation: "The Domain Series 2500 is not a high-performance workstation, but its entry level price will serve to put a workstation on a desk that may otherwise not have had one." Unfortunately, they test a fully loaded machine ($16,295!) and sound a bit like they expected it to have options like a fully loaded something-else- besides-a-lowest-end-model. If you had $16k to spend on an Apollo, would you even consider a DN2500? I think the DN2500 is about giving sys admins choices like "shall I buy another laser printer for $8k or *two* DN2500s?" They were very thorough as usual and offer these test results: "Test results show that Apollo's Domain Series 2500 did better on DR Lab's CPU 2 Benchmark Suite than two other systems that use the same Motorola 68030 CPU chip (albeit at a lower clock speed [16 vs. 20 MHz]): the Macintosh IIcx and the HP 9000 Model 340. The Apollo machine didn't do as well compared with a Sun [-4/110] workstation and the DEC VAXstation 3100." The configuration was 200MB internal, 16MB RAM, 802.3 EN, 19" mono. The price for the equivalent HP was $21,450. Anyone out there know what the Mac, Sun, or VAX would run? Here are the DN2500 "pros" they listed: o "Base model is priced as low as $3,990" o Gives users choice of System V and 4.3BSD Unix, and Aegis environments [they didn't exactly put that right; also don't forget the Korn Shell] o "Is binary-compatible with all other Apollo workstations except the Domain 10000" o "Can be networked easily" [this was referring to: 1) ease of adding Apollo node vs. Sun node, a "tremendous advantage"; 2) Domain's method where all disks on a net appear as one universal file system; 3) binary compatibility of all but DN10k] o "Supports X Window System" The "cons": o "CPU performance is below that of other entry-level systems" o "Price of fully equipped model is more than four times higher than price of base model" Flames, anyone? ...lori From apollo-request@umix.cc.umich.edu Wed Dec 13 07:14:48 1989 Date: 13 Dec 89 10:02:34 GMT From: khb%chiba.uucp@sun.com (chiba) Organization: Sun Microsystems, Mountain View Subject: Re: PRISM Fortran compiler causes trashing! Message-Id: <129180@sun.Eng.Sun.COM> References: , <47625cb9.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <47625cb9.20b6d@apollo.HP.COM> madler@apollo.HP.COM (Michael Adler) writes: >You are quite correct that 8MB isn't much for compiling large programs. >However, I strongly discourage breaking apart source files for users with >reasonable amounts of memory. ... I have not used the PRISM compiler, but have used many others with similar behavior. Really large programs should typically be broken, profiled and if necessary reassembled. On one large commerical FE code (276K lines), for a largish computer (names withheld) the moral equivalent of saxpy was called several hundred times. Inlining (which would have been natural) all such call sites was a big lose. In about 4 call sites, inlining, loop interchanges, hand unrolling to a depth of 3 (all calls were multiples of 3) and some other vile and unnatural transformations resulted in a total application speedup of more than a factor of 2. >Breaking routines apart into separate source files causes longer calling >sequences, makes inlining (-opt 4) impossible and destroys any chances for >interprocedural optimizations. Compilers can only do so much. In addition, the cost of compilation dominates in many shops .... Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO" From apollo-request@umix.cc.umich.edu Wed Dec 13 07:18:08 1989 Date: 13 Dec 89 09:53:07 GMT From: khb%chiba.uucp@sun.com (chiba) Organization: Sun Microsystems, Mountain View Subject: Re: PRISM Fortran compiler causes trashing! Message-Id: <129179@sun.Eng.Sun.COM> References: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article hanche@imf.unit.no (Harald Hanche-Olsen) writes: >This is a short tale about a long FORTRAN compilation on the DN10000. >... >Rhetoric question: What do those compiler writers at HP/apollo think >they're doing? Writing for machines with a minimum of 128M of memory? > Most (all I have ever seen, from PDP-11 to Cray) unix compilers act this way. In the unix universe the common idiom is to store things which are different in different files. This permits make to act in a sensible fashion. In addition, it is seldom a good idea to compile a large application with the optimizer set to just one setting for the whole application on machines with interesting optimizers. The proper approach is to compile at low (or no) levels of optimization, and to enable profiling. Optimizers can, and will be serious pessimizers in some cases (consider a machine with multiple functional units and long pipes, and an application which has loops which run from 1 to 3 ... but this is hidden from the compiler .... all loops will be unrolled to a depth of beyond 3 ... and etc.). In addition, most often the modules most expensive to optimize are the ones with the least payoff... Lastly, one should consider one of Amdahl's old "laws" .... 1MIP => 1Mb of RAM. Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO" From apollo-request@umix.cc.umich.edu Wed Dec 13 09:16:25 1989 Message-Id: <8912131306.AA14840@unix.sri.com> Date: Tue, 12 Dec 89 17:52:09 PST From: ramu%tcipro.uucp@unix.sri.com (Ramu Iyer) To: apollo%umix.cc.umich.edu%sri-unix.uucp@unix.sri.com Subject: Domain Ring and NFS We have a network of Apollos and Suns at our site. The Apollos talk to each other through the Domain Ring network. The Apollos and Suns cannot talk to each other since NFS isn't running on *both* the Apollos and Suns. Could anyone outline the advantages of having NFS on an Apollo network apart from the Domain Ring Network? Thanks in advance. --ramu iyer From apollo-request@umix.cc.umich.edu Wed Dec 13 11:16:56 1989 Date: Wed, 13 Dec 89 10:24:44 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912131524.AA17942@richter.mit.edu> To: apollo@umix.cc.umich.edu, conrad%tlc%motcsd%csibtfr%excelan%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu Subject: Re: GUARD FAULT ? A guard fault means you overran the end of the stack space. I believe Apollo puts a write protected page of memory at the end of the stack space to "guard" against programs using more stack space than is available, thus causing a memory page fault when you try to call a recursive routine one time too many. You can increase the default stack size with a switch to the binder (at least on SR10.2). -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Dec 13 11:23:46 1989 Date: 12 Dec 89 01:48:47 GMT From: sharp%cpsc%calgary%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Maurice Sharp) Organization: Knowledge Science Lab, U. of Calgary, Calgary, Canada. Subject: Re: The White Paper & Apollo Woes Message-Id: <2218@cs-spool.calgary.UUCP> References: <14983@joshua.athertn.Atherton.COM>, <2197@cs-spool.calgary.UUCP>, <15103@joshua.athertn.Atherton.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <15103@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes: >> = Maurice Sharp from sharp@ksi.cpsc.ucalgary.ca >>> = my eariler posting >I look at RPC as a sort of temporary kludge, which should go away in three >to ten years. Right now programmers, compilers, designers, and everything >else is set up for sequential execution on one machine. RPC alows us to >should replace RPC. Unfortunately, the temporary kludge will cost in total re-design when the other distributed paradigms come into their own. Besides, the Mach system from CMU (a new UNIX, used on the Next and a few others) is a message passing operating system. >> Actually, Apollo NCS IS faster than the Suns. I have the source, >>compiled NCS and NIDL on the Suns, and it WORKED first time. NO bugs >>(unlike NFS for machine X). Not only that, it took 3 Sun 4 file >>servers to equal the speed of 6 DN3000's for the Mandel demo. >Apollo used Sun's NFS. Your last sentence seems to say that Sun's are >twice as fast as Apollos, so I'm sure you did not mean it :-) NO !! Actually, it says that it took 3 Sun 4 SPARC file servers to meet the speed available from 6 DN3000's (68000's (not 020) 4 megs memory). The DN3000 is slower than a Sun 3/50. The Suns are SLOWER because they use TCP communication on a 10 Mb/s ethernet. DDS protocol on a Ring (or an ether for that matter) is much faster than TCP. >I assume that "faster" refers to installation time, not run time speed. >The current Apollo RPC system is 4 TIMES slower than Sun RPC system >for 8K packets, which happens to be the size my application uses. >That is using Sun/TCP (for reliablity as good or better than Apollo). >If I use Sun/UDP, it is 8 times faster than Apollo, but not as >reliable. See above. I do not know how you built your stuff, but the Sun RPC system is much slower than NCS. >I do not want to talk about interface langauge syntax (everyone has their >own favorite), but I will say one sentence: I thought that both NIDL's >PASCAL syntax and its C syntax looked like PASCAL, and were almost identical. >This is personal taste, however, just look at example code from all three >to see which one you like better, RPCGEN, NIDL(C), or NIDL(PASCAL). Actually, the C syntax is very close to ANSII C. This is a good thing. [bunch of stuff about NCS using only one transport protocol deleted]. NCS so far used 2 protocols concurrently. DDS on the Apollos and TCP/UDP on anything else. I have had systems running over the Suns and Apollos using DDS on the Apollos and the IP protocol on the Suns. They are also working on other protocols (PUP, ...). I guess I am biased. The Sun NFS system has been nothing but a buggy pain in the ^&*. I have constant problems with NFS fileserver not responding. And when that happens watch loads go from 2 -> 75 in a few minutes. The Apollos, no problem. A node goes down, no probs. If my files were not on it, I am OK. A server goes down on the Sun network and goodby network. Like a machine I did not know about mucks me up. Apollo NCS (and dds) is far superior technology to anything Sun has. BUT Sun is out there, they will push out half ready code (NFS) to get a user base, then fix it later. NCS will be ready eventually, but reasonably right. I am not saying Apollo is perfect, they have had their own cockups. But not in the name of grabbing the market by fooling the user community. I guess I should end with a black prediction. Right now I think Sun will win the market wars. They have inferior enginerring technology on their workstations, they have an inferior RISC (SPARC), they have a bastardized UNIX (sys5 with 4.3 extensions), but they have the glittzy catalogues, the technical reports, the cheap desktop power, the applications, the customer base, the SPARC hardware license, the road shows, and the good anti-Apollo propaganda. Apollo has superior engineering technology for workstations, superior OS, MUCH better file sharing, much better compute serving, superior networking. In other words, much better engineering, design, and thought (The network is really the computer, unlike Sun). What they do not have is marketing, tech support, technical reports, glittzy catalogues, road shows, cheap prices, decent sales support, decent backing from HP, etc... What I see is networks of Suns with some Apollos using NFS. Apollo better get their act together soon, or Sun will be the standard. maurice Maurice Sharp MSc. Student University of Calgary Computer Science Department 2500 University Drive N.W. sharp@ksi.cpsc.UCalgary.CA Calgary, Alberta, T2N 1N4 ...!alberta!calgary!sharp From apollo-request@umix.cc.umich.edu Wed Dec 13 13:22:13 1989 Date: 13 Dec 89 15:40:00 GMT From: oj%apollo.uucp@eddie.mit.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Memory allocation bug Message-Id: <47672d19.20b6d@apollo.HP.COM> References: <8912111825.AA06689@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8912111825.AA06689@umix.cc.umich.edu> derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") writes: > >I found there is a patch on the November patch tape that sounds >suspiciously like this problem but only applies to SAU2, 3, and 5 >machines. I haven't gotten any word back from the Apollo >hotline yet. Hmm, either your definition of the term "November Patch Tape" is different from ours, or you have a strange tape. As far as I can tell, there wasn't a Prism November patch tape, and the Moto tape contained only patches related to the X Window System. /oj (speaking for myself, not necessarily for HP Apollo) From apollo-request@umix.cc.umich.edu Wed Dec 13 13:32:03 1989 Date: Wed, 13 Dec 89 11:03:40 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912131603.AA17968@richter.mit.edu> To: lori%hacgate%usc%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu Subject: Re: review of _Digital_Review_ review of DN2500 Cc: apollo@umix.cc.umich.edu No flames whatsoever. The diskless DN2500's we have are 80% the speed of our DN3500's. The price (for a university) was $2500 for the 15" screen and $3400 for the 19" screen. Memory can be bought from Apollo for about $500/MB (same as Sun charges for Sparcstation 1 memory) or from any IBM-PC clone memory manufacturer for about $100/MB (we paid $115/MB for 1MBx9, 80ns memories from Allegence Group, Inc). It's well known that the cost of disk drives is now equal to or greater than the cost of the CPU, memory, and monitor in a system, so seeing that the fully loaded system is 4X the base model is not at all surprising. As for the fact that they're not as fast as a high-end workstation ... what do you expect for a list price of $3990? Well, what I got was a machine which is twice as fast as my DN330's, DN560's, and DSP90's; three times faster than my DN460's and DN660's; has higher resolution screens; holds more RAM (16Mb with 1Mb SIMMS, 64Mb with 4Mb SIMMS) that can be bought for 1/10th of what I had to pay for DN3000 memory; and that can be bought for a price ($2500) equal to what I would pay for a 1Mb Mac SE/20 (MIT discount price for a 1Mb machine with 68000 chip, no floating point, no ethernet, low resolution screen, no virtual memory, 1 floppy and 1 20Mb disk). At this price I can finally afford to unplug the DN3xx/DN4xx/DN5xx/DN6xx machines and replace them. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Dec 13 15:20:58 1989 Date: 13 Dec 89 15:40:52 GMT From: kint%software.org.uucp@uunet.uu.net (Rick Kint) Organization: Software Productivity Consortium, Herndon, Virginia Subject: Re: Domain Ring and NFS Message-Id: <1661@sunny.software.org> References: <8912131306.AA14840@unix.sri.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8912131306.AA14840@unix.sri.com> ramu@tcipro.UUCP (Ramu Iyer) writes: >We have a network of Apollos and Suns at our site. The Apollos talk to each other through the Domain >Ring network. The Apollos and Suns cannot talk to each other since NFS isn't running on *both* the >Apollos and Suns. > >Could anyone outline the advantages of having NFS on an Apollo network apart from the Domain Ring Network? > >Thanks in advance. > >--ramu iyer Well, the obvious (and compelling) advantage is that Suns and Apollos will be able to share files if you run NFS on your ring... There's good news and bad news about Apollo NFS. The good news is that it lets you mount the entire ring through a single server: /etc/mount -t nfs foo:// /nfs/apollo will mount an entire Domain internet (as seen by //foo) on /nfs/apollo on a Sun. You then use node names below that. This helps keep /etc/fstab and/or your automount map within bounds, although it may not work well with estabished naming conventions. The bad news is that since mount points are typed files (nfs_gate), you can't mount remote filesystems on remote directories (like you can on Suns and other native UNIX boxes), so you lose the filesystem hierarchy on remote mounts. All of our mount points for a given host are in a flat namespace. It looks like they've fixed a lot of bugs at NFS 2.1, so I'm not sure what the other bad news is at present. It's worth trying. -- Rick Kint CSNET: kint@software.org Software Productivity Consortium ARPANET: kint%software.org@relay.cs.net Herndon, VA UUNET: ...!uunet!sunny!kint From apollo-request@umix.cc.umich.edu Wed Dec 13 17:26:56 1989 Date: Wed 13 Dec 89 09:25:26-PST From: Steve Albrecht Subject: Re: Why is Domain OS so big? To: rtp1%tank%ux1.cso.uiuc.edu%brutus.cs.uiuc.edu%zaphod.mps.ohio-state.edu%pacific.mps. Cc: apollo@umix.cc.umich.edu Message-Id: <629573126.130000.ALBRECHT@INTELLICORP.COM> In-Reply-To: <6627@tank.uchicago.edu> Mail-System-Version: RE: Why is DOMAIN/OS so big? I was able to install a full BSD plus links to SYS5 and AEGIS on another node in 49MB. I happily have 98MB free on my little 160MB hard disk. I do not know why/if OS 10.1 requires lots more space on a DN10000 (I did this on a DN3500). (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ) Steve Albrecht - IntelliCorp, Inc. - Knowledge Systems Product Development ( ( "Opinions expressed here are my own, if anyone's, and not my employer's." ) ) DDS albrecht@intellicorp.com : COMPUSERVE 73657,1342 ( ( UUCP ...!sun!intellicorp.com!albrecht : public bbs (415)969-5643 ) ) or ...!sun!icmv!albrecht : "c"omment to sysop ( (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ------- From apollo-request@umix.cc.umich.edu Wed Dec 13 17:33:30 1989 Date: 13 Dec 89 16:24:00 GMT From: oj%apollo.uucp@eddie.mit.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Can you have a library like a cmpexe? Message-Id: <4767565a.14e4f@apollo.HP.COM> References: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article abair@turbinia.oakhill.uucp (Alan Bair) writes: >To make life easier, is it possible >to have a library of object files with both machine types >included like with a cmpexe? No, that's not the way we do it. You could write some sort of type manager, but I doubt it would be worth the effort. >If not, is there some easy way to make the library >selection more automatic, maybe use the ISP variable? Yes, this is the way we deliver the .a files we furnish. For a simple example, consider the Open Dialogue library /usr/apollo/lib/libdlgprs.a : When we install it, we install all the following things in /usr/apollo/lib : lrwxrwxrwx 1 root 18 Dec 13 10:19 libdlgprs.a -> libdlgprs_$(ISP).a lrwxrwxrwx 1 root 16 Dec 13 10:19 libdlgprs_.a -> libdlgprs_m68k.a -rwxrwxr-x+ 1 root 68032 Nov 21 13:48 libdlgprs_a88k.a -rwxrwxr-x+ 1 root 55779 Nov 21 13:21 libdlgprs_m68k.a You'll find the ISP environment variable always defined, so if you refer to libdlgprs.a, the file system follows the symbolic link to libdlgprs_a88k.a (when your program is running on a Prism) or the other one (when your program is on a m68k): ISP=a88k ... libdlgprs.a --> libdlgprs_$(ISP).a --> libdlgprs_a88k.a ISP=m68k ... libdlgprs.a --> libdlgprs_$(ISP).a --> libdlgprs_m68k.a If the ISP variable is, perchance, not defined (due to some problem someplace) you get the default via libdlgprs_.a The default depends on what kind of machine the directory is installed on. ISP= ... libdlgprs.a --> libdlgprs_$(ISP).a --> libdlgprs_.a --> libdlgprs_m68k.a This Open Dialogue installation is the simplest form of this ISP dependency. We almost never have trouble at runtime with this kind of stuff, although installing it from install-scripts takes a lot of care. For a more complex approach involving ISP-specific subdirectories, please look at /usr/lib . /Ollie Jones (speaking for myself, not necessarily for HP Apollo) From apollo-request@umix.cc.umich.edu Wed Dec 13 18:00:30 1989 Date: Wed, 13 Dec 89 12:19:50 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912131719.AA18047@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: surge suppressors I've been looking into buying a surge suppressor for the DN4000 I have at home, and they seem to range in price from $15 to $150. They all seem to have the same basic features (both common mode and differential mode (ie. protecting both "hot" to ground and "common" to ground) protection), so why do the prices vary so much? Anyone got a recommendation as to a particularly good brand to buy? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Dec 13 19:49:58 1989 Date: Wed, 13 Dec 89 13:18:14 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912131818.AA18099@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: more ignorant questions ... I've noticed that a number of Apollo supplied programs manage to their process names (the ones shown by /com/pst) no matter what name you use when you start the program. Anyone have any idea how this is accomplished? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Wed Dec 13 21:22:35 1989 Message-Id: <8912140107.AA28759@unix.sri.com> Date: Wed, 13 Dec 89 16:18:21 PST From: ramu%tcipro.uucp@unix.sri.com (Ramu Iyer) To: apollo%umix.cc.umich.edu%sri-unix.uucp@unix.sri.com Subject: CLX availability I have two questions: a) Has anyone ported CLX (common lisp interface to X) to run under X-11 on Apollos under X-11 and Apollo Common Lisp 3.0 (actually Lucid Common Lisp 3.0)? b) I am interested in learning how to use CLX. Does anyone out there have pointers to enable me access a tutorial that will give me an quick overview of CLX? Thanks in advance. --Ramu Email: ramu%tcipro.uucp@unix.sri.com (Internet) sri-unix!tcipro!ramu@uunet.uu.net (uucp via Internet) From apollo-request@umix.cc.umich.edu Wed Dec 13 21:24:16 1989 Date: 14 Dec 89 00:25:16 GMT From: newsuser%lth.se%sunic%mcsun.uucp@uunet.uu.net (Ralph Haglund) Organization: Computer Science, Lund Institute of Technology, Sweden Subject: KERMIT, ZMODEM for SR10.1 Message-Id: <1989Dec14.002516.5037@lth.se> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, The subject covers it - where can I find these? Or if some kind soul wants to raise his Karma and send me I would be forever grateful! |-------------------------------------------------------------| | Want to talk to me? Try: | | QRALPH@SELDC51 || QRALPH@SELDC52 || qralph@dna.lth.se | | My name? In official Sweden it is: 4.901.185.654 (secret) | | Anywhere else: Ralph Haglund | | Disclaimer: If it works, it's out of date. | |_____________________________________________________________| From apollo-request@umix.cc.umich.edu Wed Dec 13 21:45:24 1989 Date: 13 Dec 89 21:20:17 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: How can a script determine machine type & OS? Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are developing gnumake files to use on all of the machines we have to support, so we need a way to determine the machine type and OS. For the Sun, we grep the first line of /etc/motd, which is a line from the booting messages that we add. For example: Sun UNIX 4.2 Release 3.4 (CALYPSO) #1: Mon Dec 28 10:45:53 CST 1987 We run BSD4.3 on the Apollos, so I looked at doing something similar to the Sun, but cannot find a log file to obtain similar information from. I have noticed that when you login, there is a single line displayed with similar information as follows. DomainOS Release 10.1 (bsd4.3) Apollo DN10000 serapis It is displayed just before /etc/motd, presumably by the login process. I have checked the normal Apollo startup files, and it does appear to come from them. If I could get the above string from a command, then my problem would be solved. I would prefer a non-Aegis method, but will accept any ideas. -- Alan Bair SPS CAD Logic Simulation & Test Motorola, Inc. Austin, Texas ...!cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Wed Dec 13 23:16:13 1989 Return-Path: Message-Id: <8912140112.AA28403@gateway.mitre.org> Date: 14 Dec 89 01:01:00 WET From: "Art McClinton" Subject: RE: surge suppressors To: "krowitz" Cc: "apollo" Date sent: 14-DEC-1989 00:57:54 GMT > >I've been looking into buying a surge suppressor for the >DN4000 I have at home, and they seem to range in price >from $15 to $150. They all seem to have the same basic >features (both common mode and differential mode (ie. >protecting both "hot" to ground and "common" to ground) >protection), so why do the prices vary so much? >Anyone got a recommendation as to a particularly good >brand to buy? > -- David Krowitz What you are paying for is the ability to "re-act quickly" and handle a large spike. A cheap surge supressor will not re-act quickly. It uses a circuit breaker to shunt the spike. Also as the load increases, it is harder to develop a quick a dirty (read that cheap) solution to protect. Thus it is almost impossible to get a cheap surge protector for a DN10000. * *---Art * *Arthur T. McClinton Jr. ARPA: ART@MITRE.ORG *MITRE Corporation Phone: 703-883-6356 *7525 Colshire Dr Internal Mitre: ART@AERA785 or M10319@MWVM *McLean, Va. 22102-3481 DCS: MCCLINTON * FAX: 703-883-6308 From apollo-request@umix.cc.umich.edu Thu Dec 14 01:17:14 1989 Date: 14 Dec 89 04:31:25 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: surge suppressors Message-Id: <6721@tank.uchicago.edu> References: <8912140112.AA28403@gateway.mitre.org> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Can anybody recommend any surge suppressor at all for a DN10000, cheap or otherwise? Is one really necessary, or does the power supply take care of the important stuff (like lightning hits)? From apollo-request@umix.cc.umich.edu Thu Dec 14 03:17:16 1989 Date: 13 Dec 89 19:21:24 GMT From: janick%crk56.bnr.ca%bnr%bnrgate%bnr-vpa%utzoo%yunexus%ists%helios.physics.utoronto.ca%jarvis. (Janick Bergeron 1617964) Organization: Bell-Northern Research, Ottawa, Canada Subject: NNTP configuration within network of Apollos Message-Id: <650@crk56.bnr.ca> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Looks like I am the de facto news administrator for a network of (currently) about 200 Apollos... Now, I want to set-up things right. To the best of my knowledge, here is how we're set-up (No criticism about the set-up please): o The mix is about 60% 4500, 30% 4000 and 10% 3000, all running SR10.1 o 99% of the WS are disked with 300M disks. Most of them are 70-80% full. A few have 150M free. o We have 1 4-CPU DN10000 with a lot of disk but it is used as CPU server for heavy batch jobs. Disk usage on that node varies a lot. o WS are linked via Ethernet, on hubs of up to 64. The hubs are hooked to a building-wide backbone. Gateways connect backbones of several buildings together. o The main feed comes from a off-site Sun via NNTP Now for the wish list (in order of decreasing importance): - Minimize disk space used for keeping articles - Minimize network traffic when reading and transfering news (main USENET feed nightly, internal stuff every 5 mins). - Minimize response time when reading news - Minimize the load on the server machine Here are a few observations made on a temporary set-up: o rrn/Pnews are VERY slow to start on client nodes. But once it's started, everything goes smoothly. (I think someone tracked that problem to the gethostbyname() call in the NNTP stuff...) o My clients seems to prefer to go into VT100 mode, crp on the server then use local rn. One would think that that would minimize traffic as only screen update needs to be transfered, not entire articles (especially if you use '=' a lot) o My node is the server and I have 3 regular NNTP readers and 2 readers who crp onto my node and use local rn. I don't see a significant decrease in performances. o I am currently receiving news from a main feed and in turn feeding two other servers. Transfering news does significantly impact on the performance of my node. o I was fairly successfull at managing 4 servers from my own server which is the USENET gateway in/out of the building. Using a building-only distribution, tasks like newsgroup creation and removal, article "unjunking" and auditing was not too painful. Given these constraints and objectives: + What should be a good ratio of server/clients ? + Should we crp onto the server nodes instead ? + To how many other server should a server transfer news ? I suppose that providing a newsgroup on demand rather than a full feed (regardless whether a newsgroup is read or not) would greatly reduce traffic; but that would give me a headache just managing the sys files!!. Thanks for any help. Please reply via email to address below. Follow-ups (if any) directed to news.admin only. -- Janick Bergeron Bell-Northern Research, Ltd Ph.: (613) 763-5457 VHDL Tools P.O. Box 3511, Station C Fax: (613) 763-2661 Ottawa, Ontario, Canada, K1Y 4H7 janick@bnr.ca library disclaimer; use disclaimer.all; From apollo-request@umix.cc.umich.edu Thu Dec 14 09:20:08 1989 Message-Id: <8912141352.AA03361@umix.cc.umich.edu> Date: Thu, 14 Dec 89 08:33:57 EST From: Scott Ferguson Subject: Don't Let this Happen to You To: APOLLO@UMIX.CC.UMICH.EDU Here's a good one you can get a chuckle out of (or not): A company called Mercury Computer Systems makes plug-in boards for computer systems. The boards are based on Weitek floating-point chips, and have their own C and Fortran compilers. They run at something like 20 MFLOPS, and plug into an AT-bus. About two years ago, we bought one of these boards for heavy image corrections and it worked real well. With 10 MBytes of RAM on the board, it cost about $10,000. I've been griping about 3rd-parties not upgrading to SR10 to the ozone for a while, and I decided it was about time to really start getting on their case about it. Mercury, saying they've only got 5-10 Apollo-using customers, and isn't going to bother re-doing their software for SR10. So, I can either throw out the board and go to sr10, or stay at 9.7 for the rest of my days or until I replace all my Apollos with some other brand. Anyhow, I was just wondering: Is there some kind of unwritten legal obligation for a vendor to provide usability for a period of time? This board has only been here for less than two years, and that's not a sufficient product cycle in my book. Maybe we jost got hosed, I wasn't here when we bought the thing, but I'm tired of telling myself that "that would work if I had sr10 up", and now my system is doomed to stagnation. I wouldn't mind being able to legally force the company to upgrade. Thanks for listening to my weeps, and I'll take offers on a Mercury MC32 array processor from anyone interested (I've got a nice bridge in Brooklyn, cheap, too!) Scott Ferguson Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 From apollo-request@umix.cc.umich.edu Thu Dec 14 12:29:54 1989 Date: 14 Dec 89 14:57:00 GMT From: oj%apollo.uucp@eddie.mit.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: GUARD FAULT ? Message-Id: <476c0e1a.20b6d@apollo.HP.COM> References: <8912131524.AA17942@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8912131524.AA17942@richter.mit.edu> krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: >A guard fault means you overran the end of the stack space. Yes. If you use the "las" ("list-address-space") utility in /usr/apollo/bin/las (Not Just Like Real Unix) on a typical process, you'll get something like this (349 is the Unix PID, and this is SR10.2, but "las" in some form works on all SRs). means a hunk of virtual memory which is not associated with a file. The change which allowed the Prism to take 0.5 meg per process instead of % las 349 VA Range Obj Start Pathname 8000 - FFFF 0 10000 - 17FFF 0 3B2A0000 - 3B2AFFFF 7FFF0000 3B2D0000 - 3B2EFFFF 7FFE0000 3B340000 - 3B377FFF 0 /sys/node_data/systmp/dm_mbx 3B378000 - 3B37FFFF 7FFF8000 3B380000 - 3B3C7FFF 7FFB8000 <---stack pointer in here. 3B3C8000 - 3B3CFFFF 0 /sys/node_data/systmp/stack_guard_file 3B3D0000 - 3B3F7FFF 0 . . . 3B528000 - 3B537FFF 0 /lib/kslib 3B538000 - 3B54FFFF 0 /lib/rgylib 3B550000 - 3B55FFFF 0 /lib/ddslib 3B560000 - 3B56FFFF 0 /lib/ftnlib . . . 4672 KB mapped. /Ollie Jones (speaking for myself, not necessarily for HP Apollo) From apollo-request@umix.cc.umich.edu Thu Dec 14 14:14:50 1989 Message-Id: <8912141635.AA09413@umix.cc.umich.edu> Date: 12 Dec 89 15:23:00 CST From: "DAVE ERSTAD" Subject: Re: Memory allocation bug To: "apollo" One last note: To use Adam's workaround on an SR9 compile, change "c_param" to "val_param, d0_return". They are equivalent but the former is not supported at SR9. Of course, you only need to do this if you need code than runs at both SR9 and 10 (as we do). From apollo-request@umix.cc.umich.edu Thu Dec 14 14:20:17 1989 Message-Id: <8912141642.AA09694@umix.cc.umich.edu> Date: 13 Dec 89 13:56:00 CST From: "DAVE ERSTAD" Subject: Re: White paper To: "apollo" > meet the speed available from 6 DN3000's (68000's (not 020) 4 megs memory). Actually, the DN3000 is 68020 based. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Thu Dec 14 14:30:54 1989 Message-Id: <8912141633.AA09376@umix.cc.umich.edu> Date: 13 Dec 89 13:41:00 CST From: "DAVE ERSTAD" Subject: Re: memory allocation To: "apollo" Cary Scofield writes: > As of SR10, "memory allocations" are constrained by the amount of free > space on the disk. The more memory you allocate, the less free space > on the disk you have. The less free space on the disk you have, the > more time it takes. It's that simple. Sorry, but it's not that simple. There really was a doozy of a bug in Pascal's memory allocation. This has been confirmed by the hotline; a public message from an Apollo engineer; and other sources. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Thu Dec 14 14:37:48 1989 Message-Id: <8912141641.AA09668@umix.cc.umich.edu> Date: 13 Dec 89 13:53:00 CST From: "DAVE ERSTAD" Subject: Re: memory allocation bug To: "apollo" > >I found there is a patch on the November patch tape that sounds > >suspiciously like this problem but only applies to SAU2, 3, and 5 > >machines. I haven't gotten any word back from the Apollo > >hotline yet. > > Hmm, either your definition of the term "November Patch Tape" is different > from ours, or you have a strange tape. As far as I can tell, there > wasn't a Prism November patch tape, and the Moto tape contained > only patches related to the X Window System. The patch tape had release notes labeled Patch_M68K_8911 Release Notes There were many non-X patches (over half, I'm sure). The bulk seemed to fix sau7/DN4500 problems. The patch in question was unrelated to the problem, however. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Thu Dec 14 14:43:06 1989 Date: 14 Dec 89 15:24:02 GMT From: jhmccormick%watmath.uucp@iuvax.cs.indiana.edu (John McCormick) Organization: U of Waterloo, Ontario Subject: Apollo lpr filters for Apple LaserWriter, etc. Message-Id: <32611@watmath.waterloo.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello Everyone. I am currently running Domain/OS SR10.1 (about to switch to 10.2) under the BSD4.3 and Aegis environments on our Apollo workstations. Up until now, I have been using an SR9.7 node for printing to an Apple LaserWriter. I would like to upgrade the OS on this node and begin using the lpr software for printing (We have other Unix boxes that want to use the LaserWriter connected to the Apollo). Does anyone have the necessary input and/or output filters that lpr needs in order to print on a LaserWriter (or HP LaserJet Series II, or Toshiba 351)? I would like to be able to print ascii files, postscript documents, GPR, and GMF files. I know that it is possible to have the lpr software invoke the Aegis print software. If the above filters are not readily available, I'll have to set it up this way. Thanks in advance for any help, John McCormick jhmccormick@watmath.uwaterloo.ca From apollo-request@umix.cc.umich.edu Thu Dec 14 14:45:10 1989 Message-Id: <8912141627.AA09068@umix.cc.umich.edu> Date: 13 Dec 89 08:18:00 CST From: "DAVE ERSTAD" Subject: Re: GUARD FAULT ? To: "apollo" > Does anyone know what a GUARD FAULT is ?. I got it in a deeply recursive > routine on an DN-4000, SR 0.1, bsd4.2. The same program runs ok on a SUN. Too much junk on the stack, usually. Another message you might get is unable to unwind stack because of invalid stack frame Generally, I have found the "guard fault" is issued when procedures have large local storage, and the "invalid stack frame" when the recursion is very, very deep (for example, 10,000 deep). If you can move some data items which are local to the recursive routine into a global area, or mark them as STATIC that will help. The maximum stack size is 262144 bytes. This means you can call a procedure with about a quarter meg of local storage, or recurse twice on a procedure with about 0.12 MB, recurse three times on 0.08 MB, etc. I have no idea where the limit comes from. It seems pretty silly to have 64 MB or whatever of address space and limit applications to such a small stack space. Maybe someone at Apollo can shed some light?... Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Thu Dec 14 15:00:28 1989 Message-Id: <8912141634.AA09388@umix.cc.umich.edu> Date: 12 Dec 89 14:28:00 CST From: "DAVE ERSTAD" Subject: Re: Memory allocation bug To: "apollo" Thanks to all who responded to the memory allocation problem. Here's a summary of what's going on, which is a combination of contributed info and further experiments we've done. 1) There is a problem. It is a big problem for applications with lots of memory use. 2) The problem is only with PASCAL dynamic memory allocation 3) The problem goes away at 10.2 4) At least one of the patches on the November patch tape significantly moves the point at which the problem occurs for DN4500. Whichever patch it is, it doesn't help DN3000 machines. 5) The workaround given by Adam Matusiak does solve the problem (uses malloc in place of new) works. BTW, Apollo has no plans to generate a patch even though they have known about this for months. Their solution is to load 10.2, which doesn't help those of us with substantial quantities of third party software which isn't supported under 10.2. There should be a better way for Apollo to communicate known bugs of this magnitude to users. Even if they can't generate a patch, putting a note about this bug in the patch tape release notes would help. A mention in the 10.2 release notes would have been nice as well. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Thu Dec 14 15:09:08 1989 Date: 14 Dec 89 14:11:54 GMT From: dkukral%encad%ncrwic%ncrlnk.uucp@uunet.uu.net (Dean Kukral) Organization: NCR Corporation Wichita, KS Subject: Re: surge suppressors Message-Id: <965@encad.Wichita.NCR.COM> References: <8912131719.AA18047@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8912131719.AA18047@richter.mit.edu>, krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: > I've been looking into buying a surge suppressor for the > DN4000 I have at home, and they seem to range in price > from $15 to $150. They all seem to have the same basic > features (both common mode and differential mode (ie. > protecting both "hot" to ground and "common" to ground) > protection), so why do the prices vary so much? > Anyone got a recommendation as to a particularly good > brand to buy? > An EE friend of mine thinks that surge suppressors in this price range are not worth alot. We had reliability problems with our Apollos and tried surge suppressors, hoping they would help. We paid about $100 each and got the kind with the drop-out protection, i.e. when the electricity went off, the surge protector stayed off. The idea was that when the electricity came back on, it had a surge which was the real cause of most of our problems. After installing the surge suppressors, it seemed like we had less trouble. However, about that time the DN3000's started coming in, and then we took part in Mentor's upgrade program to upgrade all of our nodes to DN3000's. The newer nodes have been much more reliable, and I doubt that it was the surge suppressors that did it. We still use the surge suppressors, though - just in case they do some good. They are cheap compared to the cost of down-time. And they are a one time only expense. -- Dean Kukral, NCR Peripheral Products Division, Wichita, Kansas dean.kukral@wichita.ncr.com From apollo-request@umix.cc.umich.edu Thu Dec 14 15:09:43 1989 Date: 14 Dec 89 15:22:02 GMT From: brian%padouk.ima.isc.com%haddock%ima%spdcc%snorkelwacker.uucp@think.com (Brian R. Holt) Organization: Interactive Systems Corporation - Cambridge, MA Subject: Re: How can a script determine machine type & OS? Message-Id: <15436@haddock.ima.isc.com> References: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article , abair@turbinia.oakhill.uucp (Alan Bair) writes: > We are developing gnumake files to use on all of the machines > we have to support, so we need a way to determine the machine > type and OS. For the Sun, we grep the first line of /etc/motd, > I have noticed that when you login, there is a single line > displayed with similar information as follows. > > DomainOS Release 10.1 (bsd4.3) Apollo DN10000 serapis > > It is displayed just before /etc/motd, presumably by the login > process. I have checked the normal Apollo startup files, and it does > appear to come from them. That is coming from /bin/login. I believe I put that in, back when I worked at Apollo, from the System V /bin/login. In any case, you should be able to get the same info from the uname command. =brian Disclaimer: This message brought to you by me, not my employer. brian@ima.isc.com US 617-661-7474 x206 near the Charles River From lubkin@apollo.com Thu Dec 14 16:29:23 1989 Message-Id: <8912142210.AA02338@xuucp.ch.apollo.com> From: lubkin@apollo.com (David Lubkin) Date: Thu, 14 Dec 89 16:02:29 EST Subject: INFO-DSEE mail To: dsee_list:@apollo.com Date: thu, 14 dec 89 14:17:41 From: conliffe@caen.engin.umich.edu (Darryl C. Conliffe) Subject: Building based upon a release A reference to a release area in a configuration thread can result in a build using modules used in that build. Can the source files and tool files included in a release area likewise be designated as those the model is to use during a rebuild? - Darryl C. Conliffe ====================================================================== Post to info-dsee@apollo.com Administrative mail to info-dsee-request@apollo.com ====================================================================== ------- From apollo-request@umix.cc.umich.edu Thu Dec 14 19:27:39 1989 Date: 14 Dec 89 18:40:31 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%zaphod.mps.ohio-state.edu.uucp (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: review of _Digital_Review_ review of DN2500 Message-Id: <23404@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu It is true that if you buy disk storage from Apollo that you will spend as much for it as you did for the rest of your DN-2500. However, if you buy your storage from third parties you will find that you can get it for about half that price. Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Thu Dec 14 19:31:04 1989 Date: 14 Dec 89 18:20:21 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%zaphod.mps.ohio-state.edu% (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: GUARD FAULT ? Message-Id: <23402@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu You've probably run out of stack space. You can extend the amount of stack allocated by your application by rebinding (relinking) and specifying that you want more than the default (256k?). The exact syntax is mentioned in the Aegis bind command---ok, so it's not bsd4.2, but it's the best I can do! Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Thu Dec 14 19:32:33 1989 Date: 14 Dec 89 19:00:30 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%zaphod.mps.ohio-state.edu.uucp (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: surge suppressors Message-Id: <23406@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu There are a number of power conditioner/uninterruptable power supply manufacturers that claim to offer systems in the 2KVA and up range, which covers the requirements of the 10000. BTW, if you have an 'empty' 10000, you only need to provide 15 amps (and can probably plug your UPS into a 20 amp circuit). A more fully loaded DN-10000 will require something more substantial. Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Thu Dec 14 20:16:54 1989 Date: 14 Dec 89 19:43:43 GMT From: pang%Neon.Stanford.EDU%neon%shelby.uucp@decwrl.dec.com (Swee-Chee Pang) Organization: Computer Science Department, Stanford University Subject: Registry problem on DN3500 Message-Id: <1989Dec14.194343.12174@Neon.Stanford.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi, I was recently given the job of getting a "stand-alone" Apollo DN3500 functioning again, the password being lost. So, I booted up as root (by playing with rc) and tried to run rgy_create. However, rgy_create gives: Registry: Error - Unable to get next pgo entry when generating UNIX password file 0x1c040008. and a second run produce: Registry: Fatal Error - 0x1c050003 - Unable to create database (Network computing system/Registry Server Replication) I am at a loss. Please reply via e-mail if possible! Thank you in advance for any responses. -------------------------------------------------------------- [Pang, Swee-Chee] pang@neon.stanford.edu -------------------------------------------------------------- He believed in a door. He must find that door. The door was the way to ... to ... -------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Thu Dec 14 20:24:15 1989 Date: 14 Dec 89 18:40:35 GMT From: lampi%pnet02%gryphon%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%zaphod.mps.ohio-state.edu% (Michael Lampi) Organization: People-Net [pnet02], Redondo Beach, CA. Subject: Re: more ignorant questions ... Message-Id: <23405@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The names of the processes are entered in `node_data/proc_dir. If you change the names in this directory, you change the name displayed by /com/pst. Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927 UUCP: {ames!elroy, }!gryphon!pnet02!lampi INET: lampi@pnet02.gryphon.com "My opinions are that of my corporation!" From apollo-request@umix.cc.umich.edu Fri Dec 15 00:13:25 1989 Date: 14 Dec 89 20:36 -0500 From: Neal Holtz To: Message-Id: <1364*holtz@cascade.carleton.cdn> Subject: Re: more ignorant questions ... To set the name of a process (in SR9.7), we use the following C procedure, which uses an undocumented system call. The procedure tries 25 (or is it 26) times to set the name, appending a numeric count to the name when a process of the desired name already exists. ##################################################################### /* * set the name of this process */ int Name_process( pn ) char *pn; /* the desired process name */ { std_$call pm_$set_my_name(); /* undocumented, but handy */ typedef long stat_$t; /* status codes returned */ stat_$t st; stat_$t exists = 0x800E0003; /* if process already exists */ int cnt = 0; /* to append to name */ char buf[100]; strcpy( buf, pn ); pm_$set_my_name( buf, (short)strlen(buf), st ); while( st == exists && cnt < 25 ) { sprintf( buf, "%s.%d", pn, cnt++ ); pm_$set_my_name( buf, (short)strlen(buf), st ); } return( st == 0 ); } From apollo-request@umix.cc.umich.edu Fri Dec 15 08:18:33 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8912151054.AA00867@icaen.uiowa.edu> Date: Fri, 15 Dec 89 04:29:03 CST Subject: Re: GUARD FAULT ? To: apollo@umix.cc.umich.edu WRT posting: <923@tlc.tlc.com> > Does anyone know what a GUARD FAULT is ?. I got it in a deeply recursive > routine on an DN-4000, SR 0.1, bsd4.2. The same program runs ok on a SUN. -- A Guard Fault is the error that you get when your program runs off the end of its stack segment. IE runs out of stack space. Apollo uses a "guard segment" to implement its stack overflow trapping. This is a small (32Kb) segment that is put in memory just after the stack segment. Its MMU atributes are set to trap on any access. So when you program goes walking off the end of its stack, it runs into the guard segment and triggers a guard fault trap. It is possible to run off the stack and not trigger a guard fault. If a program goes "walking" down the stack in small steps (less than 32Kb) then it will trigger a guard fault when it hits the end. Such as the case of a overly deep recursive program with moderate amounts of local storage. But if the process has large amounts of local storage (>64Kb) so that it goes down the stack in large steps, it is possible to "step over" the guard segment and mess up other things. This can result in errors like "segmentation fault", "access violation" or the dreaded "unable to unwind stack" (really FUBAR). In any case, you need more stack space. The system allocates a 256Kb stack by default (Do a man/help on "limits"). This is considered big enough for general purposes but not so large that it will eat up lots of disk space for each active process. (On the DN10k under sr10.0.p the default stack size was 5Mb and people started screaming when the found that they lost 5Mbytes of disk each time another process started up.) There is an option to the loader (binder) that can be used to request a larger stack when making your program. Dave Funk From apollo-request@umix.cc.umich.edu Fri Dec 15 08:19:59 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8912151018.AA00864@icaen.uiowa.edu> Date: Fri, 15 Dec 89 04:03:20 CST Subject: Re: more ignorant questions ... To: apollo@umix.cc.umich.edu, krowitz@richter.mit.edu WRT posting <8912131818.AA18099@richter.mit.edu>: > I've noticed that a number of Apollo supplied programs > manage to their process names (the ones shown by /com/pst) > no matter what name you use when you start the program. > Anyone have any idea how this is accomplished? By this I assume that you're refering to something like: 1) You start a process with the DM "cps" or a "crp -cps" command such as: "Command: cps /sys/ncs/llbd -n my_name" (sr9.7) 2) You then do a "/com/pst" and see: ... 34246.796 3/14/14 3B416592 Wait tcp_server 42.164 3/14/14 3B416072 Wait netman 32.812 3/13/14 3B416592 Wait process_333 1307.390 3/14/14 3B416592 Wait ns_helper 10.636 3/14/14 3B416592 Wait llbd 0.123 3/14/14 3B416592 Wait message ... And you notice that "my_name" is gone and that "llbd" is now there. Here's what is happening; The name that you gave to the process during the process creation was OK, but the program was written so that it did some stuff and then did a Unix "fork" to create a new copy of itself. The parent process (the one that you started and named) then exited and the new child process was un-named so it was free to set its own name with the "set my name" system call. A program usually does the "fork" trick when it wants to do things like change the standard streams around or detach itself from the controlling "tty" or if it's a "set-uid" program. BTW don't try to go changing the names that you find in `node_data/proc_dir. This can cause problems/confusion and under sr10, you can see named processes with pst and find no entry for them in `node_data/proc_dir. Dave Funk From apollo-request@umix.cc.umich.edu Fri Dec 15 15:21:43 1989 Date: 7 Dec 89 22:07:00 GMT From: rchrd%well.uucp@hplabs.hp.com (Richard Friedman) Subject: Re: KERMIT, ZMODEM for SR10.1 Message-Id: <14862@well> References: <6534@tank> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu check that the assumed parity is thesame between the two systems over kermit. I have had problems like this when dialing into a system where the server was set for no parity and the dialin was set with even. They could never get talking. -- /s/ rchrd <=> Richard Friedman <=> rchrd@well rchrd@well.sf.ca.us | {apple,pacbell,hplabs,ucbvax}!well!rchrd [Pacific-Sierra Research / Berkeley CA] (415) 540-5216 (The usual disclaimers apply - I speak only for myself!) From apollo-request@umix.cc.umich.edu Fri Dec 15 15:25:05 1989 Date: 14 Dec 89 20:34:36 GMT From: bgo%pbhya%pacbell%vixie.uucp@decwrl.dec.com (Bud Odekirk) Organization: Pacific * Bell, San Ramon, CA Subject: vacation program Message-Id: <31356@pbhya.PacBell.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Has anyone been able to compile the vacation program in BSD4.2 Unix ? I keep getting the following message after it ahas compiled: Undefined Globals: dbminit fetch store strncasecmp syslog Thanks From apollo-request@umix.cc.umich.edu Fri Dec 15 15:31:11 1989 Date: 15 Dec 89 12:13:58 GMT From: bsw%cci632%rit%rochester.uucp@rutgers.edu (Brad Werner) Organization: CCI, Communications Systems Division, Rochester, NY Subject: Has anyone ported NCS to a tahoe? Message-Id: <32629@cci632.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu [I can't seem to cancel that runaway article, as another machine does the posts--sorry.] I've been told by a local HP/Apollo sales rep. that NCS is available on some non-Apollo machines. I'm interested in what is involved in getting it running on another machine; such as any information regarding source licensing, ease of porting, and existing ports. In particular, I'm interested in the availability of an existing port to a CCI 6/32-tahoe running any of 4.[23]BSD, S5R3. Could someone give me a summary of the internals and/or protocol used by NCS so I can get an idea of how easy it would be to port if a source license is available. Thanks in advance, //Brad Werner: bsw@cci.com || UUCP: ...!{rochester,ritcv}!cci632!ccird1!bsw From apollo-request@umix.cc.umich.edu Fri Dec 15 15:35:55 1989 Date: 15 Dec 89 11:10:35 GMT From: lucenius%vtt%router%tut%sunic%luth%eru.uucp@bloom-beacon.mit.edu Organization: VTT/TEL Subject: live video for Apollo ? Message-Id: <5207.2588d12b@vtt.vtt.fi> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We intend to experiment with multimedia retrieval including live video, thus if possible we would like to get video from external source(s) in window(s) onto the consol screen. Video sources could be videodisk players or possibly video tape recorders, for example. Video should be used together with other data which may appear in different windows. We have an Apollo DN3500 workstation. If possible we would also use X-windows and some tool for rapid prototyping. Are there any such systems for DN3500. How with other workstations. Has any- body any experience; what hardware and software is needed ? Jan Lucenius From apollo-request@umix.cc.umich.edu Fri Dec 15 15:38:45 1989 Message-Id: <8912151920.AA16360@umix.cc.umich.edu> Date: Fri, 15 Dec 89 14:05:30 EST From: Scott Ferguson Subject: High-Capacity Storage To: APOLLO@UMIX.CC.UMICH.EDU I just got a sales thing in the mail from MDL Corp., saying they've got a magneto-optical disk system for the 2500. Anyone know if they've got any for regular systems (like ones most of us have, 4000's, 4500's,etc) Also, I'm getting an Exabyte drive for my Ardent, and wouldn't mind having one on my Apollos as well, because I have an Apollo that's far away, and I need to move data from it back home on tape. If I had two Exabyte drives that were compatible, one on Apollos, one on the Ardent, I could throw out my Fork-lift palet of reel tapes. Is the helical-scan stuff standard enough to be able to buy drives for two systems and share tapes? Tar or Cpio formats are preferable, or I could write my own software to read/write if necessary. So: Are ExaByte tapes written with a standard format? and Are there affordable erasable-optical and removable systems for other than the 2500? Thanks for tuning in. Scott Ferguson Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339 "Back when I was your age, dogs didn't even have the right to vote" From apollo-request@umix.cc.umich.edu Fri Dec 15 15:45:03 1989 Date: 8 Dec 89 23:44:00 GMT From: cricket%hp-ses%hpsmtc1%hpcuhb%hpda.uucp@ucbvax.Berkeley.EDU (Jiminy Cricket) Subject: Re: Re: Response to <31904@cci632> Message-Id: <3960006@hp-ses> References: <31904@cci632> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu > To my mind, more abstraction brings with it both an "easier and [more] > straighforward" programming paradigm, but often at the cost of greater > compiler or interpreter complexity This is a good rule of thumb also, but it is not perfect either. Granted. You could always write a Byzantine compiler for a simple programming language, or (better) find a powerful, straightforward paradigm which happened to map directly to your CPU's instruction set. > C, to many folks, is a nasty, grubby language. Surely we can find something more interesting to talk about then "my language is better than your language". Just meant to underscore the idea the C is not, by many standards, an "easy and straightforward" language. Besides, I'm not the right person to talk about "my language is better than your language" here (unless you wanna defend something else). I program mostly in C. cricket From apollo-request@umix.cc.umich.edu Fri Dec 15 16:06:59 1989 Date: 8 Dec 89 22:35:00 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Subject: Re: Domain Ring and NFS Message-Id: <6653@tank> References: <104@tlc> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu NFS can be obtained directly from Apollo. Call Apollo Direct, or your sales rep. Mine cost about $100 some dollars, and I installed it using minst in about 15 minutes. Worked perfectly the first time. It has been trouble free, so I didn't order the pricey $50/mont support/update service From apollo-request@umix.cc.umich.edu Fri Dec 15 17:37:00 1989 Date: 15 Dec 89 03:29:22 GMT From: rtp1%tank%ux1.cso.uiuc.edu%brutus.cs.uiuc.edu%wuarchive%zaphod.mps.ohio-state.edu.uucp@tut. (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: Don't Let this Happen to You Message-Id: <6740@tank.uchicago.edu> References: <8912141352.AA03361@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu for Macs and Suns) is only for very special circumstances (multiply and accumulate). The typical speed is more like 2-3 megaflops. I thought about buying a Mercury board, but decided against it for more or less the reasons that eventually caught up with you. By way of comparison, a processor for the DN10000 does 28 megaflops on dotproduct (single precision), 6-7 megaflops on a broad range of code, and costs about $13000 to universities. The extra cost is worth the support. The real killer in the cost of adding a processor is the memory cost, as you really ought to add about 16MB for each new processor. This doubles the cost. Anybody know of any cheap third-party memory for the DN10000? From apollo-request@umix.cc.umich.edu Fri Dec 15 17:44:39 1989 Date: 14 Dec 89 20:55:34 GMT From: abair%oakhill%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Alan Bair) Organization: SPS CAD, Motorola Inc., Austin, Texas. Subject: Thanks for cmpexe library answers Message-Id: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I would like to thank all the people that have responded to my request for handling multiple architecture libraries; Stephen Vinoski, Robert Stanzel, Tom Lyons, Ellis Oliver Jones, etc. There were 2 ways described, both making use of the ISP environment variable. One was like the /usr/lib is setup, with links to multiple architecture lib dirs and the other with multiple lib files linked in the same directory. I chose the latter method. Seems to work fine, though installing new libs requires carefull planning. Again thanks, -- Alan Bair SPS CAD Logic Simulation & Test Motorola, Inc. Austin, Texas ...!cs.utexas.edu!oakhill!turbinia!abair From apollo-request@umix.cc.umich.edu Fri Dec 15 17:47:04 1989 Date: 15 Dec 89 03:36:46 GMT From: rtp1%tank%ux1.cso.uiuc.edu%brutus.cs.uiuc.edu%zaphod.mps.ohio-state.edu.uucp@tut.cis. (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: Don't Let this Happen to You Message-Id: <6742@tank.uchicago.edu> References: <8912141352.AA03361@umix.cc.umich.edu>, <6740@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Sorry, somehow my posting got messed up. Here is the correct full text of the posting: Actually that 20megaflops you quote for the Mercury board (also available for Macs and Suns) is only for very special circumstances (multiply and accumulate). The typical speed is more like 2-3 megaflops. I thought about buying a Mercury board, but decided against it for more or less the reasons that eventually caught up with you. By way of comparison, a processor for the DN10000 does 28 megaflops on dotproduct (single precision), 6-7 megaflops on a broad range of code, and costs about $13000 to universities. The extra cost is worth the support. The real killer in the cost of adding a processor is the memory cost, as you really ought to add about 16MB for each new processor. This doubles the cost. Anybody know of any cheap third-party memory for the DN10000? From apollo-request@umix.cc.umich.edu Fri Dec 15 17:48:04 1989 Date: 15 Dec 89 01:24:00 GMT From: rousseau%apollo.uucp@eddie.mit.edu (John Rousseau) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: How can a script determine machine type & OS? Message-Id: <476e3eb9.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article you write: >We are developing gnumake files to use on all of the machines >we have to support, so we need a way to determine the machine >type and OS. For the Sun, we grep the first line of /etc/motd, Well, the command /usr/apollo/bin/bldt will give you a wealth of interesting information. Although it qualifies as an Aegis command, it is one of our commands that is meant to be used in any environ. % bldt **** Node 29C15.E582 **** "//ferrari" Domain/OS kernel(7), revision 10.2, October 13, 1989 12:51:22 pm Some creative grep'ing and awk'ing will snarf out the info you want. the 'kernel(7)' part refers to the sau type. If you want the actual node type, use /etc/nodestat -l . -John -------------------------------------------------------------------------- John Rousseau Internet: rousseau@apollo.hp.com Apollo Division UUCP: {mit-eddie,yale,uw-beaver}!apollo!rousseau Hewlett-Packard Phone: (508) 256-6600 Chelmsford, MA 01824 Fax: (508) 250-0361 Disclaimer: (you know the words, sing along if you like) -------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Fri Dec 15 17:57:32 1989 Date: 8 Dec 89 18:11:00 GMT From: joshua%athertn%pyramid.uucp@hplabs.hp.com (Flame Bait) Subject: Re: Response to <31904@cci632> Message-Id: <15131@joshua> References: <31904@cci632> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I said: | C is simple. I understand how to write a compiler for it. Even though I | never will, the fact that I could is very important. It shows that the | language is understandable. cricket@hp-ses.SDE.HP.COM (Jiminy Cricket) replies: > Whoa. What? I think you'd better take some time to qualify your terms. To > say that because it's easy to write a compiler for a language makes it "easy > and straightforward" (for a programmer, anyway) is ludicrous. I was describing a rule of thumb, not causality. I'm sorry if it sounded that way. I was thinking of ALGOL type languages. Take these as examples: C, PASCAL, ADA, ALGOL-68, PL/I. Those languages that are easy to write a compiler for are easy to understand, and the reverse is also true. This rule tends to break down for non ALGOL type languages like LISP, PROLOG, SMALLTALK, and database languages. > To my mind, more abstraction brings with it both an "easier and [more] > straighforward" programming paradigm, but often at the cost of greater > compiler or interpreter complexity This is a good rule of thumb also, but it is not perfect either. > C, to many folks, is a nasty, grubby language. Surely we can find something more interesting to talk about then "my language is better than your language". Joshua Levy joshua@atherton.com home:(415)968-3718 {decwrl|sun|hpda}!athertn!joshua work:(408)734-9822 From apollo-request@umix.cc.umich.edu Fri Dec 15 17:58:00 1989 Message-Id: <8912152124.AA21689@umix.cc.umich.edu> Date: 15 Dec 89 15:17:00 CST From: "DAVE ERSTAD" Subject: More SR10 Woes To: "apollo" Here's another one for netland to think about. I'm doing software development using SR10.1 on a DN4000 with Pascal 8.6 and C 6.6 (application mixes both). Two odd things are happening, one always and the other intermittently. The intermittent problem is that when trying to execute the bound object code, I get a "file is not an object module or is not executable on this machine type" message. I'm using Motorola compilers and running on a Motorola node (actual execution is on a DN3000). I'm in a cycle of minor change-compile-bind-run-repeat, and the problem pops up sometimes and not others for no discernable reason. The other problem is that after I bind the object, the length is 292 blocks, but the "current length" is about 5 MB. After executing the code, the block length increases to about 5000. Moreover, this occurs even when the code does not actually run due to the other problem. A guess I had was that it had something to do with allocating space in the coff file for all the static storage, but I was unable to replicate this behavior with small test programs. Does anyone have explanations for these? The first problem is really the troublesome one; the second is just annoying, and I suspect there is a logical explanation (although I find it hard to understand how executing an object is allowed to change the object.). Thanks in advance, Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Fri Dec 15 18:25:49 1989 Date: 15 Dec 89 03:33:31 GMT From: rtp1%tank%ux1.cso.uiuc.edu%brutus.cs.uiuc.edu%zaphod.mps.ohio-state.edu.uucp@tut.cis. (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: review of _Digital_Review_ review of DN2500 Message-Id: <6741@tank.uchicago.edu> References: <23404@gryphon.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Concerning the price of disk space for the DN2500: What is a good source of third party SCSI drives for this machine? What do they cost? From apollo-request@umix.cc.umich.edu Fri Dec 15 18:29:49 1989 Date: 13 Dec 89 14:44:11 GMT From: bhagwan%voodoo%ssc-vax%fluke.uucp@beaver.cs.washington.edu (The Bhagwan) Organization: Voodoo Graphics Project Subject: Anyone have CScheme7, T3.1, Elk 1.0 on Apollo SR10.2 Message-Id: <631@voodoo.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello, I'm looking for anyone that has: MIT C-Scheme-7 Yale T3.1 or Elk 1.0 compiled and running on Apollo SR10.2 (68xxx). I can ftp source but we have no assembler so cannot build. If anyone has done this perhaps you can let me know and we'll make arrangements to mail binaries. Also, I can ftp. Thanks, -- Al McPherson Member Holstein Aerobatic Team Boeing Computer Services ...uw-beaver!ssc-vax!voodoo!bhagwan P.O. Box 24346 MS: 6M-49 Seattle, WA 98124 (206) 234-7825 From apollo-request@umix.cc.umich.edu Fri Dec 15 20:28:21 1989 Date: 15 Dec 89 22:16:16 GMT From: shull%kings.wharton.upenn.edu%netnews.upenn.edu.uucp@rutgers.edu (Christopher E. Shull) Organization: Decision Sciences, Wharton School, U. of Pennsylvania Subject: Open Dialog for "other" systems and the death of Apollo... Message-Id: <18175@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anybody out there know about Open Dialog for "other", ie. non-Apollo systems. Specifically, we are interested in a version for DEC DECstations running Ultrix, VAXstations running VMS 5.1, and Silicon Graphics systems run- ning whatever their flavor of Unix is. Assuming that at least one of the above is available, where the hell can we order it? Our local sales people seem to be having their brains sucked out by the giant HP machine. Along the same line, our hardware and software service contract seems to have vanished into the abyss in Chelmsford -- the local administrator sent it on two months ago, and the 800 number still won't talk to me. I can't get patch tapes, and I am probably missing the SR10.2 shipment. I'm getting pretty pissed off! -Chris Christopher E. Shull shull@scrolls.wharton.upenn.edu Decision Sciences Department shull@wharton.upenn.edu The Wharton School University of Pennsylvania Philadelphia, PA 19104-6366 215/898-5930 --------------------------------------------------------------------------- "Damn the torpedoes! Full speed ahead!" Admiral Farragut, USN, 1801-1870 --------------------------------------------------------------------------- From apollo-request@umix.cc.umich.edu Fri Dec 15 23:19:38 1989 Date: 16 Dec 89 02:00:00 GMT From: weber_w%apollo.uucp@eddie.mit.edu (Walt Weber) Organization: Hewlett Packard NARC @ Apollo Systems Division Subject: Programs with their own names (was Re: more ignorant questions) Message-Id: <477366a7.20b6d@apollo.HP.COM> References: <8912131818.AA18099@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: >I've noticed that a number of Apollo supplied programs >manage to their process names (the ones shown by /com/pst) >no matter what name you use when you start the program. >Anyone have any idea how this is accomplished? Someone has already supplied the key to this one in an earlier posting, so I'll post the following Aegis shell script, written by a wizard whose cloak is no longer in use in the Chelmsford rings. Note that this is a PRE-sr10 script, which was most useful on sr9.7 systems when /bin/ps and /com/pst did not co-operate as closely as they do under Domain/OS. Apologies for the lines greater than 80 chars. ...walt... ================cut here=========================================== #!/com/sh eon SYSTYPE := bsd4.2 export SYSTYPE abtsev -max /bin/ps -axN | /com/chpat -o -a -p 'uid = {[~ ]*}?*[0-9]:[0-9][0-9] {[~ ]*}?*' '@1 @2' @ | while read uid pname do args ^uid | /com/chpat '.' ' ' | read hi lo args ^pname | /com/chpat '?*/' '' | read pname cnt := 1 oldname := ^pname while existf `node_data/proc_dir/^pname do if /bin/ps -axN | /com/fpat "%^pname" | read foo then pname := "^oldname.^cnt" cnt := ^cnt + 1 else dlf -du -f `node_data/proc_dir/^pname endif enddo /com/ctob `node_data/proc_dir/^pname ^hi ^lo enddo =================end cut=========================================== Walt Weber Hewlett Packard NARC @ Apollo Systems Division -The views expressed herein are personal, and not binding on ANYONE- "The power of accurate observation is commonly called cynicism by those who have not got it" -George Bernard Shaw From apollo-request@umix.cc.umich.edu Fri Dec 15 23:23:17 1989 Date: 14 Dec 89 14:41:53 GMT From: arane%me%jarvis.csri.toronto.edu%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Raphael Arane) Organization: University of Toronto Subject: 8mm cassette tape Message-Id: <1989Dec14.094152.10983@me.toronto.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Apollo has the 8mm cassette backup tape with 2.3GB capacity. What experience/knowledge netters have about this tape with respect to: - Reliability - Cost of cassettes - Availability of cassettes - Popularity, esp. among workstations; do Sun, SGI have them? - Do you think this might become an industry standard as the 1/4 inch cartridge tape did? - Anything else that deems relevant I'll try to summarize and post the responses that will be e-mailed directly to me. Thanks, , -- Rafi Arane arane@me.utoronto.ca Tel (416) 749-0880 arane@me.toronto.edu Fax (416) 749-9669 From apollo-request@umix.cc.umich.edu Sat Dec 16 23:12:41 1989 Date: 15 Dec 89 15:44:46 GMT From: kosbab%hp-lsd%hpldola%hpfcso.uucp@hplabs.hp.com (Bruce J. Kosbab) Organization: HP Logic Systems Division - ColoSpgs, CO Subject: Re: How can a script determine machine type & OS? Message-Id: <11360003@hp-lsd.COS.HP.COM> References: Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Use the "uname -a" command to get the information you need. It gives the OS version, type (Sys V or BSD), and machine type. Bruce Kosbab hp-lsd!kosbab From apollo-request@umix.cc.umich.edu Mon Dec 18 07:18:23 1989 Date: 18 Dec 89 09:00:51 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p device entries Message-Id: <602@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If I can say '/etc/ifconfig eth0' I would assume there exists a device entry /dev/eth0 to which e.g. I can do ioctl() s. Nope. There isn't any. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:21:36 1989 Date: 18 Dec 89 09:18:08 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p df command does not list nfs mounted filesystems Message-Id: <620@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The bsd /bin/df command does not list information on nfs mounted filesystems. This is a pity. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:24:26 1989 Date: 18 Dec 89 09:28:04 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p use of organization field in accounts Message-Id: <631@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu One cannot specify an organization field when establshing a new account, unless the person is explicitly made a member of this organization first. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:29:11 1989 Date: 18 Dec 89 09:03:17 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p ruptime does not display load averages Message-Id: <604@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The ruptime command does not display load averages, although such information from remote (non-apollo) machines is present in the appropriate files in the /usr/spool/rwho directory. The SR9.7 version of ruptime was ok in this respect. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:33:30 1989 Date: 18 Dec 89 09:01:35 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p daylight savings time Message-Id: <603@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Will the bsd environment automatically obey daylight savings time rules during the appropriate period if I live in some known timezone (like MET) as do various other decent BSD4.3 implementations? I could not find information about this issue. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:38:01 1989 Date: 18 Dec 89 09:08:10 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p proc_dump file contains unnecessary information Message-Id: <609@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The good-old proc_dump file, now residing in `node_data/system_logs, still records every normal process_quit. This makes it cumbersome to find the real error situations in between all these useless dumps. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:40:48 1989 Date: 18 Dec 89 09:12:33 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p bsd/sys5 du report wrong number of blocks Message-Id: <614@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The 'du' command in both bsd and sysv report a number of disk blocks which is incorrect. The bsd command is off by a factor 4, the sysv command by a factor 6 (not 12 as with ls -ls). /com/lst works ok. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:44:39 1989 Date: 18 Dec 89 09:04:39 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p netstat -r does not list local routes Message-Id: <605@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The bsd netstat -r command does not list the 'local' routes, via the local interfaces ("U" and "UH" flags), not even after explicitly adding such routes with the /etc/route command. This means that I cannot see the "Refcnt" and "Use" statistics. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:50:22 1989 Date: 18 Dec 89 09:17:20 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p makewhatis misses many man pages Message-Id: <619@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The bsd /usr/lib/makewhatis utility (invoked by /etc/catman -w) does not pickup all ../cat[1-8] man pages when reconstructing the whatis database. Many will not be included. I have not yet found time to discover what is going on here. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:52:49 1989 Date: 18 Dec 89 09:07:17 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p keep right for links in open directory Message-Id: <608@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Although I can give a file the 'keep' right to prevent it being deleted from an open directory, there is no way to prevent a symbolic link being deleted from such open directory. This is terrible, since some necessarily open directories (like `node_data) must have some symbolic links. Eric Wasenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:55:55 1989 Date: 18 Dec 89 09:10:48 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p bsd/sysv du hangs for large files Message-Id: <612@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you do a 'du' for a directory containing some very big files, the command may take very long, or may never finish. It seems to be dependent on the size of the files. It is not working for both bsd and sysv. /com/lst works ok. What sort of system is this if I cannot even use 'du' ? Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 07:58:13 1989 Date: 18 Dec 89 09:20:12 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p syslog.pid should be link to `node_data/etc Message-Id: <623@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu /etc/syslog.pid should be a symbolic link to `node_data/etc/syslog.pid Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 08:01:31 1989 Date: 18 Dec 89 09:11:36 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p bsd/sys5 ls -ls report wrong number of blocks Message-Id: <613@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The 'ls -ls' command in both bsd and sysv report a number of disk blocks which is incorrect. The bsd command is off by a factor 4, the sysv command by a factor 12. /com/ld -a works ok. The number of bytes (byte offset) is usually ok, except for files with holes in it, in which case all 3 commands report different values. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 08:03:24 1989 Date: 18 Dec 89 09:16:35 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p find misses option to skip nfs filesystems Message-Id: <618@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The bsd /usr/bin/find utility misses the '-fstype nfs -prune' option to skip nfs mounted filesystems. In the script /usr/lib/find/updatedb you now must include the option '-xdev', and add all your type 4.3 mounted disk partitions to the SRCHPATH variable. (Of course you want to list only your local disks). Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 08:06:19 1989 Date: 18 Dec 89 08:57:37 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p cannot start csh on spm server console Message-Id: <600@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you have a simple terminal attached to sio.spm on your DSP10000, and you login via the spm "sh" command, you cannot start /bin/csh since it will be immediately suspended ('T' status in /bin/ps). This is terribly annoying if you have /bin/csh as your login shell. Perhaps /dev/sio1 is a strange device for bsd, but even if you try to '/bin/csh Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If edrgy invalidates the account of a user, this user can still 'crp -me' from an SR9.7 node. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 08:11:28 1989 Date: 18 Dec 89 09:27:19 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p sysv /bin/sh is insecure Message-Id: <630@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The /sys5.3/bin/sh does not have the necessary security check when importing IFS, so anyone who knows the trick can become root. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 08:17:29 1989 Date: 18 Dec 89 09:05:39 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p passwd/group changes are not immediately visible Message-Id: <606@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you modify the registry database with edrgy, changes are not immediately propagated to /etc/passwd and /etc/group. If you list these files shortly after the change, they still show the old information. You can force the new database changes by invoking 'rgy_admin' and put the registry in "state -in_maintenance" immediately followed by "state -not_in_maintenance". This is terrible. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 09:20:37 1989 Date: 18 Dec 89 09:21:38 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p utilities dealing with utmp have chaotic display Message-Id: <625@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Since the width of the username and hostname fields in /etc/utmp or /usr/adm/wtmp in the Apollo implementation is 32 (instead of the usual 8 and 16), the output of some utilities displaying user info is totally misaligned and difficult to read on a 80 column terminal. This applies to finger, who, last, and the like. I think one should adhere to the unix convention, especially if I have requested so in the rgy properties. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 09:25:43 1989 Date: 18 Dec 89 09:20:53 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p csh file completion does not look nice Message-Id: <624@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If one has 'set filec' in /bin/csh, the visible filename substitution displayed on the terminal is completely garbled. (but the mechanism itself works). Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 09:32:32 1989 Date: 18 Dec 89 09:06:27 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p symbolic links drawbacks Message-Id: <607@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The symbolic links in bsd are the traditional aegis links, not the old 'slink' type of files. I find this choice unfortunate. When I make a time-sorted directory listing with 'ls -lt', the time reported for the symbolic links is the time of the last directory modification. This is not what I want. What I want to see, is the time the link was made, just as in other bsd implementations. Furthermore, I cannot chown/chgrp such symbolic link. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 09:39:20 1989 Date: 18 Dec 89 09:14:09 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p node IDs are still returned in uppercase Message-Id: <615@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu As was the case in SR9, in SR10 node-ids are still returned in uppercase, e.g. in the printout of various commands, or in the environment variable NODEID, even if the node ids were defined as lowercase. This is inconsistent as SR10 is supposed to be case-sensitive. It is very inconvenient if one has to take care of this in shell scripts, or in the use of variant links with the $(NODEID) in it. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 09:45:23 1989 Date: 18 Dec 89 09:15:06 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p canned rgy entries with too long names Message-Id: <616@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Some canned rgy entries as distributed cannot be manipulated, e.g. one cannot change the "owner" of 'sys_person' to someone more trustworthy than "%.%.%". edrgy complains with 'name is too long'. However, this can be overcome if one changes the rgy property that unix conventions must NOT be met. Be aware that you should change the ownership of every individual entry in the rgy database, or everyone can gain total control. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 09:52:37 1989 Date: 18 Dec 89 09:18:47 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p mesg command disables further crp logins Message-Id: <621@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If one logs in using crp onto an SR10 node, the 'mesg n' command puts /dev/crp?? in mode 644, which is never reset to mode 666 after logout. This disables further crp logins, since they require mode 666 from the beginning. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 09:54:20 1989 Date: 18 Dec 89 09:22:56 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p allows invalidated passwords in ftp sessions Message-Id: <627@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If edrgy invalidates the password of a user, this user can still establish ftp connections (where the password must be entered), although rlogin is indeed not possible (except if a ~/.rhosts file exists, but that's ok). Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 09:59:16 1989 Date: 18 Dec 89 09:22:15 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p finger cannot show user idle time Message-Id: <626@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The finger utility cannot show the idle time of a logged-in user. It shows the time since this user actually logged in. So everyone seems very idle. This is actually documented: SR10 does not update the time on the /dev entries. Why? This is unfortunate. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:06:02 1989 Date: 18 Dec 89 08:55:06 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p rlogin does not have any reasonable flowcontrol Message-Id: <599@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We have a DSP10020 server to which we login via rlogin from remote (non-apollo) BSD4.3 hosts. The terminal flow control quality is almost nonexisting and absolutely unacceptable. Decent BSD4.3 implementations can terminate output to the terminal almost instantaneously upon receipt of the interrupt character, even if such output was suspended witt XOFF. In SR10 you have to endure many, many pages and pages of output before you see any reaction. It is as bad as telnet. Either it works with extremely large socket buffers, or it cannot handle urgent OOB data. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:11:03 1989 Date: 18 Dec 89 09:26:37 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p acl of /sys/registry Message-Id: <629@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu As distributed, the acl of the directories /sys/registry and /sys/registry/rgy_data is wide open and anyone can delete any file at will. It seems that it is sufficient that only root has write access to these directories and the files in them. Is there any reason to have world access to some files? Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:11:05 1989 Date: 18 Dec 89 09:28:43 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p does not allow multiple (independent) registries Message-Id: <632@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu (I did not completely follow the rgy discussion on the net, so my comments may not be new). In SR10 the rgy database seems to be network-wide. This is absolutely unacceptable if there are multiple groups of machines which are under separate administrative management, with different accounts, which must have different registries. In SR9 this was perfectly possible. On specific machines in our network, only a very limited number of accounts is allowed of the many accounts that are defined on other machines in the network. There is no way to do this with the distributed global database. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:11:50 1989 Date: 18 Dec 89 09:19:28 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p crp should not be used for unix style logins Message-Id: <622@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If one works in a unix environment, logging in to another node using crp may not give you what you thought. If your login shell is /bin/csh, you get a c shell allright, but it is not a regular 'login shell' in the sense that it does not go through ~/.login Also, your 'tty' (some /dev/crp??) cannot be set to the proper ownership and mode, so various commands may not work. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:17:58 1989 Date: 18 Dec 89 09:09:54 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p bsd/sysv ls -l hangs for large files Message-Id: <611@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you do a 'ls -l' for a directory containing some very big files, the command may take very long, or may never finish. It seems to be dependent on the size of the files. It is not working for both bsd and sysv. /com/ld -a works ok. As a side effect, for the duration of such hanging ls, the rgy daemon becomes unavailable for servicing requests. Effectively this means that your whole machine comes to a grinding halt. And not only your machine, also a remote (non-apollo) machine that has your filesystems mounted via nfs is affected. (See nfs articles to be posted hereafter). My god, what is going on here? Isn't ls just doing a stat() of a file? What sort of system is this if I cannot even use 'ls' ? Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:24:05 1989 Date: 18 Dec 89 09:08:56 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p residence of system files Message-Id: <610@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Since there are now special directories `node_data/system_logs and `node_data/systmp to store various log files resp. system data files, it is surprising that some files still reside in `node_data itself or in subdirectories like `node_data/tmp. Examples are: `node_data/tmp/llbdbase.dat `node_data/ipc_data `node_data/glb.* Another strange place is for the file `node_data/system_logs/nfs_data I think all these files should go into `node_data/systmp. At least /tmp should be left alone for user files only, and should not have any apollo-specific files. Unfortunately, some names are still required to exist in `node_data, although the actual files reside in `node_data/systmp. The symbolic links in the open directory `node_data can be removed by the world, since `node_data has to be open to the world. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:24:08 1989 Date: 18 Dec 89 09:15:51 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p nfs cannot mount filesystems on top of each other Message-Id: <617@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In non-apollo NFS implementations it is possible to mount remote NFS filesystems on top of each order, like /etc/mount rhost:/ /mountpoint /etc/mount rhost:/usr /mountpoint/usr so that the whole remote filesystem tree can be transparently accessed using the same pathname syntax, starting at /mountpoint, as on the remote host itself. The mount points must be existing directories. In the Apollo SR10 NFS implementation, this is still impossible. Mount points must be non-existing. They are created as objects of type 'nfs_gate' by the mount operation, and obviously cannot reside on already mounted remote filesystems. It is very unfortunate that Apollo NFS breaks this transparency. It breaks sophisticated symbolic link structures on such remote systems. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:26:02 1989 Date: 18 Dec 89 08:59:43 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p only bsd disk device is /dev/wn0a Message-Id: <601@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If I want to partition my disk into several logical volumes, I need to have device entries like /dev/wn0b, /dev/wn0c, etc. If I have more than one disk and more than one disk controller, I need to have device entries like /dev/wn1a, /dev/wn1b, etc. I want to say '/etc/mount -avt 4.3' to mount all devices mentioned in /etc/fstab, instead of using /com/mtvol. None of this seems to be possible in the bsd environment. I cannot find information how to 'mknod' such disk devices. Showing my mounted disks after /com/mtvol yields the strange /dev/wn0a on / type 4.3 (rw) /dev/dsk/W0d1s1 on /shiva2 type AEG (rw) and the df listing has its own non-bsd naming conventions Filesystem kbytes used avail capacity Mounted on 1d858.1 1367480 311552 1055928 23% / 1d858.2 1367480 1118560 248920 82% /shiva2 Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:35:10 1989 Date: 18 Dec 89 08:50:56 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p installation messed up Message-Id: <598@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you start to install SR10 from scratch from cartridge tape onto your newly invol-ed disk using the recommended new installation procedures (minst, install++), you may end up with a very undesired situation. Be warned. If you specify a 'closed' system, you end up with a system as open as possible, with acl-s allowing full access to the world. If you desire bsd-type inheritance rules (owner from process, group from directory), you won't get it. Both owner and group come from the process. (This looks like sys5 inheritance, apart from the non-organization inheritance). If you specify bsd as your primary environment, the /etc/environ file will contain ENVIRONMENT=sysv To get a closed system, specify as target machine not the usual "//nodename" but instead "//nodename/topdirectory", and move everything by hand back to the //nodename directory. However, the installation procedure still leaves many files with world access in the new system tree. You can trace them with appropriate variants of the command 'find /topdirectory -perm -002 -ls' and fix them by hand. This is terrible. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:35:49 1989 Date: 18 Dec 89 08:48:51 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p is not a stable product Message-Id: <597@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In the next several postings, I will report on my findings installing SR10.1.p on a DSP10020 server node, from a system managers standpoint. This was my first experience with SR10 and I am not satisfied. The setup is as follows: we have a DSP10020 with 32 MB of memory, and 2 * 2 760MB disk drivers, sector striped. Ring connection to a network of 30+ Apollo workstations, ethernet connection to the outer world, NFS to a BSD4.3 remote (non-apollo) host. Access is usually via rlogin. More such machines may be added. They are to act primarily as compute servers for cpu bound fortran jobs processing very large data files (200+ MB). I/O to/from magnetic tape and IBM 3480 cartridge is done on remote machines with access via NFS. In principle, they are pretty well suited for our type of computing. We think that they are ideal to off-load traditional centralized multi-purpose mainframes. Our experience with Apollo workstations started back in 1984, we've seen everything from SR7 to SR9.7.5, and we were mostly very satisfied. In contrast, if SR10.1.p is typical for SR10, then SR10 is unreliable, inconsistent, and unpredictable. If you only want to run your fortran job on a stand-alone single-user DN10000 you are probably ok. But if you want to embed such machine in a larger general multi-user environment and use it as a production machine, you may be confronted with unpleasant surprises. I did not follow every SR10 discussion on the net in full detail, so I may report issues that have been dealt with already. Apologies if I repeat things. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:42:10 1989 Message-Id: <8912181208.AA01524@umix.cc.umich.edu> Date: Mon, 18 Dec 89 19:58 H From: Subject: vmstat and DSP90 To: apollo@umix.cc.umich.edu X-Original-To: apollo@umix.cc.umich.edu, YEOAK Re: vmstat and DSP90 I've collected the following statistics from our DSP90 (3MB RAM) running SR10.1 with default SYSTYPE=4.3: ===> /systest/ssr*/vmstat 2 5 procs memory page disk net faults cpu r b w avm fre re pi po fr de sr dr dw nr nt da ex cs us sy id ------ -------- --------------------- ----- ----- ---------- -------- 1 0 0 2222 0 0 6 0 0 0 0 0 0 0 0 0 2 0 95 0 5 1 0 0 2222 0 0 4 0 0 0 0 2 0 0 0 0 0 0100 0 0 1 0 0 2222 0 0 0 0 0 0 0 4 0 0 0 0 0 0 97 1 2 1 0 0 2222 0 0 0 0 0 0 0 0 0 0 0 0 0 0100 0 0 1 0 0 2222 0 0 0 0 0 0 0 0 0 0 0 0 0 0 97 0 3 Notice that the CPU user processes times (us under cpu) is strangely high, I wonder anybody has tried using vmstat on DSP90 and got this kind of results. I am puzzled by the high cpu-us time b'cos I was the only log-in user thru' the terminal connected to DSP90. I didn't run any program except /systest/ssr*/vmstat. The similar kind of statistics on DSP90 can be collected anytime using 'vmstat'. I ran 'vmstat' on our DN580 series, the statistics showed a low cpu-us but high cpu-id time which is very reasonable since nobody is doing anything on those machines. Can anyone tell me wether 'vmstat' is reliable or SR10.1 on DSP90 is doing something very different when it is on DN580? The following ps might be helpful: PID TTY STAT TIME COMMAND 1 ? S < 0:32 /etc/init 2 ? R 2:13 null 3 ? S 1:41 purifier 4 ? S 0:05 purifier 5 ? S 0:53 unwired_dxm 6 ? S 0:00 pinger 7 ? S 0:06 netreceive 8 ? S 11:15 netpaging 9 ? S 2:06 wired_dxm 10 ? S 6:22 netrequest 85 ? S 25:34 /etc/tcpd 90 ? S 1:59 /etc/routed -h -f 93 ? S 0:02 /etc/inetd 96 ? S 0:01 /etc/ncs/llbd 99 ? S < 7:44 /etc/rgyd 104 ? S 0:00 /sys/net/netman 106 sio1 R 3011:15 spm 108 sio1 S 0:00 /sys/mbx/mbx_helper 121 tty01 S 0:07 -ksh 272 tty01 R 0:00 ps ax Thanks in advance. --AnnKian Yeo Email: YEOAK%NUSDISCS.BITNET@CUNYVM.CUNY.EDU Department of Information Systems and Computer Science (DISCS) National University of Singapore (NUS) From apollo-request@umix.cc.umich.edu Mon Dec 18 10:43:52 1989 Date: 18 Dec 89 09:32:59 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p /etc/dm_or_spm in /etc/ttys Message-Id: <638@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is there a subtle reason for putting /etc/dm_or_spm into /etc/ttys and e.g. not explicitly /sys/spm/spm on server nodes? Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:49:13 1989 Date: 18 Dec 89 09:30:09 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p passwd does not check registry properties Message-Id: <634@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The passwd utility does not recognize those nice registry properties such as the minimum password length, when changing passwords. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 10:55:41 1989 Date: 18 Dec 89 09:55:10 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p undocumented suid_exec Message-Id: <657@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Could someone explain what the undocumented /etc/suid_exec is supposed to do ? Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:00:19 1989 Date: 18 Dec 89 09:30:47 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p unwanted login message during rlogin Message-Id: <635@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does somebody know where this "DomainOS Version SR10.1.1 ..." line is generated when I rlogin to an SR10 machine, and how to disable this unwanted message? Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:07:42 1989 Date: 18 Dec 89 09:31:32 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p /com/sigp is distributed setuid root Message-Id: <636@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Be aware: if you have constructed a nice `node_data/node_owners file, all your work is in vain if you didn't see that /com/sigp was installed as setuid root. Can you believe it? Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:09:07 1989 Date: 18 Dec 89 09:37:50 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p talk cannot be suspended Message-Id: <644@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If one starts a talk session from an rlogin terminal, one cannot suspend the program (with ^Z as suspend char in c shell). The only control possibility is to abort the session with ^C. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:12:02 1989 Date: 18 Dec 89 09:35:43 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p crp login prompt does not recognize eof Message-Id: <641@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If one enters an end-of-file to the crp "login: " prompt, crp complains with "unable to read login name (end of file)", and keeps on repeating this. One should expect the same behaviour as with rlogin, which terminates the connection in such case. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:12:28 1989 Date: 18 Dec 89 09:53:55 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p /etc/mount versus /etc/nfsmount Message-Id: <655@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does someone know the difference between /etc/mount and the furthermore completely undocumented /etc/nfsmount ? The same for /etc/umount and /etc/nfsumount. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:19:23 1989 Date: 18 Dec 89 09:29:22 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p chfn only knows about usa phone numbers Message-Id: <633@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The chfn utility has an usa-specific interpretation of various syntax rules in office numbers and phone numbers, especially hyphenation. Unfortunately, I cannot recompile this program even if I have some regular bsd source, because of the apollo-specific features. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:23:33 1989 Date: 18 Dec 89 09:34:42 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p /bin/start_csh gives wrong path to root Message-Id: <640@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If root does a /bin/start_csh he gets a path variable containing the erroneous '.' and '/usr/apollo/bin/etc' instead of the expected '/usr/apollo/bin' and '/etc'. One can see the programmers typo if one does a 'strings /bin/start_csh' and searches for the PATH Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:35:22 1989 Date: 18 Dec 89 09:39:56 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p write to read-only file system Message-Id: <646@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If one attempts to create a file on a read-only nfs-mounted filesystem, one gets the extremely confusing error message "bad file number" in a bsd environment. sysv is better, but terse: "cannot create" aegis tells you why: "attempted write to read-only filesystem" Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:39:42 1989 Date: 18 Dec 89 09:50:37 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p strange root access via nfs Message-Id: <651@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you create as root a file on a remote (non-apollo) nfs filesystem, and you do an 'ls -l' for that remote file, the owner is shown as '-1' by the bsd ls and as '4294967295' by the sysv ls. On the remote system, the local 'ls -l' shows properly '-2'. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:45:47 1989 Date: 18 Dec 89 09:49:54 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p passwd file garbled for person without account Message-Id: <650@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you define a person in the 'person' rgy database without creating a corresponding account for this person in the 'account' rgy database, the /etc/passwd file becomes garbled. An extra stray entry is listed with some random information from other accounts. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 11:53:49 1989 Date: 18 Dec 89 09:56:31 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p /etc/install resides in wrong place Message-Id: <659@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The /etc/install program as distributed is located in the wrong place. This is an sysv specific utility, and should probably be moved into the /etc/sys5.3 directory, with a symbolic link /etc/install pointing to $(SYSTYPE)/install so that it resolves only for sys5.3, whereas you get the desired /usr/bin/install for bsd. This avoids disaster if the search PATH for root starts with /etc Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 12:02:10 1989 Date: 18 Dec 89 09:58:22 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p /etc/lprotect does not work Message-Id: <661@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Altough /etc/lprotect does not work for SR10.0 and SR10.1 workstations, is should work for SR10.1.p prism machines, according to the release notes. Don't you believe it. Both 'lprotect -rmtroot none' or 'lprotect -rmtroot readonly' grant root access from other workstations in the network. Only new files cannot be created, but existing files can be overwritten at will. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 12:05:53 1989 Date: 18 Dec 89 09:49:11 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p lists incorrect uid/gid via nfs Message-Id: <649@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If one has a remote (non-apollo) filesystem mounted via nfs, and you do an 'ls -lg' for files on this remote filesystem that have a uid or gid which is not defined in the SR10 registry, you do not see the usual '-1', but instead you see one of the defined SR10 user/group names, apparently randomly chosen. If you use the sys5 ls option '-n' you see the wrong uid/gid number itself that is inappropriately used. This is terrible. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 12:08:39 1989 Date: 18 Dec 89 09:54:31 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p cannot properly terminate suspended jobs Message-Id: <656@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If one is logged in to an SR10 machine via rlogin, and has the bsd csh as login shell, and has several suspended (stopped) jobs, those jobs remain hung in some undetermined state if the rlogin connection is broken. The SR10 rlogind and csh disappear properly, but not the stopped jobs started by the csh. (Actually, this behaviour was also present in SR9, but apparently has not been fixed in SR10). Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 12:17:33 1989 Date: 18 Dec 89 10:00:38 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p /bin/cc -I.. does not work Message-Id: <664@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The option '-I..' to the c compiler does not fetch include files from the parent directory. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 12:50:54 1989 Date: 18 Dec 89 09:33:39 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p processes hang if tcpd daemon crashes Message-Id: <639@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If the tcp daemon crashes, all tcp-related processes hang in some undetermined way. They don't terminate, and must be killed by hand. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 13:07:32 1989 Date: 18 Dec 89 09:39:10 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p lpr is insecure Message-Id: <645@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The bsd lpr command still has the old bug that makes it possible to remove any file you want without being root, if you know the trick. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 13:18:35 1989 Date: 18 Dec 89 09:37:11 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p ls -l command makes rgy unavailable Message-Id: <643@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you do an 'ls -l' on a directory containing some big files, it not only never finishes (see one of my previous postings), but also stalls the rgy daemon and stops it servicing requests. This makes effectively the whole machine inoperational. And not only your machine, also a remote (non-apollo) machine that has your filesystems mounted via nfs suffers terribly if the rgy daemon does not work when it is engaged in nfs transfers. This is absolutely unacceptable. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 13:21:40 1989 Date: 18 Dec 89 09:59:05 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p /etc/shutdown does not work Message-Id: <662@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you shutdown your machine with '/etc/shutdown +1 message' you get after a while the single user mode "login: " prompt, but if you try to login as root, you get the message "Using local registry - can't use network registry - access violation" and then for everything you type in, you get "command not found". The only thing left is to reset/reboot the machine. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 13:26:08 1989 Date: 18 Dec 89 09:51:23 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p bsd man output is not piped through ul Message-Id: <652@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu It looks as if the output from the bsd 'man' command consists only of the cat files piped through 'more'. You see all those backspaces executed on your rlogin vt100 terminal instead of properly piped through 'ul' to generate bold and italic (underscored) text. (By the way: a most useful enhancement would be to pipe the text through 'less' instead of 'more', so that you can move back and forth at will if your 'window' is only 24*80. The line that you were looking for is always on the previous page.) Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 13:32:02 1989 Date: 18 Dec 89 09:46:48 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p cannot transfer very large apollo files via nfs Message-Id: <648@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu It is impossible to read on a remote (non-apollo) host via nfs a big apollo file for which 'ls -l' gives problems. I have reported in previous postings that this may be the case for some very big files in an apollo directory. Both local 'ls -l' and a remote 'ls -l' via nfs cannot list such big files, and crash the rgy daemon and/or nfs. Since such big files are generated on our DSP10020, and have to be processed further on remote (non-apollo) machines via nfs without duplication on remote disks, this situation is totally unacceptable. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 14:08:12 1989 Date: 18 Dec 89 09:36:30 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p passwd command makes rgy unavailable Message-Id: <642@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If root attempts to change the password of another user with the 'passwd username' command, the command hangs, and the registry becomes unavailable. The files /etc/passwd and /etc/group become empty. Sometimes one experiences bad side-effects, such as: The rgyd daemon does not respond any more. All pending nfs connections abort. New nfs connections are refused. This situation is usually restored automatically, if you are lucky within some 10 minutes. This is unacceptable. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 15:21:06 1989 Date: 18 Dec 89 10:02:25 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p nfsd has strange error messages Message-Id: <666@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Sometimes I see the following strange nfs error message. I have no idea under which circumstances it is generated. nfsd: unable to convert unix error number 4 (no rights) unix_fio_$stat_xoid failed in getattr_uid Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 15:25:04 1989 Date: 18 Dec 89 09:52:16 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p recognizes only registered accounts via nfs Message-Id: <653@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If an SR10 apollo filesystem has been mounted via nfs by a remote (non-apollo) host, arbitrary remote users on that remote host cannot access any file on the apollo disk via nfs. Only remote users that have an identical account on the SR10 system are allowed access. This means that if a remote user UUU belonging to remote group GGG wants to use nfs with the apollo disks, there must be not only an SR10 person UUU and an SR10 group GGG with identical numeric unix uid and gid, but there MUST also be an SR10 account UUU.GGG.org for nfs to work. This is absolutely unacceptable. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 15:31:06 1989 Date: 18 Dec 89 09:59:56 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p bsd make cannot be suspended Message-Id: <663@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you start a bsd 'make' during your rlogin session (bsd c shell), you cannot suspend make with the suspend character (usually ^Z). If you interrupt make with ^C, the previous ^Z triggers the shell to execute old commands, which problem I have reported in a previous posting. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 15:35:14 1989 Date: 18 Dec 89 10:11:35 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p /usr/ucb/script does not work Message-Id: <670@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This is (for the time being) my last posting in this series. I would have liked to illustrate some of my previous postings with example typescripts of various phenomena reported, but unfortunately /usr/ucb/script does not work. It terminates the typescript file immediately after it has been opened. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 15:42:24 1989 Date: 18 Dec 89 09:32:14 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p acl on `node_data directory Message-Id: <637@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Is there any reason why the `node_data directory should have world access write permission? So far I have seen only new crp_mbx??? files from SR9 crp logins. If this directory stays open, any of the (necessary) symbolic links in it can be deleted. Anybody can create new directories or rename old directories. To be more general: could Apollo publish a complete list of files and directories which necessarily MUST have world write permission? Some directories must be open for a while, since files must be created for the first time. But once such files are there, the directory can be closed again. Unfortunately, such files sometimes have an explicit ownership of the user who created the file the first time, and the file must be writable for the world. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 15:46:38 1989 Date: 18 Dec 89 09:57:27 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p cannot handle terminal suspend character Message-Id: <660@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If you are logged in via rlogin, and enter inadvertently the 'suspend' character (usually ^Z in bsd environment) to your favorite shell, it triggers the execution of random commands that you executed earlier on the machine. Not necessarily in the same rlogin session, they could be commands from previous sessions, even from several days ago. They are not fetched from the ~/.history file. They must still be stored somewhere in memory. Spectacular results can be achieved if you have an rlogin session as root and have just installed vital software and rearranged half of your disk, and then want to suspend your whole rlogin session with ~^Z but did not press the ~ key hard enough. Needless to say this is unacceptable. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 15:53:36 1989 Date: 18 Dec 89 10:03:12 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p has trouble counting processes Message-Id: <667@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This may not be a serious complaint, but it surprises me that during the shutdown sequence I see these messages on the console Waiting for 3 processes to stop ... Waiting for 2 processes to stop ... Waiting for 1 processes to stop ... Blasting 2 miscreants ... By the way: every once in a while the latter action will take forever, and you have to reset the machine. I don't know under which circumstances. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 15:57:21 1989 Date: 18 Dec 89 09:55:51 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p passwd program oddities Message-Id: <658@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu At first I thought I made a mistake, but it is true: If you, as an ordinary (non-root) user, do an '/bin/passwd otheruser' the passwd program prompts for YOUR password, not the other's password. (You probably know your own password, since you just logged in, but okay, I can understand why it wants to know your password anyway). The authority to change anything in the rgy database is controlled by the ownership of the various individual entries (persons, groups, orgs), and the registry database as a whole (see registry properties). Be aware that the default ownership of everything is anybody (%.%.%). This is also true for the pre-defined accounts when you create a new registry. Better change the ownership of every individual entry in the rgy database, or everyone can gain total control. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 16:03:34 1989 Date: 18 Dec 89 10:01:42 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p csh builtin which command does not work Message-Id: <665@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu The bsd 'which' command is a builtin command in the csh. It does not consider those commands in the $path directories which have no execute right to the world (e.g. mode 750, root, staff). Since I am a member of group staff, I can execute such commands, but 'which' cannot find them, or I am misled in case a command with the same name exists in a directory with lower search priority. Fortunately there is still the good-old /usr/ucb/which, which does not try to be clever. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 16:10:11 1989 Date: 18 Dec 89 09:53:10 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p recognizes only registered accounts via nfs (continued) Message-Id: <654@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu This is a continuation of my previous posting, which reported that you must have a real account on SR10 before you can access an SR10 apollo disk via nfs from a remote (non-apollo) host. As a consequence, every remote program that does a stat() of statfs() for an apollo nfs disk, will fail with authorization errors. Needless to say this is terribly annoying is you realize that often used utilities on normal bsd4.3 machines like '/bin/df' also deal with nfs mounted filesystems. Every time one of my innocent remote users does a 'df', an authorization error is reported on the remote machine, and many, many lines are added to the SR10 /usr/adm/nfs_error_log file. nfsd: _svcauth_aegis(): FYI unable to convert uid N, gid M, to a SID _svc_auth_aegis(): unable to cache new user uid N, gid M Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 16:15:21 1989 Date: 18 Dec 89 10:10:06 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p problems with resolver contacting remote nameserver Message-Id: <668@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I don't run a nameserver on our DSP10020, but use the nameserver on a remote bsd4.3 (non-apollo) host. This remote host is properly specified in the /etc/resolv.conf file. This setup works fine. Problems arise when this remote nameserver host goes out of service. Every name/address translation will (of course) fail. But apparently there are no timeouts, and everything hangs forever. I have also an /etc/hosts file, but this file is never consulted as a last resort. Example: if you start /usr/ucb/netstat in such situation, it hangs. If you try to interrupt with ^C, after a while you get the unexpected error message "Bus error". Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 16:19:32 1989 Date: 18 Dec 89 10:10:48 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p portmap crashes with odd address error Message-Id: <669@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu /etc/portmap will crash with an odd address error if the remote host that runs the nameserver, goes out of service. (See previous posting). This is bad, since mountd and nfsd, which are still running, become inoperational. If the remote host comes up again, it wants to mount the apollo disks via nfs, but will fail to do so. You have to kill mountd and nfsd first, then restart portmap, mountd, and nfsd again. I have seen various circumstances: in routine _gethtent line 554 called from ... called from get_myaddress in routine errlog_$tb line 586 called from unknown location Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 16:20:42 1989 Date: 18 Dec 89 09:40:50 GMT From: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net (Eric Wassenaar) Organization: Nikhef-H, Amsterdam (the Netherlands). Subject: SR10.1.p remote ls -l to nfs mounted apollo disk crashes nfs Message-Id: <647@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If your apollo disks are mounted via nfs by a remote (non-apollo) host, and on this remote host you do an 'ls -l' to an apollo directory containing some very big files, nfs becomes totally inoperational. This is the same sort of case in which a local 'ls -l' also hangs your SR10 machine, as reported in some previous postings. After 45 minutes the situation becomes automatically normal again. This is totally unacceptable. Example: If the apollo // directory is successfully mounted by the remote host on its directory /apollo, you see something like this: total 3464 drwxr-xr-x 1 root staff 4096 Nov 1 22:39 1989 apollo drwxr-xr-x 2 root staff 2048 Oct 24 11:38 1989 bin drwxr-xr-x 2 root staff 7168 Nov 8 21:27 1989 dev drwxr-xr-x 4 root staff 6144 Nov 8 11:08 1989 etc ..... After an 'ls -l /apollo/dn10000/topdir/subdir' you see things like total 68991 ------x-w- 0 2 20 65535 Jan 1 19:12 1970 apollo drwxr-xr-x 2 root staff 2048 Oct 24 11:38 1989 bin drwxr-xr-x 2 root staff 7168 Nov 8 21:27 1989 dev drwxr-xr-x 4 root staff 6144 Nov 8 11:08 1989 etc ..... total 68991 --ws--xr-t -1 -1 65535 Jan 1 19:12 1970 apollo drwxr-xr-x 2 root staff 2048 Oct 24 11:38 1989 bin drwxr-xr-x 2 root staff 7168 Nov 10 15:27 1989 dev drwxr-xr-x 4 root staff 6144 Nov 10 14:04 1989 etc ..... Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl From apollo-request@umix.cc.umich.edu Mon Dec 18 16:31:41 1989 Message-Id: <8912181633.AA12104@umix.cc.umich.edu> Date: Mon, 18 Dec 89 11:23:12 EST From: Scott Ferguson Subject: Internet Bandwidth To: APOLLO@UMIX.CC.UMICH.EDU I think it would be more proper for those with large numbers of problems to send them in one long message, thus saving time on the internet, as well as making them all easier to get through instead of wading through hundreds of lines of message headers. Anyone else care to comment? Scott Ferguson From apollo-request@umix.cc.umich.edu Mon Dec 18 16:34:01 1989 Message-Id: <8912181639.AA12278@umix.cc.umich.edu> Date: 18 Dec 89 10:12:00 CST From: "DAVE ERSTAD" Subject: Re: SR10.1.p node IDs are still returned in uppercase To: "apollo" Node id's are hexadecimal numbers. It is equally correct to return them in upper or lower case, regardless of whether the OS is case sensitive or not. In fact, I personallyl have a preference for seeing hex in upper case, and most systems I have been on use upper case for hex display. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Mon Dec 18 16:36:27 1989 Date: Mon, 18 Dec 89 09:45:07 PST From: JTBAUER%FSU.MFENET@CCC.NMFECC.GOV Message-Id: <891218094507.22200126@CCC.NMFECC.GOV> Subject: Please remove me from Apollo mailing list..thx. To: apollo@umix.cc.umich.edu Comment: From JTBAUER@FSU.MFENET on December 18, 1989 at 12:46 EST From apollo-request@umix.cc.umich.edu Mon Dec 18 16:39:54 1989 Date: 18 Dec 89 15:39:00 GMT From: mishkin%apollo.hp.com%apollo%hp-sdd.uucp@hplabs.hp.com (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: Has anyone ported NCS to a tahoe? Message-Id: <47805371.20b6d@apollo.HP.COM> References: <32629@cci632.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <32629@cci632.UUCP>, bsw@cci632.UUCP (Brad Werner) writes: > I've been told by a local HP/Apollo sales rep. that NCS is available on > some non-Apollo machines. I'm interested in what is involved in getting > it running on another machine; such as any information regarding source > licensing, ease of porting, and existing ports. In particular, I'm interested > in the availability of an existing port to a CCI 6/32-tahoe running any of > 4.[23]BSD, S5R3. > > Could someone give me a summary of the internals and/or protocol used by > NCS so I can get an idea of how easy it would be to port if a source license > is available. NCS is available in source form and can be ordered from the standard Apollo price list. There are two source products: NCK (runtime library) and NIDL (stub generator). The code should port for a BSD system with virtually no effort. For System V the difficulty is largely a function of how much of the bsd socket and select stuff (if any) was ported to the System V system you have. The NCS code has (at least at one time or another) been built on systems from 16 bits (80x86) to 64 bits (Cray UNICOS). It has been built on Unix and non-Unix systems (VMS, Prime OS). It's very portable. The NCS protocols are specified in the Network Computing Architecture book just published by Prentice-Hall. From apollo-request@umix.cc.umich.edu Mon Dec 18 16:43:16 1989 Date: Mon, 18 Dec 89 12:47:23 CST From: lray@civilgate.ce.uiuc.edu (Leland Ray) Message-Id: <8912181847.AA00810@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: Lots of issues Mr. Wassenaar has raised a large number of issues regarding SR10.1.p on the DN10000. Let me interrupt his deluge with a few points: 1. The vast majority of Mr. Wassenaar's bugs are known and have been corrected either on a patch tape or the upcoming release of SR10.2.p. Please Mr. Wassenaar, order a patch tape. 2. I'm very glad that Mr. Wassenaar did not use SR10.0.p, I would hate to see his reaction. I had the unfortunate experience of installing SR10.0.p on a 4 processor DSP10k with no cartridge tape drive over an ethernet using faulty SR10.1 microcode. BLEAGH. :-) 3. The version of SR10 for 68k machines (be it SR10.0 or SR10.1) has always been higher quality than the Prism versions. I am hoping that the discrepancy will be corrected with the release of SR10.2.p. Just spendin' my days, Leland Ray Systems Administrator Soakin' in them cathode rays. UIUC - Dept. Civil Engineering (217) 333-3821 From apollo-request@umix.cc.umich.edu Mon Dec 18 16:43:50 1989 Date: Mon, 18 Dec 89 14:41:17 EST From: crh@apollo.eng.ohio-state.edu (Charlotte Hawley) Message-Id: <8912181941.AA01755@apollo.eng.ohio-state.edu> To: apollo@umix.cc.umich.edu, e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net Subject: Re: SR10.1.p cannot transfer very large apollo files via nfs To solve your problem - do a rm /usr/lib/sendmail* Be sure you are root From apollo-request@umix.cc.umich.edu Mon Dec 18 16:48:57 1989 Date: 18 Dec 89 15:22:36 GMT From: ajk%mace.cc.purdue.edu%mentor.cc.purdue.edu.uucp@purdue.edu (Jeff Boerio) Organization: Purdue University Computing Center Subject: changing environments? Message-Id: <3732@mace.cc.purdue.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello, I would like to know if someone could tell me how to change environments from System V to BSD on a DN3500. I much prefer using BSD over System V, and can't find the info I need. Thanks, - Jeff -- Jeff Boerio : Purdue University Dept. of Computer Science ajk@mace.cc.purdue.edu : Purdue University Computing Center Volunteer boerio@orchestra.ecn.purdue.edu : Purdue University ECN Student Programmer From apollo-request@umix.cc.umich.edu Mon Dec 18 18:52:14 1989 Date: Mon, 18 Dec 89 15:24:53 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912182024.AA04130@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: bug reporting If anyone has the current address for sending bug reports via email, please post it to this list. Thanks, Dave From apollo-request@umix.cc.umich.edu Mon Dec 18 18:54:25 1989 Date: Mon, 18 Dec 89 15:23:43 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912182023.AA04126@richter.mit.edu> To: e07%nikhefh%hp4nl%mcsun.uucp@uunet.uu.net Subject: Re: SR10.1.p passwd command makes rgy unavailable Cc: apollo@umix.cc.umich.edu The mailing list you are sending message to is a list of Apollo users, not the Apollo corporate bug-reporting address. We (the users) are quite aware that SR10.1.p is full of bugs as we have been using it for sometime now. Please ask your field service office for a copy of SR10.2/SR10.2.p for your site. A lot of what you are reporting are known bugs, and a number of them were fixed in 10.2 -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Mon Dec 18 19:01:19 1989 Date: 18 Dec 89 19:28:25 GMT From: achille%cernvax%mcsun.uucp@uunet.uu.net (achille petrilli) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Subject: Re: PRISM Fortran compiler causes trashing! Message-Id: <1191@cernvax.UUCP> References: , <47625cb9.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <47625cb9.20b6d@apollo.HP.COM> madler@apollo.HP.COM (Michael Adler) writes: >Breaking routines apart into separate source files causes longer calling >sequences, makes inlining (-opt 4) impossible and destroys any chances for >interprocedural optimizations. Well said Michael, but do you know that if we compile a bunch of subroutine together and then make a library out of them, then a reference to any one of the subroutine will bring in all others ? This is due to the wonderful Unix library scheme. We all would be very happy to avoid file splitting, it just does not work if we want to have real libraries. Give us a decent librarian and we'll follow your advice, no doubt about that ! Achille Petrilli Cray and PWS Operations From apollo-request@umix.cc.umich.edu Mon Dec 18 21:15:27 1989 Date: Mon, 18 Dec 89 19:07:26 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912190007.AA04449@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: ACL problem with ~/mbox under SR10.2 I've just installed SR10.2 on about 1/2 of my machines (up from SR9.7), and my users are noticing that everytime they read their mail the ACL on the "mbox" file gets changed so they no longer have any rights to it. I've reset the ACL several times (and checked the initial ACL for the home directory) and each time the ACL gets closed up again. Anyone have any idea what is going on? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Mon Dec 18 21:21:00 1989 Date: 18 Dec 89 23:59:00 GMT From: oj%apollo.uucp@beaver.cs.washington.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: Open Dialog for "other" systems and the death of Apollo... Message-Id: <4782125c.20b6d@apollo.HP.COM> References: <18175@netnews.upenn.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <18175@netnews.upenn.edu> shull@kings.wharton.upenn.edu (Christopher E. Shull) writes: >Does anybody out there know about Open Dialog for "other", ie. non-Apollo >systems. Specifically, we are interested in a version for DEC DECstations >running Ultrix, VAXstations running VMS 5.1, and Silicon Graphics systems run- >ning whatever their flavor of Unix is. The stuff we've committed to replication for V2.0 is for * Apollo m68k and Prism machines * Sun 3 and Sun 4 machines * Source You'll be able to order this in early January. We're currently testing a port to the HP-UX 9000-3xx series, and it's looking pretty good for February...(famous last words? :-) We have source-code customers doing ports to VMS, VAX/Ultrix, and SGI. I believe the VMS and VAX/Ultrix ports are straightforward, but the SGI port ran into a couple of snags related to C++ language processor incompatibilities. We wanted to do the VAX ports ourselves, but we couldn't find a beta site. Is anybody interested? (Ditto for DEC/PMAX)? We'd like to hear from you. >Assuming that at least one of the above is available, where the hell can we >order it? Please contact Cathy Betz at 508 256 6600 x 6085 or Peter Duffey at 508 256 6600 x 2382 for further information about this topic. And thanks for your patience. /Ollie Jones (speaking for myself, not necessarily for HP Apollo Systems Division) From apollo-request@umix.cc.umich.edu Mon Dec 18 21:30:06 1989 Date: 19 Dec 89 00:12:00 GMT From: oj%apollo.uucp@beaver.cs.washington.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: memory allocation bug Message-Id: <47821de1.20b6d@apollo.HP.COM> References: <8912141641.AA09668@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8912141641.AA09668@umix.cc.umich.edu> Dave Erstad took issue with my posting: >> Hmm, either your definition of the term "November Patch Tape" is different >> from ours, or you have a strange tape. As far as I can tell, there >> wasn't a Prism November patch tape, and the Moto tape contained >> only patches related to the X Window System. Dave wrote: >There were many non-X patches (over half, I'm sure). The bulk seemed >to fix sau7/DN4500 problems. He's right. The patch tapes are cumulative, of course. I feel unnaturally possessive about the November tape because I prepared the only two NEW patches on it. Sorry for the wrong info. /Ollie Jones. From apollo-request@umix.cc.umich.edu Mon Dec 18 22:03:07 1989 Date: 18 Dec 89 16:07:00 GMT From: awhitton%bcara2%bnrgate.uucp@uunet.uu.net (Alan Whitton) Subject: RBAK -rem command Message-Id: <296@bnrgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi: I am trying to use the RBAK command with the -REM[OTE] command. I have REXEC turned ON on the site I wish to use the tape drive from but I get the following message when I try this: rbak -rem foo:/dev/rct8 -f 1 -all -pdt -sacl -l Login incorrect. ?(rbak) Unable to establish connection to remote host. I have phoned this into the HP/Apollo hot line and there are no outstanding APRs on this, so has anyone got this running? Be Seeing You, Alan -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "These is my thoughts ONLY" Alan Whitton awhitton@bnr.ca OR Bell Northern Research awhitton%bnr.ca@cunyvm.cuny.edu "I am not a number, I am a Free Man!" From apollo-request@umix.cc.umich.edu Mon Dec 18 23:58:33 1989 Date: 18 Dec 89 14:18:32 GMT From: marmen%is2%bnrgate.uucp@uunet.uu.net (Rob Marmen 1532773) Subject: Re: More SR10 Woes Message-Id: <295@bnrgate.UUCP> References: <8912152124.AA21689@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8912152124.AA21689@umix.cc.umich.edu>, derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") writes: > > I'm doing software development using SR10.1 on a DN4000 with > Pascal 8.6 and C 6.6 (application mixes both). > > The intermittent problem is that when trying to execute the bound > object code, I get a "file is not an object module or is not executable > on this machine type" message. I'm using Motorola compilers and running > on a Motorola node (actual execution is on a DN3000). I'm in a cycle > of minor change-compile-bind-run-repeat, and the problem pops up sometimes > and not others for no discernable reason. > > Dave Erstad > Honeywell SSEC > DERSTAD@cim-vax.honeywell.com I ran into the same problem at our site. I was trying to execute an Apollo compiled program which had been moved to an HP 9000 for storage. I was accessing the module from the HP via NFS. The problem was reported to the Apollo hotline. I forgot what the response was. We've labelled it an NFS "feature". Hope this helps.... rob... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Robert Marmen marmen@bnr.ca OR | | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | | (613) 763-8244 My opinions are my own, not BNRs | From apollo-request@umix.cc.umich.edu Tue Dec 19 00:00:56 1989 Date: 18 Dec 89 22:08:37 GMT From: orand%kuhub.cc.ukans.edu%wuarchive%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (BRADY ORAND) Organization: University of Kansas Academic Computing Services Subject: Good reference material needed Message-Id: <20056@kuhub.cc.ukans.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am trying to learn our Apollo DN4000 workstations. I have some responsibility for helping to manage a lab of 16 DN 4000's. I need to find some way to learn "all I can" about our Apollos. Needless to say, the Apollo manuals are meant for reference and not for learning. Is there a third party manual or any other reference source that would help me to learn the Apollo's? Thanks, Brady... =========================================================================== Brady Orand - University of Kansas Computer Center Lawrence, Ks. 66045 ORAND@kuhub.cc.ukans.edu Work: (913) 864-0490 Home: (913) 749-1341 =========================================================================== From apollo-request@umix.cc.umich.edu Tue Dec 19 00:24:46 1989 Date: 18 Dec 89 16:21:42 GMT From: awhitton%bcara2%bnrgate.uucp@uunet.uu.net (Alan Whitton @ BNR) Subject: COMP in /usr/new/mh a little confused Message-Id: <298@bnrgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello: We have just received FCS sr10.2 and it seems much more sain than SR10.1 (my opinion after 1 week only). I have found 1 quite interesting "feature" of the MH package included under the /usr/new directory. If you try to create a message using COMP the default editor under SR10.1 was /usr/apollo/bin/eddm. I recall this not working too well with machines that have BSD4.3 ONLY installed (such as all of our machines). I submitted an APR on this and they have changed this under SR10.2. Now if you try to use COMP under SR10.2 you get the following message comp cannot find /usr/bin/ex /usr/bin/ex ? Funny on my system it is under /usr/ucb/ex, maybe in a SYSV environment this works, but not in a BSD only system! I have resubmitted an APR on this (again, chuckle ;-) ). Be Seeing You, Alan -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "These is my thoughts ONLY" Alan Whitton awhitton@bnr.ca OR Bell Northern Research awhitton%bnr.ca@cunyvm.cuny.edu "I am not a number, I am a Free Man!" From apollo-request@umix.cc.umich.edu Tue Dec 19 00:48:19 1989 Date: 18 Dec 89 21:24:02 GMT From: lori%hacgate%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc%zaphod.mps.ohio-state.edu.uucp@tut. (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: Internet Bandwidth Message-Id: <6504@hacgate.scg.hac.com> References: <8912181633.AA12104@umix.cc.umich.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8912181633.AA12104@umix.cc.umich.edu> SRFERGU@ERENJ.BITNET (Scott Ferguson) writes: > >I think it would be more proper for those with large numbers of problems >to send them in one long message, thus saving time on the internet, as well >as making them all easier to get through instead of wading through >hundreds of lines of message headers. > >Anyone else care to comment? I disagree. If a message header says "Multifarious and Sundry Questions," how are you going to know to 'n' past it without reading the whole darn thing? Then what if the discussion goes in three different directions? I think even tiny questions on unrelated topics should be posted individually, so we can read all the messages we want in a given day's crop, then 'c' the rest away. Also, sometimes trivial issues become meaty discussions, and if they start out under an inappropriate or nebulous Subject:, then one could miss an enlightening debate. I do suggest, however, that SR9-specific issues have SR9 in the Subject: so SR10 people can kill these out. Also, Unix- or Aegis- specific topics might also contain those keywords in the Subject:. And if DN10k-type discussions have that in the header, the rest of us Motorola-bound admins can just disregard. I say put this info in the Subject: because kill files work lots faster when that's the only place they have to look, and a quick scan of the Subject: lines is what I do first when I log in. For me, it's not the number of messages, but getting to the right ones quickly. ...lori From apollo-request@umix.cc.umich.edu Tue Dec 19 01:29:27 1989 Date: 19 Dec 89 04:40:42 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Ownership inheritance in 10.1p Message-Id: <6794@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu One of the comments in the tirade from the Netherlands reminded me of a problem I have been having with ownership protection. As I am a Unix novice, I thought it was a normal bad feature, but evidently not. Running BSD 4.3, if I am in a directory with owner, say, "bob", and do a mkdir, the directory made comes out with owner "none" whereas under normal BSD you would have bob inheriting the ownership. This is extremely awkard (it wreaks havoc with our Gatorbox nfs file sharing with the macs, as you can't copy a directory from a mac to unix unless you are logged in as "none). My question: Is there anyway to set things up so that newly created files and directories inherit ownership from the parents? Actually, on the subject of the tirade from the Netherlands, I don't mind the bugs in 10.1. All complex software has its problems (its nothing com- pared to the early Cray and Cyber OS's). What really gets my goat is having to PAY $100/month for the privilege of helping Apollo (division of HP) debug their software. That, as our friend from the land of Tulips and dikes would say, is unacceptable. From apollo-request@umix.cc.umich.edu Tue Dec 19 11:18:51 1989 Date: 19 Dec 89 04:32:31 GMT From: kint%software.org.uucp@uunet.uu.net (Rick Kint) Organization: Software Productivity Consortium, Herndon, Virginia Subject: Bugs in SR10.2 rc files Message-Id: <1872@sunny.software.org> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We just brought up our first few SR10.2 systems, and so far are happy with it. We had a couple of problems with rc files I'd like to pass on. If you uncomment the commands to start prmgr and/or prsvr in rc.user (/etc/rc.user, a link to `node_data/etc/rc.user), the commands may not start, commands after them in rc.user may not start, and the "Starting Windows" message from init may appear on the same line as the "Starting Other Daemons" message instead of on the next line (this is a sign that rc.user did not fully execute, since its last act is to echo a period and a newline to /dev/console). The first error is on the following line (line 76 in the stock rc.user) if [ -f /sys/hardcopy/prsvr -a $LLBD_ENABLED = true]; then The Bourne shell uses spaces to delimit tokens and considers "true]" to be a single token. This causes test to exit with an error, which causes rc.user to abort. Putting a space in fixes this: if [ -f /sys/hardcopy/prsvr -a $LLBD_ENABLED = true ]; then The other problem is more subtle. The prmgr and the prsvr both test the value of the shell variable LLBD_ENABLED. This variable is set in /etc/rc (a link to `node_data/etc/rc). Unfortunately, shell variables are not automatically exported to child processes; LLBD_ENABLED is not exported to rc.user by rc, so LLBD_ENABLED is evaluated as a null string. Thus the line above is interpreted as if [ -f /sys/hardcopy/prsvr -a = true]; then The '=' operator is a binary infix operator which needs a string on both sides. This not being the case, test exits and causes rc.user to exit. Add the following line to /etc/rc to export the variable: export LLBD_ENABLED -- Rick Kint CSNET: kint@software.org Software Productivity Consortium ARPANET: kint%software.org@relay.cs.net Herndon, VA UUNET: ...!uunet!sunny!kint From apollo-request@umix.cc.umich.edu Tue Dec 19 11:41:40 1989 Date: Tue, 19 Dec 89 10:36:13 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912191536.AA05300@richter.mit.edu> To: apollo@umix.cc.umich.edu, rtp1%tank.uucp@handies.ucar.edu Subject: Re: Ownership inheritance in 10.1p When you invol (ie. format) your SR10 disk, you get to choose whether the default method of propagating ownership on newly created files and subdirectories is the BSD model, the SYSV model, or the AEGIS model. My guess is that your disk was set up for AEGIS. Anybody out there know a quick test and fix for this problem? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Tue Dec 19 16:53:35 1989 Date: 19 Dec 89 18:29:26 GMT From: lwa%skeptic%paperboy%snorkelwacker.uucp@tut.cis.ohio-state.edu (Larry Allen) Organization: Open Software Foundation Subject: Re: Ownership inheritance in 10.1p Message-Id: <2137@paperboy.OSF.ORG> References: <8912191536.AA05300@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Dave is right. To check, use the "lsacl" command to list the initial file ACL on the directory. To change the initial file ACL to be UNIX-style (either BSD or System V style), you can use the "chacl" command; "chacl -B" sets BSD-style inheritance (file owner is the creator's uid, while group comes from the directory), and I forget what the flag for System V style inheritance (both file owner and file group come from the creator's uid and gid). See the chacl documentation. -Larry Allen Open Software Foundation From apollo-request@umix.cc.umich.edu Tue Dec 19 17:13:34 1989 Date: 19 Dec 89 19:04:32 GMT From: hall%aplcen.uucp@uunet.uu.net (Marty Hall) Organization: AAI Corp AI Lab, JHU P/T CS Faculty Subject: Addresses of locations doing chip fabrication Message-Id: <4347@aplcen.apl.jhu.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hi. I have a friend who is looking to change jobs and is looking for addresses of vendors/sites that do their own chip fabrication. He has been doing Gallium Arsenide stuff but says he is also interested in getting back into Silicon. Any suggestions? [This is probably not of general interest in this group, so please email replies. I can send summaries to interested parties.] Thanks! - Marty Hall ------------------------------------------------------------------ hall@aplcen.apl.jhu.edu hall%aplcen@jhunix.bitnet ..!uunet!aplcen!hall From apollo-request@umix.cc.umich.edu Tue Dec 19 17:15:30 1989 Date: 19 Dec 89 18:03:56 GMT From: kcarroll%utzoo%utgpu%jarvis.csri.toronto.edu%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Kieran A. Carroll) Organization: U of Toronto Zoology Subject: Stolen DN4000: 130f1 Message-Id: <1989Dec19.180356.12043@utzoo.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu (I'm posting this message for a friend, whose employer suffered the loss of one of their Apollo nodes recently. He works for a small company, so this theft hurt them badly. Any information regarding this matter would be greatly appreciated; please send any info. to me via >>MAIL<< (NOT news!), or phone me at (416)-667-0517, and I'll pass it along to my friend. Thanks! -KAC) On Saturday, December 9th, several items of computer equipment were stolen from a Toronto company. They were: - an Apollo DN4000, Node ID = 130f1, with a 5-1/4" floppy disc drive, a cartridge tape controller board, and an ethernet card; - a QMS-PS 810 laser printer; - a Danford external cartridge tape drive; - a Fastcomm 9600 "Turbo" modem. If you see any such equipment come on the market ("great deal; real cheap"), and suspect that it might be the stolen equipment, please contact me, either via email or telephone. In particular, if people on the net were to do a "bldt" command on any newly-installed DN4000's that they happen across in the next few weeks, and compare the resulting node ID with the one given above, I think that there's a fair chance of finding out who carried out the theft. The possibility of a reward (say, for information leading to recovery of equipment, or prosecution of the thief or thieves) should >>not<< be ruled out. Many thanks. -- Kieran A. Carroll @ U of Toronto Aerospace Institute uunet!attcan!utzoo!kcarroll kcarroll@zoo.toronto.edu From apollo-request@umix.cc.umich.edu Tue Dec 19 17:47:50 1989 Message-Id: <8912191955.AA18883@umix.cc.umich.edu> Date: 19 Dec 89 12:50:00 CST From: "DAVE ERSTAD" Subject: Re: More SR10 Woes To: "apollo" >From Robert Marmen: > I ran into the same problem at our site. I was trying to execute an Apollo compi > led > program which had been moved to an HP 9000 for storage. I was accessing the modu > le > from the HP via NFS. and Andrew Wescott: > I think you will find the NFS problem is solved with > the above combination. Actually, I think the newest > Pascal compiler will do the job.. The above combo > should also solve the vms problem you were having. > I beta-tested all of the current compilers, and I was > able to compile and link remote (NFS) source files, > as well as load executables onto the NFS disk. However, this is not an NFS problem. Everything is on the same token ring. I have determined that local binds never exhibit this problem, and the object code runs on at least two other nodes successfully, so I suspect my local nodes type managers might be corrupted somehow. It's odd that the problem is intermittent, however. We may reload my node. I'll keep the net posted. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Tue Dec 19 19:14:40 1989 Date: 19 Dec 89 21:19:00 GMT From: pcc%apollo.hp.com%apollo.uucp@EDDIE.MIT.EDU (Peter Craine) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: SR10.1.p does not allow multiple (independent) registries Message-Id: <47868ad5.20b6d@apollo.HP.COM> References: <632@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <632@nikhefh.nikhef.nl>, e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: > > In SR10 the rgy database seems to be network-wide. > This is absolutely unacceptable if there are multiple groups of > machines which are under separate administrative management, > with different accounts, which must have different registries. > In SR9 this was perfectly possible. This is quite possible under SR10.2 using NCS cells. See the documentation about this in the SR10.2 manual "Managing NCS software" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + You Klingon son, you killed my bastard Hewlett-Packard + Chelsmford Response Center + *I* don't want my opinions. Why would HP? From apollo-request@umix.cc.umich.edu Tue Dec 19 19:25:17 1989 Date: 19 Dec 89 22:20:28 GMT From: lori%hacgate%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc.uucp@ucsd.edu (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: live video for Apollo ? Message-Id: <6519@hacgate.scg.hac.com> References: <5207.2588d12b@vtt.vtt.fi> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <5207.2588d12b@vtt.vtt.fi> lucenius@vtt.vtt.fi writes: >We intend to experiment with multimedia retrieval including live video, >thus if possible we would like to get video from external source(s) in >window(s) onto the consol screen. [...] >Are there any such systems for DN3500. How with other workstations. Has any- >body any experience; what hardware and software is needed ? Well, the Intelligent Light system we bought isn't exactly what you are asking about, but they may have the capability you seek. (Our system generates 3-D graphics animation on a Sony monitor via a VCR-type machine which is wired in to a DN3000.) Their number is 201-794-7550. I question whether a DN3500 will have the graphics horsepower to display real-time video sequences smoothly, but I'm no hardware expert. Double buffering with an enhanced 256-bit-plane graphics card (if exists) might be a minimum upgrade. Please let us know what you find out. ...lori From apollo-request@umix.cc.umich.edu Tue Dec 19 19:28:46 1989 Date: 19 Dec 89 23:52:10 GMT From: kerr%tron%umbc3%haven%aplcen%uakari.primate.wisc.edu%zaphod.mps.ohio-state.edu%nisca.ircc. (Dave Kerr) Organization: Westinghouse Electric Corporation Subject: Re: Ownership inheritance in 10.1p Message-Id: <469@tron.UUCP> References: <6794@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <6794@tank.uchicago.edu> rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) writes: >One of the comments in the tirade from the Netherlands reminded me of >a problem I have been having with ownership protection. As I am a [ text describing inheritance deleted ] Under sr10, you can have three styles of initial acls, one based on bsd unix, one based on sys5 unix and one based on aegis. The unix ones get the acls (permissions) for newly created files from your process and group, while aegis style acls are inherited from initial file and directory acl entries found in the parent directory. You can use the /usr/apollo/bin/chacl command to select the style of your choice. -- Dave Kerr (301) 765-4453 kerr@tron.bwi.wec.com from an Internet site kerr@tron.UUCP from a smart uucp mailer From apollo-request@umix.cc.umich.edu Tue Dec 19 19:57:31 1989 Date: 19 Dec 89 21:30:00 GMT From: pcc%apollo.hp.com%apollo.uucp@eddie.mit.edu (Peter Craine) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: SR10.1.p bsd/sysv ls -l hangs for large files Message-Id: <4786940c.20b6d@apollo.HP.COM> References: <611@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <611@nikhefh.nikhef.nl>, e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: > If you do a 'ls -l' for a directory containing some very big files, > the command may take very long, or may never finish. It seems to be > dependent on the size of the files. > It is not working for both bsd and sysv. /com/ld -a works ok. > This is not as simple as it sounds. /com/ld shows the total disk space allocated to the file. Simple, right? Well 'ls -l' shows the amount of READABLE data in the file (if you were to do UNIX read() calls). Big difference. So, 'ls' is actually calling the type manager involved to figure out "how large" the files are. (Yes, this is why the sizes will differ between 'ls' and 'ld'. For many file types, this does not pose a problem. However, for 'rec' typed files, each record has to be considered independently. I have seen this type of behaviour from SR10.1 'ls' on rec files. If the problem still exists at SR10.2, it is less noticable at 10.1. > As a side effect, for the duration of such hanging ls, the rgy daemon > becomes unavailable for servicing requests. I have never seen this symptom, but I don't use a node that has rgyd running on it. > My god, what is going on here? Isn't ls just doing a stat() of a file? Yes, stat() is doing the call to the type manager. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + You Klingon son, you killed my bastard Hewlett-Packard + Chelmsford Response Center + *I* don't want my opinions. Why would HP? From apollo-request@umix.cc.umich.edu Tue Dec 19 21:14:52 1989 Date: 19 Dec 89 23:40:58 GMT From: kerr%tron%umbc3%haven%aplcen%uakari.primate.wisc.edu%zaphod.mps.ohio-state.edu.uucp@tut.cis. (Dave Kerr) Organization: Westinghouse Electric Corporation Subject: Re: ACL problem with ~/mbox under SR10.2 Message-Id: <468@tron.UUCP> References: <8912190007.AA04449@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8912190007.AA04449@richter.mit.edu> krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: >I've just installed SR10.2 on about 1/2 of my >machines (up from SR9.7), and my users are >noticing that everytime they read their mail >the ACL on the "mbox" file gets changed so >they no longer have any rights to it. I've >reset the ACL several times (and checked the >initial ACL for the home directory) and each >time the ACL gets closed up again. Anyone have >any idea what is going on? > > We had a similar problem. The bottom line was that when we used /com/cpt -conv -pdt -sacl to move the user's home directories over to sr10 from sr9.7, the owner, group and org entries were set to "none", the user was added as an extended acl entry. When mail saves a message into ~/mbox, it (apparently) does a chmod to restrict access to the file. Chmod sets the permissions as expected but also sets the extended acl mask to all -'s effectively removing the extended acl entry. It's interesting however that our first sr10.1 (unpatched) machines set the acls so the user was the owner when you did a cpt -conv, one of the patches we installed stopped this from working in this manner. The man page for cpt says that the -conv option should add entries in as extended acl entries, so apparently the command is not "fixed" although I perfer the broken version :-). -- Dave Kerr (301) 765-4453 kerr@tron.bwi.wec.com from an Internet site kerr@tron.UUCP from a smart uucp mailer From apollo-request@umix.cc.umich.edu Tue Dec 19 21:17:13 1989 Date: Tue 19 Dec 89 17:57:54-PST From: Steve Albrecht Subject: Re: More SR10 Woes To: derstad@cim-vax.honeywell.com Cc: apollo@umix.cc.umich.edu, Albrecht@INTELLICORP.COM Message-Id: <630122274.440000.ALBRECHT@INTELLICORP.COM> In-Reply-To: <8912152124.AA21689@umix.cc.umich.edu> Mail-System-Version: RE: "file is not an object module or is not executable on this machine type" I assume that the target DN3000 is also running SR10.1. If it is running SR9.7 or before, than you will have to convert the COFF object file. Speaking from knowledge of the Domain and UNIX C compilers only, the deafult target should be "any", but you may want to specify it explicitely with the -cpu or -M options. See pp 6-222 and 6-23 of Domain C Language Reference for details. RE: "block length increases to about 5000" Do you mean "the file length increases to about 5000"? If so, this is a well known problem in SR10.1 for which a fix is promised in SR10.2. Grit your teeth if you need it fixed in Domain/OS 10.1. (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ) Steve Albrecht - IntelliCorp, Inc. - Knowledge Systems Product Development ( ( "Opinions expressed here are my own, if anyone's, and not my employer's." ) ) DDS albrecht@intellicorp.com : COMPUSERVE 73657,1342 ( ( UUCP ...!sun!intellicorp.com!albrecht : public bbs (415)969-5643 ) ) or ...!sun!icmv!albrecht : "c"omment to sysop ( (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ------- From apollo-request@umix.cc.umich.edu Tue Dec 19 23:45:41 1989 Date: Tue, 19 Dec 89 21:20:53 CST From: Steven W. Poole Message-Id: <8912200320.AA00775@lnic1.hprc.uh.edu> To: apollo@umix.cc.umich.edu, lori%hacgate%elroy.jpl.nasa.gov%henry.jpl.nasa.gov%usc.uucp@ucsd.edu Subject: Re: live video for Apollo ? 256 bit ????? Steve... From apollo-request@umix.cc.umich.edu Wed Dec 20 09:16:56 1989 Date: 19 Dec 89 12:56:26 GMT From: awhitton%bcara2%bnrgate.uucp@uunet.uu.net (Alan Whitton @ BNR) Subject: Re: bug reporting Message-Id: <299@bnrgate.UUCP> References: <8912182024.AA04130@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <8912182024.AA04130@richter.mit.edu>, krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes: > If anyone has the current address for sending bug > reports via email, please post it to this list. > > Thanks, > Dave The process for submitting BUGS to Apollo (if you do not feel like phoning their 1-800 number, or don't feel like shelling out big bucks to get access to this (only my opinion) ;-) ) is to submit an APR (Apollo Product Request) via /usr/apollo/bin/mkapr Read the manual page on this, but this will in turn send mail to the following address: apr_cs_admin@apollo.hp.com BUT PLEASE DO NOT JUST SEND MAIL THERE. I believe there is a clerk that reads this, but this is for APR SUBMISSIONS ONLY. Luckily in the APR format you can gripe to your hearts content. Be Seeing You, Alan -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "These is my thoughts ONLY" Alan Whitton awhitton@bnr.ca OR Bell Northern Research awhitton%bnr.ca@cunyvm.cuny.edu "I am not a number, I am a Free Man!" From apollo-request@umix.cc.umich.edu Wed Dec 20 11:24:53 1989 Date: 20 Dec 89 01:42:05 GMT From: dan%cpsc%calgary%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Dan Freedman) Organization: Knowledge Science Lab, U. of Calgary, Calgary, Canada. Subject: Re: SR10.1.p ruptime does not display load averages Message-Id: <2266@cs-spool.calgary.UUCP> References: <604@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <604@nikhefh.nikhef.nl> e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: >The ruptime command does not display load averages, although such >information from remote (non-apollo) machines is present in the >appropriate files in the /usr/spool/rwho directory. >The SR9.7 version of ruptime was ok in this respect. I reported this bug to Apollo via an APR. Twice. Each time, the response came back "Apollos don't generate load statistics". I believe my APRs explicitly stated that the problem was with Apollo's ruptime not reporting other vendors' machines load stats, not with the lack of such stats from Apollos. My call to the APR administrator (the replies you get from Apollo in the mail say to call the APR administrator if there are concerns with the APR) got me "Oh yes. I see what you mean. I'll make sure it gets re-interpreted". A couple of weeks later, the reply came in the mail saying "Apollos dont generate load stats". Draw your own conclusions. Dan Freedman Dan Freedman University of Calgary Computer Science Department 2500 University Drive N.W. dan@ksi.cpsc.UCalgary.CA Calgary, Alberta, T2N 1N4 From apollo-request@umix.cc.umich.edu Wed Dec 20 13:23:53 1989 Date: 20 Dec 89 16:58:00 GMT From: pcc%apollo.hp.com%apollo.uucp@eddie.mit.edu (Peter Craine) Organization: Hewlett-Packard Chelmsford Response Center Subject: Re: SR10.1.p syslog.pid should be link to `node_data/etc Message-Id: <478aa8ed.20b6d@apollo.HP.COM> References: <623@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <623@nikhefh.nikhef.nl>, e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: > /etc/syslog.pid should be a symbolic link to `node_data/etc/syslog.pid fixed at Sr10.2 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + You Klingon son, you killed my bastard Hewlett-Packard + Chelmsford Response Center + *I* don't want my opinions. Why would HP? From apollo-request@umix.cc.umich.edu Wed Dec 20 13:27:27 1989 Date: 20 Dec 89 16:50:00 GMT From: pcc%apollo.hp.com%apollo.uucp@eddie.mit.edu (Peter Craine) Organization: Hewlett-Packard Chelmsford Response Center Subject: Re: SR10.1.p mesg command disables further crp logins Message-Id: <478aa164.20b6d@apollo.HP.COM> References: <621@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <621@nikhefh.nikhef.nl>, e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: > If one logs in using crp onto an SR10 node, the 'mesg n' command > puts /dev/crp?? in mode 644, which is never reset to mode 666 > after logout. This disables further crp logins, since they require > mode 666 from the beginning. > Fixed at SR10.2 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + You Klingon son, you killed my bastard Hewlett-Packard + Chelmsford Response Center + *I* don't want my opinions. Why would HP? From apollo-request@umix.cc.umich.edu Wed Dec 20 13:34:04 1989 Date: 20 Dec 89 17:00:00 GMT From: pcc%apollo.hp.com%apollo.uucp@eddie.mit.edu (Peter Craine) Organization: Hewlett-Packard Chelmsford Response Center Subject: Re: SR10.1.p cannot start csh on spm server console Message-Id: <478aaaa9.20b6d@apollo.HP.COM> References: <600@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <600@nikhefh.nikhef.nl>, e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: > If you have a simple terminal attached to sio.spm on your DSP10000, > and you login via the spm "sh" command, you cannot start /bin/csh Because of problems in spm, you can't use csh or ksh on a DSP console. You also can't use ksh in a crp window (because of the same problems). This (more than likely) won't be fixed in sr10.x +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + You Klingon son, you killed my bastard Hewlett-Packard + Chelmsford Response Center + *I* don't want my opinions. Why would HP? From apollo-request@umix.cc.umich.edu Wed Dec 20 13:41:17 1989 Date: 20 Dec 89 16:19:37 GMT From: marc%bpe2.spix7.depr.bull.fr%bull%inria%mcsun.uucp@uunet.uu.net ( Marc PARIGOT ) Organization: BULL S.A., Paris , France Subject: Porting NCS on Dps7 (study case) Message-Id: <231@bull.bull.fr> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Hello, I work for Bull (paris) in the team that port Unix on DPS7: Spix7. It is a full SV.3/X.Open unix system. At present my boss ask me to make some investigation in the aim to port NCS on Spix7. He want to know the time to do this job. We have ported TCP(UDP)/IP and the bsd socket but I've read somewhere in this newsgroup that the difficulty to port NCS is a function of how much of the bsd socket are ported. I want to know in which way? I want to know the number of lines NCS represent and perhaps the percent that is not portable. And last thing (for the moment) I want to know if it exists a simple and fast way to convert IBM floatting point format number into IEEE format number and vice-versa (the format of dps7 floatting point number is the Ibm format): ------------------------- ---------------------------- |s| exp | mantissa | <==> | mantissa | exp |s| ------------------------- ---------------------------- fibm fieee fibm = (-1)**s * (16)**(exp1-64) * mantissa1 fieee = (-1)**s * 2**(exp2-127) * mantissa2 ibm_to_ieee(exp1, mantissa1, &exp2, &mantissa2); ieee_to_ibm(exp2, mantissa2, &exp1, &mantissa1); Thanks for your time. Marc Post-scriptum: I beg your pardon for my approximative english, I realize that it's a kind of pseudo language... E.mail: Marc.Parigot@depr.bull.fr From apollo-request@umix.cc.umich.edu Wed Dec 20 13:49:48 1989 Date: 20 Dec 89 15:30:00 GMT From: rehrauer%apollo%hp-sdd.uucp@hplabs.hp.com (Steve Rehrauer) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Subject: Re: PRISM Fortran compiler causes trashing! Message-Id: <478a5a3f.20b6d@apollo.HP.COM> References: , <129179@sun.Eng.Sun.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article hanche@imf.unit.no (Harald Hanche-Olsen) writes: >This is a short tale about a long FORTRAN compilation on the DN10000. >... >Rhetoric question: What do those compiler writers at HP/apollo think >they're doing? Writing for machines with a minimum of 128M of memory? (I'm responding for Bruce Olsen regards Prism compiler performance. These are his words, not mine.) --------------------------------------------- Mr. Hanche-Olsen has evidently encountered a compile_time performance problem that we have not seen. He got these results with the first release Fortran compiler, compiling on a machine configured with the minimum amount of physical memory. The design goals for the DN10000 compilers were ( in priority order ) - Code Quality, - Reliability, - Compile-time efficiency. While we were very pleased with the levels of code quality an reliability that we attained, the initial release did not exhibit the level of compile- time efficiency that we wanted. The second release shows substantial improvement. The typical user, compiling code that is not dramatically too large for his physical memory, will see compile speeds on the order of several thousand lines per minute. Your mileage may vary. We expect to make further substantial compile-time improvements in subsequent releases. In sum, we believe that you can expect good compile times on the DN10000 provided that you have a reasonable amount of physical memory for the job at hand. When you're estimating your memory needs, keep in mind that code for most RISC machines is 1.5 -2.0X as large as the corresponding code for CISC machines. Again, your mileage may vary. Also, it generally requires a sophisticated compiler to take advantage of the improved run-time performance of RISC architectures. Such compilers tend to be bigger and (yes, we admit it) slower than comparable CISC compilers. The payoff, we believe, is that your program runs faster. Should you experience this problem (or any other), we would of course welcome any input that can help us reproduce and analyze it. Bruce Olsen Apollo Division/HP -- >>"Aaiiyeeee! Death from above!"<< | Steve Rehrauer, rehrauer@apollo.hp.com "Flee, lest we be trod upon!" | The Apollo System Division of H.P. From apollo-request@umix.cc.umich.edu Wed Dec 20 15:13:06 1989 Date: 20 Dec 89 18:03:00 GMT From: aaron%apollo.uucp@eddie.mit.edu (Aaron Sawyer) Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA Subject: Re: bug reporting (email address) Message-Id: <478ae31b.20b6d@apollo.HP.COM> References: <8912182024.AA04130@richter.mit.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In <8912182024.AA04130@richter.mit.edu>, krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) asks: >If anyone has the current address for sending bug >reports via email, please post it to this list. >From the mkapr *on-line* man page (sr10.2) -- Encoded product reports may be sent to Apollo Customer Services via the UUCP network. The network address is: apollo!apr_cs_admin Recommended paths to Apollo are via mit-eddie or decvax. Some other sites that are short hops from Apollo are uunet, kddlab and unido. These paths may change with time; check with your site administrator. If your site knows about one of the following Hewlett Packard sites, E-mail delivery to Apollo is rapid and reliable. hplabs Palo Alto, CA hp-sdd San Diego, CA hp-pcd Corvallis, OR hpbbn Boeblingen, West Germany hplb Bristol, UK hpycla Tokyo, Japan Apollo is registered with the (ARPA) Internet. If your site has access, our Internet address is: apr_cs_admin@apollo.hp.com Customer Services will acknowledge all product reports received. Do not assume your product report has been received until you receive a reply. Security-conscious sites should not send confidential material. Voluminous submissions should be sent via magnetic media. ----- Aaron Sawyer Disclaimer: 'My ~/.signature, my opinions' Internet: aaron@apollo.hp.com UUCP: ...{decvax,mit-eddie}!apollo!aaron Aaron Sawyer Disclaimer: 'My ~/.signature, my opinions' Internet: aaron@apollo.hp.com UUCP: ...{decvax,mit-eddie}!apollo!aaron QQQQ (Quoted Quotable Quotidian Quotation): "Yeah? Well, 4Q2!" Copyright 1989 by Aaron Sawyer. All rights reserved. Free redistribution allowed. From apollo-request@umix.cc.umich.edu Wed Dec 20 15:21:58 1989 Date: 20 Dec 89 17:11:00 GMT From: pcc%apollo.hp.com%apollo%hp-sdd.uucp@hplabs.hp.com (Peter Craine) Organization: Hewlett-Packard Chelmsford Response Center Subject: Re: SR10.1.p only bsd disk device is /dev/wn0a Message-Id: <478ab441.20b6d@apollo.HP.COM> References: <601@nikhefh.nikhef.nl> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <601@nikhefh.nikhef.nl>, e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: > If I want to partition my disk into several logical volumes, > I need to have device entries like /dev/wn0b, /dev/wn0c, etc. > If I have more than one disk and more than one disk controller, > I need to have device entries like /dev/wn1a, /dev/wn1b, etc. > > I want to say '/etc/mount -avt 4.3' to mount all devices > mentioned in /etc/fstab, instead of using /com/mtvol. > > None of this seems to be possible in the bsd environment. > I cannot find information how to 'mknod' such disk devices. Do a "man 4 intro" (in BSD). That will give you the device number layout. In short, the minor number = (controller # * 128) + (drive # * 16 ) + (Log Vol #) UNLESS YOU'RE ON A DN2500 If you're on a dn2500, then the world changes. There are only two bits for controller number, and "nobody really has more than 4 drives on a controller", so, keep the low two bits of the controller number, put the high bit of the controller # in the high bit of drive #, and plug it into the formula above (drive # = 3 bits). [Oh, what fun!] I've written a program to do all these calculations and to give you the appropriate commands. I'll be posting it soon. /etc/rc* don't automatically mount 2nd and 3rd disks. You will need to write a small script to "salvol -n" your disks, and then you can do a mount -a. > > Showing my mounted disks after /com/mtvol yields the strange > /dev/wn0a on / type 4.3 (rw) > /dev/dsk/W0d1s1 on /shiva2 type AEG (rw) > and the df listing has its own non-bsd naming conventions > Filesystem kbytes used avail capacity Mounted on > 1d858.1 1367480 311552 1055928 23% / > 1d858.2 1367480 1118560 248920 82% /shiva2 > If you don't use BSD mount, then df (and mount) make up their own device names. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + You Klingon son, you killed my bastard Hewlett-Packard + Chelmsford Response Center + *I* don't want my opinions. Why would HP? From apollo-request@umix.cc.umich.edu Thu Dec 21 05:52:56 1989 Date: 20 Dec 89 19:40:55 GMT From: sscott%camdev%csccat%texsun%texbell%wuarchive%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Steve Scott) Organization: Motorola Inc., Ft. Worth, Tx Subject: Need Postscript model for /usr/spool/lp/model Message-Id: <232@camdev.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anybody have a Postscript (Apple NTX specifically) compatible script for /usr/spool/lp/model on a Sys V machine (HP/UX 6.5 specifically)? -- Steve Scott UUCP: {attctc|texbell|texsun}!csccat!camdev!sscott Motorola, Inc. Telephone : 1-817-232-6317 From apollo-request@umix.cc.umich.edu Thu Dec 21 06:14:07 1989 Date: 20 Dec 89 19:49:25 GMT From: sscott%camdev%csccat%texsun%texbell%wuarchive%usc%zaphod.mps.ohio-state.edu.uucp@tut.cis. (Steve Scott) Organization: Motorola Inc., Ft. Worth, Tx Subject: Need Postscript model for /usr/spool/lp/model Message-Id: <234@camdev.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anybody have a Postscript (Apple NTX specifically) compatible script for /usr/spool/lp/model on a Sys V machine (HP/UX 6.5 specifically)? -- Steve Scott UUCP: {attctc|texbell|texsun}!csccat!camdev!sscott Motorola, Inc. Telephone : 1-817-232-6317 From apollo-request@umix.cc.umich.edu Thu Dec 21 09:16:49 1989 From: David B Funk Date: Thu, 21 Dec 89 01:28:59 CST Subject: Re: ACL problem with ~/mbox under SR10.2 To: apollo@umix.cc.umich.edu, krowitz@richter.mit.edu In posting <8912190007.AA04449@richter.mit.edu> David Krowitz asks: > I've just installed SR10.2 on about 1/2 of my > machines (up from SR9.7), and my users are > noticing that everytime they read their mail > the ACL on the "mbox" file gets changed so > they no longer have any rights to it. Per chance when you say "they no longer have any rights to it" do you mean that they no longer 'own' it? Is it the case that that they still own it but can't get at it or is it the case that the mbox becomes owned by "none"? If it is the case that they still own it but have no rights to it then check the value of their "umask". If it is the case that the file becomes owned by "none" then here's what may be happening: One of the problems of running a mixed sr9.7 - sr10.x network is caused by an incompatability of the ACL systems. sr10 has a 2 level ACL system, the mandatory ACL entries and the optional extended ACL entries. sr9.x only has what could be called mantitory "extended" ACL entries. All sr9.x ACL entries get mapped into the sr10 "extended" ACL entries, sr9.x cannot express to sr10 the mandatory "ownership" entries. When a sr9.x system changes the ACL on a sr10 object (a file or dir on a sr10 machine) all the required "ownership" entries get 'nulled out' and all the info gets pushed down into the "extended" entry. Thus the object loses its 'ownership' as seen by the sr10 system. Here's the big pain: If a user has his/her home directory on a sr10 machine and changes the ACL (protections) on an object, while logged into a sr9.7 machine, then he/she loses 'ownership' of that object as seen by sr10. It will look OK from a sr9.7 machine but when you go to a sr10 machine, it will be FUBAR. Where this is a real problem is that many Unix utilities (like most of them) love to do "chmod"s on files that they create/modify. So if your home directory is on a sr10 machine and you use Unix (Domain/IX) from a sr9.7 machine, then you will make a mess of the sr10 ownership of your stuff. For example: Here's the ACLs on a "mbox" file in my sr10 directory, as seen from the sr10 machine: $ acl ~/mbox Acl for ~/mbox: Required entries dbfunk.%.% prw-- %.sys_admin.% ----- %.%.none [ignored] %.%.% ----- Extended entry rights mask: ----- Here's the ACLs on the same file in my sr10 directory, as seen from a sr9.7 machine: $ acl mbox Acl for mbox: dbfunk.%.%.% pgndwr- %.sys_admin.%.% --nd--- here I do a "chmod" on that same file from the sr9.7 machine $ chmod 600 mbox $ acl mbox Acl for mbox: dbfunk.%.%.% pgndwr- %.sys_admin.%.% --nd--- %.backup.%.% --n--r- Now I go back to the sr10 machine and look at its ACL: $ acl ~/mbox Acl for mbox: Required entries none.%.% [ignored] %.none.% [ignored] %.%.none [ignored] %.%.% ----- Extended entry rights mask: prw-k Extended entries dbfunk.%.% prw-- %.sys_admin.% ----- %.backup.% -r--k $ ls -l mbox -rw-rw-rw-+ 1 none 17276 Dec 21 01:19 mbox Note that now (according to sr10) the file is 'owned' by "none". There are entries in the extended ACL that give me rights to the file, but according to "stat" I no longer own it. Dave Funk From apollo-request@umix.cc.umich.edu Thu Dec 21 09:17:52 1989 Date: 21 Dec 89 09:25:38 GMT From: frederit@boulder.colorado.edu (FREDERICKS THOMAS M) Organization: University of Colorado, Boulder Subject: Shutdown question Message-Id: <15111@boulder.Colorado.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I have recently become a sysadmin for our apollos. I find it rediculous to see that the machines can be shut down by anyone at the console. Is there a way to prevent this. I am referring to the fact that you can just type shut to the login prompt and it will die. BTW we are running sr10.1 on a dn3500. Tom... From apollo-request@umix.cc.umich.edu Thu Dec 21 17:25:21 1989 Message-Id: <47905eafa.00129dc@caen.engin.umich.edu> To: Scott Ferguson Cc: APOLLO@UMIX.CC.UMICH.EDU Subject: Re: Internet Bandwidth In-Reply-To: Your message of Mon, 18 Dec 89 11:23:12 -0500. <8912181633.AA12104@umix.cc.umich.edu> Date: Thu, 21 Dec 89 15:13:37 -0500 From: paul killey There is something to be said for putting things together in fewer messages to this list. Especially in that this is not a formal bug reporting channel to apollo. On the other hand, people should feel that they have the latitude to make their own decision about how they want to present material here. Understanding that they may hear back from recipients, etc. (Bland enough? -:)) >From the standpoint of this mailing list, I have decrufted it quite a bit (getting rid of broken addresses and trying to be much more prompt about requests to apollo-request) so there weren't a lot of bounces. But there are always two or three VMS machines where a recipient has used all their disk space and the message couldn't be delivered. --paul From apollo-request@umix.cc.umich.edu Thu Dec 21 17:32:41 1989 Date: 21 Dec 89 18:51:31 GMT From: barriost%utopia%hrc%asuvax%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Tim Barrios) Organization: gte Subject: news software (b/c) for Apollo SR10 Message-Id: <4790152b.15b4b@utopia.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We are in the process of converting to Domain/OS (SR10). Currently, we run bnews on one of 800+ Apollo nodes and all of our nodes are linked to the news server. Our news software is in need of a re-configure/re-make so I want to find out if there is a new version of news that works better on SR10. Here are my specific questions: 1. is there an Apollo/SR10 specific version or will the generic source make on Apollo SR10 2. where can i get it 3. does new still have to be batched still (because of a locking of the active file problem) 4. is anyone running it successfully under sys5 instead of bsd 5. do both bnews and cnews work on SR10 if this is of general interest, post followups. if not, just send me mail and i will post a summary (use my signature mailing address since the news one is wrong). -- Tim Barrios (barriost@gtephx) UUCP: {ncar!noao!asuvax | uunet!zardoz!hrc | att}!gtephx!barriost AGCS (formerly GTE), Phoenix (602) 582-7101 From apollo-request@umix.cc.umich.edu Thu Dec 21 17:37:36 1989 Date: 21 Dec 89 18:14:22 GMT From: lori%hacgate%elroy.jpl.nasa.gov%henry.jpl.nasa.gov.uucp@decwrl.dec.com (Lori Barfield) Organization: Hughes Aircraft Co., El Segundo, CA Subject: Re: Shutdown question Message-Id: <6536@hacgate.scg.hac.com> References: <15111@boulder.Colorado.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <15111@boulder.Colorado.EDU> frederit@boulder.Colorado.EDU (FREDERICKS THOMAS M) writes: > [...] the machines can be shut down by anyone > at the console. Is there a way to prevent this. [...] If it's that important, you might write your own DM script to mimic the standard DM input window. You would put user input into a buffer, then: sc -off s/ shut /msg 'Ask your local guru to shut me down' ^ ^ | | You'd need to wildcard carefully around the 'shut' string or a DM command 'cv shutterbug.file' would get discombooberated. You'd also need to KD the dark keys on the keyboard. If your problem is that people are shutting down or turning off a disked node off which diskless nodes are booted, then you can put a pad or alarm window on the disked node when the diskless ones come up. This way, the user on the disked node knows better than to shut down or switch off. Another option (something I've done extensively when logged in via an SIO line) is to pop up an alarm window when a user on the diskless node (or SIO line) first logs in, then pop a second when s/he logs out. Remember, you might have to crp and start the alarm_server first if you use that method. ...lori From apollo-request@umix.cc.umich.edu Thu Dec 21 21:17:34 1989 Date: 21 Dec 89 22:00:01 GMT From: robinb%merlin%bruce%munnari.oz.au%samsung%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Robin Brown) Organization: none Subject: Re: changing environments? Message-Id: <1362@merlin.bhpmrl.oz> References: <3732@mace.cc.purdue.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >From article <3732@mace.cc.purdue.edu>, by ajk@mace.cc.purdue.edu (Jeff Boerio): > > Hello, I would like to know if someone could tell me how to change > environments from System V to BSD on a DN3500. I much prefer using BSD > over System V, and can't find the info I need. > Just type "ver bsd4.3" to change from sys5.3 to bsd4.3 and "ver sys5.3" to do the reverse. Typing "ver" by itself displays the current version. Robin From apollo-request@umix.cc.umich.edu Fri Dec 22 05:51:16 1989 Date: 21 Dec 89 16:11:56 GMT From: awhitton%bcara2%bnrgate.uucp@uunet.uu.net (Alan Whitton @ BNR) Subject: DNS under SR10.2 Works ?! Message-Id: <300@bnrgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Well it looks like Apollo has fixed DNS under SR10.2. We have been able to get our Apollos to connect to our Primary DNS server and in the words of NASA "... we have resolution...". Apollo has republished it's "Configuring and Managing a TCP/IP Network" (part 008543-A02) and it is more usable than before BUT it is still quite confusing and there is a lot of contradicting information in it, so be warned. Is there interest in how this is done, if so I will post a "how to" article. Be Seeing You, Alan Whitton -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "These is my thoughts ONLY" Alan Whitton awhitton@bnr.ca OR Bell Northern Research awhitton%bnr.ca@cunyvm.cuny.edu "I am not a number, I am a Free Man!" From apollo-request@umix.cc.umich.edu Fri Dec 22 06:12:19 1989 Date: 21 Dec 89 16:35:55 GMT From: richi%hpopd%hpsqf%hpcuhb%hpda.uucp@ucbvax.Berkeley.EDU (Richard Jennings) Organization: HP PWD, Pinewood UK. Subject: Re: live video for Apollo ? Message-Id: <7950001@hpopd.HP.COM> References: <5207.2588d12b@vtt.vtt.fi> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I'm not an expert in Apollo hardware (OK, so I know next-to-nowt), but I remember that (some?) Apollo machines have AT busses. This may allow you to use PC video-in-windows cards that don't mind higher frame rates that that generally experienced in a PC (eg. VGA). A good choice might be the DVA-4000/ISA board produced by VideoLogic. It is aimed at DOS machines, but they might well be helpful in telling you how to drive the board from a different platform (ie. Apollo). VideoLogic Ltd. Home Park Estate Kings Langley Hertfordshire WD4 8LZ Tel (intn): +44 9277 60511 Fax (intn): +44 9277 68969 Telex: 917310 VL-G Good luck, richi. Disclaimer: this posting is on behalf of myself, as an individual, and does not necessarily contain or represent opinions of my employers. From apollo-request@umix.cc.umich.edu Fri Dec 22 13:23:18 1989 Date: 22 Dec 89 14:09:00 GMT From: oj%apollo%hp-sdd%ucsdhub.uucp@ucsd.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: SR10.1.p ruptime does not display load averages Message-Id: <479420d1.20b6d@apollo.HP.COM> References: <604@nikhefh.nikhef.nl>, <2266@cs-spool.calgary.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >In article <604@nikhefh.nikhef.nl> e07@nikhefh.nikhef.nl (Eric Wassenaar) writes: >>The ruptime command does not display load averages... For what it's worth, the sr10.2.p xload command seems to work, which probably means that the load-average bug got some attention... /oj From apollo-request@umix.cc.umich.edu Fri Dec 22 13:23:35 1989 Date: 22 Dec 89 14:24:00 GMT From: oj%apollo%hp-sdd%ucsdhub.uucp@ucsd.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: How to control screenblank time? Message-Id: <47942d8f.20b6d@apollo.HP.COM> References: <19844@siemens.siemens.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <19844@siemens.siemens.com> samaddar@demon.siemens.com (Sumitro Samaddar) writes: >How can I set the time period of inactivity that blanks the screen? scrto in /usr/apollo/bin From apollo-request@umix.cc.umich.edu Fri Dec 22 13:28:02 1989 Date: 22 Dec 89 14:21:00 GMT From: oj%apollo%hp-sdd%ucsdhub.uucp@ucsd.edu (Ellis Oliver Jones) Organization: Apollo Computer, Chelmsford, MA Subject: Re: How can a script determine machine type & OS? Message-Id: <47942aec.20b6d@apollo.HP.COM> References: <11360003@hp-lsd.COS.HP.COM>, <1361@merlin.bhpmrl.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Nobody has mentioned the environment variables set up automatically in Domain/OS processes: SYSTYPE=bsd4.3 ISP=m68k TERM=apollo_1280_bw NODETYPE=DN4000 NODEID=14E4F SYSTYPE, ISP, and NODETYPE can tell you a lot about what kind of machine you're running on. Avoid depending on TERM, because a lot of the newer display devices just use the value "apollo." Beware if you hardcode dependencies on NODETYPE -- sometimes beta and early bird versions of new hardware have strange nodetype values like "DNEXYZ" (which later became "DN2500"). /oj (speaking for myself, not necessarily for HP Apollo Systems Division) From apollo-request@umix.cc.umich.edu Fri Dec 22 13:31:18 1989 Message-Id: <8912221816.AA08358@umix.cc.umich.edu> Date: 22 Dec 89 11:54:00 CST From: "DAVE ERSTAD" Subject: Re: Shutdown question To: "apollo" While I emphasize with the desire to limit the shutdown command, there's kind of a limit to how far you can go with the power switch and reset button in plain view. If the user wants the node shut down, it'll get shut down... I think a lot has to do with the way the user base perceives the Apollos (i.e. as "real computers" or "personal computers".) Around here, we have about 60 networked Apollos, and probably more Macs in several smaller networks. The Apollos are "real computers" and we have no problems with users shutting them down. The Macs are "personal computers" and get turned on and off left and right, even though there is file sharing, etc. occuring on those systems as well (abeit not as much). Dave Erstad DERSTAD@cim-vax.honeywell.com From apollo-request@umix.cc.umich.edu Fri Dec 22 17:17:57 1989 Date: 22 Dec 89 18:47:42 GMT From: majka%ubc-cs.uucp@beaver.cs.washington.edu (Marc Majka) Organization: UBC Department of Computer Science, Vancouver, B.C., Canada Subject: DN10000 NFS problem Message-Id: <6085@ubc-cs.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I've just installed NFS 2.1.p (beta) on a DN10000. When I try to mount anything, I get the message: WARNING: MOUNT TABLE CONTAINS NULLS AFTER MODIFICATION I've tried rebooting, and have fiddled with /etc/mtab, but to no avail. Also, I can't mount anything from the DN10000. I get the message: server not responding: RPC: Remote system error portmap, nfsd, and mountd are all running. Any ideas would be very much appreciated! Apollo is not supporting my beta installation, but without NFS, my DN10000 remains pretty useless to most of my users. If anyone out there has installed NFS 2.1.p beta and got it working, I'd like to hear from you! --- Marc Majka - System Manager UBC Computer Science From apollo-request@umix.cc.umich.edu Fri Dec 22 17:43:26 1989 Message-Id: <8912221908.AA09449@umix.cc.umich.edu> Date: Fri, 22 Dec 89 13:52:14 EST From: Scott Ferguson Subject: Concurrent execution of piped output/input To: APOLLO@UMIX.CC.UMICH.EDU In the past, I learned that since Aegis shells ran "inprocess", you couldn't multitask/concurrently run processes by piping output of one into input of another. For example, you have a front-end program with a user interface that formats commands for a package with a command line-based input language. You'd do this: % front_end : big_program I found from the vast knowledge base known as apollo@umix.cc.umich.edu that UNIX DOES allow this by spawning a process for each program in the pipeline. Well, I tried the same tactic with a twist, and am having trouble. Let's say, you'd like to pipe standard output of one program into input of a program on a remote, non-Apollo machine, say an Ardent. I figured that you just say: % front_end : rsh remotehost 'big_program' When I do this, however, the stdout of the front-end doesn't reach stdin in the remote shell until the front-end exits, just like an Aegis shell would. Why would an rsh run in-process, or is it something else? Of course, I chose to do this because mbx_$ system calls are not part of UNIX, and my Ardent is UNIX. Now, you're asking, why not use NCS, SYS5 Streams, or other IPC implementation? Because I'm stuck at 9.7, and may be stuck there for some time. I hesitate to get too deeply involved in things that have a large number of problems fixed at sr10. Thanks for any advice, and Happy Holidays. Scott Ferguson srfergu@erenj.bitnet "That's no fuzzy dufflebag, that's my daughter, Fuzzy-Mae" From apollo-request@umix.cc.umich.edu Fri Dec 22 17:47:33 1989 Date: 22 Dec 89 21:01:20 GMT From: sl11%prism%mephisto%usenet.ins.cwru.edu.uucp@tut.cis.ohio-state.edu (LIEBESKIND,SUSAN H) Organization: Georgia Institute of Technology Subject: Can we run Domain/X11 Version 1.0 without TCP/IP Message-Id: <4493@hydra.gatech.EDU> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We need to install Domain/X11 on a Apollo 4000 running SR 9.7. We do not have TCP/IP running on our system currently. We want to run the server, client and display all on the same workstation. In the *SR10.x* documentation, it says we can run the server using UDS (Unix Domain Sockets) if TCP is not working correctly. However, we are running on the earlier OS, and on the earlier version of Domain/X11 as well. Is this a valid alternative for Domain/X11 1.0 under SR 9.7? Thanks in advance for any help. Susan Liebeskind -- LIEBESKIND,SUSAN H Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!sl11 Internet: sl11@prism.gatech.edu From apollo-request@umix.cc.umich.edu Fri Dec 22 23:41:08 1989 Date: 22 Dec 89 19:28:37 GMT From: danny%idacom%ncc%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Danny Wilson) Organization: IDACOM Electronics Ltd. Subject: rlogin locks up Message-Id: <1989Dec22.192837.22198@idacom.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu After installing SR10.1 we are experiencing strange problems with rlogin locking up. This problem only happens if you rlogin 'two deep', which means in our case: apollo1 --rlogin-> sun1 --rlogin-> sun2 If you do this, after the rlogin to 'sun2', no characters are echoed on the original apollo. Keystrokes are properly passed to 'sun2' and commands can be executed if you terminate the command with a LINEFEED instead of a CR. When you press LF, the command is echoed 'in toto' and the output from the command is visible. This problem does not happen with: sun0 --rlogin-> sun1 --rlogin-> sun2 or, apollo0 --rlogin-> apollo1 --rlogin-> apollo2 Anyone know what is is going on?? PH (Possible Hint) #1 When you rlogin to 'sun1' first a '!' character is printed; a second later, the login message from the Sun is printed. This does not happen in any other circumstance PH#2 After connected to sun2, 'stty sane', 'reset' or 'tset' commands do not fix the problem any. -- Danny Wilson danny@idacom.uucp IDACOM Electronics alberta!idacom!danny Edmonton, Alberta X.400 danny@idacom.cs.ubc.cdn C A N A D A Voice +1 403 462 4545 From apollo-request@umix.cc.umich.edu Sat Dec 23 05:10:51 1989 Date: 22 Dec 89 20:24:09 GMT From: kts%quintro%tiamat.uucp@uunet.uu.net (Kenneth T. Smelcer) Organization: Glenayre Corp. Quincy, IL Subject: DM Editor from command line? Message-Id: <1989Dec22.202409.5841@quintro.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I little while back, someone posted a program that would allow you to invoke a DM Edit pad from the command line without using the 'xdmc' command. I didn't save it then, and now I need it. Could someone send me a copy? Thanks! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Glenayre Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet From apollo-request@umix.cc.umich.edu Mon Dec 25 21:55:10 1989 Date: 25 Dec 89 18:19:35 GMT From: bshaw%vlsic2%ti-csl%pollux%texsun%newstop%sun-barr.uucp@apple.com (Bob Shaw) Organization: Texas Instruments Inc, SPDC Operations, Dallas, TX Subject: prf question Message-Id: <103574@ti-csl.csc.ti.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Question on prf -read According to the man pages on prf , one should be able to do a prf -read and look at the files in the print queue. Is my assumption correct. When I do a prf -read I get the following error.... ?(prf) problem reading print queue specified printer does not exist (US/print utility) For this example, my printer queue name is ml and I have tried several approaches such as prf -pr ml -read etc and still get the same error. My print que is on a 9.7 node. About 1/2 of my nodes are on 9.7 and the other half on 10.1 . Thanks in advance for any comments etc. Bob Shaw bshaw@hcvdl.vdl.ti.com From apollo-request@umix.cc.umich.edu Mon Dec 25 21:57:07 1989 Date: 23 Dec 89 15:37:38 GMT From: kerr%tron%umbc3%haven%aplcen.uucp@uunet.uu.net (Dave Kerr) Organization: Westinghouse Electric Corporation Subject: Re: DNS under SR10.2 Works ?! Message-Id: <471@tron.UUCP> References: <300@bnrgate.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <300@bnrgate.UUCP> awhitton@bcara2.bnr.ca (Alan Whitton @ BNR) writes: >Well it looks like Apollo has fixed DNS under SR10.2. We have >been able to get our Apollos to connect to our Primary DNS >server and in the words of NASA "... we have resolution...". > On a related topic, does anybody know if Apollo provide a version of sendmail that supports the DNS system (MX records) with SR10.2? -- Dave Kerr (301) 765-4453 kerr@tron.bwi.wec.com from an Internet site kerr@tron.UUCP from a smart uucp mailer From apollo-request@umix.cc.umich.edu Mon Dec 25 21:57:12 1989 Subject: send index To: apollo%umix.cc.umich.edu%mailrus.uucp@umix.cc.umich.edu Date: Sat, 23 Dec 89 9:36:57 CST X-Mailer: ELM [version 2.3dev PL3] Message-Id: <8912230937.AA23446@dhump.lakesys.COM> From: mort%dhump.lakesys.com%rutgers%mailrus.uucp@umix.cc.umich.edu (Mort d`Hump) send index I'm interested in any information you may have. Thanks, -- Marty Wiedmeyer mort@dhump.lakesys.COM {uunet!marque,uwvax!uwm}!lakesys!dhump!mort From apollo-request@umix.cc.umich.edu Tue Dec 26 13:12:31 1989 Date: Tue, 26 Dec 89 11:51:10 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912261651.AA04111@richter.mit.edu> To: apollo@umix.cc.umich.edu, bshaw%vlsic2%ti-csl%pollux%texsun%newstop%sun-barr.uucp@apple.com Subject: Re: prf question prf -read only works on machines running SR10.x for printers that are being controlled by the new SR10 printing software (ie. for print servers based on /sys/hardcopy/prsvr, not for print servers based on the old Sr9 /com/prsvr). The correct command format is: "prf -read ". -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Tue Dec 26 22:28:31 1989 Date: 26 Dec 89 20:17:03 GMT From: bshaw%vlsic2%ti-csl%pollux%texsun%newstop%sun-barr.uucp@apple.com (Bob Shaw) Organization: Texas Instruments Inc, SPDC Operations, Dallas, TX Subject: NFS question / comment Message-Id: <103585@ti-csl.csc.ti.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu We use NFS between Apollo,Sun and Convex. One interesting thing that happens to us is ...... We have no problems both ways from Apollo and Suns and have no problems mounting the Convex disks on the Apollo's , HOWEVER, when the Convex mounts the Apollo disks, everything comes up and works for awhile but then after x amount of time, if you try to ls or cd the mounted dir we get the following error. NFS gettr failed for server_e80b. RPC: unable to receive /tmp/apollo I/O error. I first suspected our Apollo server (node_e80b) as having something wrong , even though the Convex disks mounted on node_e80b were stable. I then picked another node and did the same test with the exact same error messages indicated above. I'm new at NFS and was just wondering is you have seen anything like this or can offer any comments . Thanks Bob Shaw Texas Instruments Dallas, Texas bshaw@hcvdl.vdl.ti.com From apollo-request@umix.cc.umich.edu Wed Dec 27 05:13:22 1989 Date: 22 Dec 89 11:13:05 GMT From: paolo%ai-vie%tuvie%mcsun.uucp@uunet.uu.net (Paolo Petta) Organization: Austrian Research Institute for Artificial Intelligence Subject: Re: news software (b/c) for Apollo SR10: we too Message-Id: <586@ai-vie.UUCP> References: <4790152b.15b4b@utopia.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <4790152b.15b4b@utopia.UUCP> barriost@utopia.UUCP (Tim Barrios) writes: > >We are in the process of converting to Domain/OS (SR10). ... >Our news software is in need of a re-configure/re-make so I want to find >out if there is a new version of news that works better on SR10. > Same is true for us - please let us know if there is a *European* distribution facility... (we are upgrading to SR10.1.? BSD4.3) thank you! -- paolo petta, paolo@ai-vie.uucp (..mcsun!tuvie!ai-vie!paolo) austrian research institute for bitnet: paolo%ai-vie.uucp@cernvax artificial intelligence outside europe: paolo%ai-vie.uucp@uunet.uu.net From apollo-request@umix.cc.umich.edu Wed Dec 27 23:13:41 1989 Date: 27 Dec 89 23:03:46 GMT From: danny%idacom%ncc%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Danny Wilson) Organization: IDACOM Electronics Ltd. Subject: X-Windows System Message-Id: <1989Dec27.230346.7847@idacom.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am trying to get X up under SR10.1 and I have the distribution tape from ADUS. (X11R1) I had used this tape a long time ago (SR9.6) to try out X and everything worked fine (although a little slowly). However, now when I restore the tape, there are a total of 164 files that seemed to have disappeared! After the restore, there are only links to the actual files: eg. under the 'include' directory - $ ld -lt -ent Xlib.h Xlib.h "X.V11R1/include/Xlib.h" This makes it impossible to compile under SR10 unless I get the missing files. Questions: 1. Is there a more recent (and free) version of X around that I should be using instead or 'R1' ?? Where do I get it from? 2. I am _possitive_ that those files were fine under SR9.6. Where did they go? Did they spontaneously turn into links to themselves or is this a feature of SR10? Many Thanks -- Danny Wilson danny@idacom.uucp IDACOM Electronics alberta!idacom!danny Edmonton, Alberta X.400 danny@idacom.cs.ubc.cdn C A N A D A Voice +1 403 462 4545 From apollo-request@umix.cc.umich.edu Wed Dec 27 23:15:37 1989 Date: 27 Dec 89 22:55:48 GMT From: danny%idacom%ncc%alberta%ubc-cs.uucp@beaver.cs.washington.edu (Danny Wilson) Organization: IDACOM Electronics Ltd. Subject: rlogin locks up Message-Id: <1989Dec27.225548.7746@idacom.uucp> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu After installing SR10.1 we are experiencing strange problems with rlogin locking up. This problem only happens if you rlogin 'two deep', which means in our case: apollo1 --rlogin-> sun1 --rlogin-> sun2 If you do this, after the rlogin to 'sun2', no characters are echoed on the original apollo. Keystrokes are properly passed to 'sun2' and commands can be executed if you terminate the command with a LINEFEED instead of a CR. When you press LF, the command is echoed 'in toto' and the output from the command is visible. This problem does not happen with: sun0 --rlogin-> sun1 --rlogin-> sun2 or, apollo0 --rlogin-> apollo1 --rlogin-> apollo2 Anyone know what is is going on?? PH (Possible Hint) #1 When you rlogin to 'sun1' first a '!' character is printed; a second later, the login message from the Sun is printed. This does not happen in any other circumstance PH#2 After connected to sun2, 'stty sane', 'reset' or 'tset' commands do not fix the problem. -- Danny Wilson danny@idacom.uucp IDACOM Electronics alberta!idacom!danny Edmonton, Alberta X.400 danny@idacom.cs.ubc.cdn C A N A D A Voice +1 403 462 4545 From apollo-request@umix.cc.umich.edu Thu Dec 28 03:12:08 1989 Date: 27 Dec 89 23:30:15 GMT From: rwl%apcipdx%mntgfx%sequent%tektronix%zephyr.ens.tek.com.uucp@uunet.uu.net (Rob Lucke) Organization: se Subject: CNEWS for SR10.X Message-Id: <1989Dec27.233015.2359@apcipdx> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Tim, I am successfully using CNEWS version 2.11 (with patches) on the BSD side of my SR10.2 node. It works fine. Sorry about the post, I have *not* gotten pathalias installed yet, so my mailer cannot find you. -- Rob Lucke (503)682-8288\ / hpupora!apcipdx!rwl \ / Hewlett-Packard (sales) \/tektronix!mntgfx!apcipdx!rwl\/ Memory fault. 9255 S.W. Pioneer Court /\ or /\ Core Dumped. Wilsonville, OR 97070 / \ apcipdx!rwl@apollo.com / \ You have new mail. From apollo-request@umix.cc.umich.edu Thu Dec 28 21:16:52 1989 From: David B Funk Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-Id: <8912290058.AA00991@icaen.uiowa.edu> Date: Thu, 28 Dec 89 18:40:26 CST Subject: Re: DNS under SR10.2 Works ?! To: apollo@umix.cc.umich.edu In article <300@bnrgate.UUCP> awhitton@bcara2.bnr.ca (Alan Whitton @ BNR) writes: >Well it looks like Apollo has fixed DNS under SR10.2. We have >been able to get our Apollos to connect to our Primary DNS >server and in the words of NASA "... we have resolution...". > Well actually the DNS (/etc/named) shipped with sr10.1 wasn't brain-dead, it was just senile. For some reason Apollo shipped named v4.4 with sr10.1 which is an obsolete version. At sr10.2 they've shipped named v4.8 which is a more current version. I ported named v4.8 to sr9.7 2 years ago, and I'm glad to see Apollo now supporting it. In article <471@tron.UUCP> kerr%tron%umbc3%haven%aplcen.uucp@uunet.uu.net (Dave Kerr) asks: > On a related topic, does anybody know if Apollo provide a version > of sendmail that supports the DNS system (MX records) with SR10.2? > -- The sendmail that's in the sr10.2 release is version 5.52, which does NOT support MX records. You need sendmail v5.59 or newer for that functionality. I tried to port v5.59 under sr9.7 but found it too hard. I didn't try under sr10.1 but it should be do-able under sr10.2. Note that the Apollo supplied sendmail includes some added functionality, including support for the rgyd "subscriber directory" mailer, and a patch to fix the "debug loop-hole" that was one of the "internet worm" attack points. Hopefully Apollo will soon provide a current version of sendmail (v5.59 or newer). Dave Funk From apollo-request@umix.cc.umich.edu Fri Dec 29 03:19:37 1989 Date: 29 Dec 89 01:02:44 GMT From: robinb%merlin%bruce%munnari.oz.au%samsung%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Robin Brown) Organization: none Subject: Monitoring memory use Message-Id: <1363@merlin.bhpmrl.oz> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Does anybody know how to monitor memory use on an apollo DN4500 running sr10.1, we just upgraded to 16 Meg and would like to know if it is being utilized by the application. Thanks in advance, Robin From apollo-request@umix.cc.umich.edu Fri Dec 29 03:20:16 1989 Date: 29 Dec 89 07:11:54 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: NFS under 10.2p Message-Id: <6914@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I am running 10.1p on my DN10000, and NFS has been working without any problems. When I migrate to 10.2p, will my present version of NFS continue to work, or will I have to update NFS as well? If NFS has to be replaced, does anybody have any experience with the reliability of the version that goes with 10.2? From apollo-request@umix.cc.umich.edu Fri Dec 29 11:14:46 1989 Date: Fri, 29 Dec 89 09:18:37 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912291418.AA07159@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: beta-test sites wanted I am preparing an SR10 print server for the Shinko CHC-series color printers (sold by Mitsubishi International and the Instant Apollo catalog). The preliminary version will be ready in about two weeks, and I'm looking for sites that would be willing to test the software and give me feedback as to bugs, features, documentation, etc. If you would be interested in testing the software please send me your email address, US mail address, whether you need floppy or cartridge tape, whether you need M68020/68030 or DN10K version, and your printer model. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Dec 29 17:13:51 1989 Date: 29 Dec 89 18:56:00 GMT From: pcc%apollo.hp.com%apollo%hp-sdd.uucp@hplabs.hp.com (Peter Craine) Organization: Hewlett-Packard Chelmsford Response Center Subject: Re: NFS under 10.2p Message-Id: <47b8550c.20b6d@apollo.HP.COM> References: <6914@tank.uchicago.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <6914@tank.uchicago.edu>, rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) writes: > > I am running 10.1p on my DN10000, and NFS has been working without any > problems. When I migrate to 10.2p, will my present version of NFS > continue to work, or will I have to update NFS as well? You will need to install NFS V2.1.p (if it's not yet available, it will be very soon). NFS V2.0.p WON'T WORK on SR10.1.p. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter Craine + "Sometimes you have to slap them in the face Hewlett-Packard + to get their attention." Chelmsford Response Center + *I* don't want my opinions. Why would HP? From apollo-request@umix.cc.umich.edu Fri Dec 29 17:14:26 1989 Date: Fri, 29 Dec 89 16:57:26 EST From: krowitz%richter@umix.cc.umich.edu (David Krowitz) Message-Id: <8912292157.AA07552@richter.mit.edu> To: apollo@umix.cc.umich.edu Subject: mailing address for Barbara Poppe Does anyone have a current, working, email address for Barbara Poppe, the ADUS Ring editor? The one I have seems to be out of date. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference) From apollo-request@umix.cc.umich.edu Fri Dec 29 19:11:13 1989 Date: 29 Dec 89 22:41:30 GMT From: rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: NFS under 10.2p Message-Id: <6922@tank.uchicago.edu> References: <6914@tank.uchicago.edu>, <47b8550c.20b6d@apollo.HP.COM> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Jeez, so SR10.2 breaks NFS! There goes my plans for upgrading to 10.2. I think I'll just wait and sit this one out for a while. Sure, I could order the new NFS, and maybe it would work, but I'd have to cut a purchase order, get it sent out, install the new tape, and hope it works as well as what I've got now. Couldn't you have built some backward compatibility into SR10.2? What else did you break? Will my compilers still work? (c and fortran?) Will the 10.6 compiler (fortran) work under 10.1p, or would I have to upgrade to 10.2? This is all really annoying, as I keep hearing that all the things that are broken about 10.1 are fixed in 10.2. BTW, I'm not on the software subscription list for NFS, because spending $600 per year each and every year to eternity for updates to software that only cost about $100 to begin with sounds like highway robbery to me. Especially since the updates in this case (unlike SR10.2 itself, to which I am a subscriber) don't provide any additional functionality, but only fix things that should never have gotten broken in the first place. And speaking of response, why is it so hard to pry loose software out of Apollo? It took me a month just to find out what the current version of the Prism Fortran compiler is. I ordered it from so-called "instant Apollo" about a month ago, and so far, nothing. I ordered the December patch tape, to fix the awful problem with huge Fortran executables because of the bug in the crt0/compress business, but still nothing. I don't have the time to keep on peoples cases and make them do their jobs, and I'm getting royally ticked off. I wish somebody out there would do some house-cleaning. I really love the hardware in my 10000, but the whole business of the software is really driving me up a wall. I don't know that the competition is particularly better (Silicon Graphics charges relatively little for the NFS software updates, but you have to pay $600 up front, though in the long run it works out cheaper. I haven't heard anybody with any Unix box really happy with the software support anywhere). That's no excuse for shoddy organization, though. At least I have my macs, which work and are hassle free. I try to view the 10000 as a kind of humongous Mac peripheral, and deal with the beast as little as possible, except when it comes to crunching. I had hoped to change this somewhat when SR10.2 and X came up, but I think I'll just forget it. From apollo-request@umix.cc.umich.edu Sat Dec 30 01:12:14 1989 Date: Fri, 29 Dec 89 22:46:22 EST From: GELINASJ%CMR001.bitnet@ugw.utcs.utoronto.ca To: apollo@umix.cc.umich.EDU Message-Id: <891229.23073378.058775@CMR.CP6> Subject: joindu - Joint disk usage of similar directories This csh script can be used to list side by side the files of similar directories -perhaps on different apollo nodes- and the disk space used. It is slow and, hum..., not elegant, but helps me to keep in sync the /usr/local/bin directories on our 3 DN4000 cluster. If you want to speed it up or translate it to sh or FORTRAN, please feel free to do so. And a happy new year to all. ------------------------cut here--------------------------------- #!/bin/csh # joindu [directory list] # # Creates a joint listing of disk space used in directories # For example, # % joindu //node_[1-3]/usr/local/bin # will produce on standard output a 3 column listing # of of each directory with a TOTAL line. # onintr cleanup # Header line with date and time if (! $#argv) set argv=(".") set date=`date` echo " JOINT DISK USAGE on $date[1], $date[3] $date[2] \ $date[6], at $date[4]" >! /tmp/joindu$$.dirs # Reverse the arguments and make a list of directory names set dirs= foreach d ($*) set dirs=($d $dirs) echo \#${#dirs}: $d >>/tmp/joindu$$.dirs end # Make a sorted, unique list of all files names with 0 blocks apply ls $* | \ sort -u | \ awk '{print $1,0}' - > /tmp/joindu$$.miss # Initialise the database with a dummy void directory cp /tmp/joindu$$.miss /tmp/joindu$$.all # Join on the file names (first field) foreach d ($dirs) (cd $d; /bin/du -s *) | \ awk '{print $2,$1}' - | \ sort -m +0 -1 +1 -2 -dr - /tmp/joindu$$.miss | \ sort -um +0 -1 - | \ join - /tmp/joindu$$.all > /tmp/joindu$$.t mv /tmp/joindu$$.t /tmp/joindu$$.all end # align the output, sum the block counts (skip the last column) awk 'NR == 1 { nf=NF \ printf "\n%15s" , " " \ for( i = 1 ; i < nf-1 ; i++ ) \ printf " #%2d" , i \ } \ { printf "\n%15s" , substr( $1, 0, 15 ) \ for( i = 2 ; i < nf ; i++ ) \ { \ printf "%8d" , $i \ s[i] += $i \ } \ } \ END { printf "\n\n%15s" , "TOTAL" \ for( i = 2 ; i < nf ; i++ ) \ { \ printf "%8d" , s[i] \ } \ printf "\n" \ }' /tmp/joindu$$.all | \ cat /tmp/joindu$$.dirs - # Clean up /tmp cleanup: rm -f /tmp/joindu$$.{all,dirs,miss,t} ------------------------cut here--------------------------------- J. GELINAS (gelinasj@cmr001.bitnet) From apollo-request@umix.cc.umich.edu Sat Dec 30 17:16:03 1989 Date: 30 Dec 89 18:57:35 GMT From: bshaw%vlsic2%ti-csl%pollux%texsun%newstop%sun-barr%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Bob Shaw) Organization: Texas Instruments Inc, SPDC Operations, Dallas, TX Subject: sr10 print servers question Message-Id: <103962@ti-csl.csc.ti.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu Shortly, I will be updating my present dn3000 9.7 print server to either 10.1 or 10.2 . I have an omni TI2115 laser printer via serial port @ 19200 baud on this server. Just wondering, what kind of surprises should I expect :-) :-( . Any particular "gotchas" that I should know about ? Any comments / suggestions etc are appreciated .. Thanks in advance Bob Shaw Texas Instruments bshaw@hcvdl.vdl.ti.com From apollo-request@umix.cc.umich.edu Sat Dec 30 23:21:32 1989 Date: 30 Dec 89 19:19:39 GMT From: bshaw%vlsic2%ti-csl%pollux%texsun%newstop%sun-barr%cs.utexas.edu.uucp@tut.cis.ohio-state.edu (Bob Shaw) Organization: Texas Instruments Inc, SPDC Operations, Dallas, TX Subject: Apollo termcap .. a dumb question Message-Id: <103964@ti-csl.csc.ti.com> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu I know this may be a dumb question ... however Is there an Apollo termcap available for other systems. Here is why I'm asking .... When I rlogin from my apollo to another system (Convex for example) I would like to have the same enviornment as the Apollo. One reason is to get a full screen advantage for emacs. Of course , you can use the vt100 emulator, but you are limited to ~80x24 and cannot realize the full benefit of emacs or whatever you're running. We tried taking the "Apollo" section from /etc/termcap on the Apollo and appending it to the Convex termcap and then setenv TERM Apollo. This did "change" things but still didn't do what we thought it should. I'm sure we are missing something very simple here but ... Any comments / suggestions etc Thanks in advance bshaw@hcvdl.vdl.ti.com From apollo-request@umix.cc.umich.edu Sat Dec 30 23:42:09 1989 Date: Sat, 30 Dec 89 15:39:26 CST From: lray@civilgate.ce.uiuc.edu (Leland Ray) Message-Id: <8912302139.AA18516@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: Miscellaneous questions That reminds me to ask a few miscellaneous questions: 1. I need to read a tape written with wbak on a non-Apollo machine. I don't want to "dearchive" the tape file, I just need to use a tape drive to read it that happens to be connected to another machine. Once read, I had planned to ftp it to an Apollo, and use the -stdin option on rbak to recover the data. I hear these tapes are ANSI labelled. Could someone send me enough information that I can get the file off the tape? 2. Is SR10.2.p presently shipping? If not, is there an expected release date? 3. Do the scsi_$ routines shipped with GPIO at SR10.2 also work with the scsi port on the WD disk controller? 4. Is there a public domain device driver available for a AT bus parallel port add on (like the Apollo SPE board)? The quality of the driver Thanks for answers in advance. Just spendin' my days, Leland Ray Systems Administrator Soakin' in them cathode rays. UIUC - Dept. Civil Engineering (217) 333-3821 From apollo-request@umix.cc.umich.edu Sat Dec 30 23:59:23 1989 Date: Sat, 30 Dec 89 15:11:30 CST From: lray@civilgate.ce.uiuc.edu (Leland Ray) Message-Id: <8912302111.AA18350@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: SR10.2 and life >rtp1%tank.uucp@handies.ucar.edu (raymond thomas pierrehumbert) writes: >Jeez, so SR10.2 breaks NFS! There goes my plans for upgrading to 10.2. >I think I'll just wait and sit this one out for a while. Sure, I could >order the new NFS, and maybe it would work, but I'd have to cut a >purchase order, get it sent out, install the new tape, and hope it >works as well as what I've got now. Couldn't you have built some >backward compatibility into SR10.2? What else did you break? Will Welcome to the world of workstations, a world where the software grows and changes daily. Apollo likes to obsolete software; during the time I've worked with their machines they have changed binary formats twice, required that all disks be reformatted, and changed their install procedure quite a number of times. The amount of time I've had to spend patching and reconfiguring the system has grown. Of course, I don't really blame Apollo for that. While their software has molted, so has their hardware, so has their customer service, so has their sales, and so has their profits. They were well on their way to recovering when HP bought them. What I would do, if I had questions about the latest version of NFS (or any product, for that matter) is to find someone who has it, and get a copy of the release notes. After reading them, you can decide for yourself if the upgrade will help you. It is worthwhile to upgrade often enough so the people at the 800 number can help you. (Quiz: How many 800 number people know why an Imagen printer at SR10.1 truncates lines after 10-15 characters?) Just spendin' my days, Leland Ray Systems Administrator Soakin' in them cathode rays. UIUC - Dept. Civil Engineering (217) 333-3821 From apollo-request@umix.cc.umich.edu Sun Dec 31 00:49:31 1989 Date: 30 Dec 89 23:00:31 GMT From: rtp1%tank%ux1.cso.uiuc.edu%brutus.cs.uiuc.edu%zaphod.mps.ohio-state.edu.uucp@tut.cis. (raymond thomas pierrehumbert) Organization: University of Chicago Subject: Re: Miscellaneous questions Message-Id: <6981@tank.uchicago.edu> References: <8912302139.AA18516@civilgate.ce.uiuc.edu> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu >3. Do the scsi_$ routines shipped with GPIO at SR10.2 also work with > the scsi port on the WD disk controller? This reminds me: I have a mysterious card (other than the video card) in the AT bus of my DN10000, and I think it must be the controller for the cartridge tape. It is a SCSI controller, no? It seems to have a port on the back of it, which looks suspiciously like a SCSI connector. My question-- is this a SCSI card? Given appropriate drivers, can other SCSI devices be connected to the port? Are there SCSI disks available for this card? Other SCSI devices. I know all about Workstation Solutions, INC, but their stuff is awfully expensive, and they don't offer any educational discounts. From apollo-request@umix.cc.umich.edu Sun Dec 31 00:55:47 1989 Date: 31 Dec 89 02:38:16 GMT From: weiner%novavax%uflorida%uakari.primate.wisc.edu%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state (Bob Weiner) Organization: Motorola Inc. Subject: Query - Does anyone have g++ working well on an Apollo SR10 system? Message-Id: <1707@novavax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu If the answer is no, will SR10.2 help the situation at all? G++ is needed because of the extensive class libraries that it provides over the standard AT&T C++ distribution including the one on Apollos. Thanks for any help. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 364-2087 From apollo-request@umix.cc.umich.edu Sun Dec 31 00:59:26 1989 Date: Sat, 30 Dec 89 17:29:34 CST From: lray@civilgate.ce.uiuc.edu (Leland Ray) Message-Id: <8912302329.AA06318@civilgate.ce.uiuc.edu> To: apollo@umix.cc.umich.edu Subject: Re: Miscellaneous questions The question: 4. Is there a public domain device driver available for a AT bus parallel port add on (like the Apollo SPE board)? The quality of the driver should read: 4. Is there a public domain device driver available for a AT bus parallel port add on (like the Apollo SPE board)? The quality of the driver is not very important, as long as it compiles and runs at SR10.x. (in other words, I'll fix the bugs). From apollo-request@umix.cc.umich.edu Sun Dec 31 17:19:10 1989 Date: 31 Dec 89 21:36:54 GMT From: rfg%uci-ics%jarthur%brutus.cs.uiuc.edu%zaphod.mps.ohio-state.edu.uucp@tut.cis.ohio-state.edu (Ron Guilmette) Organization: University of California, Irvine - Dept of ICS Subject: Re: Query - Does anyone have g++ working well on an Apollo SR10 system? Message-Id: <259E7BF6.19403@paris.ics.uci.edu> References: <1707@novavax.UUCP> Sender: apollo-request@umix.cc.umich.edu To: apollo@umix.cc.umich.edu In article <1707@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes: >If the answer is no, will SR10.2 help the situation at all? G++ is >needed because of the extensive class libraries that it provides over >the standard AT&T C++ distribution including the one on Apollos. You don't necessarily need g++ to use libg++. I believe that libg++ has been (or will shortly be) Cfront-ized. That is, version 1.36.2 should (I believe) be compilable with Cfront. (Doug Lea, please correct me if I'm wrong about this). // rfg